Sunteți pe pagina 1din 1

Identificar y plasmar en un documento las necesidades del cliente

Objetivo
Ser el Analista quien defina los requisitos del sistema.
En esta fase se
- Completa el Catlogo de requisitos obtenido en la fase anterior, obteniendo un catlogo detallado
- En el caso de orientacin a objetos se especifican, adems, los casos de uso asociados a los requisitos
funcionales como tcnica para ayudar a la obtencin de requisitos (es opcional para el enfoque estructurado.)
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 especifican
aspectos adicionales que no corresponden con el funcionamiento
del sistema. A su vez se pueden categorizar en:
Clasificacin
de requisitos

Seguridad
Rendimiento
Disponibilidad del Sistema
Portabilidad...

Requisitos de Usuario : Declaraciones abstractas de los requerimientos del usuario final y el


cliente. Se especifican normalmente como lenguaje natural o diagramas. Son los servicios que
el sistema proporciona y las restricciones que debe cumplir.
Requisitos del Sistema: Descripcin ms detallada de la funcionalidad a proporcionar. Establece
con detalle funciones, servicios y restricciones operativas del sistema.
Capacidad de comunicacin (escuchar, dilogo, argumentacin...)

Tarea ASI 2.1:


Obtencin
(identificacin o
educcin) de
Requisitos

Capacidad de sntesis de los problemas.


Capacidad de comprensin de conceptos abstractos.
Caractersticas

Capacidad para entresacar lo importante de fuentes confusas.


Capacidad de captacin de los problemas del entorno de usuario.
Habilidad para evitar que "los rboles no dejen ver el bosque" (TEST) -> no perder
de vista el objeto global de los programas.

Analista

Dificultades asociadas a la adquisicin de la informacin.


Problemas de
un analista

Manejo de la complejidad del problema.


Acomodar los cambios -durante y despus- del anlisis.
El trabajo de anlisis crece geomtricamente con la complejidad del problema.

Anlisis de
requisitos
(ASI2)
(III)

Pobre comunicacin.
Causas de una mala
especificacin de requisitos

Uso de tcnicas y herramientas inadecuadas.


Tendencia a acortar la duracin del anlisis.
Consideracin errnea de las alternativas.
Problemas de alcance (no entender bien qu tiene que hacer el sistema en general).

Problemas de la
obtencin de requisitos

Tarea ASI 2.2: Especificacin de Casos de uso

Problemas de comprensin (no comprender el negocio en el que est el sistema).


Problemas de volatilidad (los requisitos cambian).
El objetivo de esta tarea es especificar cada caso de uso
(es obligatoria en el caso de orientacin a objetos, y opcional en el caso de
anlisis estructurado, como apoyo a la obtencin de requisitos)

Se obtiene la aprobacin a los requisitos del sistema (DRS).


Conjunto de requisitos completos, correctos, consistentes y con margen aceptable de riesgo
(M3. Interfaz de Seguridad. MAGERIT)
Funcionales: del sistema SW (se pueden comprobar con casos de uso).
Tipos de
requisitos

No funcionales: de fiabilidad (Tcnica MonteCarlo, que permite estimar la fiabilidad),


mantenibilidad, portabilidad, calidad (factores o externos al sistema; criterios o internos al
sistema), reusabilidad, disponibilidad, rendimiento, seguridad, implantacin...
Correcto: cada requisito establecido debe representar algo requerido.

Paso 2 (Eusamio)
Evaluacin y sntesis
de los requisitos
identificados

No Ambiguo : Cada requisito establecido tiene una sola interpretacin


(glosario explicando trminos ambiguos).
Completo: debe incluir todo lo que el SW tiene que hacer (decir qu falta es lo ms difcil).
TEST

Caractersticas
de los requisitos

Verificable: se ha de poder comprobar, mediante un proceso efectivo y de coste


limitado, que el producto rene cada requisito establecido.
Consistente: cada requisito no puede estar en conflicto con otros requisitos.
Modificable : la estructura y estilo del documento debe hacer fciles los cambios.
Conciso y Comprensible por el usuario: no slo por el desarrollador (porque lo tiene que validar).
Independiente del diseo : el documento no implica una arquitectura SW o un diseo.
Organizado y Referenciado : fciles de encontrar, calificado y debidamente referenciado.

Tarea ASI 2.3: Anlisis de Requisitos

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

Se estudia la informacin capturada hasta ahora para detectar inconsistencias,


ambigedades, duplicidad o escasez de informacin, etc

S-ar putea să vă placă și