PA1

 Características de los requisitos del Software

La recogida de requisitos de software es la fundación de la totalidad del proyecto de desarrollo software. Por ello, debe de ser clara, correcta y bien definida.

Una completa especificación de requisitos Software debe ser:

• Correcta

• No ambigua

• Completa

• Consistente

• Calificada de acuerdo a la importancia y/o estabilidad

• Verificable

• Modificable

• Rastreable

  Correcta

Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir.   

  No ambigua

Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación.

  Completa

Una SRS es completa, sí y solo sí, incluye los siguientes elementos:

o Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema                    debe ser reconocido y tratado.

o Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada                    válidos como inválidos.

o Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida.

  Consistente

Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningunos subconjuntos de requisitos ahí descritos se contradicen o entran en conflicto.

  Jerarquizada de acuerdo a la importancia y/o estabilidad

Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tiene un identificador que indique la importancia o estabilidad del requisito.

  Verificable

Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable.

  Modificable

Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS:

o Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas.

o No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS).

o Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos.

  Rastreable

Una SRS es rastreable si el origen de cada uno de sus requisitos es claro y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Se recomiendan los siguientes dos tipos de rastreabilidad:                                                                                                 

o Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores. 

o Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en                  operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es esencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.

Requisitos de Software

Debemos intentar entender qué tipo de requisitos pueden aparecer en la fase de educción de requisitos y qué tipo de requisitos se esperan del sistema de software.

En líneas generales los requisitos de software se deben caracterizar en dos categorías:

Requisitos funcionales

Requisitos que se relacionan a aspectos funcionales del software irían en esta categoría. Definen las funciones y la funcionalidad en y desde el sistema de software.

Ejemplos:

• Buscar una opción dada al usuario para buscar desde varias facturas.

• El usuario debe ser capaz de enviar por correo electrónico cualquier informe a la Dirección.

• Los usuarios se pueden dividir en grupos y los grupos pueden tener derechos diferentes.

• Debe cumplir reglas empresariales y funciones administrativas.

• El Software se desarrolla manteniendo intacta la compatibilidad en descenso.

Requisitos no funcionales

Los requisitos, los cuales no están relacionados con aspectos funcionales del software, están en esta categoría. Son características del software implícitas o esperadas, asumidas por los usuarios.

Los requisitos no funcionales incluyen:

• Seguridad

• Acceso

• Almacenaje

• Configuración

• Actuación

• Coste

• Interoperabilidad

• Flexibilidad

• Recuperación de desastre

• Accesibilidad

Los requisitos se categorizan de forma lógica como

• Tienen que tener: El Software no puede ser operacional sin ellos.

• Deben tener: Motivando la funcionalidad del software.

• Pueden tener: El Software aún puede funcionar bien con estos requisitos.

• Lista de deseo: Estos requisitos no contienen ningún objetivo de software.