Swebok

1. 4. ANALISIS DE
REQUISITOS

2. 
Es una auditoría a todo lo que se
recopiló. De aquí salen los requisitos
del sistema y por ende los de software.
Permite establecer limitaciones y
viabilidad del proyecto; además de
permitir detetctar y resolver los
conflictos entre los requisitos, del
sistema para derivar a los de software.
ANALISIS DE
REQUISITOS

3. 
Clasificación de los requisitos
Modelo conceptual
Asignación Arquitectónica del Diseño y
los Requisitos
Negociación de los requisitos
Se divide en:

4. Pueden clasificarse en:
Funcionales o no funcionales
De alto nivel.
De producto o de proceso
Derivado
Prioritario: clasificación según su prioridad
Alcance: Grado en el cual se afecta al
software y los componentes.
Estable o Volátil
Clasificación de los
requisitos

5. Se debe elegir un modelo conceptual que ayude a
entender de una mejor manera el problema. Es
una habilidad con la que debe contar el ingeniero
de software, apoyado en herramientas que le
ayuden a contextualizar el software, como el caso
de UML o el uso de la matemática discreta. La
IEEE tiene tres estándares para el modelado.
Estos son:
IEEE Std 1320.1 (conceptual)
IDEF0 (funcional)
IEE Std 1320.2, IDEF1X97 (de información)
Modelo conceptual

6. 
Es la fusión de toda la parte de requisitos con
la parte de diseño. Es inseparable esta
combinación; una es parte integral de la otra
y es fácil su comprensión, apoyándose en el
modelo conceptual. El estándar IEEE Std
1471-2000 puede servir de apoyo en esta
práctica.
Es importante para permitir análisis
detallado del requisitos.
 Asignación Arquitectónica
del Diseño y los Requisitos

7. 
Se llega a esta etapa cuando hay
incompatibilidad en dos o más requisitos
y los solicitantes son distintos. El
ingeniero de software debe reunirlos y
tomar la decisión más conveniente para el
correcto funcionamiento de la solución.
Dar solución a los problemas que emergen
como resultado del análisis.
Negociación de los
requisitos