Análisis derequisitos

(ASI2)(III)

ObjetivoIdentificar y plasmar en un documento las necesidades del cliente

Tarea ASI 2.1:Obtención(identificación oeducción) deRequisitos

Será el Analista quien defina los requisitos del sistema.

En esta fase se- Completa el Catálogo de requisitos obtenido en la fase anterior, obteniendo un catálogo detallado- En el caso de orientación a objetos se especifican, además, los casos de uso asociados a los requisitos

funcionales como técnica para ayudar a la obtención de requisitos (es opcional para el enfoque estructurado.)

Clasificaciónde requisitos

Los requisitos se pueden clasificar en categorias. Ej:Requerimientos Funcionales : Son los requisitos que especifican el funcionamiento del software a construir

Requerimientos No Funcionales : Son los requisitos que especificanaspectos adicionales que no corresponden con el funcionamientodel sistema. A su vez se pueden categorizar en:

Seguridad

RendimientoDisponibilidad del SistemaPortabilidad...

Requisitos de Usuario : Declaraciones abstractas de los requerimientos del usuario final y elcliente. Se especifican normalmente como lenguaje natural o diagramas. Son los servicios queel sistema proporciona y las restricciones que debe cumplir.

Requisitos del Sistema: Descripción más detallada de la funcionalidad a proporcionar. Establececon detalle funciones, servicios y restricciones operativas del sistema.

Analista

Características

Capacidad de comunicación (escuchar, diálogo, argumentación...)Capacidad de síntesis de los problemas.

Capacidad de comprensión de conceptos abstractos.Capacidad para entresacar lo importante de fuentes confusas.Capacidad de captación de los problemas del entorno de usuario.

Habilidad para evitar que "los árboles no dejen ver el bosque" (TEST) -> no perderde vista el objeto global de los programas.

Problemas deun analista

Dificultades asociadas a la adquisición de la información.Manejo de la complejidad del problema.

Acomodar los cambios -durante y después- del análisis.El trabajo de análisis crece geométricamente con la complejidad del problema.

Causas de una malaespecificación de requisitos

Pobre comunicación.Uso de técnicas y herramientas inadecuadas.

Tendencia a acortar la duración del análisis.Consideración errónea de las alternativas.

Problemas de laobtención de requisitos

Problemas de alcance (no entender bien qué tiene que hacer el sistema en general).Problemas de comprensión (no comprender el negocio en el que está el sistema).

Problemas de volatilidad (los requisitos cambian).

Tarea ASI 2.2: Especificación de Casos de usoEl objetivo de esta tarea es especificar cada caso de uso(es obligatoria en el caso de orientación a objetos, y opcional en el caso deanálisis estructurado, como apoyo a la obtención de requisitos)

Paso 2 (Eusamio)Evaluación y síntesisde los requisitosidentificados

Se obtiene la aprobación a los requisitos del sistema (DRS).Conjunto de requisitos completos, correctos, consistentes y con margen aceptable de riesgo(M3. Interfaz de Seguridad. MAGERIT)

Tipos derequisitos

Funcionales: del sistema SW (se pueden comprobar con casos de uso).No funcionales: de fiabilidad (Técnica MonteCarlo, que permite estimar la fiabilidad),mantenibilidad, portabilidad, calidad (factores o externos al sistema; criterios o internos alsistema), reusabilidad, disponibilidad, rendimiento, seguridad, implantación...

Característicasde los requisitos

Correcto: cada requisito establecido debe representar algo requerido.No Ambiguo : Cada requisito establecido tiene una sola interpretación(glosario explicando términos ambiguos).Completo : debe incluir todo lo que el SW tiene que hacer (decir qué falta es lo más difícil).Verificable: se ha de poder comprobar, mediante un proceso efectivo y de costelimitado, que el producto reúne cada requisito establecido.Consistente: cada requisito no puede estar en conflicto con otros requisitos.Modificable : la estructura y estilo del documento debe hacer fáciles los cambios.Conciso y Comprensible por el usuario: no sólo por el desarrollador (porque lo tiene que validar).

Independiente del diseño : el documento no implica una arquitectura SW o un diseño.Organizado y Referenciado : fáciles de encontrar, calificado y debidamente referenciado.

TEST

Tarea ASI 2.3: Análisis de RequisitosSe estudia la información capturada hasta ahora para detectar inconsistencias,ambigüedades, duplicidad o escasez de información, etc

Tema 78-EVS y ASI (III).mmap - 28/05/2011 - Mindjet