Ayds 02 Ing Requerimientos

Análisis y Diseño de
Sistemas
Tema: Ingeniería de Requerimientos

Conceptos. Elicitación de Requerimientos
Urciuolo A.
UNPSJB – 2014
Temario
• Ingeniería de requerimientos (IR)
• Especificación de requerimientos de software
• Procesos de la IR
• Framework para los procesos de la IR
• Elicitación de requerimientos.
• Fuentes de conocimiento.
• Técnicas de elicitación
Análisis y Diseño de Sistemas 2010 1

Definición de Requerimiento (IEEE)
• Condición o capacidad necesitada por un usuario
para resolver un problema o alcanzar un
objetivo.
• Condición o capacidad que debe ser alcanzada o

poseída por un sistema o componente de
sistema para satisfacer un contrato, estándar,
especificación u otros documentos formalmente
expuestos.
• Una representación documentada de una

condición o capacidad.
Análisis y Diseño de Sistemas
Ingeniería de Requerimiento (IEEE)
Es el proceso sistemático de desarrollar

requerimientos a través de un proceso
corporativo e iterativo de analizar el
problema, documentar las observaciones
resultantes en una variedad de formatos de
representación y chequear la precisión de la
comprensión obtenida.

Ingeniería de Requerimiento (IEEE)
Los distintos modelos de desarrollo de soft
reconocen la existencia de los siguientes
componentes:
Implementación
Diseño detallado
Diseño de la arquitectura
Especificación del sistema
Especificación de
requerimientos
Desarrollo como actividad de diseño

Un proceso de diseño involucra:
•requerimientos a satisfacer.
•output: un documento de especificación del diseño
•objetivo: que la implementación del diseño satisfaga
los requerimientos.
Estas son propiedades comunes a todos los

enfoques de desarrollo.

Especificación de requerimientos
del software (ERS)- Propósito
• Modeliza lo que se necesita y formula el problema
• Documentación de los requerimientos
• Herramienta de comunicación de:
- la comprensión del dominio
- el negocio
- el sistema
• Es parte del arreglo contractual.
• Papel clave en el testeo y evaluación el producto final
del software (ERS)- Visiones
La visión tradicional:
• Requerimientos funcionales.
- inputs
- procesos
- outputs
Visión dinámica:
- control
- timing
- excepciones en el comportamiento
• Datos, entidadesAnálisis
dely Diseño
mundo real y relaciones
de Sistemas

del software (ERS)- Visiones
Una visión amplia de la ERS
• Complementar la especificación funcional con:

- comprensión del dominio del problema
- comprensión de las restricciones
• Incluir: Descripción de los requerimientos en la
empresa expresados en términos de los fenómenos
comunes a la empresa y al dominio del sistema.
Criterios a cumplir por la ERS

• Correcta
• No ambigua
• Completa
• Verificable
• Consistente
• Comprensible por los consumidores
• Modificable
• Rastreable
• Independiente del diseño
• Anotada
• Concisa
• Organizada
• Utilizable en operación y mantenimiento

Productos entregables de la IR
Modelos
• del dominio del problema
• de los requerimientos funcionales
• de los requerimientos no funcionales
Participantes en el proceso IR
• Supervisores del contrato, sugieren hitos de control y

cronogramas que disciplinan el desarrollo del sistema.
• Clientes y usuarios, deben comprender y trasmitir
adecuadamente los requerimientos, para del sistema.
• Los gerentes de negocios, para calibrar el impacto de
construir y utilizar el sistema.
• Los diseñadores que usarán los requerimientos como base
del desarrollo.
• Los verificadores encargados de las sesiones de prueba
destinadas a asegurar que el sistema cumple los
requerimientos.

Procesos de la IR
Aspectos principales de la RE
• comprender el problema
• describir el problema
• acordar sobre la naturaleza del problema
Propuesta:
• elicitación
• especificación
• validación
Framework para los Procesos IR
Feedback del
Requerimientos Usuario usuario
del usuario
modelo a ser validado
ERS
conocimiento modelo de req.
Elicitación resultados Validación

solicitud + Especificación
validados
conocimiento
conocimiento del conocimiento del

dominio dominio
Dominio del
Problema

Esquema del Proceso IR
Cada proceso se describe en términos de:

• propósito del proceso
• el input del proceso y sus orígenes
• las actividades que tienen lugar durante la
ejecución del proceso y las técnicas usadas
• los entregables final e intermedios
• la interacción con otros procesos de la IR
Elicitación de Requerimientos
1. Propósito
• Ganar conocimiento relevante del problema, para
producir una especificación rigurosa del software
necesario para resolver el problema.
• Al final de la fase de ER el analista podría ser un
“experto” en el dominio del problema.

2. Input
• Fuentes del conocimiento del dominio:
• expertos del dominio
• literatura sobre el dominio
• software existente en el dominio
• software similar en otros dominios
• standards nacionales e internacionales
• otros “stakeholders”
3. Actividades
• Tareas a encarar por el analista:
• identificar fuentes de conocimiento
• adquirir el conocimiento
• decidir sobre la relevancia de un conocimiento
• comprender la significación del conocimiento y su
impacto

4. Técnicas más usadas :

• entrevistas
• prototipos
• escenarios
• reuso de conocimiento
• casos de uso
5. Productos:
• Es un proceso de creación de modelos
• el analista comienza con modelos mentales con
conocimiento dependiente del domino
• al avanzar, los modelos son más orientados al
software
• no se produce ningún modelo formal
• sucesión de modelos mentales del dominio del
problema

Especificación de Requerimientos
Una especificación puede ser vista como un

contrato entre usuarios y desarrolladores de
software, que define el comportamiento
funcional deseado del artefacto de software
(y otras propiedades de este, tales como
performance, confiabilidad, etc.) sin mostrar
como será alcanzada tal funcionalidad.
1. Propósito
• Acuerdo usuario-desarrolladores sobre el problema
a resolver
• Pauta para el desarrollo de un sistema de software
2. Input
• Conocimiento sobre el dominio del problema
• Lo provee el proceso de elicitación

3. Actividades
• Análisis y asimilación del conocimiento de los
requerimientos
• Síntesis y organización del conocimiento en un
modelo de requerimientos coherente y lógico
4. Productos
• Se producen una variedad de modelos:
• modelos orientados al usuario, que especifican
comportamiento, características no funcionales, etc.
• modelos orientados al desarrollador, que
especifican propiedades funcionales y no
funcionales del software y restricciones

5. Interacción con otros procesos

• Proceso central de la RE
• Controla los otros procesos
• elicitación-especificación:
• puede requerir más información de la elicitación
• cambios en el conocimiento del dominio del
problema generan cambios en la especificación
• Especificación-validación: Cada parte de la
especificación dispara necesidades de validación
Validación
• Proceso que certifica que se ataca el problema

correcto
• Hay enfoques de IR que no lo separan de
elicitación y especificación
• La diferenciación es importante por razones
conceptuales y prácticas

Validación
1. Propósito
• Certifica la consistencia del modelo (de
requerimientos) con las intensiones de clientes y
usuarios
• Visión más general que el concepto común de
validación
• La necesidad aparece cuando se modifica el modelo
actual
• Se aplica también a los modelos intermedios
Validación
2. Inputs
• Todo modelo está sujeto a validación, por lo tanto
cada modelo es input
• El conocimiento sobre el dominio del problema
debe ser validado
• Algunas partes del modelo formal

Validación
3. Actividades
• Interacción entre analistas, clientes del sistema y
usuarios en el dominio del problema.
• Similar a formular una nueva teoría científica y
posteriormente testearla
• Caracterizada por:
• preparación del experimento
• ejecutar el experimento y analizar los resultados
Validación
4. Productos
• Modelo de requerimientos en línea con las
expectativas de los usuarios
• No significa que el modelo sea correcto
• Compromiso entre lo deseado y lo posible y factible

Validación
5. Interacción con otros procesos

• La validación está presente en todos los procesos
de la RE, la dispara:
• nuevo conocimiento sobre el dominio del problema
(elicitación)
• formulación de un modelo de requerimientos
(especificación)
• La validación se requiere en las etapas de análisis y
síntesis (pues debe chequearse la corrección de la
información)
Conceptos
Técnicas

Donde estamos? (Propuesta RUP)
Requerimientos Obtención de requerimientos

•Entender los requerimientos
Análisis •Modelo del Negocio, Modelo
del dominio.
Diseño •Obtención de Requerimientos
funcionales del Sistema
Implementación •Obtención de Requerimientos
no funcionales del Sistema
Prueba
Elicitación de requerimientos
• Concepto: Es el proceso de adquirir (“eliciting”)
[sonsacar] todo el conocimiento relevante
necesario para producir un modelo de los
requerimientos de un dominio de problema
• Objetivo: entender el dominio del problema en particular
• ¿Dónde encontrar el conocimiento?
• Problemas:
- Información esparcida en distintas fuentes
- Forma no utilizable del conocimiento
- Dificultad cuando se trata de un experto humano

La brecha de comunicación…
La brecha de comunicación…

Stakeholders, origen de los RS
• Personas interesadas en que se implemente

el nuevo sistema
• Tres grupos primarios de stakeholders:

⇒ Usuarios (utilizan el sistema)
⇒ Clientes (pagan y son los dueños del sistema)
⇒ Staff técnico (aseguran la operatividad del
sistema).
Administración de ER
• Fuentes:
⇒Documentación.
⇒Personas con puntos de vista necesarios.
• Técnicas
⇒Cuestionarios
⇒Entrevistas
⇒Talleres
⇒Prototipos
⇒Otras…

Fuentes de ER - Documentación
• Análisis de Documentación.
Es imprescindible cuando:
⇒Introducción del sistema en infraestructuras existentes.
⇒Suplemento de funcionalidad ya disponible.
Documentación a analizar:
⇒Sobre las prácticas existentes de los usuarios.
⇒Sobre procedimientos de soporte.
⇒Sobre componentes técnicos.
⇒Sobre el modelo lógico
⇒Sobre los modelos de procesos y datos
⇒Sobre requisitos existente
Fuentes de ER - Personas
• Personas. Identificar stakeholders con puntos de vista
precisos para representar el conjunto de los
requerimientos:
1. Dirección general
2. Usuarios finales y dirección
3. Clientes
4. Proveedores
5. El equipo operativo
6. El equipo de mantenimiento
7. Asesoría jurídica u otros expertos.
• Importante contar con más de una persona por cada punto

de vista. Análisis y Diseño de Sistemas

Técnicas de elicitación
• Partiendo del usuario

• Lectura de Información
• Análisis de objetivo y meta
• Escenarios
• Análisis de formularios
• Lenguaje natural
• Reuso de requerimientos
• Casos de uso
Partiendo del usuario
• Es el más intuitivo de los enfoques
• Razones de las dificultades:

⇒Poca claridad del usuario
⇒Dificultad del usuario para transmitir su
conocimiento
⇒Diferencias entre usuario y analista
⇒El usuario puede no querer el sistema
• Se dispone de una serie de técnicas

• Aprendiz
• Elaboración de cuestionarios
• Entrevista de comienzo y final abierto
• Entrevistas estructuradas
• Reuniones
• Brainstorming
• Talleres
Partiendo del usuario - Aprendiz

• El desarrollador se convierte en aprendiz de usuario,
aprende su trabajo por observación y preguntando.
• La gente no siempre está consciente de todas las tareas

que realiza "Nadie describe mejor lo que hace y por qué
lo hace, que cuando lo esta haciendo." [Beyer&Holtzblatt]
• El aprendiz demuestra lo aprendido haciéndolo bajo la

supervisión del usuario.
• El usuario a veces no tiene tiempo para entrevistas
• El aprendiz ve la misma tarea repetidamente
• Tiene retroalimentación inmediata
• Establece una relación fluida con los usuarios y clientes

Partiendo del usuario - Cuestionarios
Recomendable como base para la posterior entrevista

personal.
Crea un marco para el análisis de resultados. (visión
clara de cómo utilizar la información)
Comprobar que existe información suficiente en el
personal “cuestionado”.
Garantizar que es comprensible (no utiliza argot
técnico).
Probarlo antes de comenzar
Verificar la comprensión.

Tipos de cuestionarios
• Para recopilar datos estructurados. 2 Modalidades:
1. Mediante Lista de cuestiones concretas y de respuesta
cerrada.
• ¿Cuánto lleva operando el actual sistema de
facturación (en años)?.
2. Mediante índices.
• ¿Importancia de estos factores para adquirir un
Sistema operativo?
Baja Alta
Velocidad 1 2 3 4 5
Usabilidad 1 2 3 4 5
Flexibilidad 1
Análisis 2
y Diseño 3 Sistemas
de 4 5

Tipos de cuestionarios
• Para recopilar información abierta.
• Se formula una pregunta abierta.
– ¿Cuál son para usted los factores principales en la

selección de proveedor de servicios de Internet?
• Útiles para obtener una información inicial sobre el área.
• Importante evitar sesgos.
Partiendo del usuario Entrevistas

• Objetivo: Obtener toda la información posible de la visión
que el entrevistado tiene de los requisitos.
• Depende de la habilidad del entrevistador para crear un

clima de confianza.
• Resulta útil planificar las entrevistas para evitar sesgos

(evitar que un grupo incline a un lado el proceso).
– Preparar un marco para la entrevista (mediante un
cuestionario)
– Confirmar detalles del entrevistado
– Establecer la finalidad de la entrevista con el
entrevistado
– Organizar una lugar adecuado.
– Confirmar los detalles por escrito.

Entevistas de comienzo y final abierto
• Forma más simple de interacción analista-usuario

• El analista deja que el usuario hable de su tarea
• Ambiente informal
• Útiles para obtener visiones generales
• No son útiles para obtener información detallada
Partiendo del usuario - Entrevistas
Entrevistas estructuradas
• Direcciona al usuario hacia aspectos específicos de

requerimientos a elicitar
• Son útiles para información detallada
• Preguntas cerradas, abiertas, de sondeo y de guía
• Información para obstáculos y soporte

Algunos consejos
• Ir a entrevistar a los usuarios en su lugar de trabajo

• Explicar la razón de la entrevista
• Entrevistar primero al usuario más experimentado
• Comienzo “inocuo”, permiso para grabar,inicio pregunta
fáciles, preguntas abiertas hacia el final
• Preguntar, escuchar la respuesta y retroalimentar lo
entendido
• Dibujar modelos, utilizar la terminología del usuario
• Guardar ejemplares de documentos/artefactos
• Agradecer al usuario su tiempo
• Búsqueda de fallas potenciales

• Es aconsejable 2 entrevistadores (una conduce la entrevista
el otro supervisa la interacción y toma notas):
– Mejora la gestión del tiempo.
– Beneficia la supervisión.
• Es aconsejable emplear tanto preguntas abiertas como
cerradas:
– Abiertas: Suelen comenzar por “qué”, por qué” y “como”
y exigen respuesta detallada por el entrevistado.
– Cerradas: Aquellas con un Intervalo específico de
respuesta.
• El entrevistador debe centrar la entrevista cuando esta se
desvía.
• El entrevistador debe evitar emitir juicios de valor para no
influir.

Partiendo del usuario Entrevistas -
Resultados
• Análisis de resultados de la entrevista:

– Si se ha utilizado como marco un cuestionario, este se
utilizará como contexto en el análisis.
– Si la entrevista no es estructurada, el resultado se

detallará como informe.
• El entrevistador debe evitar emitir juicios de valor para

no influir.
Esquema de resumen de entrevista
Nombre entrevistado.
Puesto de trabajo y breve descripción.
Punto de vista que representa.
Fecha, hora y lugar de la entrevista
Resumen de puntos principales
Doc´s. de referencia
Otros contactos.
Partiendo del usuario Grupales -

Reuniones
• Extensiones de entrevista. Muy activas. De corta duración e
intensas con un determinado foco
- Braisntorming: lluvia de ideas
- Workshop de requisitos: existe un moderador
- JAD (Join application design): se avanza en un
principio de construcción, más organizado y racional
con generación de documentos, compromisos, fechas.
• Favorecen la aparición de múltiples opiniones, creación, y

consenso colectivo.
• Problemas; Puede haber dispersión, incomodidad en el

grupo, pensamiento generado a nivel de grupo.

Brainstorming
• Se utiliza para resolver la falta de consenso entre usuarios

• Es útil combinarlo con la toma de decisiones
• Ayuda a entender el dominio del problema
• Encara la dificultad del usuario para transmitir
• Reduce la falta de consenso
• Ayuda a entender: al usuario y al analista

Brainstorming
• El grupo de desarrolladores se reúne para una lluvia de

ideas
• Muchas ideas, ideas nuevas, toda idea es buena, sin
censuras
• No deben evaluarse, debatir ni criticar
• No limitarse por lo posible
• Luego la lista de ideas es evaluada, ordenada (votación)
-> 60 ideas locas pueden contener 5 ideas geniales.

Partiendo del usuario Grupales –
Talleres
• Reunión de partes interesadas.
• Sesiones intensivas y estructuradas concentradas en uno

o dos días, con un moderador.
• Es preciso una importante preparación previa:

– Definir con los participantes la finalidad del taller.
– Facilitarles información histórica.
• El taller debe ser dirigido por un experto para:

– Garantizar que todos los participantes aportan sus
puntos de vista.
– No se desvían del propósito del taller.
Partiendo del usuario Grupales –

Talleres
• Los requerimientos capturados en el taller se registran

junto con todas las cuestiones y acciones resultantes.
• Se genera un informe para documentar los resultados y

base de la especificación de requerimientos.
• Tiene la ventaja de reunir a los participantes pudiendo

debatirse las cuestiones más controvertidas y resolver así
requerimientos aparentemente divergentes satisfaciendo
a las partes.

Resumen
• El medio más directo para la elicitación

• Se requieren habilidades especiales del analista
• Problemas:
– tiempo limitado del usuario
– dificultades sicológicas
Técnicas ER

• Escenarios
• Casos de uso

Lectura de Información
Abarca la lectura de todos los documentos

disponibles en la organización, intenta identificar
estructuras, hechos y vocabulario similares.
Tipo de lectura: diagramas organizacionales,

standards, modelos de procesos o manuales de
sistemas existentes.
Fácil de obtener si hay documentación, permite

manejar gran volumen.
Provee información muy dispersa. Gran trabajo

para procesarlo.
Técnicas ER

• Escenarios
• Casos de uso

Análisis de Objetivo y meta
• Propósito:
– colocar los requerimientos en un contexto
mayor
– comprender la relación de ese problema
con los problemas y objetivos del sistema
mayor (la jerarquía sistémica vale para los
SBC)
– tener los requerimientos adecuados

Conceptos básicos
• Metas
– un estado del sistema, o
– un conjunto de valores deseados para un número
de parámetros.
– ejemplo: en una empresa 1M$ de ganancia,
(“ganancia”=parámetro y 1M$=valor del
parámetro)
– Varian su especificidad (abstracción) al subir el
nivel
• Metas estratégicas
• Metas tácticas
• Metas operacionales
• Objetivos
– son las metas más abstractas
– ejemplo: “aumentar la utilidad”

Resumen
• El enfoque del análisis objetivo-meta ve el dominio

del problema como consistente en objetivos, metas,
sub-metas (medios), organizados en una jerarquía de
meta-submeta (fin-medio), y restricciones
• Propósito de la jerarquía de objetivos:

– identificar los requerimientos de software en el
contexto del dominio del problema
– “mapear” los requerimientos hasta los objetivos de
alto nivel del sistema

Pasos en el análisis
• Analizar la organización y el ambiente externo

• Crear una jerarquía meta-submeta consistente en:
objetivos organizacionales, metas y restricciones y
sus relaciones (soporte, conflicto, restricción)
• Validar y consensuar el modelo
• Identificar la parte de la jerarquía meta-submeta que
modeliza la parte de procesamiento de la información
de la organización
• Eliminar los casos de conflictos en el modelo anterior
con los stakeholders
• Seleccionar tareas (requerimientos) por eliminación
de alternativas

Ventajas
• Permite una clara comprensión del dominio del

problema
• Requerimientos del problema en un contexto mayor
• Considerar soluciones potenciales
Técnicas ER

• Escenarios
• Casos de uso

Escenarios
Conceptos básicos
• Escenario = historia que ilustra cómo un

sistema puede satisfacer necesidades del
usuario
• Descripción idealizada pero detallada de una
instancia específica de interacción hombre-
máquina
• Medios diversos (texto, dibujos, diagramas)
• Estructurados en diálogos o narrativas
• Similitud con los prototipos
Escenarios
Ventajas
• Los usuarios encuentran más fácil transmitir

su experticia a través de “contar una historia”
• Es una solución prometedora al problema de
la comunicación

Técnicas ER

• Escenarios
• Casos de uso
Análisis de Formularios
• Formulario = colección estructurada de

variables que está formateada para soportar
ingreso de datos y su recuperación
• Es una fuente importante pues:
– es un modelo formal
– es un modelo de datos
– a menudo contienen información sobre la
organización
– sus instrucciones de uso encierran conocimiento
sobre el dominio
– su análisis puede automatizarse

Técnicas ER

• Escenarios
• Casos de uso
Lenguaje Natural
• Forma más habitual de representación del
conocimiento
• La mayoría de lo que vale la pena conocer sobre el
dominio del problema puede formularse en NL
• Categorías de elicitación en NL:
– enfoques que interactúan con el usuario
– enfoques que elicitan desde un texto en NL
• Su atractivo reside en:
– vocabulario preexistente
– informalidad
– sintaxis

Lenguaje Natural
Resumen
• Es una fuente importante de conocimiento

• Dos limitaciones:
– el NL es muy complejo
– la ambigüedad del NL
Técnicas ER

• Escenarios
• Casos de uso

Reuso de requerimientos
• Idea de base: los requerimientos

capturados para alguna aplicación
pueden usarse en otra similar
• Razones que la hacen interesante:
– mejora global del proceso
– similitud en sistemas
– calidad
• Problemas de aplicación:
– acceso a los documentos de los requerimientos
– “adecuabilidad” de un viejo requerimiento
• Prerequisitos de aplicación:
– acceso a los requerimientos de los sistemas
existentes
– facilidades para seleccionar, testear y modificar
viejos requerimientos
– más barato que obtener los requerimientos desde
cero

Enfoques existentes
• Reuso de especificaciones. Desarrollo y

mantenimiento de una biblioteca de componentes
reusables de requerimientos
• Análisis de Dominio. Es el precursor del reuso de

requerimientos
• Ingeniería reversa. Obtener información de alto

nivel de información de menor nivel
Reuso de especificaciones
• Abarca las bibliotecas de requerimientos

reusables así como las técnicas para reusarlos
• Hay varios enfoques:

– Knowledge-Based Requirements Assistant (KBRA)
– Aprendiz de requerimientos
– Razonamiento analógico

Análisis de dominio
• Es el precursor del reuso de requerimientos. Se

refiere a la creación de una estructura para reusar
requerimientos a través de:
– identificar categorías de dominios de problemas
– identificar y formalizar los conceptos comunes
entre los diferentes dominios de aplicación
– organizar bibliotecas de componentes reusables
• DA ayuda a la comprensión del dominio del
problema
• La elicitación de requerimientos deviene en
selección, adaptación e incorporación
• DA abarca todo el ciclo de vida del software
Ingeniería reversa
• Proceso de análisis de un sistema SW para:

– identificar componentes e interrelaciones
– crear representaciones (otra forma o mayor nivel)
• Construir SRS a partir de información de
menor nivel
• Salida: especificaciones del sistema original
• Factores de éxito:
– disponibilidad, accesibilidad, testeabilidad y
modificabilidad de los requerimientos existentes
– similitud del nuevo sistema SW con uno existente

Técnicas ER

• Escenarios
• Casos de uso
Casos de uso
• Porción de actividad del sistema: respuesta a un estímulo
externo o temporal
• Colección única de procesos y datos para cada evento/
caso de uso
• Cada proceso se puede describir
• Cada caso de uso tiene un número de requerimientos
funcionales y no-funcionales
• Algunos requerimientos no-funcionales se aplican a todo
el caso de uso.
• Se divide al sistema en “piezas de funcionalidad” (los
casos de uso)

Técnicas ER
• Que técnicas usar?
– Depende de la situación, clientes, recursos.
– Se debe analizar el contexto y respetar

limitaciones
– Combinación de técnicas

Ayds 02 Ing Requerimientos

Cargado por

Copyright:

Formatos disponibles

Ayds 02 Ing Requerimientos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ayds 02 Ing Requerimientos

Cargado por

Copyright:

Formatos disponibles

Análisis y Diseño de

Tema: Ingeniería de Requerimientos

Análisis y Diseño de Sistemas 2010 1

• Condición o capacidad que debe ser alcanzada o

• Una representación documentada de una

Ingeniería de Requerimiento (IEEE)

Es el proceso sistemático de desarrollar

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 2

Análisis y Diseño de Sistemas

Desarrollo como actividad de diseño

Estas son propiedades comunes a todos los

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 3

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 4

Una visión amplia de la ERS

• Complementar la especificación funcional con:

Análisis y Diseño de Sistemas

Criterios a cumplir por la ERS

Análisis y Diseño de Sistemas 2010 5

Análisis y Diseño de Sistemas

• Supervisores del contrato, sugieren hitos de control y

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 6

Framework para los Procesos IR

Elicitación resultados Validación

conocimiento del conocimiento del

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 7

Cada proceso se describe en términos de:

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 8

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 9

4. Técnicas más usadas :

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 10

Una especificación puede ser vista como un

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 11

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 12

5. Interacción con otros procesos

Análisis y Diseño de Sistemas

• Proceso que certifica que se ataca el problema

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 13

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 14

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas 2010 15