2. LAURA RODRIGUEZ

3. LAURA RODRIGUEZ

4. INGENIERÍA REQUISITO REQUERIMIENTO
INTERFAZ
HARDWARE
STAKEHOLDER
SOFTWARE
LAURA RODRIGUEZ

5. Fuente: Montilva, J.
(2008). LAURA RODRIGUEZ

6. Permite descubrir, analizar, especificar y validar el
conjunto de requisitos funcionales y no-funcionales
que la aplicación empresarial debe satisfacer
Según el autor
JONÁS MONTILVA
LAURA RODRIGUEZ

7. LOS REQUISITOS DEFINEN:
LAURA RODRIGUEZ

8. act Otras figuras1
«Documento»
Requisitos de la
Aplicación
«Documento»
Documento Definición de
Requisitos
«Documento»
Lista de Requisitos
de la Aplicación
«Documento»
Matriz resuisitos vs
requisitos
«Documento»
Requisitos
clasificados
«Documento»
Plan de gestión de
Requisitos
«Documento»
Matriz de rastreo
de requisitos
«Documento»
Documento de Especificación de
Requisitos de la Aplicación
«modelo»
Modelo de Casos
de Uso «modelo»
Modelo preliminar
de clases
«Documento»
Casos de Prueba
de Aceptación
«producto técnico»
Prototipo de la Aplicación
«Documento»
Descripciones
textuales
«diagrama UML»
Diagramas de casos
de uso
«diagrama UML»
Diagramas preliminares
de clases de objetos
Modelo de Productos del
Proceso de Ingeniería de Requisitos

9. Subprocesos del Proceso
act Capitulo 3
Ingeniería de
Requisitos
Descubrimiento de
Requisitos
Análisis de
Requisitos
Especificación de
Requisitos
Gestión de
Requisitos
Validación de
Requisitos
AURIMAR REQUENA

10. Actividad Tareas Producto
Determinar Objetivos de la
Aplicación.
1. Identificar objetivos de la aplicación.
2. Definir alcance de la aplicación.
3. Determinar el problema a resolver.
4. Establecer restricciones.
1. Objetivos y Alcance de la
aplicación claramente
definidos.
Establecer dominio a partir del
Modelo del Negocio.
1. Analizar el modelo de negocios y determinar el dominio de
la aplicación.
2. Revisar documentación relacionada con aplicaciones dentro
del dominio identificado - reuso de requisitos.
3. Estudiar documentación sobre aplicaciones en dominio.
4. Identificar los actores o interesados de la aplicación y que
participarán directamente en la definición de requisitos.
1. Lista de actores
clasificados.
Recolectar requisitos de la
Aplicación.
1. Contactar interesados o actores miembros del sistema de
negocios.
2. Recabar los requisitos (funcionales, no funcionales y de
interfaz) de la aplicación desde el punto de vista de cada
actor o interesado.
3. Definir requisitos (funcionales, no funcionales y de interfaz)
a partir del modelo de negocios.
4. Definir requisitos (funcionales, no funcionales y de interfaz)
a partir de aplicaciones del dominio.
5. Definir requisitos de interacción de la aplicación con otros
sistemas dentro o fuera del mismo sistema de negocios.
1. Planillas (Volère) de
recolección de requisitos.
2. Modelos de casos de uso
con sus respectivos
escenarios
Consolidación de Requisitos.
1. Verificar consistencia entre los requisitos recolectados.
2. Unificar requisitos recolectados.
1. Lista de requisitos de la
aplicación
Descubrimiento de Requisitos

11. Análisis de Requisitos
Actividad Proceso Producto
Clasificar Requisitos Recolectados.
1. Revisar los requisitos recolectados.
2. Determinar criterios de agrupamiento, generalmente va asociado al
tipo de requisitos: funcionales y no-funcionales.
3. Agrupar requisitos en las categorías establecidas.
1. Requisitos
clasificados.
Definir interacciones entre requisitos.
Establecer contradicciones entre requisitos.
Determinar grado de completitud de requisitos.
Determinar solapamientos y dependencia entre requisitos.
Elaborar matriz de requisitos .vs. requisitos.
1. Matriz de requisitos .vs.
Requisitos.
Depurar lista de Requisitos.
1. Eliminar incompatibilidades y contradicciones entre requisitos.
2. Redefinir requisitos.
3. Determinar viabilidad de los requisitos.
4. Establecer prioridades de los requisitos junto con el usuario.
1. Lista de requisitos
factibles con
prioridades acordadas
con usuario o
interesado.
Refinar Requisitos
Clasificados.
1. Describir en mayor nivel de detalle los requisitos recolectados:
a) Elaborar diagramas de caso de uso para explorar funcionalidad.
b) Definir escenarios de utilización y describiros textualmente.
c) Elaborar diagramas de clases de objetos para representar objetos
persistentes y requeridos para la funcionalidad.
d) Describir atributos y restricciones de la aplicación.
1. Diagramas de casos de
uso.
a) Descripciones textuales.
2. Diagramas preliminar
de clases.
3. Diagramas de estados.
Validar Requisitos.
1. Revisar requisitos con los actores o interesados.
2. Ajustar y corregir los diagramas de casos de uso, clases y la
definición de restricciones y atributos.
1. Documento de
definición de requisitos

12. Especificación de Requisitos
Actividad Tareas Productos
Definición del documento
de especificación.
1. Establecer la estructura y contenido de la especificación
de requisitos.
a) Especificar requisitos desde el punto de vista del actor o
interesado: funcionales y no funcionales.
b) Especificar requisitos desde el punto de vista del
desarrollador: Modelos del sistema funcional, estático o
estructural y dinámico.
1. Estructura y contenido de
documento.
Especificar requisitos
desde el punto de vista
del interesado
(stakeholder)
1. Documentar técnicamente los requisitos de la
aplicación (punto de vista del grupo de desarrollo):
a) Refinar los diagramas y modelos preliminares de
casos de uso, clases de objetos, estados y
transiciones, objetos y secuencia.
2. Documentar atributos, restricciones y otras
especificaciones según la estructura y contenido
definidos para el documento.
1. Documento de
especificación de
requisitos de la
aplicación.

13. Validación de Requisitos
Actividad Tareas Producto
Revisar documento de
especificación de requisitos.
1. Validar la estructura y el contenido del documento.
2. Validar especificación técnica de los requisitos. 1. Documento validado.
Construir un prototipo para
validar los requisitos.
1. Desarrollar un prototipo que emule la funcionalidad
(según los casos de uso) y la interfaz que tendría la
aplicación.
2. Validar funcionalidad e interfaz de la aplicación.
1. Prototipo de la
aplicación.
Ajustar los modelos y
descripciones de la
especificación de requisitos.
1. Modificar los modelos y descripciones de
especificación técnica atendiendo a los resultados de
validación del prototipo.
2. Verificar consistencia e integridad de la especificación
técnica.
1. Modelos actualizados y
validados.
Definir pruebas y
parámetros de aceptación
de la aplicación.
1. Determinar parámetros de aceptación de la aplicación.
2. Definir casos de prueba de aceptación.
3. Verificar, con los interesados, los parámetros de
aceptación y los casos de prueba de aceptación de la
aplicación.
1. Conjunto de casos de
prueba de aceptación
de la aplicación.

14. Gestión de Requisitos
Actividad Tareas Productos
Planificar el proceso de gestión
de modificaciones en los
requisitos.
1. Definición de los medios y modos de almacenamiento de los
requisitos de la aplicación – Base de Datos de apoyo a la
gestión.
2. Establecer procedimientos y mecanismos de actualización,
mantenimiento y control de requisitos.
1. Plan de gestión de
Requisitos.
Realizar cambios en los
requisitos.
1. Seguir los procedimientos y mecanismos establecidos para la
gestión de cambios en los requisitos.
2. Realizar los cambios en los requisitos.
3. Modificar documento de especificación de requisitos.
4. Asegurar consistencia e integridad de la base de datos una vez
realizados los cambios
1. Documento de
especificación
actualizado.
2. Base de datos de
Requisitos
actualizada.
Rastreo de cambios en los
requisitos.
1. Definir ámbito de influencia del cambio sobre los requisitos de
la aplicación.
2. Elaborar matriz de rastreo de requisitos.
3. Asegurar actualización de documentos y modelos de la
aplicación.
1. Matriz de rastreo de
requisitos.

15. CREAR Y MANTENER UN DOCUMENTO DE
REQUERIMIENTO DEL SISTEMA.
Según el autor
IAN SOMMERVILLE
LUIS MARTINEZ

16. ETAPA 1
ESTUDIO DE VIABILIDAD
Una descripción resumida
del sistema
Informe que recomiende si merece o no seguir con la
ingeniería de requerimientos y procesos del desarrollo del
sistema
LUIS MARTINEZ

17. ETAPA 2
OBTENCIÓN Y ANÁLISIS
El descubrimiento de
requerimiento
Punto de vista Entrevista
Punto de vista de los
interactuadores
Puntos de vistas indirectos
Punto de vista del Dominio
LUIS MARTINEZ

18. VALIDACIÓN DEL REQUERIMIENTO
Trata de mostrar que esto realmente define el sistema que el cliente
desea
1
• Verificaciones de valides
2
• Verificación de consistencia
3
• Verificación de completitud
4
• Verificación de realismo
5
• Verificabilidad
ETAPA 3
LUIS MARTINEZ

19. Según el autor
JAMES A. SENN
Cumple un papel primordial en el proceso
de producción de software,
MARIANNY UGUETO

20. ETAPA 1
LAS ESTRATEGIAS PARA EL DESARROLLO
DE SISTEMAS
MARIANNY UGUETO

21. ETAPA 2
Investigación
preliminar
Determinación de los
requerimientos de los
sistemas
Diseño del
sistema
Desarrollo de
software
Prueba de los
sistemas
Implantación y
evaluación.
CICLO DE VIDA DEL DESARROLLO
DE SISTEMAS
MARIANNY UGUETO

22. Investigación preliminar
Aclaración de la
Solicitud
Estudio de
Factibilidad
Aprobación de la
Solicitud
Factibilidad técnica
Factibilidad económica
Factibilidad operacional
MARIANNY UGUETO

23. Determinación de los
requerimientos de los sistemas
¿qué es lo que se
hace?
¿cómo se hacen?
¿con que
frecuencia se
presentan?
¿qué tan grande
es el volumen de
transacciones o de
decisiones?
¿cuál es el grado
de eficiencia con
el que se efectúa
las tareas?
¿existe algún
problema?
si existe un
problema ¿Qué
tan serio es?
si existe un
problema ¿cuál es
la causa que lo
origina?
MARIANNY UGUETO

24. Diseño del Sistema
MARIANNY UGUETO

25. Desarrollo del Software
MARIANNY UGUETO

26. Prueba de los sistemas
MARIANNY UGUETO

27. Implantación y Evaluación
MARIANNY UGUETO
Verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la
aplicación y construir todo los archivos de datos necesarios para
utilizarla.
1. Evaluación operacional
2. Impacto organizacional
3. Opinión de los
administradores
4. Desempeño del desarrollo
La evaluación se lleva a cabo para
identificar puntos débiles y fuertes , y
ocurre a lo larga de cualquiera de las
siguientes dimensiones:

28. IAN SOMMERVILLE JAMES. A SENN JONAS MONTILVA
Proceso de crear y
mantener
un documento de
requerimiento del sistema.
Herramienta que cumple un
papel
Primordial en el proceso de
producción de software.
Una estrategia para permitir
descubrir, analizar, especificar y
validar el conjunto de
requisitos funcionales y no
funcionales que la aplicación
empresarial debe conocer.
Estudio de viabilidad,
obtención y análisis,
especificación y validación.
Estrategias para el desarrollo
de sistemas y ciclo de vida del
desarrollo de sistemas.
Descubrimiento, análisis,
especificación, validación y
gestión de requisitos.
No plantea ningún tipo de
requisitos o preguntas.
En la etapa 2, plantea ocho
preguntas para la
determinación de los
requerimientos del sistema.
En la etapa 1, emplea ocho
requisitos que complementan
las 5 etapas.
CARLOS LOPEZ

29. Caso practico
INGENIERÍA DE REQUISITOS PARA PROCESOS DE EJECUCIÓN
DE ESTRATEGIAS DE MERCADEO (IMPULSOS Y FACHADAS),
COORDINACIÓN DE DESARROLLO EN EL PUNTO DE VENTA
CERVECERÍA POLAR C.A TERRITORIO COMERCIAL ORIENTE
SUR
Autor: Br. Sarabia D, Karinthia L
Desarrollar la ingeniería de requisitos de aplicación empresarial para
la gestión, control y seguimiento de los procesos de ejecución de
estrategias de mercadeo (Impulsos y Fachadas).
CARLOS LOPEZ

30. Autor: Br. Sarabia D, Karinthia L
• Carácter Proyectivo y nivel comprensivo
Investigación
• Observación directa
• Revisión documental
• Entrevistas no estructuradas
• Cuestionario
Técnicas de recolección de
datos
• Gray watch
• Lenguaje unificado de modelado (UML)Metodología
• Solución para diseñar y construir una aplicación
empresarial que atienda las necesidades planteadas
en la coordinación con la finalidad de automatizar los
procesos Impulsos y Fachadas
Propuesta
CARLOS LOPEZ

31. Solicitud de Impulsos Rol Usuario y SuperUsuario.
Autor: Br. Sarabia D, Karinthia L
Se plantea un sistema desarrollado bajo ambiente web que
permita mejorar el procesamiento de manera eficaz de las
estrategias requeridas.
CARLOS LOPEZ

32. Autor: Br. Sarabia D, Karinthia L
Planilla Volere
Identificador del
requisito: RF-01
Tipo de requisito:
Funcional
Caso de uso/Evento:
Descripción: El sistema debe validar el acceso de todos los usuarios del
sistema.
Justificación del requisito: es necesario para restringir el acceso al
sistema sólo a personas autorizadas y a su vez muestra opciones del
sistema de acuerdo al rol del usuario.
Fuente:
Jaime Albornett
Unidad en la que se origina:
Departamento de Sistemas
Criterios de validación: El sistema implementado se estará revisando
periódicamente para evaluar si la aplicación permite el acceso a la misma a
personas que no se encuentren registradas o autorizadas.
Grado de satisfacción del
interesado: 5
Grado de insatisfacción del
interesado: 1
Dependencias: 2, 5, 6, 7, 32, 34, 35,
36, 38, 40
Conflictos: No presenta
Documentos de soporte: No
definido
Histórico de cambios:06/09/2010
Proyecto: Sistema para la gestión y
control de las estrategias de
mercadeo
Analista: Karinthia Sarabia
Primer Requisito Funcional
CARLOS LOPEZ