Especificación de Requerimientos de Software (SRS)

uEspecificación de Requerimientos de Software (SRS)

Contiene una descripción del comportamiento externo del sistema. Puede ser escrito por el cliente o por el ingeniero. En el primer caso sirve para representar las necesidades del cliente, por ejemplo, para una licitación. En el segundo caso se escribe como primer paso para el proceso de construcción de software y debe ser un documento más específico que en el primer caso.

El propósito del SRS es proveer un medio de:

 Comunicación entre clientes, usuarios, analistas y diseñadores: Si el SRS está bien escrito, el cliente no se desilusionará con el producto final. No se puede dar lugar a malinterpretaciones y si hay desacuerdo entre las partes debe detectarse en esta etapa, no después, ya que sería más costoso.

El SRS debe especificar cómo el sistema será visto por su entorno y por los usuarios. Puede incluir aspectos de diseño para lograr esto, pero no es parte de la etapa de diseño, en la cual se puede rehacer todo de nuevo.

 Servir como base para actividades de prueba y verificación: se comparan las pruebas en escenarios reales con el SRS y se analiza la ambigüedad, inconsistencia o inestabilidad del SRS y del sistema. El SRS es la entrada primaria de la planeación y generación de las pruebas.

 Ayudar a controlar la evolución del software: Debe permitir que los cambios futuros se hagan de manera simple, facilitando la búsqueda y modificación de requerimientos. El SRS es la única definición de lo que el software debe hacer. Un control formal del SRS permite que el software evolucione correctamente.

Atributos de un SRS bien escrito

1. Correcto: Un SRS es correcto si y solo si cada requerimiento representa algo requerido por el sistema. Este atributo depende de la aplicación a desarrollar.

2. No ambiguo: Un SRS no es ambiguo si y solo si cada requerimiento establecido tiene una única interpretación. Esto se puede verificar consultando los requerimientos con distintas personas y oyendo sus interpretaciones.

Los términos con múltiples significados deben aparecer en un glosario, así como también deberemos evitar, dentro de lo posible, el lenguaje natural, el cual lleva implícita la ambigüedad. Al

Al momento de diseñar y desarrollar, la ambigüedad puede llevar a resultados muy graves.

fun

3. Completo: Un SRS es completo si posee cuatro cualidades:

 Todo lo que el software se supone que debe hacer está en el SRS. Es lo más difícil de definir o detectar violaciones en él. Una violación es algo que no está en el SRS, por eso es difícil ubicar. Esto lo pueden resolver aquellos que tienen el problema y solicitaron el software. Los prototipos son útiles en este sentido.

 Definiciones de las respuestas del software a todos los tipos realizables de datos de entrada en todas las situaciones posibles. Se deben especificar las entradas válidas e inválidas, indicando en todos los casos la salida correspondiente.

 Todas las páginas están numeradas, las tablas y figuras también, con nombres y referencias, todos los términos y unidades de medida son provistos y todos los materiales y secciones mencionados están presentes.

 Ninguna sección está marcada como “Pendiente de terminación”. Si se incluye, se debe indicar quién es el responsable y la fecha de terminación.

4. Verificable: Un SRS es verificable si y solo si cada uno de los requerimientos es verificable. Un requerimiento es verificable si y solo si existe algún proceso en el cual una persona o máquina puede chequear que el software actual satisface ese requerimiento.

La verificabilidad es una función de la forma en como el SRS es escrito, no solo del producto.

La ambigüedad puede llevarnos a la no verificabilidad. También si usamos unidades no mensurables o si tenemos algún requerimiento que sea equivalente a un problema de bloqueo.

5. Consistente: Un SRS es consistente si y solo si

...