NORMA IEEE 830 PARA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE

1. NORMA IEEE 830 PARA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE Noviembre de 2005

2. Antes de describir la norma IEEE 830...

3. Una vez que se ha detectado algún problema que afecte a la calidad del producto/servicio, o a la satisfacción del cliente... • conviene analizar si puede resolverse mediante algún tipo de tecnología de información y telecomunicaciones (TIT): • Hardware • Software • Redes (LAN, MAN, WAN, VPN, web, alámbricas, inalámbricas, etc.)

4. Cómo saber si el problema puede resolverse con TIT • ¿La causa del problema está relacionada con... • almacenamiento de datos? • procesamiento de datos? • transferencia de datos? • Si el problema puede resolverse por medios más baratos sin necesidad de invertir en TIT, ¿para qué gastar en TIT?

5. Si el problema se relaciona con almacenamiento, procesamiento o transferencia de datos, conviene definir los requerimientos específicos (necesidades) que tengamos • Al definir claramente los requerimientos que deseamos que satisfaga un software, se facilitan: • La estimación de su costo • La estimación del tiempo para diseñarlo/programarlo • La decisión sobre desarrollarlo nosotros, subcontratar o comprar • La búsqueda de algún proveedor que pueda programarlo/venderlo

6. Definir los requerimientos de un software puede parecer algo sencillo, pero es común que el usuario/cliente o el desarrollador cometan errores u omisiones importantes • Muchos problemas en los proyectos de software se deben a una inadecuada especificación de requerimientos

7. Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos guía para hacerlas preguntas pertinentes: IEEE 830 • Esta norma le sirve tanto al usuario/cliente como al desarrollador

8. IEEE 830 Recommended Practice for Software Requirements Specifications SRS

9. El propósito principal de esta norma es ayudarnos a elaborar un documento muy útil: el SRS • Es esencialmente una guía para redacción

10. IEEE 830 • Quién la hizo: Software Engineering Standards Committee, del IEEE Computer Society • IEEE (Institute of Electric and Electronic Engineers, en E.U.A.) • Cuándo: 1998 • ¿Es de uso obligatorio? NO

11. IEEE 830 • Quién la puede usar: • Un cliente/usuario que vaya a definir requerimientos (características) de un software que necesite • Un desarrollador (interno/externo) que haga software “a la medida” mediante proyecto • Un desarrollador que haga software “de paquete” que se venda masivamente

12. IEEE 830 sirve para que... • Un cliente describa claramente lo que quiere • Un proveedor entienda claramente lo que el cliente quiere • Se establezcan bases para un contrato de desarrollo (o de compra-venta) • Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)

13. IEEE 830 sirve para que... • Se tenga una base o referencia para validar o probar el software solicitado • Se facilite el traspaso del software a otros clientes/usuarios • Se le puedan hacer mejoras (o innovaciones) a ese software

14. CONSIDERACIONES PARA REDACTAR EL SRS • Su naturaleza • Su ambiente • Características deseables del documento • Preparación conjunta del SRS • Evolución del documento • Prototipos • Diseño “implícito” en el SRS • Requerimientos de proyecto “implícitos”

15. Naturaleza del SRS • El SRS es una especificación para un producto de software en particular, ya sea un sólo programa, o un conjunto de programas, que realicen ciertas funciones en un ambiente específico • A veces el usuario no sabe si necesitará un solo programa o más de uno

16. NATURALEZA DEL SRS • Frecuentemente, el usuario sólo conoce las necesidades pero no el tipo de solución más conveniente • El SRS puede escribirse por uno o más representantes del proveedor, uno o más del cliente, o por ambos • Lo más recomendable es que haya representantes de ambas partes • El usuario/cliente puede redactar un borrador inicial y después revisarlo con el proveedor

17. NATURALEZA DEL SRS (cont.) • Funcionalidades deseadas • Interfaces externas • Desempeño • Atributos(seguridad, portabilidad, mantenibilidad, etc.) • Restricciones de diseño impuestas a la implementación(estándares técnicos propios o internacionales, lenguaje de progr., sistema operativo, límites de recursos, políticas internas).

18. AMBIENTE DEL SRS • El SRS es la fuente principal para hacer el plan detallado de un proyecto de software • Un SRS puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes (módulos) individuales del mismo

19. AMBIENTE DEL SRS • Si se hacen SRS por separado para varios módulos, tiene que mantenerse la consistencia en los documentos • Si un software necesita interactuar con otro, tienen que especificarse los requerimientos de esa interacción (interfaces), definiendo sus funcionalidades y el nivel de desempeño deseado

20. CARACTERÍSTICAS DE UN BUEN SRS • Correcto • No ambiguo • Completo • Consistente • Ordenado con base en importancia y/o estabilidad • Verificable • Modificable • Rastreable

21. Correctez • El SRS es correcto si los requerimientos escritos son aquellos que el software deberá cumplir • No hay un método para saber si el SRS es correcto; lo importante es que se pida lo que realmente se necesita

22. No ambiguo • Un SRS es no ambiguosi cada requerimientoestablecido en él tiene una sóla interpretación posible, tanto por el cliente/usuario como por el desarrollador • En casos donde alguna palabra pudiera tener múltiplessignificados, se debe incluir su definición precisa en un glosario que se adicione al SRS. • Ejemplos: planta, obra, maestro, carga, flecha

23. No ambiguo (cont.) • Problema: El usuario/cliente y el desarrollador generalmente tienen diferentes perfiles profesionales, y por ello describen los requerimientos en diferente forma • Problema: Las descripciones que pudieran ser más claras para el desarrollador, podrían ser difíciles de entender para el usuario, y viceversa.

24. No ambiguo (cont.) • El lenguaje natural es inherentemente ambiguo; por ello, es conveniente que el SRS sea revisado por un tercero que no haya participado en la redacción • Se han creado lenguajes formales para especificación de requerimientos de software, que se basan en reglas matemáticas y lógicas para evitar la ambigüedad (como la Notación Z, ISO/IEC Z Standard 13568:2002)

25. Ejemplo de uso de Notación Z RAdd Birthday Birthday Book name?: NAME date?: DATE result!: REPORT (name?  known  birthday’= birthday  {name? Date?}  result!= ok) V (name?  known  birthday’ = birthday  result != already_known)

26. No ambiguo (cont.) • Métodos de representación de requerimientos: • Basados en objetos: identificar clases de objetos similares (alumno, empleado, producto, etc.). • Basados en procesos (compras, ventas, cobranza) • Basados en conductas (la conducta de un robot)

27. COMPLETO • El SRS es completo si incluye: • Todos los requerimientos significativos sobre funcionalidades, desempeño, restricciones de diseño, atributos, o interfaces externas • Las respuestas que debería dar el software a todas las posibles entradas de datos en todas las situaciones posibles (entradas aceptables o no aceptables: validación) • Especificación de unidades de medida (si son aplicables) • En caso de que el SRS tenga diagramas o tablas informativas, hay que darles número o identificación

28. CONSISTENTE • Los diversos requerimientos escritos tienen que ser compatibles entre sí; no debe haber contradicciones ni conflictos entre ellos. • Para lograr la consistencia deben evitarse los siguientes conflictos: • En características especificadas de objectos del mundo real • De lógica o de tiempo entre dos actividades • Referencia a un mismo objeto del mundo real pero usando diferentes palabras para el mismo objeto

29. ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD • Cada requerimiento especificado debe tener alguna identificación (número, letra, secuencia alfanumérica) para indicar su grado de importancia o de estabilidad • Algunos requerimientos son más importantes que otros • Al “rankearlos” se puede dar a cada requerimiento la atención que se merece

30. ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD • Grado de estabilidad: númerode cambios que se podrían esperar para un requerimiento, debido a eventos futuros que afectena la organización, las responsabilidades, y las personas que usarán el software • Grado de necesidad: • Esencial • Condicional • Opcional

31. VERIFICABLE • Un requerimiento es verificable si existe algún método rentable mediante el cual se pueda analizar si el software cumple ese requerimiento. • Ejemplo: • “La respuesta del programa deberá darse dentro de los 20 seg posteriores a la apertura de la válvula VX389, y debe responder correctamente en el 60% de los casos” • Contraejemplo (algo no verificable): • “El programa tiene que funcionar bien”

32. VERIFICABLE (cont.) • Si no existe algún método para saber si el software cumple o no un requerimiento, entonces ese requerimiento debe ser revisado o eliminado.

33. MODIFICABLE • Es modificable si la estructura y estilo de redacción permiten la realización de cambios en forma fácil, completay consistente • Para esto es recomendable: • Incluir índice, tabla de contenido y tabla de referencias cruzadas • Cada requerimiento debe aparecer sólo una vez (la redundancia propicia errores de inconsistencia) • Poner cada requerimiento separado de los demás

34. RASTREABLE • Cada requerimiento debe identificarse con algún número, letra o secuencia alfanumérica • Un SRS es rastreable si el origen de cada requerimiento es claro, y si facilita el seguimiento de cada requerimiento a lo largo del proyecto de software • Dos tipos de rastreabilidad: • Hacia atrás: en cada requerimiento se menciona explícitamente su fuente documental • Hacia delante: los documentos que se deriven del SRS deben usar las identificaciones de requerimientos como fueron dadas en el SRS

35. RASTREABLE (cont.) • La rastreabilidad hacia delante facilita las actividades de diseño, codificación, y modificación del software.

36. PREPARACIÓN CONJUNTA DEL SRS • El desarrollo de un software solamente debería iniciar cuando el cliente y el proveedor estén de acuerdo acerca de lo que el software deberá hacer

37. EVOLUCIÓN DEL SRS • Un SRS puede necesitar cambios mientras el software está en etapas de diseño o de desarrollo • Los cambios pueden estar motivados por: deficiencias, errores, omisiones o imprecisiones en el documento original • Cada requerimiento debe documentarse tan completo como sea posible, aún si pudiera necesitar cambios posteriormente

38. EVOLUCIÓN DEL SRS • Los cambios en los requerimientos tienen que documentarse con el propósito de: identificarlos, controlarlos, rastrearlos, y reportarlos • Tanto el cliente como el proveedor deben designar a su respectivo responsable de autorizar (o rechazar) cambios en los requerimientos

39. CREACIÓN DE PROTOTIPOS • Un prototipo es un pequeño programa parecido al software solicitado que sirve de ejemplo, muestra o modelo para que el cliente vaya especificando sus requerimientos en forma progresiva junto con el desarrollador

40. CREACIÓN DE PROTOTIPOS • El prototipo es útil para: • Que el cliente/usuario vea y describa más fácilmente las funcionalidades que desea • Prever aspectos de la conducta del sistema, haciendo que el SRS sea más completo y preciso • Reducir la cantidad de cambios durante las etapas de diseño o desarrollo

41. CREACIÓN DE PROTOTIPOS (cont.) • Un prototipo puede ayudar al usuario a definir detalles específicos de la interfaz humana o de las funcionalidades que requiera • Puede facilitarle al desarrollador el diseño y la programación del software

42. DISEÑO “IMPLÍCITO” EN EL SRS • Aunque el SRS no constituye un documento de diseño, implícitamente está diciéndole a los desarrolladores lo que se espera que ellos diseñen • Establece restricciones • El SRS tiene que especificar las funcionalidades que se aplicarán sobre ciertos datos para producir resultados en cierto lugar para determinados usuarios

43. Lo que generalmente no necesita escribirse en el SRS • Cómo se deben organizar los módulos del software • Cómo se deben asignar funcionalidades específicas a cada módulo • Cómo será el flujo de datos o el control de ejecución de los módulos • Elección de estructuras de datos que se usarán dentro del código

44. Sin embargo… • Algunas situaciones especiales pueden inducir requerimientos estrictos de diseño • Ejemplo: las restricciones de seguridad contra ataques en Internet pueden requerir que: • Algunas funcionalidades del software se localicen en módulos (programas) separados • Sólo se permita una comunicación limitada entre ciertos módulos • Se verifique la integridad de datos para variables críticas

45. Más ejemplos de restricciones en diseño • Requerimientos físicos (ej. peso en el shuttle) • Requerimientos de desempeño • Uso de estándares de desarrollo de software • Estándares de aseguramiento de la calidad del software • Los requerimientos se establecen siempre desde el punto de vista del usuario/cliente

46. REQUERIMIENTOS DE PROYECTO “IMPLÍCITOS” • El SRS se enfoca en el software como producto, no en su proceso de creación • Implícitamente establece restricciones sobre la planeación y administración del proyecto correspondiente

47. REQUERIMIENTOS DE PROYECTO “IMPLÍCITOS” (cont.) • El SRS da origen a otros documentos (por separado) relacionados con el ciclo de vida de un software • Estimación de costos (¿cómo calcularlos?) • Fechas de entrega • Reportes de avances • Métodos de desarrollo • Aseguramiento de la calidad • Criterios de validación y verificación • Procedimientos de aceptación

48. CONTENIDO Y ORGANIZACIÓN TÍPICOS DE UN SRS

49. ( Del documento ) ( Del software ) Contenido y organización típicos de un SRS

50. CONTENIDO DE UN SRS • SECCIÓN 1: INTRODUCCIÓN • Debe incluir una descripción general del SRS, mostrando lo siguiente: 1.1 Propósito del documento 1.2 Alcance 1.3 Definiciones, acrónimos, y abreviaturas 1.4 Referencias 1.5 Descripción general del documento