Cómo hacer una gran especificación funcional

Voy a comenzar un pequeño proyecto paralelo muy pronto, pero esta vez quiero no solo el pequeño modelo de dominio UML y los diagramas de casos que suelo hacer antes de programar, pensé en hacer una especificación funcional completa. ¿Hay alguien que tenga experiencia en escribir especificaciones funcionales que pueda recomendarme lo que necesito agregar? ¿Cuál sería la mejor manera de comenzar a prepararlo? Aquí escribiré los temas que considero más relevantes:

• Propósito
• Resumen funcional
• Diagrama contextual
• Factores críticos del éxito del proyecto
• Alcance (dentro y fuera)
• Supuestos
• Actores (fuentes de datos, actores del sistema)
• Use el diagrama del caso
• Diagrama de flujo del proceso
• Diagrama de actividad
• Requerimientos de seguridad
• Requisitos de desempeño
• Requisitos especiales
• Reglas del negocio
• Modelo de dominio (modelo de datos)
• Escenarios de flujo (éxito, alternativo ...)
• Horario (gestión de tareas)
• Metas
• Requisitos del sistema
• Gastos esperados

¿Qué opinas sobre esos temas? ¿Debo agregar algo más? o tal vez eliminar algo?

Utilicé todas las respuestas y me gustaría agradecerles a todos por la información útil.

Estoy haciendo este proyecto paralelo para una empresa, y ellos esperan de mí un flujo constante de comunicación y tendré que explicar por qué hago cada cosa, porque tendré que administrar los recursos que me darán. Esta será mi primera especificación de func y, como dije, quiero que sea útil, no solo grande e inútil. Creo que esto es algo que hay que hacer, pero quiero hacerlo de la manera que sea más útil para mí y mi equipo. Es malo que no tengamos un gerente, por eso también necesito ocuparme de algunas tareas administrativas ...

En cuanto a la programación ágil, creo que es 100% compatible con el enfoque ágil. Soy un programador ágil y sinceramente me sentí más seguro cuando alguien ya pensaba por mí. Todavía era Junnior, pero trabajé antes como desarrollador web de Tapestry en otros proyectos, donde la organización era un caos total.

No estoy de acuerdo con que estoy haciendo un enfoque en cascada, creo que solo estoy tratando de definir algunos límites que harán que el proyecto sea más fácil cuando comience el desarrollo.

Lo que sugiere está bien desde el punto de vista de los puristas de Ingeniería de Sistemas.

(Habrá algunos devotos Ágiles que piensen que está por encima de la cima ... y solo debes salir y hacer cosas con las críticas habituales, etc.).

Sin embargo, debe tener en cuenta lo que está haciendo y para quién lo está haciendo.

Hacer un proyecto por ti mismo es diferente a hacerlo por alguien más, por dinero.

Cuando trabajas para otra persona (ya sea en una empresa o por contrato), los ÚNICOS medios de comunicación son hablar y escribir. (En última instancia, habrá un producto o resultado que puede evaluarse).

El objetivo de una especificación es intentar reducir el costo de hacer arreglos y cambios que vendrán después. Es posible que haya visto los gráficos que muestran el costo de hacer arreglos en diferentes etapas de un proyecto, es algo así:

• Una solución hecha a una idea tonta cuesta $ 1

• Una solución hecha cuando la idea tonta se convirtió en una especificación (que tiene que actualizarse) cuesta $ 10

• Una solución hecha cuando ha construido un prototipo cuesta $ 100

• Se corrigió el tiempo que está haciendo una aceptación antes del envío cuesta $ 1000

• Una solución hecha después de que haya enviado y cabreado a sus clientes cuesta $ 10000.

Entonces, lo que escribes en una especificación es bastante importante.

Argumentar que no debe tener ninguna especificación es ingenuo, tonto y probablemente peligroso.

Uno de los mayores problemas que tiene al escribir una especificación es saber cuándo ha ido demasiado lejos. Esto varía según el tamaño del proyecto. Por ejemplo, un proyecto que demore entre 1 y 2 personas alrededor de un año debería tener entre 2 y 4 SEMANAS en total gastado en especificaciones ... que incluye la investigación de factibilidad ... la especificación que deben escribir las personas que realmente lo hacen el trabajo no es un tipo de analista de alto nivel de falutina que no conoce los detalles sangrientos Un proyecto que lleva 10 personas 2 años necesita mucho más tiempo.

Ahora para algunos comentarios sobre sus diversos puntos:

• Propósito

SÍ, escribe esto. Manténgalo en 1-2 párrafos, 1/2 página máx.

• Resumen funcional

TAL VEZ. Solo si agrega valor a todo lo demás.

• Diagrama contextual

ESENCIAL. Muestra TODAS las entradas y salidas. Muestra contexto. Puede (y debe) dedicar una cantidad de tiempo razonable a esto.

• Factores críticos del éxito del proyecto

TAL VEZ. Seguramente si el proyecto cumple con los requisitos es un éxito. Creo que esto no es realmente necesario.

• Alcance (dentro y fuera)

NO. Su diagrama de contexto hace esto.

• Supuestos

SI. Intenta que sea breve.

• Actores (fuentes de datos, actores del sistema)

TAL VEZ. Esto suena como pedazos sangrientos técnicos de diseño para mí que no deberían estar en una especificación FUNCIONAL.

• Use el diagrama del caso

TAL VEZ. Ponga esto (estos) en un apéndice. Explicar con palabras. Trate de mantener estos en un pequeño número. He visto sugerencias de que un proyecto no debe tener más de 8 casos de uso explicados en detalle. No cubras todos los caminos "infelices" o nunca terminarás.

Es muy raro que cualquier pieza de s / w tenga un solo Caso de uso / Diagrama de caso de uso.

• Diagrama de flujo del proceso

TAL VEZ. Solo si agrega un valor significativo, de lo contrario está perdiendo el tiempo.

• Diagrama de actividad

TAL VEZ. Solo si agrega un valor significativo, de lo contrario está perdiendo el tiempo.

• Requerimientos de seguridad

SÍ, si corresponde.

• Requisitos de desempeño

SÍ - obligatorio. Debo decir qué debe hacer la cosa (y con qué nivel de rendimiento).

• Requisitos especiales

QUIZÁS - si hay algo especial.

• Reglas del negocio

QUIZÁS - si es útil.

• Modelo de dominio (modelo de datos)

QUIZÁS - si es útil.

• Escenarios de flujo (éxito, alternativo ...)

QUIZÁS - si es útil.

• Horario (gestión de tareas)

NO. Esto no es lo que debería estar en una especificación. Se trata de horarios, planificación, etc.

• Metas

TAL VEZ. Los objetivos no son requisitos, son cosas vagas, esponjosas, que no serían buenas, que sirven para enturbiar las aguas. Intenta y evita.

• Requisitos del sistema

SI. Esencial. Dice lo que debe hacer la cosa.

• Gastos esperados

NO. Parte de la planificación y gestión, no los requisitos de lo que está haciendo.

Explicación: Llevo más de 15 años escribiendo especificaciones para productos, software y sistemas complejos. Todas las cosas comerciales. Principalmente comercialmente exitoso e hizo mucho dinero para varios empleadores. Incluyendo la especificación para el desarrollo Agile s / w donde todavía necesita una especificación antes de saltar al desarrollo. El desarrollo REAL puede hacerse en cualquier proceso que desee, pero al final debe tener 3 cosas para tener éxito:

1. Sepa lo que quiere hacer. Y ESCRIBIRLO ABAJO. (Eso es una especificación)

2. Haz cosas para cumplir con el n. ° 1 anterior.

3. Haga un nivel de prueba de aceptación de la cosa contra la especificación (que es esencialmente "¿hizo lo que dijo que haría").

Hay tres cosas a tener en cuenta

1) Tienes que comenzar en alguna parte

¿Has identificado cuál es el problema que este proyecto está tratando de resolver? También podría comenzar diciendo "Estas son las cosas que este proyecto no estaría completo si no pudiera hacer". También he visto algunos proyectos (algunos exitosos, otros no tanto) diseñan la pantalla principal y llenan los espacios en blanco desde allí.

2) Tienes que terminar en algún lado

Puedes especificar las cosas al infierno, pero si nunca haces nada, todo lo que has hecho es perder mucho tiempo y papel e ignorar a tu esposa e hijos durante siete semanas. (¿Has hecho eso, alguien?) Así que asegúrate de establecer algunos límites sobre cuán lejos llegarán tus especificaciones. ¿Es una especificación técnica así como una especificación funcional?

3) Tienes que ir de principio a fin

No comience por obtener un requisito principal y luego complete todos los detalles al respecto antes de obtener el segundo requisito principal, al menos en el esquema. Construya su especificación horizontalmente primero, luego verticalmente. De lo contrario, cuando se dé cuenta de algunos detalles menores del requisito uno, imposibilita todos los requisitos dos, tendrá algunos problemas importantes.

Dividiría su lista en tres partes: las cosas que les interesan a los usuarios, las cosas que les interesan a los programadores y las cosas que les interesan a los gerentes. Deje que un programador haga su parte y que un gerente haga su parte. El programador probablemente necesitará proporcionar estimaciones para partes del proyecto al gerente y al gerente para proporcionar las restricciones presupuestarias al programador (es decir, no puede tomar más de X semanas). Si todos (cliente, gerente, programador) están de acuerdo, entonces es una luz verde y comenzará el proyecto. Para el programador, muchas personas carecen de especificaciones, a veces con razón. Solo especificaría las partes donde se comunican dos o más partes (por ejemplo, cliente-servidor). Por lo demás, solo practique alguna forma de TDD basada en historias de usuarios. Una línea para el cliente también es beneficiosa para obtener historias.

Historias del usuario

• Propósito Objetivos Descripción funcional
• Actores (fuentes de datos, actores del sistema)
• Use el diagrama del caso
• Diagrama de flujo del proceso
• Diagrama de actividad
• Diagrama contextual
• Reglas del negocio
• Requisitos especiales
• Requisitos de desempeño

Gerente

• Factores críticos del éxito del proyecto
• Gastos esperados
• Escenarios de flujo (éxito, alternativo ...)
• Horario (gestión de tareas)

Programador

• Requerimientos de seguridad
• Modelo de dominio (modelo de datos)
• Requisitos del sistema

Además, probablemente no haya una receta perfecta para todo tipo de problemas de software. Para una aplicación de Facebook, es probable que desee hacer una demostración temprana y frecuente. Para un sistema de guía de misiles, probablemente no tanto ;-)

¡Preparar todos estos documentos puede llevar meses! Parece una especie de cascada para mí.

No puedo sugerir agregar nada más a su lista a menos que saque algunos de ella. Supongo que los artefactos que se producirán dependerán de la cultura dentro de su organización y del conjunto de habilidades de los desarrolladores.

No hay una mejor especificación funcional que un prototipo funcional pero fugitivo, precisamente debido a los problemas con un enfoque en cascada.