Escribir una especificación de requisitos de software

Tengo algunas preguntas sobre cómo escribir una especificación y son:

1. Cuando escribimos una especificación de software, bajo el tema "Definición de requisitos de usuario", ¿tenemos que especificar únicamente las "Funciones" y "Restricciones"?

2. ¿La "interfaz de usuario" cae en "funciones" o "restricciones"?

3. ¿Cuáles son las principales áreas clave (requisitos) en las que se puede dividir un software (p. Ej., IU)?

Si bien no soy un gran fanático de reunir todos los requisitos en detalle por adelantado (ya que están sujetos a muchos cambios en el transcurso de un proyecto no trivial), si está escribiendo documentos de requisitos, la plantilla de especificaciones de requisitos de Volere es una guía excelente .

Si bien puede ser excesivo para algunos proyectos, proporciona una excelente lista de cosas en las que pensar, incluso si es solo para marcar mentalmente la lista de que no necesita ese elemento para este requisito.

Aquí hay un enlace para obtener más información sobre la plantilla:

http://www.volere.co.uk/template.htm

La plantilla en sí (y el libro Dominar el proceso de requisitos , que en realidad es un poco menos costoso que la plantilla y contiene el texto completo de la plantilla) contiene una gran cantidad de información, ejemplos y consejos dentro de las distintas secciones sobre lo que debe ir en cada sección.

Aquí hay un resumen de las secciones (citadas en el enlace anterior):

1. El Propósito del Proyecto

2. Las partes interesadas

3. Restricciones obligatorias

4. Convenciones de nomenclatura y definiciones

5. Hechos y suposiciones relevantes

6. El alcance del trabajo

7. Modelo de datos comerciales y diccionario de datos

8. El alcance del producto

9. Requisitos funcionales y de datos

10. Requisitos de apariencia

11. Requisitos de usabilidad y humanidad

12. Requisitos de desempeño

13. Requisitos operacionales y ambientales

14. Requisitos de mantenimiento y soporte

15. Requerimientos de seguridad

16. Requisitos culturales y políticos

17. Requerimientos legales

18. Problemas abiertos

19. Soluciones listas para usar

20. Nuevos problemas

21. Tareas

22. Migración al nuevo producto

23. Riesgos

24. Costos

25. Documentación y capacitación del usuario

26. Sala de espera

27. Ideas para soluciones

Recomiendo leer Joel en software. No estoy seguro de si responde a sus preguntas específicas, pero tiene una excelente visión general de lo que significa escribir especificaciones funcionales :

La función más importante de una especificación es diseñar el programa . Incluso si está trabajando en el código usted mismo, y escribe una especificación únicamente para su propio beneficio, el acto de escribir la especificación, que describe cómo funciona el programa en minucioso detalle, lo obligará a diseñar el programa ...

... cuando diseña su producto en un lenguaje humano, solo toma unos minutos intentar pensar en varias posibilidades, revisar y mejorar su diseño. Nadie se siente mal cuando elimina un párrafo en un procesador de textos. Pero cuando diseñas tu producto en un lenguaje de programación, lleva semanas hacer diseños iterativos. Lo que es peor, un programador que acaba de pasar 2 semanas escribiendo un código va a estar bastante conectado a ese código, no importa cuán incorrecto sea ...

... Cuando escribe una especificación, solo tiene que comunicar cómo debe funcionar el programa una vez . Todos en el equipo pueden leer las especificaciones. Las personas de control de calidad lo leen para que sepan cómo se supone que funciona el programa y sepan qué evaluar. La gente de marketing lo usa para escribir sus vagos documentos de vaporware para arrojar en el sitio web sobre productos que aún no se han creado. La gente de desarrollo de negocios lo leyó mal para crear fantasías extrañas sobre cómo el producto curará la calvicie y las verrugas y esas cosas, pero atrae a los inversores, así que está bien. Los desarrolladores lo leen para saber qué código escribir. Los clientes lo leen para asegurarse de que los desarrolladores están creando un producto que les gustaría pagar. Los escritores técnicos lo leen y escriben un buen manual ...

Cuando no tiene una especificación, toda esta comunicación todavía ocurre, porque tiene que hacerlo , pero sucede ad hoc . La gente de control de calidad pierde el tiempo con el programa de manera involuntaria, y cuando algo parece extraño, van e interrumpen a los programadores una vez más para hacerles otra pregunta estúpida sobre cómo se supone que funciona la cosa ...

sin una especificación detallada, es imposible hacer un cronograma ... En muchas organizaciones de programación, cada vez que hay un debate de diseño, nadie logra tomar una decisión, generalmente por razones políticas. Entonces los programadores solo trabajan en cosas no controvertidas. A medida que pasa el tiempo, todas las decisiones difíciles se llevan al final ... Escribir una especificación es una excelente manera de concretar todas esas decisiones de diseño irritantes, grandes y pequeñas, que quedan cubiertas si no tienes una especificación. ..

Cuando escribimos una especificación de software, bajo el tema "Definición de requisitos de usuario", ¿tenemos que especificar únicamente las "Funciones" y "Restricciones"?

Un requisito es una combinación de dos cosas ...

1. Lo que hace la cosa. Requerimiento funcional.
2. Qué bien lo hace. Requisito no funcional o "restricción"

¿La "interfaz de usuario" cae en "funciones" o "restricciones"?

Yo diría que "Interfaz de usuario" sería una categoría de requisitos como usted identificó en su última pregunta.

¿Cuáles son las principales áreas clave (requisitos) en las que se puede dividir un software (p. Ej., IU)?

Depende del software. Puede agrupar los requisitos en función de partes del sistema o puede agruparlos en función del caso de uso o el requisito comercial que cumplen las funciones.

Por supuesto, todo esto es secundario a su objetivo real, que es determinar una descripción clara, inequívoca y comprobable del sistema de software.

El requisito principal para un requisito es que sea comprobable. Si no puede descubrir cómo probar un requisito, lo más probable es que no se implemente de la manera prevista por el escritor.

Nunca he visto un documento de requisitos limitado solo a Funciones y Restricciones, pero puedo ver algún valor en tener una estructura como esta: obliga al escritor a clasificar los requisitos en "cosas que el software debe hacer" y "gobierna el el software debe seguir ".

Creo que una interfaz de usuario tiene requisitos en ambas categorías.

Restricciones:

• "la pantalla de inicio mostrará dos botones:" Inicio "y" Detener "
• "La fuente de visualización no será menor de 10 puntos".

Funciones:

• "Cuando Startse presiona la tecla, el software establecerá una conexión TCP / IP a WOPR "