Sesion 3 - Ingeniería de Requisitos

UNIVERSIDAD NACIONAL HERMILIO VALDIZAN
FACULTAD DE INGENIERA INDUSTRIAL Y DE

SISTEMAS
EAP INGENIERA DE SISTEMAS
INGENIERA DE
REQUISITOS
SESION 3
TU PEOR
PESADILLA!!!!
Un cliente entra a tu oficina, se sienta te

mira directo a los ojos y dice :
Yo s que ud. piensa que entiende lo
que digo, pero lo que Ud. no entiende es
que lo que digo no es realmente lo que
quiero decir
Ralph Young
REQUERIMIENTOS O
REQUISITOS?
Requirements Engineering = Ingeniera de

Requisito
Request Engineering = Ingeniera de
Requerimiento
Qu es un Requerimiento?
Es una definicin abstracta de
alto nivel de un servicio que
debe proporcionar el sistema o
una restriccin de ste
REQUERIMIENTOS O
REQUISITOS?
Qu es un Requisito?
Son declaraciones que
identifican atributos,
capacidades , caractersticas y/o
cualidades que necesita cumplir
un sistema para que tenga
valor y utilidad para el usuario .
En otras palabras, los requisitos
muestran qu elementos y
funciones son necesarias para
un proyecto.
QUE ES INGENIERA DE REQUISITOS?
Es un proceso que comprende todas las

actividades requeridas para crear y
mantener un documento de requisitos
del sistema
El proceso de recopilar, analizar y
verificar las necesidades del cliente para
un sistema .
La meta de la ingeniera de requisitos es
entregar una especificacin de requisitos
de software, correcta y completa.
La parte ms difcil de construir un

sistema de software es decidir qu
construir []
Ninguna otra tarea afecta tanto
negativamente al sistema, al final, si
se realiza de manera incorrecta, al
inicio.
Frederick Phillips Brooks
Professor Department of Computer Scienc.
University of North Carolina. USA.
En la actualidad muchos de los desarrollos

de aplicaciones fracasan porque no se hace
un anlisis correcto sobre la determinacin
de requisito que tiene el usuario para darle
solucin a su problema de informacin.
La IR que facilita el mecanismo apropiado
para comprender lo que quiere el cliente,
analizando sus necesidades, confirmando su
viabilidad, negociando una solucin sin
ambigedad, validando la especificacin y
gestionando los requisitos para que se
transforme en necesidad operacional.
Tipos de usuarios del documento de requisitos

Clientes del sistema
Gerentes
Especifican los requisitos y los leen para

chequear que atienden sus necesidades.
Especifican cambios en los requisitos.
Usan los documentos de requisitos para
planificar una propuesta (oferta) para el sistema
y planificar el proceso de desarrollo.
Ingenieros de sistemas
Usan los requisitos para entender qu sistema

tiene que ser desarrollado.
Ingenieros de prueba de
sistemas
Usan los requisitos para desarrollar pruebas de

validacin para el sistema.
Ing. de mantenimiento
de sistemas
Usan los requisitos para ayudar a entender los

sistemas y las relaciones entre sus partes.
IEEE/ANSI 830-1998:
Standard for Software Requirements Specification
1.Introduccin
1.1.Propsito del documento de requisitos
1.2.Alcance del proyecto
1.3.Definiciones, acrnimos y abreviaturas
1.4.Resumen del resto del documento
2.Descripcin General
2.1.Perspectiva del producto
2.2.Funciones del producto
2.3.Caractersticas de los usuarios
2.4.Limitaciones generales
2.5.Suposiciones y dependencias
3.Requisitos Especficos
3.1.Requisitos funcionales, no funcionales
4.Apndices
5.ndice
Definiciones
Requisito:
Propiedad que debe ser exhibida por un software para
resolver un problema particular (SWEBOK).
Condicin o capacidad que necesita el usuario para
resolver un problema o conseguir un objetivo
determinado.
Especificacin de Requisitos Software (ERS,
SRS): Documento formal de los Requisitos del
Sistema
SRS Software Requirements Specification
Definicione
s
Ingeniera de Requisitos:
Conjunto de actividades para descubrir, documentar y
mantener un conjunto de requisitos
Establecer los servicios que el cliente requiere de un
sistema y las restricciones bajo las cuales opera y es
desarrollado.
Proceso de Ingeniera de Requisitos:
Conjunto estructurado de actividades de cuya
ejecucin se obtiene, valida y mantiene el documento
de requisitos del sistema
Gestin de Requisitos:
Actividad para gestionar los cambios en los
requisitos de un sistema.
Qu es un requisito?
Un requisito podra describir:
Una facilidad a nivel usuario
Ej.: el procesador de palabras debe incluir un verificador de ortografa y un

comando de correccin
Una propiedad muy general del sistema

Ej.: el sistema debe asegurar que la informacin personal nunca se haga
disponible sin autorizacin
Una restriccin especfica del sistema

Ej.: el sensor debe ser activado 10 veces por segundo
Una restriccin para el desarrollo del sistema

Ej.: el sistema debe ser desarrollado usando Ada
Cmo llevar a cabo algn clculo

Ej.: la nota final debe ser calculada sumando las notas del examen,
proyecto y cursada del estudiante basado en la siguiente frmula
nota final = nota_exam + 2 * nota_proy + 2/3 * nota_cursada
Propiedades del dominio: Cosas en el dominio de aplicacin

que son verdaderas independientemente que se construya o no
el sistema de software
Requisitos: Cosas en el dominio de aplicacin que se desean
sean verdaderas mediante la construccin del sistema de
software
Especificacin: Descripcin de comportamiento (y datos) que
el programa tiene que tener para cumplir los requisitos slo
puede ser descrito en trminos de los fenmenos
compartidos por la maquina y el dominio de aplicacin
Rol de los requisitos

Acuerdo desarrolladores-stakeholders
Aspecto contractual
Multipartes (comunicacin, conflicto y
cambio de visiones)
Base para el diseo del software
Minimizar defectos tanto como sea posible
Proyecto Tcnicamente factible
Soporte para verificacin y validacin
Soporte a la evolucin del sistema
Stakeholder:
Entidad que ser afectada por el
sistema y que tienen una influencia
directa
o
indirecta
sobre
los
requisitos del sistema.
Usuarios finales del sistema
Gerentes
involucrados
en
los
procesos
organizacionales
influenciados
o
que
influencian al sistema
Ingenieros responsables por el desarrollo y
mantenimiento del sistema,
Clientes de la organizacin
Cuerpos externos tales como autoridades
reguladoras o de certificacin.
.
STAKEHOLDERS
Posibles stakeholders de un sistema
automatizado de sealizacin ferroviaria:
Los Operadores responsables de ejecutar el
sistema de sealizacin
Tripulacin del tren
Gerentes ferroviarios
Pasajeros
Ingenieros de instalacin y mantenimiento de
equipos
Autoridades de certificacin de seguridad
Documentos de
Requerimientos
Existen dos documentos
que
emanan
del
anlisis de requerimientos:
Definicin de requerimientos
Es un documento que debe escribirse en
trminos 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.
Documentos de
Especificacin de requerimientos
Requerimientos
Documento que reitera la definicin de los
requerimientos en los trminos tcnicos
apropiados para el desarrollador del diseo
de un sistema.
Es la contrapartida tcnica al documento de
definicin de requerimientos y es escrito por los
analistas de requerimientos.
A veces un nico documento puede servir para
ambos propsitos, lo que lleva a un entendimiento
comn entre clientes, analistas de requerimientos
y diseadores.
Pero a menudo se necesitan ambos documentos.
Documentos de
Requerimientos
Es muy importante, que
al usar ambos
documentos
exista
una
correspondencia directa entre cada
requerimiento
del documento de
definicin y aquellos documentos en
la especificacin.
Esto para que la visin del cliente este
unida a la de los desarrolladores (esto se
logra
gracias
a
la
gestin
de
configuracin).
Clasificacin de
Requerimientos
Segn el Tipo los requerimientos se clasifican en:
Requerimientos funcionales.
Requerimientos no funcionales.
Requerimientos del Dominio.
Segn a quien van dirigidos se clasifican en:
Requerimientos del Usuario.
Requerimientos del Sistema.
Clasificacin de
Requerimientos
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 funcin de
ste, sus entradas y salidas, excepciones,
etc.
Clasificacin de
Requerimientos
Requerimientos no funcionales
Son los requerimientos que no se refieren
directamente a las funciones especficas 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 ms que a rasgos particulares del
mismo.
A menudo son mas crticos que los funcionales.
Mientras
que
un
incumplimiento
de
un
requerimiento funcional degrada el sistema, el de
un requerimiento no funcional del sistema lo
Clasificacin de
Requerimientos
Los requerimientos no funcionales se clasifican segn su
implicancia:
Del producto: especifican comportamiento del
producto. Ej.:
de desempeo en la rapidez de
ejecucin 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 polticas y
procedimientos existentes en la organizacin del cliente
y del desarrollador. Ej.: estndares en los procesos que
deben utilizarse, requerimientos de implementacin
como los lenguajes de programacin o el mtodo de
diseo a utilizar.
Clasificacin de
Requerimientos
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 comn con los requerimientos no funcionales
es que algunas veces son difciles de verificar.
De forma ideal los requerimientos no funcionales se deben
expresar de manera cuantitativa utilizando mtricas que se
puedan probar de forma objetiva. En la prctica, es difcil. El
costo es muy alto.
Clasificacin de
Requerimientos del dominio
Requerimientos
Se derivan del dominio del sistema ms que
de las necesidades especificas del usuario.
Son importantes debido a que a menudo reflejan
los fundamentos del dominio de la aplicacin. 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 aplicacin que a menudo es difcil
de comprender. Ej.: operacin para calcular
desaceleracin del tren, para un sistema de
control de trenes.
Caractersticas de los requerimientos

Es importante sealar que los requerimientos
pueden servir a tres propsitos:
Permitir que el desarrollador explique como ha
entendido lo que el cliente pretende del sistema.
Indican a los diseadores que funcionalidades
y caractersticas 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 haba ordenado.

Los requerimientos deben ser de alta calidad para
la
buena
comprensin
de
clientes
y
desarrolladores.
Con este fin debe comprobarse que los
requerimientos posean las caractersticas 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
simultneamente.
los requerimientos son completos?. El conjunto

de requerimientos es completo si todos los estados
posibles, cambios de estado, entradas, productos,
restricciones estn 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 slo aquellos que inciden
directamente en la resolucin del problema del cliente.
los requerimientos son verificables?. Debemos
preparar pruebas que demuestren que se han cumplido
los requerimientos.

los requerimientos son rastreables?. Se
puede rastrear cada funcin del sistema hasta el
conjunto de requerimientos que la establece?.
Resulta
fcil
encontrar
el
conjunto
de
requerimientos que coinciden a un aspecto
especifico del sistema?.
Fuentes de
Requerimientos
Modelo del Dominio
Deseos y necesidad
Modelo de la
situacin actual
De los interesados
Organizacin y
sistemas actuales
Requerimientos
Requerimientos
Reutilizables
Biblioteca de
Reutilizacin
Documentos
existentes
Tipo de
Requerimientos
recomendados
Plantilla de
Requerimientos
Proceso: Ingeniera de Requerimientos

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Estudio de Factibilidad
La entrada de este es una descripcin resumida del
sistema y como se utiliza dentro de una organizacin.
El resultado del estudio es un informe que recomienda si
es conveniente llevar a cabo la ingeniera de
requerimientos y el proceso de desarrollo del sistema.
Adems permite proponer cambios al alcance,
presupuesto, calendarizacin, etc.
Este es un estudio corto para resolver si es posible y
conveniente construir el sistema con la tecnologa
existente, las restricciones de costo y tiempo, etc.

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Obtencin y Anlisis de requerimientos
Se trabaja en conjunto con los usuarios y los
clientes.
Problemas Comunes:
No saben lo que quieren del sistema , slo en
trminos generales, no conocen el costo de sus
peticiones.
Los requerimientos estn en sus trminos y con
conocimientos implcitos de su propio trabajo.
Distintos usuarios tienen distintos requerimientos,
se deben encontrar todas las fuentes.
Influyen factores polticos.
La importancia de los requerimientos varia en el
tiempo.

Proceso de Obtencin y Anlisis de requerimientos.
Comprensin
Comprensin
del
del dominio
dominio
Verificacin
Verificacin
de
de Requerimientos
Requerimientos
Recoleccin
Recoleccin de
de
Requerimientos
Requerimientos
Priorizacin
Priorizacin
Clasificacin
Clasificacin
Resolucin
Resolucin de
de
Conflictos
Conflictos

Fases:
1.
Comprensin del Dominio: el analista debe desarrollar su

propia comprensin del dominio de la aplicacin. Ej.: Si fuera
un sistema para un supermercado este debe evaluar como
funciona un supermercado.
2.
Recoleccin de Requerimientos: ste es el proceso de

interactuar con los clientes y usuarios para descubrir sus
requerimientos . Ac se desarrolla la compresin del dominio.
3.
Clasificacin: considera la recoleccin no estructurada de

requerimientos y los organiza en grupos coherentes.

4.Resolucin de conflictos: de forma inevitable, cuando existen

muchos stakeholders involucrados, los requerimientos estarn en
conflicto. Est actividad se refiere a resolver estos conflictos.
5.Priorizacin: Descubrir la importancia de cada requerimiento.
Es til separar los requerimientos en tres categoras:
Requerimientos que deben ser absolutamente satisfechos.

Requerimientos que son muy deseables pero no indispensables.
Requerimientos que son posibles, pero que podran eliminarse.
6.Verificacin de Requerimientos: Los requerimientos se

verifican para descubrir si estn completos, son consistentes y
acorde con lo que realmente quieren los stakeholders.
No existe un enfoque perfecto ni universal aplicable a la obtencin
y anlisis de requerimientos .

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Especificacin de Requerimientos
Lenguaje Natural
Comprensible para el Cliente/Usuario.
Ambiguo (glosario).
Poca legibilidad (plantilla, formateo del texto).
Difcil de tratar
completitud).
(Verificar
correctitud,
consistencia,
Notaciones Especiales (ms formales)

Poca o ninguna ambigedad.
Facilita tratamiento.
Necesidad de entrenamiento en la notacin.
Dificultades de comprensin por Cliente/Usuario

Especificacin de Requerimientos
Notaciones Especiales.
Grficas vs. Basadas en texto
Estticas vs. Dinmicas
Descripciones Estticas.
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 Dinmicas
Especifican estados y las transiciones entre estados en el

tiempo.

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Validacin de Requerimientos
Proceso por el cual se determina si la especificacin es consistente

con las necesidades del cliente.
Incluye verificar trazabilidad
documento de requerimientos.
entre
la
especificacin
el
Se trabaja con un bosquejo completo del documento a diferencia

de la verificacin del Anlisis.
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

presupuesto y calendario).
Verificabilidad: Disear conjunto de pruebas para demostrar que el

sistema cumple esos requerimientos.
(incluye:
tecnologa,

Validacin de Requerimientos
Verificacin de Requerimientos no funcionales.
Son difciles de verificar.
Se deben expresar de manera cuantitativa utilizando mtricas

que se puedan probar de forma objetiva ( esto es IDEAL).
Propiedad
Medida
Rapidez
Transacciones por seg.
Tamao
KB.
Fiabilidad
Tiempo promedio entre fallas.
Robustez
Probabilidad de datos corruptos despus de la falla.
Portabilidad
Nmero de sistemas.
Facilidad de uso
Tiempo de capacitacin.
Para los usuarios es difcil especificarlos en forma cuantitativa.

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.
Diseadores: quienes utilizan los requerimientos como
base para el desarrollo de una solucin 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.

Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Modelado del Sistema
Existen una gran cantidad de mtodos para el

modelamiento de sistemas, a continuacin se nombran los
ms significativos:
Tablas de Decisin.
Diagramas de transicin de estados.
Redes de Petri.
Diagramas de Flujo de Datos.
Diagramas de Casos de Uso.
Tcnicas para
describir un
sistema entorno a
estados y
estmulos.

Modelado del Sistema Tablas de Decisin
Descripcin dinmica.
Conjunto de condiciones posibles en un cierto instante o
tiempo dado.
Estados donde se verifica una combinacin determinada de
Estados
las condiciones.
=Condicin
CondicinFalsa
Falsa
FF=
1
2
3
4
5
Acciones a tomar.
Importe
1000
V>
= Condicin
Condicion
es
Acciones
V = Condicin
Verdadera
Buenos Antecedentes
Verdadera
Ya oper antes
=condicin
condicinno
no
--=
Autorizar importa
Crdito
importa
Analizar antecedentes
X
X

Modelado del Sistema Tablas de Decisin
La tabla de decisin representa acciones a ser tomadas

cuando el sistema est en uno de los estados representados.
El nmero de estados es = 2^ n de condiciones, lo que da
como resultado tablas de decisin muy extensas.
Se puede verificar que si todo conjunto de posibles
condiciones resulta en una accin, entonces la especificacin
est completa. Tambin se puede analizar la consistencia de la
tabla, y eliminar cualquier caso conflictivo.
Modelado del Sistema Tablas de Transicin de Estados

Descripcin dinmica.
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 funcin de transicin de estados, F.
F(Si,Cj) = Sk
Modelado del Sistema Tablas de Transicin de Estados

Ejemplo de un diagrama de transicin de estados para
reserva de Hotel (Utilizando forma UML).
Condicin
INICIO
Solicitud de plaza
Acciones
ninguna
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 ocupa
El cliente desiste
Retirar de la lista
ninguna
Ocupada
Cancelada

Modelado del Sistema Diagramas de Flujo de Datos (DFD)
Descripcin dinmica
Proviene de Metodologa de Anlisis y Diseo Estructurado
fin de la dcada del 70.
Usados en versin original de OMT (Rumbaugh 91), no
incorporados a UML.
Antes de los Casos de Uso era una de las formas ms 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
Proceso
Datos que salen

Ejemplo:
Historia Clnica
Experiencia y
conocimiento
Registro Contable
Lista de exmenes y
servicios brindados
Examen
Mdico
Sntomas
Contabilidad
Medicacin y
Diagnostico
Factura
Paciente
Paciente

Permite visualizar cmo fluye la informacin por el sistema.

Est asociado a una realizacin particular del sistema.
El diagrama no es suficiente para precisar el comportamiento:
por un flujo que entra a un proceso desde un archivo,
un registro o todo el archivo?.
fluye
No estipula sincronizacin, un flujo llega a una entidad

externa y otro sale Estn 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 estn documentados con DFD.

Modelado del Sistema Casos de Uso (UML)
Tcnica 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 cmo debe
hacerlo.
Se describen mediante documentos de texto.
Introducido por Ivar Jacobson (1992).

Modelado del Sistema CasosLimite
de Uso
(UML)
del Sistema
Limite del Sistema
Ejemplo:
Casode
deUso
UsoEscenario
EscenarioVariable
Variable
Caso
<<extends>>
<<extends>>
Actor:
Actor:
Entidad Externa
Externa que
que interacta
interacta con
con elel
Entidad
sistema (persona
(persona identificada
identificada por
por un
un
sistema
roloosistema
sistemaexterno).
externo).<<extend>>
rol
Caso de
de Uso
Uso
Caso
<<include>>
Retiro de Monedas
<<include>>
Reutilizable
Reutilizable
<<include>>
Retiro
Cliente
<<include>>
Depsito
<<include>>
Casode
deUso:
Uso:
Caso
Validar con PIN
Conjunto de
de escenarios
escenarios posibles
posibles que
que
Conjunto
Generalizacin
Generalizacin
puede encarar
encarar un actor (o varios) con
puede
Validar
Cliente un actor (o varios) con
sistema para
para elel logro
logro de
de cierto
cierto
elel sistema
objetivo.
objetivo.
Validar con Scaner de Retina
Transferencia

Modelado del Sistema Eleccin de una Tcnica
Ninguna tcnica de especificacin es completa.
La eleccin de la tcnica esta limitada por:
Caractersticas del proyecto.
Preferencia de los desarrolladores.
Preferencias del cliente.
Por lo general se combinan varios enfoques, por
ejemplo:
Una tcnica para requerimientos funcionales.
Otra tcnica
funcionales.
para
los
requerimientos
no

Tcnicas Obtencin y Anlisis de Requerimientos
Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Tcnicas -Obtencin y Anlisis de requerimientos
Posibles conflictos:
Necesidades
Expectativas
Balancear
Ti
s
em
o
s
r
po
u
c
Re
Calidad
Alcance
Necesidades
Expectativas
Restriccion
es
Proces
o

Tcnicas :
Investigar antecedentes.
Entrevistas individuales/grupales.
Encuestas/Cuestionarios.
Tormenta de ideas.
Casos de Uso.
Prototipado.

Investigar Antecedentes
Estudio, muestreo, visitas,
Buena forma de comenzar un proyecto.
Interna: Estructura de la organizacin, Polticas y
procedimientos, Formularios e informes, Documentacin de
sistemas.
Externa: Publicaciones de la industria y comercio, Encuentros
profesionales, Visitas, Literatura y presentaciones de vendedores.
Ventajas
Ahorra tiempo de otros.
Prepara para otros enfoques.
Puede llevarse a cabo fuera
de la organizacin.
Desventajas
Perspectiva limitada.
Desactualizado.
Demasiado genrico.

Entrevistas Individuales y Grupales
Usar para:
Entender el problema de negocio.

Entender el ambiente de operacin.
Evitar omisin de requerimientos.
Mejorar las relaciones con el cliente.
Ventajas
Orientacin a las personas.
Interactivo / Flexible.
Rico.
Desventajas
Costoso.
Depende de las habilidades
interpersonales.

Encuesta / Cuestionario
No substituye la entrevista.
Antes de usar el enfoque:
Determinar la informacin que se precisa.
Desarrollar cuestionario.
Probarlo con perfil tpico.
Analizar resultado de las pruebas.
Su principal uso es para validar asunciones y obtener

datos estadsticos sobre preferencias.
Ventajas
Conveniente
para
contesta.
Respuestas annimas.
Desventajas
quien
Menos Rico.
Problemas
por
no
Respuestas.
Esfuerzo de desarrollo.

Tormenta de Ideas
Objetivo: Lograr consenso sobre los requerimientos.

Ayuda a la participacin 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 imaginacin.
Generar tantas ideas como sea posible.
Mutar y combinar ideas.

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 interacta.
Pueden ser usados en el diseo y en el testing del sistema.
Usarlo
Cuando el sistema est
orientado a la funcionalidad,
con varios tipos de usuarios.
Cuando la implementacin
se va a hacer OO y con UML.
No son la mejor eleccin:

Sistemas sin usuarios y con
pocas interfaces.
Sistemas
dominados
primariamente
por
requerimientos
no
funcionales y restricciones
de diseo.

Prototipado
Implementacin parcial, permite a los desarrolladores y

usuarios:
Entender mejor los requerimientos.

Cuales son necesarios, deseables.
Acotar riesgos.
Prototipo desechable: El propsito es solo establecer que

algo se puede hacer, luego se parte de cero en la construccin,
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 percepcin de la interfaz de usuario.

Arquitectura (riesgos tcnolgicos, tiempos de respuesta).
Otros aspectos riesgosos.

Tcnicas Validacin de Requerimientos.
Actividad
es
Estudio
Estudio de
de
factibilidad
factibilidad
Obtencin
Obtencin yy
Anlisis
Anlisis de
de
Requerimientos
Requerimientos
Especificacin
Especificacin
de
de
Requerimientos
Requerimientos
Validacin
Validacin
de
de
Requerimientos
Requerimientos
Artefacto
s
Informe
de
factibilida
d
Documento
de
Requerimient
os
Modelo del
Sistema
Especificacin
de
Requerimiento
s

Tcnicas Validacin de Requerimientos.
La validacin incluye dos pasos:
Asegurar que cada especificacin pueda ser rastreada hasta su

requerimiento en el documento de definicin.
Luego se chequea la definicin para ver si cada requerimiento es

rastreable hasta la especificacin.
Es importante recordar, que la validacin no es tan solo un

rastreo de traza. Ya que, adems, pretende garantizar que el
sistema har lo que los clientes y usuarios esperan. Validando
que las metas e intenciones de los usuarios y clientes estn
satisfechas.
Una forma simple de validar los requerimientos es la
realizacin de reuniones de revisin.

Tcnicas Validacin de Requerimientos
Revisiones de Requerimientos
Participan representantes
del cliente: operadores, quienes realicen entradas, utilicen salidas, y

sus gerentes.
del equipo de desarrollo: analistas de requerimientos, diseadores,
encargados de pruebas y gestin de configuracin.
Incluye:
Revisar objetivos del sistema.
Evaluar alineamiento de requerimientos con los objetivos (necesidad).
Revisar el ambiente de operacin 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 verificacin y validacin.
Medicin de Requerimientos
La medicin de requerimientos est enfoca a tres reas: Producto,
Proceso y Recursos.
Los productos de los requerimientos (definicin y especificacin)
pueden ser evaluados en primer lugar considerando el nmero de
requerimientos.
De manera similar se puede medir la cantidad de cambios
introducidos a los requerimientos. Un gran nmero de cambios
indica cierta inestabilidad o incertidumbre en la comprensin de lo
que el sistema debe hacer o como comportarse.
Tambin es bueno evaluar la incertidumbre por tipo de
requerimiento. Esto permite seccionar.
Debido a que los requerimientos son utilizados por los
diseadores y verificadores, pueden utilizarse medidas que
reflejen cuando los requerimientos estn preparados para
derivar a ellos.
Existe un forma de evaluacin utilizada para verificadores y
diseadores, donde califican los requerimientos en una
escala de 1 a 5 para saber si estos estn listos.
La escala es la siguiente:
1. Lo comprende por completo, ha diseado (verificado)
requerimiento similar antes y no debera tener problema.
2. El requerimiento posee algn elemento que le resulta nuevo,
pero no es radicalmente distinto de lo que ha diseado (verificado)
con xito antes.
3. Hay elementos nuevos que lo hacen muy diferente de los que ha
diseado (verificado) antes, pero los comprende y piensa que a
partir de ellos puede desarrollar un buen diseo (prueba).
4. Hay partes del requerimiento que no entiende bien y no est
seguro de poder desarrollar un buen diseo (prueba).
5. No comprende este requerimiento en absoluto y no puede
desarrollar un diseo (prueba) para l.
Si un verificador o diseador entrega un perfil con mayora

de 1 y 2 entonces el requerimiento esta en forma y puede
pasar al equipo de diseo o verificacin.
Verificadores
Diseadores
OK
A
1
B
1
Caractersticas
Los requisitos de un software suelen ser una
combinacin compleja de los requisitos de diferentes
personas en diferentes niveles de una organizacin y
del entorno en el cual operar el software.
Es fundamental que un requisito sea verificable.
Otros atributos que les caracterizan son:
Prioridad
Identificador nico.
Los requisitos deben ser lo ms claros y no

ambiguos que se pueda, y cuantificables (si es
posible).
Dificultades
Posibles Problemas con los Requisitos:
o No reflejan las necesidades reales del
cliente
o Son inconsistentes y/o incompletos
o Es costoso realizar cambios sobre los
requisitos una vez que han sido
acordados
o Puede haber malentendidos entre
clientes, analistas, ingenieros software,
Dificultades - Posibles Problemas con los

Requisitos:
Dificultade
s
Es frecuente que no est clara la frontera entre
Requisitos y Diseo.
En principio, los requisitos indican lo que el sistema
debe hacer y el diseo describe cmo lo hace.
En la prctica, ambas etapas son inseparables
porque:
o La arquitectura del sistema puede ser diseada para
estructurar los requisitos.
o El sistema interacciona con otros sistemas que generan
requisitos de diseo del software.
o El uso de un diseo especfico puede ser un requisito de
dominio.
Principios de la ingeniera de
requisitos
Hacer que los requisitos alcancen un estado ptimo
antes de alcanzar la fase de diseo en el proyecto
Lo buenos requisitos deben ser medibles,
comprobables, sin ambigedades o contradicciones,
etc.
Quin hace la Ingeniera de Requisitos?

Los Ingenieros de Software (Ingenieros de Sistemas o Analistas de
Sistemas) y los interesados (gerentes, clientes, usuarios finales).
IMPORTANCIA DE LA INGENIERA DE REQUERIMIENTOS?

El diseo y la construccin de un elegante programa de computadora
que resuelva el problema incorrecto no satisface las necesidades de
nadie. Por lo tanto, es muy importante entender lo que el cliente
quiere antes de comenzar a disear y construir un sistema basado en
PC.
Qu debe hacer el ingeniero de Requisitos?

Punto de inicio
Nocin de existencia de un problema que debe
ser resuelto, ej:
Insatisfaccin con estado corriente del sistema/negocio
Oportunidad del negocio
Potencial ahorro de tiempo, recursos, costos, etc.
Un ingeniero de requisitos es un agente de

cambio
El ingeniero de requisitos debe:
Identificar el problema/oportunidad
Cual es el problema que se debe resolver? (Identificar los

lmites)
En donde se debe resolver (Comprender el contexto)
De quien es el problema ? (Identificar los stakeholders)
Por qu necesita ser resuelto? (Identificar los objetivos de los
stakeholders)
Cmo podra ayudar un S.S. ( Plantear escenarios)
Cuando necesita resolverse? (Identificar restricciones de
desarrollo)
Que podra evitar que lo resolvamos? (Identificar riesgos y
viabilidad)
PASOS PARA HACER INGENIERA DE REQUERMIENTOS
Inicio.- Se define al mbito y la naturaleza del problema que

debe resolverse
Obtencin .- Ayuda al cliente a definir sus necesidades. QFD
Elaboracin.- Se refinen y modifican los requisitos bsicos
Negociacin .- Se definen las prioridades, cuales aspectos son
esenciales y en qu momento se requieren
Especificacin.- Puede ser un documento escrito, modelos
grficos, matemticos, etc.
Validacin.- Examinar existencia, omisiones y ambigedades
Gestin.- Identificar, controlar y rastrear los requisitos y los
cambios de stos en el proyecto
Ejercicio
Definir 10 requerimientos necesarios
para el desarrollo del problema
planteado.
Personal involucrado
Los roles pueden clasificarse de la siguiente manera:
Personal Involucrado
Usuario Final. Es la persona que usar el sistema
desarrollado. Ser quien utilice, disponga y se
encuentre familiarizado con los procesos que debe
realizar el software; as tambin, es el que utiliza las
interfaces y los manuales de usuario.
Usuario Lder. Es el individuo que comprende el
ambiente del sistema o el dominio del problema en
donde ser empleado el software desarrollado.
Personal de Mantenimiento. Para proyectos que
requieran un mantenimiento eventual, stas
personas son las responsables de la administracin
de cambios, de la implementacin y resolucin de
anomalas. Su trabajo consiste en revisar y mejorar
Personal Involucrado
Analistas y programadores. Son los responsables del desarrollo

del producto, en s ellos interactan directamente con el cliente.
Personal de pruebas. Se encarga de elaborar y ejecutar el plan
de pruebas para asegurar que las condiciones presentadas por el
sistema son las adecuadas. Son quienes validan si los
requerimientos satisfacen las necesidades del cliente.
Ejercicio
Mostrar una tabla con la cantidad de personal
requerido para el desarrollo y solucin del problema
planteado.
Tipo de personal
Cantidad
Justificacin
ACTIVIDADES DE LA INGENIERA DE
REQUERIMIENTOS
A pesar de las diferentes interpretaciones que cada
desarrollador tenga sobre el conjunto de actividades
mostradas en la tabla anterior, podemos identificar y extraer
cinco actividades principales que son:
1. ANLISIS DEL PROBLEMA

El objetivo de esta actividad es entender las
verdaderas necesidades del negocio para el cual
se har el proyecto.
Durante el anlisis del problema, se realiza una serie de
pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio, los pasos
serian los siguientes:
Comprender el problema que se est resolviendo

Construir un vocabulario comn
Identificar a los afectados del sistema
Definir los lmites y restricciones del sistema
PARA PROYECTO
Redactar el problema planteado.
Elaborar el vocabulario comn.
Identificar los afectados del sistema.
Definir los lmites y restricciones del problema a
solucionar.
2. EVALUACIN Y NEGOCIACIN DE
REQUERIMIENTOS
Las principales actividades son:
Descubrir problemas potenciales.
Clasificar los requerimientos (Prioridad de cada requerimiento
depender de las necesidades que tenga el negocio)
Busca identificar la importancia que tiene un requerimiento en
trminos de implementacin.
Mandatario
Deseable (se necesitan pero no son indispensables)
Innecesario
Una vez hecha esta categorizacin de los requerimientos, puedo tomar
como estrategia general el incluir los mandatorios, discutir los
deseables y descartar los innecesarios. Antes de decidir la inclusin de
un requerimiento, tambin debe analizarse su costo, complejidad, y
una cantidad de otros factores.
Las principales actividades son:

Evaluar factibilidades y riesgos
Factibilidades tcnicas
Factibilidades operacionales
Factibilidades econmicas
Factibilidades tcnicas (pueden implementarse los
requerimientos con la tecnologa actual?);
Factibilidades operacionales (puede ser el
sistema utilizado sin alterar el organigrama
actual?);
Factibilidades econmicas (ha sido aprobado por
los clientes el presupuesto?).
Incremento en la comunicacin entre el equipo de

desarrollo y los afectados. Para una comunicacin
efectiva, hay una serie de consideraciones a tener en
cuenta:
Documentar todos los requerimientos a un nivel de
detalle apropiado.
Mostrar todos los requerimientos a los involucrados
en el sistema.
Analizar el impacto que causen los cambios a
requerimientos antes de aceptarlos.
Establecer las relaciones entre requerimientos que
indiquen dependencias.
Negociar con flexibilidad para que exista un
beneficio mutuo.
Enfocarse en intereses y no en posiciones.
EJERCICIO.
Entregar documento en donde se enlisten los
requerimientos del sistema planteando los puntos
vistos anteriormente, dicho documento ser la
carta de presentacin de los equipos.
Exponer ante los compaeros los requerimientos
fundamentales para llevar a buen trmino la
solucin del problema a plantear. (tiempo de
exposicin max. 10 minutos)
3. ESPECIFICACIN DE REQUERIMIENTOS
DE SOFTWARE.
Es la actividad en que se genera el documento y
contiene una descripcin completa de las
necesidades y funcionalidades del sistema, que
ser desarrollado; describe el alcance del sistema
y la forma como har sus funciones, definiendo
los requerimientos.
En la especificacin se definen:
Todos los requerimientos de hardware

Todos los requerimientos de software
Diagramas
Modelos de sistemas y cualquier otra cosa que sirva de
soporte y gua para fases posteriores.
Los clientes y usuarios utilizan la SRS para comparar si lo

que se est proponiendo, coincide con las necesidades de la
empresa.
Los analistas y programadores la utilizan para
determinar el producto que debe desarrollarse.
El personal de pruebas elaborar las pruebas funcionales
y de sistemas en base a este documento.
Para el administrador del proyecto sirve como
referencia y control de la evolucin del sistema.
4. VALIDACIN DE LOS REQUISITOS

Permite demostrar que los requerimientos definidos en el
sistema son los que realmente quiere el cliente, adems
revisa que no se haya omitido ninguno, que no sean
ambiguos, inconsistentes o redundantes.
La validacin de requerimientos es importante pues de
ella depende que no existan elevados costos de
mantenimiento para el software desarrollado
No debe confundirse la actividad de

evaluacin de requerimientos con la
validacin de requerimientos. La
evaluacin verifica las propiedades de
cada requerimiento, mientras que la
validacin revisa el cumplimiento de las
caractersticas de la especificacin de
requisitos.
Durante la actividad de validacin pueden hacerse preguntas en

base a cada una de las caractersticas que se desean revisar. A
continuacin se presentan varios ejemplos:
Estn incluidas todas las funciones requeridas por el cliente?

(completa)
Existen conflictos en los requerimientos? (consistencia)
Tiene alguno de los requerimientos ms de una
interpretacin? (no ambigua)
Est cada requerimiento claramente representado?
(entendible)
Pueden los requerimientos ser implementados con la
tecnologa y el presupuesto disponible? (factible)
Est la SRS escrita en un lenguaje apropiado? (clara)
Existe facilidad para hacer cambios en los requerimientos?
(modificable)
Est claramente definido el origen de cada requisito?
(rastreable)
Pueden los requerimientos ser sometidos a medidas
cuantitativas? (verificable)
5. EVOLUCIN DE LOS REQUERIMIENTOS

La actividad de evolucin es un proceso externo que
ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones:
Porque al analizar el problema, no se hacen las
preguntas correctas a las personas correctas.
Porque cambi el problema que se estaba
resolviendo.
Porque los usuarios cambiaron su forma de
pensar o sus percepciones.
Porque cambi el ambiente del negocio.
Las actividades del proceso incluyen :

Extraccin de requerimientos
Anlisis del problema
Especificacin
Validacin
Evolucin

Sesion 3 - Ingeniería de Requisitos

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sesion 3 - Ingeniería de Requisitos

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDAD NACIONAL HERMILIO VALDIZAN

FACULTAD DE INGENIERA INDUSTRIAL Y DE

Un cliente entra a tu oficina, se sienta te

Requirements Engineering = Ingeniera de

QUE ES INGENIERA DE REQUISITOS?

Es un proceso que comprende todas las

La parte ms difcil de construir un

En la actualidad muchos de los desarrollos

Tipos de usuarios del documento de requisitos

Especifican los requisitos y los leen para

Usan los requisitos para entender qu sistema

Usan los requisitos para desarrollar pruebas de

Usan los requisitos para ayudar a entender los

Ej.: el procesador de palabras debe incluir un verificador de ortografa y un

Una propiedad muy general del sistema

Una restriccin especfica del sistema

Una restriccin para el desarrollo del sistema

Cmo llevar a cabo algn clculo

Propiedades del dominio: Cosas en el dominio de aplicacin

Rol de los requisitos

Caractersticas de los requerimientos

Caractersticas de los requerimientos

Caractersticas de los requerimientos

los requerimientos son completos?. El conjunto

Caractersticas de los requerimientos

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso de Obtencin y Anlisis de requerimientos.

Proceso: Ingeniera de Requerimientos

Comprensin del Dominio: el analista debe desarrollar su

Recoleccin de Requerimientos: ste es el proceso de

Clasificacin: considera la recoleccin no estructurada de

Proceso: Ingeniera de Requerimientos

4.Resolucin de conflictos: de forma inevitable, cuando existen

Requerimientos que deben ser absolutamente satisfechos.

6.Verificacin de Requerimientos: Los requerimientos se

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Notaciones Especiales (ms formales)

Proceso: Ingeniera de Requerimientos

No describe como cambian las relaciones con el tiempo

Especifican estados y las transiciones entre estados en el

Proceso: Ingeniera de Requerimientos

Proceso: Ingeniera de Requerimientos

Proceso por el cual se determina si la especificacin es consistente

Se trabaja con un bosquejo completo del documento a diferencia

Validez: compromiso con el usuario, que valide que es lo que

Consistencia: que no haya contradicciones.

Realismo: que se puedan implementar

Verificabilidad: Disear conjunto de pruebas para demostrar que el

Proceso: Ingeniera de Requerimientos

Verificacin de Requerimientos no funcionales.

Son difciles de verificar.

Se deben expresar de manera cuantitativa utilizando mtricas

Transacciones por seg.

Tiempo promedio entre fallas.

Probabilidad de datos corruptos despus de la falla.

Para los usuarios es difcil especificarlos en forma cuantitativa.

Proceso: Ingeniera de Requerimientos