Análisis y requisitos de software

Fundamentos de Ingeniería del Software

Capítulo 3. Análisis de Requisitos

Cap 3. Análisis de Requisitos Estructura
Actividades iniciales
Análisis de necesidades Estudio de viabilidad

Técnicas de recogida de la información Actividades generales de análisis Documentos de especificación de requisitos Análisis estructurado Casos de uso Prototipado

Cap 3. Análisis de RequisitosBibliografía
De esta primera parte del tema...
(Piattini et al. 96) (Piattini et al. 04) cap. 6 y cap. 7 (aptdos. 7.1 y 7.2, este último no con tanto nivel de detalle)

Cómo comienza un proyecto...
Análisis de necesidades y estudio de viabilidad:
Decisión de emprender el proyecto Recoger información sobre el proyecto (Directivos nivel alto/medio) Técnicas recogida información

Informe denecesidades
Estudio de la viabilidad del proyecto (Análisis de factibilidad)

Estudio de viabilidad
Alternativas. Evaluación de las alternativas:
Económico. Técnico. Legal (p.e. LOPD “Ley Orgánica de Protección de Datos”) Operativo.

Especificación detallada de la alternativa seleccionada. Definición del plan inicial del proyecto.

Estudio viabilidad Alternativas
Comprar un producto softwarecomercial, ya construido, que cumpla los requisitos marcados (COTS, Commercial Off-The-Shelf) Desarrollar el producto internamente. Desarrollarlo de forma externa mediante un contrato (outsourcing). Automatizar sólo parcialmente el sistema, para no tener que afrontar demasiados gastos.

Plan tentativo del proyecto
Identifica:
Áreas de riesgo Presupuestos, calendarios, planes de trabajo delpersonal y asignación de tareas. Soporte necesario para el equipo del proyecto. Técnicas de comunicación entre los componentes del proyecto. Forma de interactuar con el cliente.

Técnicas de recogida de información
Entrevistas JAD (Joint Application Design) Prototipado Observación Estudio de documentación Cuestionarios Tormenta de ideas (brainstorming) ...

JAD - Desarrollo conjunto deaplicaciones
Conjunto de reuniones usuarios/analistas: 2 - 4 días Dinámica de grupos
Se comienza con un doc. de trabajo, y se discute Al final del JAD

Doc. de requisitos (aprobado)

Entrevistas vs. JAD
Entrevistas:
Requieren mucho tiempo (prepararlas, hacerlas, y elaborar conjunto coherente de requisitos a partir de diferentes entrevistados). Más difícil detectar errores (sólo analistarevisa).

JAD:
Participación más profunda usuarios (se identifican con el sist.) Más difícil llevar a la práctica. Requiere más organización. Empíricamente: ahorro tiempo ↑↑, satisfacción usuarios ↑↑

Análisis de requisitos
AR: − “El proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hw. o de sw.” − “El proceso de estudio yrefinamiento de dichos requisitos” [IEEE Std. 610, Glosario estándar de términos en ingeniería del software] − Condiciones que debe cumplir un sistema para satisfacer un contrato, una norma o una especificación. − Condición o capacidad que necesita el usuario para poder resolver un problema o conseguir un beneficio determinado.

REQUISITO:

Importancia del análisis de requisitos
Los problemas conlos requisitos constituyen la principal fuente de problemas (37%)
60 50 40 30 20 10 0 Información errónea del usuario Cambios en los requisitos Mala direción Requisitos incompletos Habilidades técnicas pobres Otros 13 12 12 7 6 50

Factores del coste en proyectos software reales (Standish94, http://www.standishgroup.com/chaos/toc.php)

Importancia del análisis de requisitos (II)
En diciembrede 1997, un estudio de 500 directores de proyectos en tecnologías de la información (en RU y EE UU), informó que el 76% había estado involucrado en algún proyecto que había fracasado totalmente ⇒ La causa del fracaso más frecuentemente nombrada era “requisitos de usuarios cambiantes”

Requisitos funcionales y no funcionales
Requisitos funcionales: describen la funcionalidad o los servicios...