LAURA RODRIGUEZ
LAURA RODRIGUEZ
INGENIERÍA REQUISITO REQUERIMIENTO
INTERFAZHARDWARE
STAKEHOLDER
SOFTWARE
LAURA RODRIGUEZ
Fuente: Montilva, J. (2008). LAURA RODRIGUEZ
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
LOS REQUISITOS DEFINEN:
LAURA RODRIGUEZ
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 v s
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
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
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
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
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.
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.
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.
CREAR Y MANTENER UN DOCUMENTO DE REQUERIMIENTO DEL SISTEMA.
Según el autor IAN SOMMERVILLE
LUIS MARTINEZ
ETAPA 1
ESTUDIO DE VIABILIDAD
Una descripción resumida del sistema
Informe que recomiende si merece o no seguir con laingeniería de requerimientos y procesos del desarrollo delsistema
LUIS MARTINEZ
ETAPA 2
OBTENCIÓN Y ANÁLISIS
El descubrimiento de requerimiento
Punto de vista Entrevista
Punto de vista de losinteractuadoresPuntos de vistas indirectosPunto de vista del Dominio
LUIS MARTINEZ
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
Según el autor JAMES A. SENN
Cumple un papel primordial en el proceso de producción de software,
MARIANNY UGUETO
ETAPA 1
LAS ESTRATEGIAS PARA EL DESARROLLODE SISTEMAS
MARIANNY UGUETO
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 DESARROLLODE SISTEMAS
MARIANNY UGUETO
Investigación preliminar
Aclaración de la Solicitud
Estudio de Factibilidad
Aprobación de la Solicitud
Factibilidad técnicaFactibilidad económicaFactibilidad operacional
MARIANNY UGUETO
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
Diseño del Sistema
MARIANNY UGUETO
Desarrollo del Software
MARIANNY UGUETO
Prueba de los sistemas
MARIANNY UGUETO
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 operacional2. Impacto organizacional3. Opinión de los
administradores4. 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:
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
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
Autor: Br. Sarabia D, Karinthia L
• Carácter Proyectivo y nivel comprensivoInvestigació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
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
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
Top Related