Analisis De Requisitos

Análisis de requisitos

Cuando se realiza un proyecto, el primer paso es la obtención de requisitos, preguntando al usuario qué servicios quiere que lleve a cabo, y las condiciones en que se va a ejecutar, lo que se denominan _condiciones de uso_.

La primera de las actividades en muchos modelos del ciclo de vida es la obtención de los requisitos.

Los requisitos definen: los servicios que el sistema debe proporcionar a los usuarios, y las restricciones y condiciones de uso.

La definición de los requisitos debe ser el fruto del trabajo conjunto de las partes involucradas como son los desarrolladores y usuarios. Los usuarios son los únicos que tienen poder para modificar, añadir, quitar, etc., un requisito. El desarrollador sólo actúa como “notario”.

Un usuario es el conocedor del dominio de aplicación, del área del proyecto. Por ejemplo, si se desarrolla un proyecto de contabilidad, el usuario debe conocerla. Si el dominio es abordable desde diferentes puntos de vista, cada uno que lo conoce es un usuario.

Por otra parte, los encargados de elaborar los requisitos son los analistas funcionales, que no necesitan ser informáticos ni conocedores del dominio porque el análisis no forma parte de las actividades técnicas informáticas, que comienzan en la fase de diseño.

El análisis de requisito genera la especificación de características operaciones de software; indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe tener el software.

El análisis de requisito permite que el ingeniero de software se extienda sobre requerimientos básicos establecidos durante tareas anteriores a la ingeniería de requisitos y construya modelos que representen escenarios del usuario.

Tipos de requisitos

Los funcionales describen la funcionalidad o los servicios que se espera que el sistema provea, sus entradas y salidas, excepciones, etc. Describen lo que el sistema debería hacer.

Los no funcionales se refieren a las propiedades del sistema, como el tiempo de respuesta,

etc. Describen las restricciones de cómo serán implementados los requisitos funcionales.

Problemas comunes

Muchos de los problemas que aparecen en los sistemas software una vez en utilización (aproximadamente el 37 %) se derivan de problemas aparecidos, o no detectados, en la identificación de los requisitos. Estos problemas son que:

1. Los requisitos no reflejan las necesidades reales de los usuarios del sistema software.

2. Los requisitos son inconsistentes y/o incompletos.

3. Es difícil introducir cambios en los requisitos una vez estos han sido consensuados entre usuarios y desarrolladores.

4. La causa de estos problemas es una falta de entendimiento entre los usuarios y aquéllos que desarrollan el sistema software.

Requisitos y análisis de requisitos

La identificación de requisitos es la actividad mediante la cual los usuarios y desarrolladores describen los requisitos que desean que satisfaga el sistema software a desarrollar.

Los problemas más comunes en la identificación de requisitos son:

Fijar el alcance o límites del sistema: Si cambian los objetivos, el proyecto también cambia en gran medida.

Comprensión y comunicación: El lenguaje natural es poco apto para la comunicación

A esto se añade la sobrevaloración de sus capacidades por parte del usuario, que omite algunas funciones o las expone desde su punto de vista, que él considera casi de informático.

Volatilidad: Existencia de cambios inevitables.

Para solucionar estos problemas, Somerville sugiere una serie de actuaciones:

a) Identificar a los usuarios y contrastar su papel en la organización.

b) Utilizar técnicas adecuadas tales como entrevistas.

c) Utilizar prototipos en el caso de requisitos ambiguos.

Técnicas de recolección de aplicación

Observación: debemos estar alerta y observar todo cuanto ocurre a nuestro alrededor fijándose en cualquier acontecimiento o actividad que pueda estar relacionado con el sistema de información.

Examen de archivos: técnicas basadas para obtener información cuantitativa, volúmenes, frecuencias, tendencias etc.

Muestreos: es útil cuando se pide información relativa a un gran volumen de documentos o actividades que se repitan con mucha frecuencia.

Cuestionario: son difíciles de diseñar y de interpretar, por lo que su uso debe restringirse a los casos de localidades remotas, o cuando la información debe proporcionarla un número elevado de personas.

Entrevistas: es la técnica que principal y la que más se usa, una o varias personas, desarrolladores y usuarios, se reúnen para que estos últimos indiquen los servicios que requieren y las condiciones de uso en las que se desarrollaran.

JAD (Joined Application Development, Desarrollo Conjunto de Aplicaciones)

Surgen con fuerza para resolver dos de los problemas que presentan las entrevistas:

Los conflictos entre requisitos al entrevistar por separado a distintos usuarios y el alargamiento en el tiempo debido a las numerosas entrevistas.

Un JAD es una alternativa a las entrevistas, que consiste en un proceso acelerado de reuniones en el cual todos los usuarios y analistas se reúnen de forma intensiva (puede durar desde un día a una semana) para documentar los requisitos. Normalmente un especialista supervisa las reuniones y actúa como mediador para promover una mejor comunicación entre analistas y usuarios.

La idea del JAD es:

Aprovechar la dinámica de grupos.

Aprovechar toda clase de ayudas visuales, de comunicación y comprensión de soluciones.

Realizar un trabajo sistemático y organizado.

El método utilizado se divide en:

Preparación: Seleccionar los participantes, recabar información sobre el sistema a construir y organizar la reunión (lugar, fecha, ayudas audiovisuales, redacción de un documento de trabajo...).

Sesión JAD: Consiste en diversas reuniones bien estructuradas y organizadas donde se parte de un documento de trabajo que hay que analizar para completar los requisitos del sistema, documento que deberá ser aprobado por los presentes. El jefe del JAD es el responsable de conseguir que las reuniones sean productivas y de mantener el orden.

Documentación: Aunque el documento final debería estar terminado al final de las sesiones JAD, lo cierto es que es preciso completarlo, organizarlo, etc., para tener el documento es su forma final.

El JAD es difícil de llevar a la práctica al tener que disponer

...