INGENIERA DE SOFTWARE II RECOMENDACIONES PRCTICAS PARA LA

INGENIERÍA DE SOFTWARE II RECOMENDACIONES PRÁCTICAS PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE Gabriel Tamura gtamura@icesi. edu. co Norha M. Villegas nvillega@icesi. edu. co Cali, 2009 1

IEEE 830 -1998 IEEE Recommended Practice for Software Requirements Specifications 2

El Ciclo de Vida de los Requerimientos ELICITACIÓN ANÁLISIS ESPECIFICACIÓN MANTENIMIENTO VERIFICACIÓN Y VALIDACIÓN 3

El estándar IEEE 830 -1998 • Conjunto de recomendaciones para la especificación de los requerimientos de software. • Estructura propuesta para el desarrollo del documento de especificación de requerimientos. ¿Para qué un documento de especificación de requerimientos? Ingenieros de Software ¿Cuál es el resultado de la fase de análisis de requerimientos? ¿Cuál es el punto de partida para la validación y verificación? ¿Dónde quedan consignados los requerimientos? ¿cómo debe hacerse la especificación? Ingeniero de Requerimientos ¿Cuál es la descripción de las funcionalidades que debe tener el software? ¿Qué características y propiedades debe cumplir? ¿Cuál es el costo del producto a desarrollar? Inversión, recursos, tiempos… Gerente de Proyecto o Producto 4

Consideraciones Para Generar un Buen SRS • Naturaleza del SRS • Alcance del SRS • Características de un buen SRS • Generado en conjunto con el cliente • Evolución del SRS • Prototipos • Diseño embebido en el SRS • Requerimientos de proyecto en el SRS 5

SRS – Software Requirement Specification (naturaleza) • Condensa el resultado de la fase de análisis de requerimientos – Documento de especificación. • Contenido general de un documento SRS • Funcionalidad ¿Qué es lo que debe hacer el software? • Interfaces externas ¿Cómo interactúa el sw con las personas, el hardware del sistema, otros componentes de hw y otros componentes de sw? • Desempeño ¿Cuál es el tiempo de respuesta deseado? ¿de recuperación? • Atributos ¿Cuáles son las consideraciones de portabilidad, correctitud, mantenibilidad, etc? • Restricciones de diseño e implementación (no de proceso) Estándares, lenguajes de programación 6

Requerimientos de Proyecto • NO incluirlos en el SRS. Por ejemplo: • Costo • Cronogramas • Procesos de desarrollo de software • Aseguramiento de la calidad • Criterios de validación y verificación • Procedimiento de aceptación 7

SRS – Software Requirement Specification (estructura de contenido sugerida) 8

Ejercicio en parejas Tomando como base el sistema de la máquina expendedora de café y el análisis de requerimientos realizado hasta el momento: • Proponga una estructura de contenido para el documento de especificación de requerimientos del sistema. • Escriba el alcance del sistema como si fuera parte de su SRS (sección 1) • Especifique la sección que describe las interfaces del sistema con el usuario (sección 2) • ¿En qué sección del documento SRS ubicaría el detalle de los requerimientos y análisis? (el resultado de lo que se ha trabajado durante el desarrollo del ejercicio. • ¿Cuál sería el esquema de organización a utilizar para la especificación detallada de requerimientos en el SRS? ¿Cuáles son las consideraciones para tomar esta decisión? • Detalle los requerimientos del sistema con base en el esquema seleccionado. 9