Metodología de la especificación de requerimientos

Esta fase permite conocer las expectativas del usuario. Para ello, se identifican los grupos de usuarios reales y posibles con sus áreas de aplicación, se revisa la documentación existente, se analiza el entorno operativo y sus requerimientos de procesado y se realizan entrevistas o cuestionarios a los usuarios.

Para todo este proceso existen técnicas formalizadas de especificación de requerimientos que más o menos concuerdan con las siguientes:

Se identifican las entradas del problema, los resultados deseados o salidas y cualquier requerimiento o restricción adicional en la solución.

 Obtener información acerca de lo que los usuarios desean

Los requerimientos son el punto en que el cliente y el proyecto de desarrollo de software se unen, esta unión es necesaria para poder construir un software que satisfaga las necesidades del cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que la obtención de esta información sea de primera mano.

Esto es, mediante entrevistas con el cliente o buscando documentación que describa la manera que el cliente desea que funcione el sistema de software.

Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada revisión o cambio que se haga a esta documentación

Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas serán satisfechas por el software y cuales por algún otro producto del sistema.

 Clasificar y estructurar requerimientos

El clasificar requerimientos es una forma de organizarlos, ya que hay requerimientos que por sus características no pueden ser tratados igual que a otros. Por ejemplo, los requerimientos de entrenamiento de personal no son tratados de la misma manera que los requerimientos de una conexión a Internet.

La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones.

o Requerimientos del "entorno"

El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen ciertos tipos de requerimientos que se clasifican en esta categoría, ya que el sistema usa el entorno y lo necesita como una fuente de servicios necesarios para su funcionamiento. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos.

o Requerimientos "ergonómicos"

El más conocido de los requerimientos ergonómicos es la interfaz con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonómicos son la forma en que el ser humano interactúa con el sistema.

o Requerimientos de Interfaz

La interfaz es como interactúa el sistema con el ser humano o con otros sistemas (el enfoque es prácticamente el opuesto a los requerimientos ergonómicos), La interfaz es la especificación formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de información, el medio para comunicarse y el formato de los datos que se van a comunicar.

o Requerimientos funcionales

Estos son los que describen lo que el sistema debe hacer. Es importante que se describa el ¿Que? Y no el ¿Como? Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema.

o Requerimientos de desempeño

Estos requerimientos nos informan las características de desempeño que debe tener el sistema. ¿Que tan rápido?, ¿Que tan seguido?, ¿Cuantos recursos?, ¿Cuantas transacciones?

Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeño de un sistema es tan crítico como su funcionamiento.

o Disponibilidad (en un determinado periodo de tiempo)

Este tipo de requerimientos se refiere a la durabilidad, degradación, portabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipo de requerimiento es también muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones críticas que no deben estar fuera del servicio por periodos prolongados de tiempo.

o Entrenamiento

Este tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Que tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma?

Este tipo de requerimientos, aunque muchas veces no termina con código dentro del sistema, son muy importantes en el proceso de diseño ya que facilitan la introducción y aceptación del sistema en donde será implementado.

o Restricciones de diseño

Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este tipo de normas caen como "restricciones de diseño".

o Materiales

Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los costos de industrialización del sistema.

 Identificar los niveles jerárquicos del sistema y clasificar los

requerimientos según estos niveles.

Un sistema tiene diferentes niveles de jerarquía en sus componentes. Los componentes más pequeños se agrupan en módulos y estos a su ves se pueden agrupar en subsistemas. Si el sistema computacional se aloja en una red de telecomunicaciones entonces es probable que nuestro sistema entero pueda ser agrupado junto con otros componentes en un nodo. Entonces varios nodos pueden ser agrupados en una red. Si vemos a la red como un todo y nos concentramos en las interacciones de ésta y su entorno entonces la red y sus usuarios forman el Nivel cero de esta red.

Para poder alojar un requerimiento en el lugar correcto, hay que tomar en cuenta esta jerarquía. Es de hacer notar que entre más alto se aloje un requerimiento en la jerarquía, más costoso será su implementación.

 Especificar formalmente los requerimientos de acuerdo al nivel de

audiencia que se desea.

Una vez que ya han sido recopilados, clasificados y alojados en el nivel de jerarquía que les corresponde, hay que poner por escrito los requerimientos del sistema. Sin embargo, ¿Hasta donde llegará esta especificación?

La habilidad de comunicarse con una audiencia debe de ser balanceada con la necesidad de especificar los requerimientos precisamente y sin ambigüedad alguna.

Existen ya algunos lenguajes abstractos y herramientas para el manejo de especificaciones de requerimientos. Tales como el ASN.1 para interfaces de telecomunicación. Sin embargo, el uso de estos lenguajes implica que la audiencia deba tener un conocimiento general de este tema.

Por el contrario, si usamos el lenguaje natural, podemos correr el riesgo que nuestra audiencia confunda los términos del requerimiento.

El UML incorpora en sus estructuras los casos de uso (Use cases) propuestos por Ivar Jacobsson. Esta Estructura maneja especificaciones formales y abstractas pero se acompaña de una descripción textual y estructurada del requerimiento del sistema. En este contexto entraría dentro de las características de las metodologías.

Hay que encontrar un punto medio entre precisión y entendimiento como se muestra en la Fig. 2.19

Una vez que el requerimiento ha sido plasmado, deberá de tener una identificación única. Esto es con el fin de facilitar el manejo de requerimientos. Tema que explicamos a continuación.

Fig. 2.20 Proceso de validación de requerimientos

2.3.2.1 Manejo de requerimientos

De acuerdo con el "Capability Maturity Model" (CMM) el manejo de requerimientos involucra:

“Establecer y mantener un acuerdo con el cliente sobre los requerimientos del proyecto de software. Este acuerdo son los requerimientos del sistema alojados al software.”

“Este acuerdo cubre requerimientos técnicos y no técnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida.”

“Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos que están bajo su responsabilidad estén documentados y controlados”

"Para lograr el control de los requerimientos, el grupo de requerimientos revisan los requerimientos antes de que estos sean incorporados al proyecto de

Entrada del Proceso Dominio del entendimiento Validación de los requerimientos Requerimiento definido y especificado Priorización Conflictos de resolución Clasificación Colección de requerimientos

software y cada vez que los requerimientos cambian los planes, productos, y actividades son ajustadas para quedar en línea con los nuevos requerimientos de software".

En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos se debe tomar en cuenta dos cosas.

Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos y en ninguna forma deben ser impuestos en su totalidad por presiones externas al proyecto.

El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no técnicos (Calidad, Costo y Tiempo de entrega) deberán estar especificados de común acuerdo con el grupo de requerimientos del proyecto de software.