specifications - technical - ¿Cuáles son algunos recursos para aprender a escribir especificaciones?

technical specifications

Question

En el trabajo, soy responsable de escribir las especificaciones con bastante frecuencia y, en primer lugar, soy la persona que insistió en obtener las especificaciones. El problema es que no estoy seguro de cómo deberían verse las especificaciones y qué deberían contener. Muchas veces, cuando mi jefe escribe las especificaciones (los dos somos inexpertos) ponen nombres de tablas y cosas que no creo que pertenezcan allí. Entonces, ¿cuál es una buena forma de aprender a escribir una buena especificación?

EDITAR: ¿Debería una especificación funcional incluir cosas como suponer que estoy especificando una aplicación web, los tipos de entrada (un cuadro de texto, lista desplegable, etc.)?

Answer 1

Comprar libros: Ingeniería de requisitos por Ian Sommerville y Pete Sawyer ISBN 0-471-97444-7 o Requisitos de software por Karl Wiegers ISBN 0-7356-0631-5

Answer 2

Hay un gran capítulo en el Código Completo de Steve McConnell que se ejecuta a través de documentos de especificación y lo que deberían contener.

Cuando me encomendaron la tarea de crear un equipo de Análisis de Arquitectura y Negocio en una empresa que nunca había tenido ninguno, utilicé el capítulo de especificaciones de McConnell para crear el esquema del documento de Especificaciones Técnicas. Se desarrolló con el tiempo, pero al comenzar con este marco de trabajo me aseguré de que no nos perdiéramos nada y resultó ser sorprendentemente utilizable.

Cuando escribo especificaciones, una regla práctica que sigo es intentar que los documentos técnicos siempre comiencen desde lo general y pasen a lo específico: siempre reafirme el (los) problema (s) comercial (es) o el (los) objetivo (s) que la solución técnica se está desarrollando para resolver, por lo que la persona que lee la especificación no necesita ir a otros documentos para ponerlo en cualquier tipo de contexto.

Answer 3

Lo importante es escribir algo en lugar de preocuparse por el formato.

Answer 4

Vea las especificaciones funcionales sin dolor de Joel Spolsky.

Algunas de las cosas que él dice que deben tener todas las especificaciones:

• Un descargo de responsabilidad
• Un autor. Un autor
• Escenarios
• No objetivos
• Una visión general
• Detalles, detalles, detalles
• Problemas abiertos
• Notas laterales

Answer 5

La parte más importante de la documentación de desarrollo, en mi opinión, es hacer que la persona correcta lo haga.

• Documentos de requisitos: usuarios + analista de negocios
• Functional Spec - Business Analyst + desarrollador
• Especificaciones técnicas (cómo se implementará realmente la funcionalidad) - Sr. Desarrollador / Arquitecto
• Estimaciones de tiempo para propósitos de programación: el desarrollador específico asignado a la tarea

Tener a alguien además del Sr. Desarrollador / Arquitecto definir estructuras de tablas / interfaces, etc. es un ejercicio inútil, ya que el desarrollador más experimentado generalmente arrojará la mayor parte.

Wikipedia es en realidad un buen comienzo para la especificación funcional, que parece similar a su especificación - http://en.wikipedia.org/wiki/Functional_specification .