Ingeniera De Requerimientos

Introduccin
cmo explicamos la alta incidencia de
fallos en los proyectos de software?
Por qu existen tantos proyectos de
software vctimas de retrasos,
presupuestos sobregirados y con
problemas de calidad?
Cmo podemos tener una produccin o
una economa de calidad, cuando
nuestras actividades diarias dependen de
la calidad del sistema?
Ingeniera de Requerimientos
Cumple un papel primordial en el
proceso de produccin de software, ya
que enfoca un rea fundamental: la
definicin de lo que se desea producir.
Su principal tarea es la generacin de
especificaciones correctas que
describan con claridad, sin
ambigedades, en forma consistente y
compacta, el comportamiento del
sistema
13
12 12
7
6
50
0
10
20
30
40
50
60
I
n
f
o
r
m
a
c
i

n
e
r
r

n
e
a

d
e
l
u
s
u
a
r
i
o
R
e
q
u
i
s
i
t
o
s
i
n
c
o
m
p
l
e
t
o
s
C
a
m
b
i
o
s

e
n
l
o
s
r
e
q
u
i
s
i
t
o
s
H
a
b
i
l
i
d
a
d
e
s
t

c
n
i
c
a
s
p
o
b
r
e
s
M
a
l
a
d
i
r
e
c
i

n
O
t
r
o
s
Ms de 37% de los proyectos de software
fracasan debido a problemas en los
requerimientos.
Requerimientos
Tipos:
Funcionales
No funcionales
Caractersticas
Necesario
Conciso
Completo
Consistente
No ambiguo
verificable
Ingeniera de Requerimientos
El proceso de recopilar, analizar y
verificar las necesidades del cliente
para un sistema es llamado Ingeniera
de Requerimientos.
La meta de la ingeniera de
requerimientos (IR) es entregar una
especificacin de requisitos de
software correcta y completa.
Personal involucrado en la
Ingeniera de Requerimientos
Usuario final
Usuario Lder
Analistas y programadores
Personal de pruebas
Puntos a considerar durante la
Ingeniera de Requerimientos
Barreras de comunicacin: intensa
comunicacin entre clientes y
analistas de requerimientos
Evolucin e integracin del sistema:
quizs comprender sistemas ya
existentes
Documentacin de requerimientos:
dificultad para comprender
documentos largos.
Actividades de la IR
Anlisis del Problema
Evaluacin y Negociacin
Especificacin
Validacin
Evolucin
Anlisis del Problema
entender las verdaderas necesidades
del negocio
Pasos:
Comprender el problema que se est
resolviendo: perspectiva tcnica como la
del negocio
Construir un vocabulario comn. Ej:
glosario
Anlisis del Problema
Identificar a los afectados por el sistema
Quin usar el sistema que se va a construir?
Quin desarrollar el sistema?
Quin probar el sistema?
Quin documentar el sistema?
Quin dar soporte al sistema?
Quin dar mantenimiento al sistema?
Quin vender, y/o distribuir el sistema?
Quin se beneficiar por el retorno de inversin
del sistema?
Definir los lmites y restricciones del sistema
Evaluacin y negociacin de los
requerimientos
pasos
Descubrir problemas potenciales
Clasificar los requerimientos: prioridad.
Mandatorio
Deseable
Innecesario
=>hecha esta categorizacin, se puede tomar como
estrategia general el incluir los mandatorios,
discutir los deseables y descartar los
innecesarios
Evaluar factibilidades y riesgos
Especificacin de Requisitos de
Software (SRS)
actividad en la cual se genera el
documento con descripcin completa de
las necesidades y funcionalidades del
sistema
describe el alcance del sistema
Define requerimientos funcionales y los
no funcionales
requerimientos de hardware y software
Diagramas
modelos de sistemas
Especificacin de Requisitos de
Software (SRS)
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.
Validacin de Requisitos
Es la actividad de la IR que 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
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)
Validacin de Requisitos
Pueden los requerimientos ser implementados
con la tecnologa y el presupuesto disponible?
(factible)
Est la SRS escrita en un lenguaje apropiado?
(clara)
Est claramente definido el origen de cada
requisito? (rastreable)
Pueden los requerimientos ser sometidos a
medidas cuantitativas? (verificable)
Evolucin de los
requerimientos
esencial planear posibles cambios a
los requerimientos cuando el sistema
sea desarrollado y utilizado
es un proceso externo que ocurre a lo
largo del ciclo de vida del proyecto
Ojo !!
Tcnicas y herramientas
utilizadas en la IR
Entrevistas y Cuestionarios
Lluvia de Ideas (Brainstorm)
Prototipos
Prototipo rpido (o concept prototipe):
Prototipo evolutivo
Administracin de Requerimientos con
Casos de Uso
Qu son los Casos de Uso?
Casos de Uso
Son una tcnica para especificar el
comportamiento de un sistema: "Un caso de
uso es una secuencia de interacciones entre un
sistema y alguien o algo que usa alguno de sus
servicios.
Por ejemplo: un sistema de ventas, si pretende
tener xito, debe ofrecer un servicio para
ingresar un nuevo pedido de un cliente. Cuando
un usuario accede a este servicio, podemos
decir que est "ejecutando" el caso de uso
ingresando pedido.
Los Casos de Uso y UML
Son una excelente forma de
especificar el comportamiento externo
de un sistema
fue incorporada al lenguaje estndar
de modelado UML (Unified Modeling
Language) propuesto por Ivar
Jacobson, James Rumbaugh y Grady
Booch
Definiciones y Notaciones
Actores
Casos de uso
Extensiones
Relaciones
Abstraccin
Herencia
Actores
Un actor es una agrupacin uniforme de
personas, sistemas o mquinas que
interactan con el sistema que estamos
construyendo de la misma forma.
Por ejemplo, para una empresa que recibe
pedidos en forma telefnica, todos los
operadores que reciban pedidos y los
ingresen en un sistema de ventas, si
pueden hacer las mismas cosas con el
sistema, son considerados un nico actor:
"Empleado de Ventas".
Actores
Es importante tener clara la diferencia
entre usuario y actor.
Un actor es una clase de rol, mientras
que un usuario es una persona que,
cuando usa el sistema, asume un rol

Actores
Los actores se
representan
con dibujos
simplificados
de personas,
llamados en
ingls "stick
man" (hombres
de palo).
Actores
Otro sistema
que interacta
con el que
estamos
construyendo
tambin es un
actor
Casos de Uso
Las flechas pueden usarse para indicar el
flujo de informacin entre el sistema y el
actor.
El nombre se expresa con un verbo en
gerundio, seguido generalmente por el
principal objeto o entidad del sistema que
es afectado por el caso.
Grficamente, los casos de uso se
representan con un valo, con el nombre
del caso en su interior.
Casos de Uso
Grficamente,
los casos de
uso se
representan
con un valo,
con el nombre
del caso en su
interior.
Importante: el nombre del
caso siempre est
expresado desde el punto
de vista del actor y no desde
el punto de vista del
sistema.
Conclusiones y recomendaciones
A pesar de la importancia que tiene la Ingeniera
de Requerimientos, ha costado mucho que se le
preste la atencin adecuada a esta actividad.
No existe un modelo de proceso ideal para la IR
IR no depende solamente de la forma en cmo
se percibe el problema, sino tambin, del nivel
de experiencia que tengan los involucrados.
tomarse el tiempo necesario para conocer a
nuestros clientes y usuarios, as como su
ambiente de trabajo.
Conclusiones y recomendaciones
El uso de la tcnica de Casos de uso
es independiente del mtodo de
diseo a usar.
Finalmente, entregar software de
calidad, a tiempo y dentro del
presupuesto, har que nuestros
clientes confen y asegurar el
crecimiento y madurez de la relacin
de negocio