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