1. INGENIERIA DE
REQUISITOS
Lic. Roxana Laurel R.

2. INTRODUCCION
 Lo
más difícil en la construcción de un
sistema software es decidir precisamente
qué construir... No existe tarea con mayor
capacidad de lesionar al
sistema, cuando se hace mal... Ninguna
otra tarea es tan difícil de rectificar a
posteriori...
 F. P. Brooks, 1987

3. LA EXPERIENCIA EMPIRICA
DEMUESTRA…






Los requisitos contienen demasiados errores
Muchos de estos errores no se detectan al
principio
Muchos de estos errores podrían ser
detectados al principio
No detectar estos errores incrementará los
costes (tiempo, dinero) de forma exponencial
Además, los programadores obedecen los
requisitos
(cuando existen).

4. CONSECUENCIAS
 El
sistema resultante no satisfará a los
usuarios
 Se producirán desacuerdos entre usuarios
y desarrolladores
 Puede ser imposible demostrar si el
software cumple, o no, los requisitos
 Se gastará tiempo y dinero en construir el
sistema equivocado

5. COMPLEJIDAD
•
OJO: No estamos hablando de sistemas
de 15 o 30 requisitos. También hay





Sistemas de cientos de requisitos
Sistemas de miles de requisitos
Sistemas de 5.000 requisitos
Sistemas de más de 10.000
Sistemas de incluso 60.000 requisitos

6. 1995/200: THE CHAOS REPORT





Gasto anual en EEUU: $250 mil millones en
unos
175.000 proyectos.
31,1% (23%) son cancelados
52,7% (49%) cuestan un 190% más de lo
estimado
Un 16,2% (28%) será finalizado a tiempo y
dentro del presupuesto, pero el producto final
poseerá (aprox.) la mitad de los requisitos
iniciales

7. ACUMULACION DE ERRORES

8. ¿QUÉ ES UN REQUISITO?
 Un
requisito es una ”condición o
capacidad que necesita el usuario para
resolver un problema o conseguir un
objetivo determinado”.
 También
se aplica a las condiciones
que debe cumplir o poseer un sistema o
uno de sus componentes para
satisfacer un contrato, una norma o una
especificación.

9. INGENIERIA DE REQUISITOS
o
o
La IR trata de los
principios, métodos, técnicas y
herramientas que permiten
descubrir, documentar y mantener los
requisitos para sistemas basados en
computadora, de forma sistemática y
repetible.
Los requisitos pueden ser funcionales y no
funcionales

10. REQUISITOS FUNCIONALES
Definición de los servicios que el sistema debe
proporcionar, cómo debe reaccionar a una
entrada particular y cómo se debe comportar
ante situaciones particulares.



Describen el funcionamiento del sistema
Los RF del usuario pueden ser frases muy
generales sobre lo que el sistema debería
hacer. Se suelen expresar como objetivos del
sistema.
Los RF del sistema deben describir los servicios
que hay que proporcionar con todo detalle: los
casos de uso

11. REQUISITOS FUNCIONALES
EJEMPLOS:
1. Se deben poder realizar búsquedas en
base a diferentes criterios.
2. Se deben proporcionar diferentes visores
para que el usuario lea los documentos
recuperados.
3. Cada factura tendrá un número único y
correlativo y la fecha.

12. REQUISITOS NO FUNCIONALES
Restricciones que afectan a los servicios o funciones
del sistema, tales como restricciones de tiempo,
sobre el proceso de desarrollo, estándares, etc.



Definen propiedades emergentes del sistema, tales
como el tiempo de respuesta, las necesidades de
almacenamiento, la fiabilidad, …
Pueden especificar también la utilización de una
herramienta CASE en particular, un lenguaje de
programación o un método del desarrollo.
Pueden ser más críticos que los funcionales.


Si un RF no se cumple, el sistema se degrada
Si un RNF no se cumple, el sistema puede inutilizarse

13. REQUISITOS NO FUNCIONALES
EJEMPLOS:



“El máximo espacio de almacenamiento
ocupado por el sistema debe ser de 8 MB
porque el sistema debe alojarse
completamente en una memoria de sólo
lectura e instalarse en el coche”
“El proceso software y los documentos a
realizar deben conformar el proceso y los
estándares de documentación recogidos en
la norma TELMo-ES-2003”
“El sistema no debe revelar ninguna
información personal sobre los clientes
excepto su nombre y su número de
referencia"

14. ¿COMO ESCRIBIR REQUISITOS?




La “mejor forma” de escribir requisitos no
existe
Lo más utilizado es el lenguaje natural. Cada
requisito expresado en una frases corta (“el
sistema hará X ...”, “se facilitará Y...”, etc)
O lenguaje natural complementado con
diagramas y/o notaciones formales
La notación utilizada depende de quien lee o
quien escribe los requisitos.

15. Procesos de la Ingeniería de
Requerimientos
 La
Ingeniería de Requerimientos es un
proceso que comprende todas las
actividades requeridas para crear y
mantener un documento de
requerimientos del sistema

16. Procesos de la Ingeniería de
Requerimientos
 Las
4 actividades genéricas de alto nivel
son:




estudio de factibilidad del sistema
obtención y análisis de requerimientos
especificación y documentación de los
requerimientos
la validación de los requerimientos

17. ESTUDIO DE FACTIBILIDAD
 Un
estudio de factibilidad es un estudio
corto y orientado a resolver varias
preguntas:



¿ el sistema contribuye a los objetivos
generales de la organización ?
¿ el sistema se puede implementar
utilizando la tecnología actual y con las
restricciones de costo y tiempo ?
¿ el sistema puede integrarse a otros que
existe en la organización ?

18. Procesos de la Ingeniería de
Requerimientos

19. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 El
personal del desarrollo técnico del
software trabajará con los clientes y los
usuarios finales del sistema para
determinar el dominio de la aplicación,
cuáles servicios debe proveer el sistema,
el desempeño requerido del sistema, las
restricciones del hardware, etc.

20. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 La
obtención y análisis es un proceso
difícil por varias razones:

los stakeholders (personas que tienen
influencia directa o indirecta sobre los
requerimientos del sistema) a menudo no
conocen realmente lo que desean
obtener, excepto en términos muy
generales.
 los
stakeholders expresan los
requerimientos con sus propios términos.

21. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 La
obtención y análisis es un proceso
difícil por varias razones (continuación):


diferentes stakeholders tienen
requerimientos distintos y podrían
expresarlos de varias formas. Se deben
identificar todas las fuentes de
requerimientos así como los conflictos.
Los factores políticos influyen en los
requerimientos. Las personas buscan
aumentar sus influencias.

22. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 El
método VORD (definición de
requerimientos orientados al punto de
vista) se ha diseñado como un marco de
trabajo orientado a servicios para la
obtención y análisis de requerimientos.

23. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 Las
etapas principales de VORD son:
1. Identificación de puntos de vista, que
implica descubrir los que reciben los servicios
del sistema e identificar los servicios
específicos que se suministran a cada punto
de vista.
2. Estructuración de puntos de vista que
comprende agrupar los relacionados en una
jerarquía

24. OBTENCION Y ANALISIS DE
REQUERIMIENTOS
 Las
etapas principales de VORD son:
3. Documentación de puntos de vista, que
comprende refinar la descripción de éstos y
los servicios identificados.
4. Trazado del punto de vista del sistema, que
comprende identificar los objetivos en un
diseño OO utilizando la información del
servicio encapsulado en los puntos de vista.

25. VALIDACION DE
REQUERIMENTOS
 Esta
validación muestra que éstos son los
que definen el sistema que el cliente
desea.
 Tiene mucho en común con el análisis
ya que implica encontrar problemas
con los requerimientos.

26. VALIDACION DE
REQUERIMENTOS
 La
validación de requerimientos es
importante debido a que los errores en el
documento de requerimientos pueden
conducir a costos excesivos al repetir el
trabajo cuando sean descubiertos.
 El costo de hacer un cambio en el
sistema es mucho mayor que reparar los
errores de diseño o codificación

27. VALIDACION DE
REQUERIMENTOS
 Las
verificaciones incluyen:
1. Verificación de validez: para incluir solo
requerimientos realmente útiles.
2. Verificación de consistencia: para evitar las
contradicciones entre los requerimientos.
3. Verificación de integridad: para incluir
todas las restricciones pedidas.

28. VALIDACION DE
REQUERIMENTOS
 Las
verificaciones incluyen:
4. Verificación de realismo: para asegurarse
que los requerimientos se pueden
implementar.
5. Verificabilidad: para reducir las discusiones
entre el cliente y el contratista, los
requerimientos deben redactarse de una
manera verificable.

29. VALIDACION DE REQUISISTOS
Algunas preguntas recomendadas para
realizar la validación:
o ¿ La fuente del requisito está
identificada?
o ¿ Cuáles otros requisitos están
relacionados con éste?
o ¿ El requisito viola alguna restricción del
dominio del sistema?
o ¿ El requisito se puede probar?

30. DOCUMENTACION DE LOS
REQUISITOS
 Los
objetivos de negocios que se desean
satisfacer con el sistema (esto viene del
modelo del negocio del cliente)
 La visión general del sistema ¿usted que
cree?
 El propósito del sistema ¿para que lo
necesito?
 Los objetivos del proyecto (y cómo mido
si se cumplieron o no)
 Los involucrados

31. DOCUMENTACION DE LOS
REQUISITOS
 Restricciones
impuestas (por el cliente o el
entorno)
 Otros hechos relevantes
 El alcance del proyecto
 El alcance del producto
 Los requisitos

32. DOCUMENTACION DE LOS
REQUISITOS
 Soluciones
ya existentes
 Riesgos
 Costos
iniciales (valoración inicial)
 Ideas de posibles soluciones

33. ¿COMO SE DEFINEN LOS
REQUISITOS ?
 Existen


diferentes técnicas:
Descripción en lenguaje natural
Lista de características (feature)

34. ADMINISTRACION DE
REQUERIMIENTOS
 Los
requerimientos para sistemas grandes
son siempre cambiantes.
 Una razón es porque no siempre el
problema puede definirse totalmente.
 Es difícil anticipar que efectos tendrá el
sistema nuevo en la organización, y
siempre se lo comparará con el sistema
anterior (manual o automatizado).

35. ADMINISTRACION DE
REQUERIMIENTOS
 Una
vez que los usuarios finales
experimenten el nuevo sistema surgirán
nuevos requerimientos porque:
 1. Por lo general un sistema grande tiene
una comunidad de usuarios diversa, los
que tienen diferentes tipos de
requerimientos, algunos contradictorios.
Esto obliga a aceptar algunos y desechar
otros.

36. ADMINISTRACION DE
REQUERIMIENTOS
 Una
vez que los usuarios finales
experimenten el nuevo sistema surgirán
nuevos requerimientos porque:
 2. Las personas que pagan por los
sistemas (clientes) raras veces son las
mismas que los usan. Los primeros
imponen requerimientos organizacionales
o presupuestarios, los segundos
funcionales.

37. ADMINISTRACION DE
REQUERIMIENTOS
 Una
vez que los usuarios finales
experimenten el nuevo sistema surgirán
nuevos requerimientos porque:
 3. El entorno de negocios y técnico del
sistema cambia y esto debe reflejarse en
el sistema mismo. Se puede introducir
nuevo hardware, puede ser necesario
que el sistema interactúe con otros
sistemas, etc.

38. ¿POR QUE FRACASAN LOS
PROYECTOS?

39. ¿QUIENES PARTICIPAN EN LA
IR?
 Entre
las personas implicadas hay que
considerar:




Organizaciones que integran la
organización del analista que está
diseñando el sistema
Organizaciones o sistemas de respaldo
Dirección
Usuarios

40. ¿QUIENES PARTICIPAN EN LA
IR?

41. PROBLEMAS RELACIONADAS
CON LAS PERSONAS
INVOLUCRADAS

Las vías que pueden dificultar la determinación
de los requisitos son:







Los usuarios no tienen claro lo que desean
Los usuarios no se involucran en la elaboración de
requisitos escritos
Los usuarios insisten en nuevos requisitos después
de que el coste y la programación se hayan
fijado.
La comunicación con los usuarios es lenta
Los usuarios no participan en revisiones o son
incapaces de hacerlo.
Los usuarios no comprenden los problemas
técnicos
Los usuarios no entienden el proceso del desarrollo

42. PROBLEMAS RELACIONADOS
CON LOS ANALISTAS

La correcta redacción de las
Especificaciones de requisitos del Software es
imprescindible para el correcto desarrollo del
proyecto. Por ello, en su redacción hay que
evitar:





Uso de terminología ambigua en la redacción
de los documentos de requisitos
Sobre especificación de los requisitos
Escritura poco legible, voz pasiva, abuso de
negaciones
Uso de verbos en condicional, expresiones
subjetivas
Ausencia de términos y verbos del dominio de
la aplicación

43. PROBLEMAS RELACIONADOS
CON LOS DESARROLLADORES
 El
personal técnico y los usuarios finales
pueden tener diversos vocabularios y
pueden llegar a creer incorrectamente
que están de acuerdo, no dándose
cuenta del desacuerdo hasta que se
provee el producto final.
 Los desarrolladores pueden intentar
encajar el sistema en un modelo
existente, en vez de desarrollar un sistema
adaptado a las necesidades del cliente.

44. TRABAJO DE INVESTIGACION
 Herramientas
CASE para la IR.
 Requisitos de usuario y sistema
 Técnicas para la especificación de
requisitos.