IEEE 830: Recommended Practices for Software Requirements SRS Specifications

IEEE 830 Recommended Practices for Software Requirements SRS Specifications

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. Fue creada por Software Engineering Standards Committee, del IEEE Computer Society. IEEE (Institute of Electric and Electronic Engineers, en E.U.A.) en 1998 y no es de uso obligatorio.

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

Para qué sirve?

• 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).

• 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

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. 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.

CARACTERÍSTICAS DE UN BUEN SRS.

• Correcto.

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.

• No ambiguo.

Un SRS es no ambiguo si cada requerimiento establecido en él tiene una sola interpretación posible, tanto por el cliente/usuario como por el desarrollador En casos donde alguna palabra pudiera tener múltiples significados, se debe incluir su definición precisa en un glosario que se adicione al SRS. – Ejemplos: planta, obra, maestro, carga, flecha.

• 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.

• 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 objetos 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.

• Ordenado con base en importancia y/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.

• Verificable.

Un

...