La Ingeniería de Requisitos (II) - Documentación de Requisitos
mayo 18, 2012En esta segunda parte definiremos lo que es el Documento de Requisitos y las características de una buena Especificación de Requisitos.
Recuerda que se trata de una serie de tres post que iré publicando:
1. La Ingeniería de Requisitos (I)
2. La Ingeniería de Requisitos (II) - Documentación de Requisitos
3. La Ingeniería de Requisitos (III) - ¿Cómo organizar una Especificación de Requisitos?
Si has leído el post anterior, te habrás dado cuenta de lo apasionantemente aburrida que puede ser el mundillo este pero también de lo importante que es. Como he dicho, dada su importancia en el ciclo de vida de desarrollo software (en caso de ser compatible con nuestra metodología, o que simplemente lo veamos como una best practice) es necesario tener claro que es la Documentación de Requisitos.
· Definición de Documentación de Requisitos:
Es el proceso de redacción o registro de los requisitos. Para este proceso se puede recurrir al lenguaje natural, lenguajes formales, modelos, gráficas, etc. Además define de forma completa, precisa y verificable, los requisitos, el comportamiento y otras características de un sistema o componente de un sistema.
Es necesario que la información que se incluya en el mismo sea cierta y que dicha información se comunique de forma eficaz. Por otra parte se deben describir correctamente todos los requisitos software, pero sin incluir los necesarios y no debe describir ningún detalle del diseño, de su verificación o de la dirección del proyecto.
. Características de una buena Especificación de Requisitos:
- No ambigua: cada requisito debe tener una única interpretación.
- Completa: se dice que está completa si:
1. Incluye todos los requisitos significativos del software.
2. Define la respuesta del software a todas las posibles clases de datos de entrada y en todas las posibles situaciones.
3. Está conforme con cualquier estándar de especificación que deba cumplir.
4. Están etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas. También deben estar definidos todos los términos y unidades de medida.
- Fácil de verificar: lo es si y solo si cualquier requisito al que se haga referencia se puede verificar fácilmente, es decir, existe un procedimiento finito y efectivo en coste para que una persona o máquina compruebe que el software satisface dicho requisito. En caso de no encontrar un método para determinar si un requisito satisface una parte del producto software, este requisito debe ser eliminado.
- Consistente: una especificación de requisitos es consistente si y solo si ningún conjunto de los requisitos descritos en ella son contradictorios o entran en conflicto. Casos de conflicto sería:
1. Dos o más requisitos pueden describir el mismo objeto real pero utilizan términos distintos para designarlos.
2. Las características especificadas de objetos reales pueden estar en conflicto.
3. Puede haber un conflicto lógico o temporal entre dos acciones determinadas.
- Clasificada por orden de importancia: tienen que tener una prioridad, como ya vimos en el anterior post.
- Fácil de modificar: como te líes mucho modificando un requisito es que hay algo que no va bien. Estos deben ser claros, legibles, directos y sencillos tanto como permita su contenido y contexto. Para ello hay recomendaciones:
1. Tener una organización coherente y manejable, con una tabla de contenidos, un índice y referencias cruzadas.
2. No ser redudante.
- Fácil identificación del origen y de las consecuencias de cada requisito: debe existir una trazabilidad evolutiva (hacia adelante y hacia atrás) sencilla de los requisitos, es decir, que se conecten con futuros y pasados requisitos sencillamente para establecer consecuencias directas.
- Fácil de utilizar durante la fase de explotación y de mantenimiento.
Y hasta aquí puedo escribir, mañana más y mejor ;)
Fuente: Mis apuntes de Análisis e Ingeniería de Requisitos - URJC
0 comentarios
Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.