ESPECIFICACIÓN de REQUISITOS
-Delimitar el sistema
-el que y el como
-Contrato
estándar de IEEE 830
buen diseñador es buen programador.
ingeniería de requerimiento.
requerimiento: solicitud expresa planteada por el cliente
requisito: va inmerso en la calidad del producto
ANÁLISIS de REQUISITOS
El análisis de requisitos se puede definir como el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, hardware o software, así como el proceso de estudio y refinamiento de dichos requisitos, definición proporcionada por el IEEE [Piattini, 1996].
Analista y cliente se deben poner de acuerdo en las necesidades del nuevo sistema, ya que el cliente no suele entender el proceso de diseño y desarrollo del software como para redactar una especificación de requisitos software (ERS) y los analistas no suelen entender completamente el problema del cliente, debido a que no dominan su área de trabajo.
Así pues, el documento de especificación de requisitos debe ser legible por el cliente, con lo que se evita el malentendido de determinadas situaciones, ya que el cliente participa activamente en la extracción de dichos requisitos.
Objetivos de la ERS.
Los principales objetivos que se identifican en la especificación de requisitos software son [Chalmeta, 2000]:
1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificación de requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.
2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificación de requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creación de la aplicación.
3. Servir de base para desarrollos de estándares de ERS particulares para cada organización: Cada entidad puede desarrollar sus propios estándares para definir sus necesidades.
Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que
se indican en el IEEE son las siguientes [Chalmeta, 2000][Piattini, 1996]:
· Correcta
· No ambigua
· Completa
· Verificable
· Consistente
· Clasificada
· Modificable
· Explorable
· Utilizable durante las tareas de mantenimiento y uso
Corrección
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.
Ambigüedad
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación. Cada característica del producto final debe ser descrita utilizando un término único y, en caso de que se utilicen términos similares en distintos contextos, se deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado específicamente.
Completitud
Una ERS es completa si:
· Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).
· Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.
· Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado.
· Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.
Verificabilidad
Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual una persona o una máquina pueda chequear que el software satisface dicho requerimiento.
Consistencia
Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto.
Se pueden dar tres casos:
· Requisitos que describen el mismo objeto real utilizando distintos términos.
· Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.
· Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones serían perfectamente válidas (¿sumar o multiplicar?)
Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios:
· Importancia: Pueden ser esenciales, condicionales u opcionales.
· Estabilidad: Cambios que pueden afectar al requisito.
Lo ideal es el establecimiento de prioridades, de modo que la implementación de
un requisito de menor prioridad no emplee excesivos recursos.
Modificabilidad
Una ERS es modificable
si cualquier cambio puede realizarse de manera fácil, completa y consistente.
Para ello, es deseable tener una organización coherente y fácil de usar en la que aparezca el índice o una tabla de contenidos fácilmente accesible.
También es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en más de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa será mucho más cómodo si no tenemos que buscar el mismo requisito en varios lugares.
Explorabilidad (traceability)
Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito). Cuando un requisito de la ERS representa un desglose o una derivación de otro requisito, se debe facilitar tanto las referencias hacia atrás como hacia adelante en el ciclo de vida. Las referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del software. Cuando el código y los documentos son modificados, es esencial poder comparar el conjunto total de requisitos que puedan verse afectados por estas modificaciones.
Utilizable durante las tareas de mantenimiento y uso
En la ERS también se deben tener en cuenta las necesidades de mantenimiento. El
personal que no ha intervenido directamente en el desarrollo debe ser capaz de
encargarse de su mantenimiento. Así, dicha ERS actúa a modo de plano de la
aplicación, permitiendo incluso modificaciones que no requieran un cambio en el
diseño.
En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal
que se encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria
una correcta documentación de las funciones, ya que si no se conoce en detalle su
origen, difícilmente podrán ser modificadas.
Requerimientos funcionales y no funcionales
No funcionales: ¿Como?, restricciones al diseño del software.
(factores de calidad)
explícitos-implícitos
referencias
Copy of ESPECIFICACIÓN de REQUISITOS
By Eder Rafo Jose Pariona Espiñal
