Está en la página 1de 3

CPAP - Ingeniería de Requisitos

Ejercicio Domiciliario 1 – Propiedades de los Requisitos

1. Detectar y clasificar RNF en la especificación dada

RNF texto Clasificación


3.22. Extensibilidad de actividades Atributo de Calidad
3.24. Extensibilidad de los eventos Atributo de Calidad
3.25. Estructura de los eventos Interfaz Externa
3.26. Ejecución de flujos de forma concurrente Atributo de Calidad
4.1. Performance Atributo de Calidad
4.2. Manejo de errores y excepciones Atributo de Calidad
4.4.1 Diseño Restricción/Atributo de Calidad*
4.5 Interfaces con software Restricción
4.6 Interfaces de comunicación Restricción
4.7 Requisitos de adecuación al entorno Restricción
4.8 Requisitos de verificación Restricción
4.9 Requisitos de instalación Restricción
7.1. Lenguaje de programación y frameworks Restricción
7.2. Proceso de desarrollo de software Restricción
8.1. Manual de Usuario **
8.5. Estándar de documentación **
* Si lo miramos como usabilidad sería un Atributo de Calidad, pero lo entendí muy específico por
tal motivo puede ser una Restricción
** Los manuales de Usuarios y Documentación están solicitados de forma muy específica podrían
verse como una restricción al sistema como todo

2. Analizar las propiedades de un par de RF y RNF


a. Los requisitos a analizar son:
 3.20. Contexto (REQF8): Cada instancia de workflow tendrá asociado un
contexto que puede ser modificado al ejecutarse las distintas actividades que se
ejecutan en él. Cuando una actividad devuelve datos, estos deben ser
almacenados en una variable del contexto.
 3.6. Pausar ejecución de workflow (REQF3): Se debe permitir seleccionar, del
conjunto de workflows en estado “ejecutando”, los que se desee pausar su
ejecución (se dejan de escuchar eventos disparadores).
 3.26. Ejecución de flujos de forma concurrente: Las instancias de flujos
secuenciales y de máquina de estados deben poder ejecutarse en un motor de
forma concurrente.
 4.2. Manejo de errores y excepciones: Ante la ocurrencia de errores en el
sistema, se deben generar archivos que reporten las características de los
errores. El detalle de la información brindada debe ser de nivel técnico ya que
será analizada por desarrolladores ante la ocurrencia de errores del sistema.
Ante la ejecución no exitosa de cualquiera de las funcionalidades especificadas
no se deben proveer mecanismos de recuperación.

Mónica Rodriguez – Junio 2023


CPAP - Ingeniería de Requisitos
b. Análisis Requisitos Individuales

3.20. Contexto 3.6. Pausar 3.26. Ejecución 4.2. Manejo de


(REQF8) ejecución de de flujos de errores y
workflow forma excepciones
(REQF3) concurrente
Claro X   
Conciso    
Consistente    
No ambiguo    
Viable    
Rastreable X X X X
Verificable   X X
Priorizado X X X X
Cuantificable   X X
Completo X  X X
Correcto    
Necesario ?   

1. Análisis Conjunto de Requisitos

Realista 
Completo 
Correcto 
Consistente 
Modificable X
Ranqueado X

Mónica Rodriguez – Junio 2023


CPAP - Ingeniería de Requisitos
Nota: Para que quede en el documento el teórico

Base Teórica: Análisis Requisitos Individuales


Claro: debería estar escrito en un lenguaje preciso y simple, que cualquier lector pueda entender.
Conciso: debería describir una única propiedad y expresarla con cuantas menos palabras sea
posible.
Consistente: no debería contradecirse internamente.
No ambiguo: debería tener solo una interpretación.
Viable: debería ser realizable dentro de un lapso especificado.
Rastreable: hacia atrás hasta la solicitud del interesado y hacia adelante hasta los componentes del
software.
Verificable: debe tener un criterio claro y comprobable y un proceso rentable para comprobar que
ha sido realizado como se pedía.
Priorizado: debería tener asignada una prioridad.
Cuantificable: debería ser cuantificable, lo que ayuda en la prueba y en la verificación.
Completo: debería tener toda la información necesaria para realizarlo.
Correcto: no debe contener errores.
Necesario: debe satisfacer una necesidad real del cliente sobre el producto.

Base Teórica: Análisis Requisitos Conjunto

Realista: Obtenible dentro de las restricciones de tiempo, recursos y costo del proyecto
Completo: Deberían estar incluidos todos los servicios que se precisan del sistema
Correcto: Cada requisito incluido debería ser uno que el software satisfará.
Consistente: Ningún requisito debería contradecir otro.
Modificable: Los cambios en los requisitos se deberían poder hacer de forma fácil, completa y
consistente, al tiempo que se conserva la estructura y el estilo
Ranqueado: Debería ser posible decidir qué incluir o excluir.

Mónica Rodriguez – Junio 2023

También podría gustarte