1. “Pre-portada” (-2)
Ninguna de las ideas expresadas en
este curso debe considerarse una
verdad absoluta que es aplicable a
todos los escenarios existentes
Por el contrario, la aplicabilidad de
estas ideas depende del contexto
en el que se apliquen, del proyecto
a desarrollar, del proceso de
desarrollo, etc. 1

2. “Pre-portada” (-1)
Olvide usted que está en un curso de
Ingeniería del Software, imagine que tiene a un
cliente enfrente, y que este cliente necesita un
software...
¿cómo haría para solucionar
el problema?
Asumo que usted sabe programar al menos.
Imagine y describa todo lo que ocurre desde
que usted conoce al cliente hasta que termina
el trabajo y le entrega su software
2

3. “Pre-portada” (0)
¿cómo haría para solucionar
el problema?
para crear una solución, primero
es necesario tener claro y
comprender el problema...
3

4. REQUISITOS / REQUERIMIENTOS
¡todo lo que el cliente quiere,
exactamente lo que quiere,
a como de lugar y a cualquier precio!
Universidad de Los Andes
Demián Gutierrez
Febrero 2013
4

5. Requisitos / Requerimientos
¿qué es un requisito?
5

6. Requisitos / Requerimientos
Los requisitos expresan lo que el sistema debe hacer
para satisfacer las necesidades de sus clientes o
usuarios
“es un aspecto de un sistema o una descripción de
aquello que el sistema es capaz de hacer a fin de
cumplir su propósito”
[Pfleeger, 1998]
“Un requerimiento es un servicio que el sistema de
software debe satisfacer o una restricción bajo la
cual el sistema debe operar”
[Sommerville 2002]
si me lo preguntan, en lo personal, pienso que... 6

7. un requisito...
...es algo que el sistema debe ser
capaz de hacer (o una restricción
que debe cumplir) para que pueda
cumplir su propósito y satisfacer a
sus usuarios
7

8. Requisitos / Requerimientos
Los requerimientos se concentran en
el cliente y el problema a resolver
Definen (o deberían definir)
sobre el sistema:
Lo que el cliente quiere que haga...
Todo lo que el cliente quiere que haga...
Nada más que lo que el cliente quiere que haga...
8

9. Requisitos / Requerimientos
¡Los requisitos se
concentran en “qué”
debe hacer el
sistema, no en
“cómo” debe hacerlo!
Es decir, dejen de pensar por los momentos en
cómo los van a programar o implementar... 9

10. ¿Qué Definen los Requisitos?
Los datos que Las funciones La información
debe capturar y que debe que debe
almacenar ejecutar producir
La plataforma
de operación
del sistema
Aplicación (Hardware /
Software)
La tecnología
Restricciones
Requisitos de Operación
de información
que debe usar
Interacción Usuario /
Atributos de Calidad Las interfaces
Sistema
con otros
sistemas
Seguridad, facilidad de
La interfaz gráfica
uso, documentación,
usuario-sistema (GUI) 10
utilidad, etc.

11. ¿Qué Tipos de Requisitos?
Funcionales
Dependiendo si
definen o no
funcionalidad
No Funcionales
Tipos de
Requisitos
De Usuario
Dependiendo de a
quienes están
dirigidos
De Sistema
11

12. Requerimientos Funcionales / No
Funcionales
Los requerimientos Funcionales
Describen:
La funcionalidad o los servicios que se espera que el
sistema de software proveerá
La interacción entre el sistema de software y su
ambiente o contexto
Como el sistema deberá actuar bajo ciertos
estímulos o eventos
12

13. Requerimientos Funcionales / No
Funcionales
Ejemplos de Requerimientos
Funcionales:
R-010:
El sistema debe permitir el registro de nuevos usuarios en el
foro, los nuevos usuarios deben ser aprobados o rechazados
por un moderador antes de poder publicar mensajes
R-200:
Los usuarios deben poder intercambiar mensajes y
comunicarse por medio del foro, toda la comunicación debe
estar moderada para evitar conductas inapropiadas por parte
de los usuarios, mensajes basura y publicidad no deseada
13

14. Requerimientos Funcionales / No
Funcionales
Los requerimientos no Funcionales:
No se refieren directamente a las propiedades funcionales del
sistema, sino a sus propiedades emergentes o a
restricciones adicionales en el sistema o en el proyecto de
desarrollo de software.
Definen restricciones adicionales al sistema, tales como:
Proceso de desarrollo a utilizar, herramientas, lenguaje de
programación, limitaciones de presupuesto, de tiempo, de
interfaz, etcétera
¿Propiedades Emergentes?
14

15. Requerimientos Funcionales / No
Funcionales
Propiedades Emergentes:
Son aquellas que resultan del sistema como un todo y que es
muy difícil o imposible atribuirle a un componente particular de
éste.
Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad,
capacidad de almacenamiento, etcétera
El todo no siempre es la simple suma de sus partes...
15

16. Requerimientos Funcionales / No
Funcionales
Ejemplos de Requerimientos
no Funcionales:
R-430:
El sistema debe ser utilizable por medio de una interfaz WEB
R-233:
Se debe utilizar RUP como proceso de desarrollo del software
R-230:
El tiempo de respuesta del sistema al solicitar un reporte
nunca debe ser mayor a 10 segundos
16

17. Requerimientos Funcionales / No
Funcionales
Clasificación de Requerimientos no funcionales
(no interpretar literalmente, es sólo a modo de referencia)
Fuente: Sommerville 2002
17

18. Tipos de Requisitos (Clasificaciones)
Funcionales
Dependiendo si
definen o no
funcionalidad
No Funcionales
Tipos de
Requisitos
De Usuario
Dependiendo de a
quienes están
dirigidos
De Sistema
18

19. Requerimientos de Usuario / de Sistema
Requerimientos de Usuario:
Son aquellos que están dirigidos a los usuarios y
clientes del sistema (interesados en general).
Se redactan usando lenguaje natural (generalmente)
de forma “no técnica” con el objetivo de que el
personal no técnico los pueda entender
Requerimientos de Sistema:
Son aquellos dirigidos a personal técnico: analistas,
programadores, arquitectos, ingenieros, etcétera.
Generalmente están escritos en un lenguaje mucho
más técnico pero mucho más preciso que los
requerimientos de usuario
19

20. Requerimientos de Usuario / de Sistema
Documento de Especificación de Requerimientos
(DER)
Es el documento en el que usualmente se
especifican los requerimientos de usuario
Documento de Definición de Requerimientos
(DDR)
Es el documento en el que usualmente se
especifican los requerimientos de sistema
20

21. Requisitos / Requerimientos
nuevamente...
¿por qué son
importantes los
requisitos?
21

22. Requisitos
Se estima que un alto porcentaje de proyectos de
desarrollo de software fallan por:
Requisitos incompletos
Falta de participación del usuario
Expectativas poco realistas
Cambios en los requisitos y las especificaciones
El sistema dejó de ser necesario
22

23. Requisitos
Hoy en día la Ingeniería de Requisitos
se considera una etapa clave en el
desarrollo de software
Actualmente, se considera que la
satisfacción de los clientes es la mejor
métrica de calidad de un sistema
23

24. El Costo del Cambio (de requisitos)
Fase Costo
($)
Requerimientos 0
Diseño 1
Arquitectónico
Diseño 2
Detallado
Codificación 3
Pruebas 5
de Unidades
Validación 20
Puesta 100
en Marcha /
Operación
sin embargo, los métodos ágiles en general
desafían este punto de vista
Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006 24

25. ¿Por qué tienen éxito los
proyectos de software?
Encuesta realizada a Gerentes Ejecutivos del área de
Desarrollo de Software y TICs
Factores de éxito en el Proyecto % Respuestas
1 Usuarios involucrados con el proyecto 15,90%
2 Soporte de los Ejecutivos 13,90%
3 Requerimientos Claros 13,00%
4 Planificación Adecuada 9,60%
5 Expectativas Realistas 8,20%
6 Hitos pequeños y poco espaciados en el tiempo 7,70%
7 Personal competente 7,20%
8 Control sobre el proyecto por parte del personal 5,30%
9 Visión clara y objetivos 2,90%
10 Trabajo duro, personal enfocado y comprometido 2,40%
11 Otras 13,90%
100,00%
¡¡¡Dos de las tres primeras causas
están asociadas a los requisitos!!!
25
Tomado del Standish Group Report (1995)

26. ¿Cuáles han sido las mayores
amenazas en un proyecto de software?
Encuesta realizada a Gerentes Ejecutivos del área de
Desarrollo de Software y TICs
Factores que amenazaron el Proyecto % Respuestas
1 Falta de información de los usuarios 12,80%
2 Especificación de requerimientos incompleta 12,30%
3 Requerimientos y especificación compleja 11,80%
4 Falta de soporte ejecutivo 7,50%
5 Mala tecnología, mal uso de la tecnología 7,00%
6 Falta de recursos 6,40%
7 Expectativas poco realistas 5,90%
8 Objetivos poco claros 5,30%
9 Tiempos de desarrollo poco realistas (planificación) 4,30%
10 Tecnología nueva (desconocimiento) 3,70%
11 Otras 23,00%
100,00%
¡¡¡Las tres primeras causas
están asociadas a los requisitos!!!
26
Tomado del Standish Group Report (1995)

27. ¿Por qué fallan los
proyectos de software?
Encuesta realizada a Gerentes Ejecutivos del área de
Desarrollo de Software y TICs
Factores que acabaron/cancelaron el Proyecto % Respuestas
1 Falta de información de los usuarios 13,10%
2 Especificación de requerimientos incompleta 12,40%
3 Falta de recursos 10,60%
4 Expectativas poco realistas 9,90%
5 Falta de soporte ejecutivo 9,30%
6 Requerimientos cambiantes 8,70%
7 Falta de planificación 8,10%
8 El proyecto no se necesito más 7,50%
9 Falta de gestión adecuada de IT 6,20%
10 Problemas tecnológicos 4,30%
11 Otras 9,90%
100,00%
¡¡¡Dos de las tres primeras causas
están asociadas a los requisitos!!!
27
Tomado del Standish Group Report (1995)

28. Requisitos / Requerimientos
bien... pero...
¿cómo se obtienen
los requisitos?
28

29. Requisitos
¿Ingeniería de Requisitos?
Proceso de establecimiento de los
servicios que debe proporcionar un
sistema, así como de las restricciones
sobre las cuales debe operar
Ingeniería => Enfoque Sistemático
29

30. Procesos de la Ingeniería de Requisitos
Una visión:
Captura Análisis Especificación Validación
Otra visión (Según Pfleeger):
Análisis Descripción
Documentación
del del Prototipado
y Validación
Problema Problema
Definición y
Elicitación y Análisis
Especificación
... y hay otras...
30
(ver Sommerville cap. 6 / Pressman cap. 7)

31. Procesos de la Ingeniería de Requisitos
Captura Análisis Especificación Validación
Es la actividad por medio de la cual se obtienen
(capturan) los requerimientos
Observación Modelo de
Entrevistas
Directa Negocios
Lectura /
Análisis de Prototipos Otras...
Documentos
31

32. Procesos de la Ingeniería de Requisitos
¿Quién está detrás de la solicitud de este
trabajo? (Clientes)
¿Quién usará la solución? (Usuarios)
¿Cuál será el beneficio económico de una
solución exitosa?
¿Existe otra fuente para la solución requerida?
32
Tomado de Pressman 2005 / cap 7

33. Procesos de la Ingeniería de Requisitos
¿Cómo podría caracterizarse un buen resultado
generado por una solución? (¿Cómo sé que una
solución es buena?)
¿Cuáles problemas debería atacar la solución?
¿Podría usted mostrar o describir el ambiente de
negocios en el que se utilizará la solución?
¿Hay aspectos o restricciones especiales del
rendimiento que afecten la manera de enfocar la
solución?
33
Tomado de Pressman 2005 / cap 7

34. Procesos de la Ingeniería de Requisitos
En este punto, cuando el cliente ya está
hablando, uno se transforma en “pepito
preguntón”:
¿Por qué?
¿Y por qué?
¿Qué es esto?
¿Y esto otro?
¿Cómo hacen esto?
¿Y esto otro?
¿Quién hace esto?
...
34
Opinión personal

35. Procesos de la Ingeniería de Requisitos
¿Es usted la persona adecuada para contestar
esta pregunta? ¿Sus respuestas son oficiales?
¿Mis preguntas son relevantes para su
problema?
¿Estoy haciendo demasiadas preguntas?
¿Alguien más puede proporcionar información
adicional?
¿Debería preguntarle alguna otra cosa?
35
Tomado de Pressman 2005 / cap 7

36. Procesos de la Ingeniería de Requisitos
¿Cómo se soluciona el problema actualmente?
¿Entre que bandas de costos se debería mover
una solución para ser rentable?
... otras de seguro ...
¿Se le ocurre alguna?
36
Opinión personal

37. Procesos de la Ingeniería de Requisitos
Recuerde:
Una vez que comprenda algo,
repitalo al cliente con sus propias
palabras, y si éste lo entiende,
entonces usted estará seguro de que
lo ha entendido correctamente
37
Opinión personal

38. Procesos de la Ingeniería de Requisitos
Consejo:
Nunca vaya a una reunión de negocios o
a una entrevista de requerimientos sólo.
¡Dos es un número mágico!
¿Por qué cree usted que esto es así?
Consejo:
Tome notas / grabe la entrevista de ser
posible, y mantenga las grabaciones
para futuras referencias
38
Opinión personal

39. Procesos de la Ingeniería de Requisitos
Captura Análisis Especificación Validación
Inspecciones
Es la actividad por medio de Documentos
de la cual se extiende el Discusiones,
Entrevistas,
modelo de requisitos, se Talleres
buscan y localizan
Desarrollo de
errores, inconsistencias, prototipos
limitaciones, carencias, Muchas de las
técnicas de la actividad
etcétera... de captura
39

40. Procesos de la Ingeniería de Requisitos
Captura Análisis Especificación Validación
Es la actividad por medio de la cual se
documentan (escriben / se ponen en “blanco y
negro”) los requerimientos
Documento Documento
de Definición de de Especificación de
Requerimientos Requerimientos
¡Si los requerimientos no están por escrito
(de alguna manera), entonces NO SIRVEN!
40

41. Procesos de la Ingeniería de Requisitos
Captura Análisis Especificación Validación
Es la actividad por medio de la cual se VALIDAN
los requerimientos con el cliente
Muchas de las
Discusiones /
Inspecciones técnicas de la
Entrevistas /
de Documentos actividad
Talleres
de captura
!Esta actividad es crítica. Si los requerimientos
no se han validado, entonces NO SIRVEN!
41

42. Requisitos / Requerimientos
¿quiénes participan
en la ingeniería de
requerimientos?
42

43. Participantes en el Desarrollo de Software
CLIENTE /
EJECUTIVO /
USUARIO ¿serán
(Patrocina el
desarrollo del
sistema y
el cliente y
utiliza el
sistema) el usuario la
misma persona
en todos los
casos?
DESARROLLADOR
(Construye
el Sistema)
43

44. Participantes en el Desarrollo de Software
CLIENTE USUARIO
EJECUTIVOS (Utiliza el
(Patrocina el Sistema)
desarrollo
del sistema)
Proporciona Tiene
Financiamiento Necesidades
Tiene
Obligaciones
Proporciona
Contractuales
Sistemas de
Software
DESARROLLADOR
(Construye
el Sistema)
Pfleeger
(1998) 44

45. Participantes en el Desarrollo de Software
Otros
desarrolladores y
Usuarios
participantes en el
proyecto
Otros entes,
Clientes personas,
instituciones,
afectadas o
interesadas en el
sistema
A todas las
DESARROLLADOR personas
(Construye involucradas o
el Sistema) interesadas se
les llama
Stakeholder 45

46. Interesados / Actores / Protagonistas
(Stakeholders)
Instituciones
Consumidores Gubernamentales
Usuarios
Comunidad
analistas programadores
Empresa
Contratante
diseñadores
Líderes de
proyecto
Clientes Gerentes
Proveedores
Clientes de Consultores / arquitectos
la Empresa asesores
46

47. Requisitos / Requerimientos
¿problemas
con los requisitos?
¡DILBERT!
47

48. Requisitos (Problemas de los)
¡Para poder desarrollar software se
necesitan usuarios, comprometidos,
disponibles (e involucrados en el desarrollo)! 48

49. Requisitos (Problemas de los)
El cliente / usuario no siempre sabe o tiene claro lo que quiere
El cliente / usuario no se compromete con el proyecto
Se dan malas interpretaciones en los requerimientos
¿Ha jugado usted alguna vez al “telefonito”?
Usuario -> Cliente /Ejecutivo -> Analista ->
-> Especificación -> Diseño -> Implementación -> Usuario
Los requisitos cambian constantemente
(El cliente / usuario cambia de idea constantemente)
Fenómeno del “analista sabelotodo”: El analista cree que sabe
que es lo que necesita el cliente y por lo tanto no le consulta
49

50. Requisitos (Problemas de los)
El cliente / usuario no entiende a los analistas
(Lenguaje técnico del analista)
Los analistas no entienden al cliente / usuario
(Lenguaje asociado al dominio del cliente / usuario)
¿qué es el dominio del cliente?
¿dominio de aplicación?
Requisitos que: No reflejan las necesidades reales del cliente,
son inconsistentes, incompletos, no factibles, etcétera
Requisitos que el cliente no necesita realmente
50

51. Requisitos (Tres Leyes)
(Según Demián Gutierrez)
Primera Regla:
El usuario siempre tiene la razón
(Aunque se le puede intentar convencer de lo contrario)
Segunda Regla:
El cliente siempre tiene la razón, siempre y cuando esto no
contradiga lo establecido en le primera regla
Tercera Regla:
Usted (el desarrollador) tiene la razón, siempre y cuando esto
no contradiga la segunda o la primera regla
¿Conoce usted las tres leyes de la
robótica de Asimov?
51

52. Requisitos (Tres Leyes)
(Según Demián Gutierrez)
¡Ley Cero!
Ante la duda, siempre consulte al usuario /
cliente involucrado
¡Nunca dé nada por sentado!
52

53. Gracias
¡Gracias!
53