AYD-Sesión 06

Pregrado
SESIÓN 06:
FUNDAMENTOS Y CAPTURA DE REQUISITOS
Casos de Estudio
Ingeniería de
Pregrado
Sistemas
Competencia
Analiza y Diseña Sistemas de Información con el

Proceso de Desarrollo RUP, expresando sus ideas
con coherencia, lógica, orden, claridad, fundamento y
buen lenguaje; innovando en la búsqueda de
soluciones.
Ingeniería de
Pregrado
Sistemas
Objetivo de la clase
Comprende conceptos y fundamentos de la gestión de requisitos.
Ingeniería de
Pregrado
Sistemas
Agenda de la clase
 Importancia de los requerimientos
 Documentos de los requerimientos
 Clasificación de requerimientos
 Características de los requerimientos
 Proceso de Ingeniería de Requerimientos
Ingeniería de
Pregrado
Sistemas
Importancia de los requerimientos

Boehm y Papaccio en 1988, realizan un cuantificación del
costo de corregir los errores asociados a requerimientos
en las diversas etapas del software.
Etapa en la que se encuentra el error Costo en USD
Análisis y Esp. Requerimientos 1

Diseño 5
Codificación 10
Prueba Unitaria 20
Producción 200
Ingeniería de
Pregrado
Sistemas
Documentos de Requerimientos
Existen dos documentos que emanan del análisis de
requerimientos:
Definición de requerimientos
 Es un documento que debe escribirse en términos

que el cliente pueda entender. Es decir, este
documento es un listado completo de todas las cosas
que el cliente espera que haga el sistema propuesto.
 Este documento es escrito en forma conjunta por el
cliente y el desarrollador.
Ingeniería de
Pregrado
Sistemas
Especificación de requerimientos
 Documento que reitera la definición de los requerimientos

en los términos técnicos apropiados para el desarrollador
del diseño de un sistema.
 Es la contrapartida técnica al documento de definición de
requerimientos y es escrito por los analistas de
requerimientos.
A veces un único documento puede servir para ambos

propósitos, lo que lleva a un entendimiento común entre
clientes, analistas de requerimientos y diseñadores.
Pero a menudo se necesitan ambos documentos.

Ingeniería de
Pregrado
Sistemas
Es muy importante, que al usar ambos documentos
exista un correspondencia directa entre cada
requerimiento del documento de definición y aquellos
documentos en la especificación.
Esto para que la visión del cliente este unida a la de los

desarrolladores (esto se logra gracias a la gestión de
configuración).
Ingeniería de
Pregrado
Sistemas
Clasificación de Requerimientos
Según el Tipo los requerimientos se clasifican en:
 Requerimientos funcionales.
 Requerimientos no funcionales.
 Requerimientos del Dominio.
Según a quien van dirigidos se clasifican en:
 Requerimientos del Usuario.

 Requerimientos del Sistema.
Ingeniería de
Pregrado
Sistemas
Requerimientos funcionales
Describen la funcionalidad o los servicios que se espera

que el sistema proveerá. Dependen del tipo de
software, del sistema que se desarrollo y de los
posibles usuarios.
Cuando se expresan como Requerimientos del

usuarios, se definen de forma general.
Cuando se expresan como requerimiento del sistema

describen con detalle la función de éste, sus entradas
y salidas, excepciones, etc.
Ingeniería de
Pregrado
Sistemas
Requerimientos no funcionales
Son los requerimientos que no se refieren directamente

a las funciones específicas que entrega el sistema, sino a
las propiedades emergentes de éste, como la fiabilidad, la
respuesta en el tiempo y la capacidad de almacenamiento.
Muchos requerimientos no funcionales se refieren al sistema

como un todo más que a rasgos particulares del mismo.
A menudo son mas críticos que los funcionales. Mientras que

un incumplimiento de un requerimiento funcional degrada el
sistema, el de un requerimiento no funcional del sistema lo
inutiliza.
Ingeniería de
Pregrado
Sistemas
Los requerimientos no funcionales se clasifican según su

implicancia:
Del producto: especifican comportamiento del producto. Ej.:

de desempeño en la rapidez de ejecución del sistema, cuanta
memoria se requiere; los de fiabilidad que fijan la tasa de fallas
para el sistema sea aceptable, los de portabilidad y de
usabilidad.
 Organizacionales: se derivan de las políticas y

procedimientos existentes en la organización del cliente y del
desarrollador. Ej.: estándares en los procesos que deben
utilizarse, requerimientos de implementación como los
lenguajes de programación o el método de diseño a utilizar.
Ingeniería de
Pregrado
Sistemas
Externos: cubre todos los requerimientos que se derivan de

los factores externos al sistema y de su proceso de desarrollo.
Ej.: requerimientos de interoperabilidad, requerimientos
legales, requerimientos éticos.
Un problema común con los requerimientos no funcionales es

que algunas veces son difíciles de verificar.
De forma ideal los requerimientos no funcionales se deben

expresar de manera cuantitativa utilizando métricas que se
puedan probar de forma objetiva. En la práctica, es difícil. El
costo es muy alto.
Ingeniería de
Pregrado
Sistemas
Requerimientos del dominio
Se derivan del dominio del sistema más que de las

necesidades especificas del usuario.
Son importantes debido a que a menudo reflejan los

fundamentos del dominio de la aplicación. Si estos no se
satisfacen es imposible que el sistema trabaje de forma
satisfactoria.
Estos se expresan utilizando un lenguaje especifico del

dominio de la aplicación que a menudo es difícil de
comprender. Ej.: operación para calcular desaceleración
del tren, para un sistema de control de trenes.
Ingeniería de
Pregrado
Sistemas
Características de los requerimientos

Es importante señalar que los requerimientos pueden
servir a tres propósitos:
 Permitir que el desarrollador explique como ha

entendido lo que el cliente pretende del sistema.
 Indican a los diseñadores que funcionalidades y

características va a tener el sistema resultante.
 Los requerimientos indican al equipo de pruebas que

demostraciones llevar a cabo para convencer al cliente
de que el sistema que se le entrega es de hecho lo que
había ordenado.
Ingeniería de
Pregrado
Sistemas

Los requerimientos deben ser de alta calidad para la buena
comprensión de clientes y desarrolladores.
Con este fin debe comprobarse que los requerimientos

posean las características que se desprenden de las
siguientes preguntas:
 ¿los requerimientos son correctos?. Cliente y

desarrollador deben revisarlos para asegurarse que no
tienen errores.
 ¿los requerimientos son consistentes?. Es decir, ¿los

requerimientos planteados son no conflictivos ni
ambiguos?. Dos requerimientos son inconsistentes cuando
es imposible satisfacerlos simultáneamente.
Ingeniería de
Pregrado
Sistemas

 ¿los requerimientos son completos?. El conjunto de
requerimientos es completo si todos los estados posibles,
cambios de estado, entradas, productos, restricciones están
descritos en alguno de los requerimientos.
 ¿los requerimientos son realistas?.¿El sistema puede

hacer realmente lo que el cliente esta pidiendo que haga?.
Todos los requerimientos deben ser revisados para asegurarse
que son posibles.
 ¿describe cada requerimiento algo que es necesario

para el cliente?. Los requerimientos deben ser revisados para
conservar sólo aquellos que inciden directamente en la
resolución del problema del cliente.
 ¿los requerimientos son verificables?. Debemos preparar

pruebas que demuestren que se han cumplido los
requerimientos.
Ingeniería de
Pregrado
Sistemas

 ¿los requerimientos son rastreables?. ¿Se puede
rastrear cada función del sistema hasta el conjunto de
requerimientos que la establece?. ¿Resulta fácil encontrar
el conjunto de requerimientos que coinciden a un aspecto
especifico del sistema?.
Ingeniería de
Pregrado
Sistemas
Fuentes de Requerimientos
Modelo del Dominio
Robertson y Robertson 1999
Deseos y necesidad
Modelo de la situación
De los interesados actual
Requerimientos
Organización y sistemas Requerimientos
actuales
Reutilizables
Biblioteca de
Reutilización
Documentos existentes
Tipo de Requerimientos
recomendados
Plantilla de
Requerimien
tos
Ingeniería de
Pregrado
Sistemas
Proceso: Ingeniería de Requerimientos
La Ingeniería de Requerimientos (IR) es un proceso

que comprende todas las actividades requeridas para
crear y mantener un documento de requerimientos del
sistema.
Ingeniería de
Pregrado
Sistemas

Actividades
Obtención y Especificación
Validación
Estudio de
Análisis de de de
factibilidad Requerimientos
Requerimientos Requerimientos
Artefactos
Informe Documento Modelo del Especificación

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de
Pregrado
Sistemas

Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de
Pregrado
Sistemas

Estudio de Factibilidad
La entrada de este es una descripción resumida del

sistema y como se utiliza dentro de una organización.
El resultado del estudio es un informe que recomienda

si es conveniente llevar a cabo la ingeniería de
requerimientos y el proceso de desarrollo del sistema.
Además permite proponer cambios al alcance,
presupuesto, calendarización, etc.
Este es un estudio corto para resolver si es posible y

conveniente construir el sistema con la tecnología
existente, las restricciones de costo y tiempo, etc.
Ingeniería de
Pregrado
Sistemas

Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de

Pregrado
Sistemas
Obtención y Análisis de requerimientos
Se trabaja en conjunto con los usuarios y los clientes.

Problemas Comunes:
 No saben lo que quieren del sistema , sólo en términos
generales, no conocen el costo de sus peticiones.
 Los requerimientos están en sus términos y con

conocimientos implícitos de su propio trabajo.
 Distintos usuarios tienen distintos requerimientos, se
deben encontrar todas las fuentes.
 Influyen factores políticos.
 La importancia de los requerimientos varia en el tiempo.
 Aparecen nuevos requerimientos.
Ingeniería de

Pregrado
Sistemas
Proceso de Obtención y Análisis de requerimientos.
Comprensión Recolección de
del dominio Requerimientos Clasificación
Verificación Resolución de
Priorización
de Requerimientos Conflictos
Ingeniería de

Pregrado
Sistemas
Fases:
• Comprensión del Dominio: el analista debe desarrollar su
propia comprensión del dominio de la aplicación. Ej.: Si
fuera un sistema para un supermercado este debe evaluar
como funciona un supermercado.
• Recolección de Requerimientos: éste es el proceso de
interactuar con los clientes y usuarios para descubrir sus
requerimientos . Acá se desarrolla la compresión del
dominio.
• Clasificación: considera la recolección no estructurada de
requerimientos y los organiza en grupos coherentes.
Ingeniería de

Pregrado
Sistemas
•Resolución de conflictos: de forma inevitable, cuando

existen muchos stakeholders involucrados, los requerimientos
estarán en conflicto. Está actividad se refiere a resolver estos
conflictos.
•Priorización: Descubrir la importancia de cada requerimiento.
Es útil separar los requerimientos en tres categorías:
• Requerimientos que deben ser absolutamente satisfechos.
• Requerimientos que son muy deseables pero no
indispensables.
• Requerimientos que son posibles, pero que podrían eliminarse.
•Verificación de Requerimientos: Los requerimientos se

verifican para descubrir si están completos, son consistentes y
acorde con lo que realmente quieren los stakeholders.
No existe un enfoque perfecto ni universal aplicable a la

obtención y análisis de requerimientos .
Ingeniería de
Pregrado
Sistemas

Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de

Pregrado
Sistemas
Especificación de Requerimientos
Lenguaje Natural
 Comprensible para el Cliente/Usuario.
 Ambiguo (glosario).
 Poca legibilidad (plantilla, formateo del texto).
 Difícil de tratar (Verificar correctitud, consistencia,
completitud).
Notaciones Especiales (más formales)
 Poca o ninguna ambigüedad.
 Facilita tratamiento.
 Necesidad de entrenamiento en la notación.
 Dificultades de comprensión por Cliente/Usuario
Ingeniería de

Pregrado
Sistemas
Especificación de Requerimientos
Notaciones Especiales.
 Gráficas vs. Basadas en texto
 Estáticas vs. Dinámicas
Descripciones Estáticas.
• Se especifican entidades y sus atributos, los
requerimientos se pueden ver como las relaciones entre
las entidades.
• No describe como cambian las relaciones con el tiempo
Descripciones
Dinámicas
• Especifican estados y las transiciones entre estados en
el tiempo.
Ingeniería de
Pregrado
Sistemas

Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de

Pregrado
Sistemas
Validación de Requerimientos
Proceso por el cual se determina si la especificación es

consistente con las necesidades del cliente.
Incluye verificar trazabilidad entre la especificación y el
documento de requerimientos.
Se trabaja con un bosquejo completo del documento a diferencia
de la verificación del Análisis.
Se realizan las siguientes verificaciones en el documento de
requerimientos:
 Validez: compromiso con el usuario, que valide que es lo que
quiere.
 Consistencia: que no haya contradicciones.
 Realismo: que se puedan implementar (incluye: tecnología,
presupuesto y calendario).
 Verificabilidad: Diseñar conjunto de pruebas para demostrar que
el sistema cumple esos requerimientos.
Ingeniería de

Pregrado
Sistemas
Validación de Requerimientos
Verificación de Requerimientos no funcionales.

 Son difíciles de verificar.
 Se deben expresar de manera cuantitativa utilizando métricas
que se puedan probar de forma objetiva ( esto es IDEAL).
Propiedad Medida
Rapidez Transacciones por seg.
Tamaño KB.
Fiabilidad Tiempo promedio entre fallas.
Robustez Probabilidad de datos corruptos después de la falla.
Portabilidad Número de sistemas.
Facilidad de uso Tiempo de capacitación.
Para los usuarios es difícil especificarlos en forma cuantitativa.

Ingeniería de

Pregrado
Sistemas
Participantes en el proceso de requerimientos.

Entre los participantes en el proceso de requerimiento pueden
incluirse:
 Supervisor del contrato: quienes sugieren hitos de control y

cronogramas que restringen el desarrollo del sistema.
 Clientes y Usuarios: quienes deben comprender los
requerimientos de modo que puedan estar seguros de que el

sistema satisface sus necesidades.
 Gerentes de negocios: pueden comprender las probables
consecuencias de construir y utilizar el sistema.
 Diseñadores: quienes utilizan los requerimientos como base
para el desarrollo de una solución aceptable, que se

implementara como un sistema basado en software.
 Verificadores: desarrollan datos de prueba y sesiones de
prueba para asegurar que el sistema de software satisface cada

uno de los requerimientos.
Ingeniería de
Pregrado
Sistemas

Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema
Existen una gran cantidad de métodos para el

modelamiento de sistemas, a continuación se nombran
los más significativos:
Técnicas para
 Tablas de Decisión. describir un
 Diagramas de transición de estados. sistema entorno a
estados y
 Redes de Petri. estímulos.
 Diagramas de Flujo de Datos.
 Diagramas de Casos de Uso.
Ingeniería de
Pregrado
Sistemas
38
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Tablas de Decisión

 La tabla de decisión representa acciones a ser tomadas
cuando el sistema está en uno de los estados representados.
 El número de estados es = 2^ nº de condiciones, lo que da

como resultado tablas de decisión muy extensas.
 Se puede verificar que si todo conjunto de posibles

condiciones resulta en una acción, entonces la especificación
está completa. También se puede analizar la consistencia de la
tabla, y eliminar cualquier caso conflictivo.
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Tablas de Transición de Estados

 Descripción dinámica.
 Se interpreta el sistema de una forma similar, a un

conjunto de estados donde el sistema reacciona a ciertos
eventos posibles.
 El conjunto de estados se denomina S.
 Un estado inicial es, S0.
 Un conjunto de eventos o condiciones, C.
 Existe una función de transición de estados, F.
F(Si,Cj) = Sk
Ingeniería de

Pregrado
Sistemas
Tabla de Transición.
ESTADO ACTUAL ENTRADA PROXIMO ESTADO
S1 0 S2
S1 1 S1
S2 0 S2
S2 1 S1
S3 0 S1
S3 1 S3
1 0
S1 1
S2
0
1
S3
Ingeniería de

Pregrado
Sistemas
Ejemplo de un diagrama de transición de estados para

reserva de Hotel (Utilizando forma UML).
Condición
INICIO
Solicitud de plaza
ninguna
Acciones
Solicitada
Plaza disponible Ninguna plaza disponible
decrementar cuenta de plaza Poner en lista de espera
Plaza disponible
decrementar cuenta de plaza
Confirmada En Lista de Espera
El cliente cancela
Incrementar cuenta de plazas El cliente desiste
El cliente ocupa
Retirar de la lista
ninguna
Ocupada Cancelada
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Redes de Petri
 Descripción dinámica.
 Las técnicas descritas hasta ahora son sumamente

útiles para sistemas cuyos estados y eventos son
secuenciales.
 Está técnica permite describir : concurrencia y

sincronización.
 La representación con una red de petri es una

alternativa que se ajusta bien para expresar los
requerimientos del procesamiento paralelo.
Ingeniería de

Pregrado
Sistemas
 Las Redes de Petri son Grafos dirigidos con dos tipos

de nodos:
• Estados y Transiciones .
• Arcos sólo pueden unir Estados con Transiciones y
Transiciones con Estados
Ingeniería de

Pregrado
Sistemas
 El estado inicial de una red de Petri se

L1 -Lugar con le llama marca, esta dado por los
marca Tokens (marcas) iniciales.
 Significado:
Transición • Transiciones: Modelan eventos o
acciones.
• Lugares con marca: Cumplimiento
de una condición.
L2 -Lugar • Transición activada: Ocurrencia
del evento o ejecución de la
acción.
Ingeniería de

Pregrado
Sistemas
 Transición habilitada: Existe  Al activarse una transición,

al menos un token en cada los tokens que activaron la
uno de sus lugares de transición desaparecen de
entrada. los lugares de entrada y se
generan tokens en los
L1 L2 lugares de salida de la
transición.
L1 L2
T1
L3 L4 L5
 Estado pronto para activar la
transición. L3 L5
L4
Ingeniería de

Pregrado
Sistemas
A1 Secuencia A4
Conflicto
T1 T3 T4 T5
T6
A2
A5 A6 A7
T2
T7 T8 T9
L3
Concurrencia
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Redes de Petri (Ejemplo)
E2- pronta Máquina dispensadora
T1-Inserta moneda
E1- Tiene moneda
T4-dispensa T2- rechaza T3- acepta moneda

moneda
E3- pronto para dispensar
Se dispararon las transiciones: t1,t3,t4

Otra secuencia posible seria t1,t2
Ingeniería de
Pregrado

Sistemas
Modelado del Sistema – Diagramas de Flujo de Datos (DFD)
 Descripción dinámica
 Proviene de Metodología de Análisis y Diseño Estructurado
• fin de la década del 70.
• Usados en versión original de OMT (Rumbaugh 91), no
incorporados a UML.
• Antes de los Casos de Uso era una de las formas más usadas
para describir un sistema.
 Elementos
• Proceso del sistema que recibe datos y genera otros.
• Archivo de datos.
• Flujo de Datos.
• Entidad Externa al sistema a modelar (actor)
Archivo
Datos que entran Datos que salen

Proceso
Ingeniería de
Pregrado

Sistemas
Ejemplo:
Historia Clínica Registro Contable
Experiencia y Lista de exámenes y

conocimiento servicios brindados
Médico Examen Contabilidad
Síntomas Medicación y
Diagnostico
Factura
Paciente
Paciente
Ingeniería de
Pregrado

Sistemas

 Permite visualizar cómo fluye la información por el sistema.
• Está asociado a una realización particular del sistema.
 El diagrama no es suficiente para precisar el comportamiento:
•por un flujo que entra a un proceso desde un archivo,
¿fluye un registro o todo el archivo?.
•No estipula sincronización, un flujo llega a una entidad

externa y otro sale ¿Están relacionados? ¿Uno es respuesta
del otro?.
 Se complementa con un diccionario de datos que describe:

•estructura de los flujos y otros detalles.
•los procesos (lenguaje natural estructurado) con lo que el
comportamiento queda determinado.
 A menudo sistemas legados están documentados con DFD.
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Casos de Uso (UML)
 Técnica para entender y describir requerimientos.

 Los casos de uso son requerimientos, describen
requerimientos funcionales.
 Pone el acento en el uso del producto.
 Describen como el sistema debe comportarse desde el
punto de vista del usuario.
 Casos de Uso como caja negra: Especifican que es lo
que el sistema debe hacer sin especificar cómo debe
hacerlo.
 Se describen mediante documentos de texto.
 Introducido por Ivar Jacobson (1992).
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Caso de uso (UML)
53
Ingeniería de

Pregrado
Sistemas
Modelado del Sistema – Elección de una Técnica
 Ninguna técnica de especificación es completa.

 La elección de la técnica esta limitada por:
• Características del proyecto.
• Preferencia de los desarrolladores.
• Preferencias del cliente.
 Por lo general se combinan varios enfoques, por
ejemplo:
• Una técnica para requerimientos funcionales.
• Otra técnica para los requerimientos
no funcionales.
Ingeniería de

Pregrado
Sistemas
Técnicas – Obtención y Análisis de Requerimientos
Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de

Pregrado
Sistemas
Técnicas -Obtención y Análisis de requerimientos

Posibles conflictos: Ti
em
sos po
r
Necesidades
e cu
Balancear R Calidad
Expectativas
Alcance
Necesidades Restricciones
gí
Pe
Expectativas
lo
rs
a cno
o na
Te
s
Proceso
Ingeniería de

Pregrado
Sistemas
Técnicas -Obtención y Análisis de requerimientos

Técnicas :
 Investigar antecedentes.
 Entrevistas individuales/grupales.
 Encuestas/Cuestionarios.
 Tormenta de ideas.
 Casos de Uso.
 Prototipado.
Proceso: Ingeniería de Requerimientos Pregrado
Ingeniería de
Técnicas -Obtención y Análisis de requerimientos Sistemas
Investigar Antecedentes
 Estudio, muestreo, visitas,…
 Buena forma de comenzar un proyecto.
 Interna: Estructura de la organización, Políticas y

procedimientos, Formularios e informes, Documentación de
sistemas.
 Externa: Publicaciones de la industria y comercio, Encuentros

profesionales, Visitas, Literatura y presentaciones de
vendedores.
 Ventajas Desventajas
 Ahorra tiempo de otros. Perspectiva limitada.
 Prepara para otros enfoques. Desactualizado.
 Puede llevarse a cabo fuera Demasiado genérico.
de la organización.
Ingeniería de
Entrevistas Individuales y Grupales

 Usar para:
• Entender el problema de negocio.
• Entender el ambiente de operación.
• Evitar omisión de requerimientos.
• Mejorar las relaciones con el cliente.
 Orientación a las personas. Costoso.
 Interactivo / Flexible. Depende de las habilidades
 Rico. interpersonales.
Pregrado
Ingeniería de
Encuesta / Cuestionario
No substituye la entrevista.
Antes de usar el enfoque:
 Determinar la información que se precisa.
 Desarrollar cuestionario.
 Probarlo con perfil típico.
 Analizar resultado de las pruebas.
 Su principal uso es para validar asunciones y obtener
datos estadísticos sobre preferencias.
 Conveniente para quien Menos Rico.
contesta. Problemas por no
 Respuestas anónimas. Respuestas.
Esfuerzo de desarrollo.
Proceso: Ingeniería de RequerimientosPregrado
Ingeniería de
Tormenta de Ideas
 Objetivo: Lograr consenso sobre los requerimientos.
 Ayuda a la participación de todos los involucrados.
 Permite pensar en otras ideas.
 Un secretario saca notas de todo lo discutido.
 Reglas:
• No se permite criticar ni debatir.
• Dejar volar la imaginación.
• Generar tantas ideas como sea posible.
• Mutar y combinar ideas.
Ingeniería de
Casos de Uso
 Formato simple y estructurado donde los usuarios y
desarrolladores pueden trabajar juntos.
 No son de gran ayuda para identificar aspectos no funcionales.
 Mientras se definen los casos de uso, puede ser un buen
momento para definir pantallas u otros objetos con los que el

usuario interactúa.
 Pueden ser usados en el diseño y en el testing del sistema.
 Usarlo No son la mejor elección:

 Cuando el sistema está Sistemas sin usuarios y con
orientado a la funcionalidad, pocas interfaces.
con varios tipos de usuarios. Sistemas dominados
 Cuando la implementación primariamente por
se va a hacer OO y con UML. requerimientos no
funcionales y restriccion
de diseño. es
Ingeniería de
Prototipado
 Implementación parcial, permite a los desarrolladores y
usuarios:
• Entender mejor los requerimientos.
• Cuales son necesarios, deseables.
• Acotar riesgos.
 Prototipo desechable: El propósito es solo establecer que

algo se puede hacer, luego se parte de cero en la construcción,
quedando el conocimiento aprendido.
 Prototipo evolutivo: Es implementado sobre la arquitectura

del producto final, el sistema final se obtiene de evolucionar el
prototipo.
 Aspectos para los que es frecuente construir prototipos:

• Apariencia y percepción de la interfaz de usuario.
• Arquitectura (riesgos técnológicos, tiempos de respuesta).
• Otros aspectos riesgosos.
Ingeniería de

Pregrado
Sistemas
Técnicas – Validación de Requerimientos.
Actividades
Validación
Estudio de
Análisis de de de
Artefactos

de de Sistema de
factibilid Re Re
ad qu qu
eri eri
mi mie
ent nto
Ingeniería de
Pregrado
Sistemas

Técnicas – Validación de Requerimientos.
La validación incluye dos pasos:
 Asegurar que cada especificación pueda ser rastreada hasta su
requerimiento en el documento de definición.
 Luego se chequea la definición para ver si cada requerimiento
es rastreable hasta la especificación.
Es importante recordar, que la validación no es tan solo un

rastreo de traza. Ya que, además, pretende garantizar que el
sistema hará lo que los clientes y usuarios esperan. Validando
que las metas e intenciones de los usuarios y clientes están
satisfechas.
Una forma simple de validar los requerimientos es la

realización de reuniones de revisión.
Ingeniería de
Técnicas – Validación de Requerimientos Sistemas
Revisiones de Requerimientos
 Participan representantes
 del cliente: operadores, quienes realicen entradas, utilicen salidas, y
sus gerentes.
 del equipo de desarrollo: analistas de requerimientos, diseñadores,
encargados de pruebas y gestión de configuración.
 Incluye:
• Revisar objetivos del sistema.
• Evaluar alineamiento de requerimientos con los objetivos (necesidad).
• Revisar el ambiente de operación y las interfaces con otros sistemas.
• Funciones completas, restricciones realistas.
• Evaluar riesgos.
• Considerar:
o Pruebas del sistema.
o Cambios en los requerimientos en el proyecto, su verificación y
validación.
Ingeniería de
Pregrado
Sistemas
Medición de Requerimientos
La medición de requerimientos está enfoca a tres áreas: Producto,
Proceso y Recursos.
Los productos de los requerimientos (definición y especificación)

pueden ser evaluados en primer lugar considerando el número
de requerimientos.
De manera similar se puede medir la cantidad de cambios

introducidos a los requerimientos. Un gran número de
cambios indica cierta inestabilidad o incertidumbre en la
comprensión de lo que el sistema debe hacer o como
comportarse.
También es bueno evaluar la incertidumbre por tipo de

requerimiento. Esto permite seccionar.
Ingeniería de
Pregrado
Sistemas
Debido a que los requerimientos son utilizados por los
diseñadores y verificadores, pueden utilizarse medidas que
reflejen cuando los requerimientos están preparados para derivar
a ellos.
Existe un forma de evaluación utilizada para verificadores y

diseñadores, donde califican los requerimientos en una escala de
1 a 5 para saber si estos están listos.
La escala es la siguiente:
7. Lo comprende por completo, ha diseñado (verificado) requerimiento

similar antes y no debería tener problema.
8. El requerimiento posee algún elemento que le resulta nuevo, pero no es

radicalmente distinto de lo que ha diseñado (verificado) con éxito antes.
Ingeniería de
Pregrado
Sistemas
1. Hay elementos nuevos que lo hacen muy diferente de los que ha
diseñado (verificado) antes, pero los comprende y piensa que a partir de
ellos puede desarrollar un buen diseño (prueba).
2. Hay partes del requerimiento que no entiende bien y no está seguro de
poder desarrollar un buen diseño (prueba).
3. No comprende este requerimiento en absoluto y no puede desarrollar
un diseño (prueba) para él.
Si un verificador o diseñador entrega un perfil con mayoría de 1 y

2 entonces el requerimiento esta en forma y puede pasar al
equipo de diseño o verificación.
Diseñadores Verificadores
OK
A
1 2 3 4 5 1 2 3 4 5
1 2 3 4 5 1 2 3 4 5
Ingeniería de
Pregrado
Sistemas
Bibliografía
 Software Engineering 6a. ed.– Ian Sommerville –
Pearson Education – 2000.(Cap. 5 y 6)
 Ingeniería de Software Teoría y Práctica – Shari
Lawrence Pfleeger – Pearson Education – 2002.
(Cap 4)
Ingeniería de
Pregrado
Sistemas
Gracias por su atención

AYD-Sesión 06

Cargado por

Copyright:

Formatos disponibles

AYD-Sesión 06

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

AYD-Sesión 06

Cargado por

Copyright:

Formatos disponibles

Pregrado

Analiza y Diseña Sistemas de Información con el

Importancia de los requerimientos

Etapa en la que se encuentra el error Costo en USD

Análisis y Esp. Requerimientos 1

 Es un documento que debe escribirse en términos

 Documento que reitera la definición de los requerimientos

A veces un único documento puede servir para ambos

Pero a menudo se necesitan ambos documentos.

Esto para que la visión del cliente este unida a la de los

Según a quien van dirigidos se clasifican en:

 Requerimientos del Usuario.

Describen la funcionalidad o los servicios que se espera

Cuando se expresan como Requerimientos del

Cuando se expresan como requerimiento del sistema

Son los requerimientos que no se refieren directamente

Muchos requerimientos no funcionales se refieren al sistema

A menudo son mas críticos que los funcionales. Mientras que

Los requerimientos no funcionales se clasifican según su

Del producto: especifican comportamiento del producto. Ej.:

 Organizacionales: se derivan de las políticas y

Externos: cubre todos los requerimientos que se derivan de

Un problema común con los requerimientos no funcionales es

De forma ideal los requerimientos no funcionales se deben

Se derivan del dominio del sistema más que de las

Son importantes debido a que a menudo reflejan los

Estos se expresan utilizando un lenguaje especifico del

Características de los requerimientos

 Permitir que el desarrollador explique como ha

 Indican a los diseñadores que funcionalidades y

 Los requerimientos indican al equipo de pruebas que

Características de los requerimientos

Con este fin debe comprobarse que los requerimientos

 ¿los requerimientos son correctos?. Cliente y

 ¿los requerimientos son consistentes?. Es decir, ¿los

Características de los requerimientos

 ¿los requerimientos son realistas?.¿El sistema puede

 ¿describe cada requerimiento algo que es necesario

 ¿los requerimientos son verificables?. Debemos preparar

Características de los requerimientos

Proceso: Ingeniería de Requerimientos

La Ingeniería de Requerimientos (IR) es un proceso

Proceso: Ingeniería de Requerimientos

Informe Documento Modelo del Especificación

Proceso: Ingeniería de Requerimientos

Informe Documento Modelo del Especificación

Proceso: Ingeniería de Requerimientos

La entrada de este es una descripción resumida del

El resultado del estudio es un informe que recomienda

Este es un estudio corto para resolver si es posible y

Proceso: Ingeniería de Requerimientos

Informe Documento Modelo del Especificación

Proceso: Ingeniería de Requerimientos

Obtención y Análisis de requerimientos

Se trabaja en conjunto con los usuarios y los clientes.

 Los requerimientos están en sus términos y con

Proceso: Ingeniería de Requerimientos

Obtención y Análisis de requerimientos

Proceso de Obtención y Análisis de requerimientos.