Proceso de Análisis de Requerimientos

El proceso del establecimiento de requerimientos de un sistema de software, como ya mencionamos, es el primer paso esencial en entregar lo que el cliente desea. A pesar de esto, la insuficiencia de tiempo y esfuerzo son a menudo encontrado en esta actividad y existen pocos métodos sistemáticos para soportarlo. Entre los métodos conocidos se puede citar a los siguientes:

Para Pressman, en el proceso de análisis de requerimientos del software se puede identificar cinco tareas o etapas fundamentales:

1. Reconocimiento del problema
Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del contexto del sistema. El analista debe establecer un canal adecuado de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la función
primordial del analista en todo momento es reconocer los elementos
del problema tal y como los percibe el usuario.

2. Evaluación y síntesis
En esta etapa el analista debe centrarse en el flujo y estructura de la información, definir las funciones del software, determinar los factores
que afectan el desarrollo de nuestro sistema, establecer las características de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la determinación del problema de forma sintetizada.

3. Modelización
Durante la evaluación y síntesis de la solución, se crean modelos del sistema que servirán al analista para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo servirá de pilar para el diseño del software y como base para la
creación de una especificación del software.

4. Especificación
Las tareas asociadas con la especificación intenta proporcionar una representación del software. Esto más adelante permitirá llegar a determinar si se ha llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales.

5. Revisión
Una vez que se han descrito la información básica, se especifican los criterios de validación que han de servir para demostrar que se ha llegado a un buen entendimiento de la forma de implementar con
éxito el software. La documentación del análisis de requerimientos y
manuales, permitirán una revisión por parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas inicialmente.

RequisitePro

RequisitePro es la herram ienta que ofrece Rational Software para tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto.
En RequisitePro los requerimientos se encuentran documentados bajo un esquema organizado de documentos; estos esquemas cumplen completamente con los estándares requeridos por algunas de las instituciones a nivel mundial más reconocidas en el desarrollo de software, tales como: IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), ISO, CMM (Modelo de Capacidad de Madurez) y por el RUP (Proceso Unificado Racional)
Esta herramienta se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo.

Segün la promoción hecha en Internet mediante la página Web para esta herramienta, algunas de sus ventajas son:

Un producto potente y fácil de utilizar para la gestión de requisitos y casos de uso que propicia una mejor comunicación, mejoras en el trabajo en equipo y reduce el riesgo de los proyectos.

Componentes de Casos de Uso

Los casos de uso representan requisitos funcionales del sistema. Se describen como conjuntos de secuencias. Cada una de estas secuencias refleja la interacción entre los elementos externos al sistema y el propio sistema (se trata de la descripción de escenarios o situaciones posibles donde se pone de relieve el comportamiento del sistema ante su uso por parte del usuario).
Así pues, los objetivos principales de la realización de casos de uso son:
• Definir el límite entre el sistema a desarrollar y los elementos externos a ese sistema (actores usuarios del sistema).

• Capturar el conjunto de funcionalidades y comportamientos del sistema a desarrollar.
Cada caso de uso se documenta mediante una representación gráfica y un texto con la descripción de las situaciones o escenarios ante los que el usuario se pueda encontrar en su interacción con el sistema.
En el modelado de casos de uso debemos tener en cuenta dos conceptos básicos:
Actores.
Los actores pueden ser personas, software o hardware; el término actor representa el rol genérico de usuario del sistema. El nombre que se le dé a un actor deberá reflejar el papel que tendrá para el sistema. Identificar los actores nos permite:

• Definir los límites del sistema (qué forma parte del sistema y qué no).

• Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades esperadas por los diferentes actores.


Casos de uso.
Reflejan el uso que harán los actores del sistema; se muestran a través de ellos tanto las funcionalidades que ofrecerá el sistema, como los diferentes comportamientos posibles inherentes a las situaciones contempladas para cada una de estas.

Diagramas de casos de uso.

Los casos de uso pueden estar relacionados con actores o con otros casos de uso; gráficamente una relación vendrá dada por una línea entre los casos de uso y/o actores relacionados, siendo que el extremo de dicha línea dependerá del tipo de relación; en principio tenemos cuatro tipos posibles:

• Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representa símplemente con una línea).
  
• Uso (include, includes, uses; se representa por una flecha apuntando en el sentido de la relación).
  
• Extensión (extend, extends; gráficamente la representación es la misma que para "uso").
  
• Generalización (se trata del concepto de herencia, habitual en los diagramas de clases, pero aplicado entre casos de uso, e incluso entre actores; se representa por una flecha con un triángulo vacío por punta señalando en el sentido de la relación).
  

Por ahora nos centraremos en las relaciones de uso y extensión.

Relación <<include>>.

Es una simple relación de inclusión, es decir, los escenarios o situaciones posibles detalladas en un caso de uso están incluidas en otro caso de uso (aquel del que, gráficamente, parte la flecha).

Relación <<extend>>.

Este tipo de relación refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripción del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión); esto se representa mediante una "etiqueta" (un texto significativo entre paréntesis) como referencia del lugar donde entraría a formar parte del caso de uso extendido.