Requerimientos

Requisitos / Requerimientos
(!Todo lo que el cliente quiere,

exactamente lo que quiere,
a como de lugar y a cualquier precio!)
1
¿Qué es un requisito?
2
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... 3
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
4
Los requerimientos se concentran en

el cliente y el problema a resolver
Definen (o deberían) 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...

5
¡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 lo van a programar o implementar... 6
¿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) 7
utilidad, etc.
¿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
8
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
9
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
10
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?
11
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...
12
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
13
Funcionales
Clasificación de Requerimientos no funcionales

(no interpretar literalmente, es sólo a modo de referencia)
Fuente: Sommerville 2002
14
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
15
Requerimientos de Usuario / de Sistema
Requerimientos de Usuario:
Son aquellos que están dirigidos a los usuarios y
clientes (interesados en general) del sistema. 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
16
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
17
Nuevamente...
¿Por qué son

importantes los
requisitos?
18
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
19
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
20
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
Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006 21

Sin embargo...
Más adelante, veremos que hay métodos de

gestión y desarrollo de software que hasta cierto
punto desafían este punto de vista...
22
¿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!!!
23
Tomado del Standish Group Report (1995)
¿Cuáles han sido las mayores
amenazas en un proyecto de software?
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%
Nuevamente:
requisitos!!!
24
¿Por qué fallan los
proyectos de software?
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%
¡¡¡Nuevamente!!!
requisitos!!!
25
Bien... pero...
¿Cómo se obtienen
los requisitos?
26
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

27
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...

28
(ver Sommerville cap. 6 / Pressman cap. 7)
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
29
¿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?
30
Tomado de Pressman 2005 / cap 7
¿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?
31
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?
...
32
Opinión personal
¿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?
33
¿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?
34
Opinión personal
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
35
Opinión personal
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
36
Opinión personal
Inspecciones
Es la actividad por medio de
Documentos
de la cual se extiende el
Discusiones,
modelo de requisitos, se Entrevistas,
Talleres
buscan y localizan Desarrollo
errores, inconsistencias, de
prototipos
limitaciones, carencias, Muchas de las
técnicas de la
etcétera... actividad
de captura 37
Es la actividad por medio de la cual se

documentan (escriben / se ponen en “blanco y
negro”) los requerimientos
Documento
Documento
de
de Definición
Especificación
de
de
Requerimientos
Requerimientos
¡Si los requerimientos no están por escrito

(de alguna manera), entonces NO SIRVEN!
38
Es la actividad por medio de la cual se VALIDAN

los requerimientos con el cliente
Muchas de las
Inspecciones Discusiones /
técnicas de la
de Entrevistas /
actividad
Documentos Talleres
de captura
!Esta actividad es crítica. Si los requerimientos

no se han validado, entonces NO SIRVEN!
39
¿Quiénes participan
en la Ingeniería de
Requerimientos?
40
Participantes en el Desarrollo de Software
CLIENTE /
EJECUTIVO /
USUARIO
(Patrocina el
desarrollo del
¿Serán
sistema y
utiliza el
el cliente y
sistema)
el usuario lo
mismo en todos
los casos?
DESARROLLADOR
(Construye
el Sistema)
41
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) 42
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 43
Interesados / Actores / Protagonistas
(Stakeholders)
Instituciones
Consumidores Gubernamen
Usuarios tales
Comunidad
programad
analistas
ores
Empresa
diseñadore Contratante
s
Líderes de
proyecto
Clientes Gerentes
Proveedore
Clientes de s Consultores
/ arquitectos
la Empresa
asesores
44
¿Problemas
Con los Requisitos?
¡Dilbert!
45
Requisitos (Problemas de los)
¡Para poder desarrollar software se

necesitan usuarios, comprometidos,
disponibles (e involucrados en el desarrollo)! 46
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
47
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

48
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?
49
Requisitos (Tres Leyes)
(Según Demián Gutierrez)
¡Ley Cero!
Ante la duda, siempre consulte al usuario /

cliente involucrado
¡Nunca dé nada por sentado!
50
¿Cómo se
documentan los
requisitos?
51
¿Qué necesito saber / definir sobre un
sistema?
Los objetivos de negocios que se desean satisfacer con el

sistema (esto viene del modelo de negocio del cliente)
La visión general del sistema

¿Usted qué cree?
El propósito del sistema

¿Para qué lo necesito?
Los objetivos del proyecto

(y como mido si se cumplieron o no)
Los involucrados
52
Fundamentado en base a la plantilla Volere, edición 14, Enero 2009
sistema?
Restricciones impuestas (por el cliente o el entorno)
Otros hechos relevantes
El alcance del proyecto
El alcance del producto
Los requisitos (evidente)

Y los hay de muchos tipos (ver la plantilla Volere)
53
sistema?
Otros aspectos
Soluciones ya existentes
Riesgos (Ojo, algunos tratan la “gestión de riesgos como algo

completamente aparte y distinto)
Costos estimados (Valoración inicial)
Ideas de posibles soluciones
54
¿Cómo se definen los requerimientos?
Listas de “Features” (Características)
55
56
57
Discusión
¿Qué ventajas / desventajas tendrán las listas

de “Features” sobre las descripciones
textuales en lenguaje natural?
58
Plantillas para Definir Requerimientos
59
Tomado de la plantilla Volere, edición 14, Enero 2009
# de 045 Tipo de Funcional Ca so de 054
Re qu isit o: Re qu isit o: Uso / Eve nt o
Re la ciona do:
De scr ip ción : Los usuar ios deben poder intercam biar m ensajes y com unicar se por
m edio del foro, toda la com unicación debe estar m oderada para
evitar conductas inapropiadas por par te de los usuar ios, m ensajes
basura y publicidad no deseada.
Just if ica ción : Esta es la razón de ser del sistem a, el objet ivo pr incipal de un foro
WEB es perm it ir intercam biar m ensajes entre usuar ios.
Or ige n Pedro Moreno
( I nt e re sa do) :
Cr it e r io de El usuar io debe poder publicar un m ensaje.
Ace pt a ción / El m ensaje no debe aparecer hasta que un m oderador lo acepte.
Va lida ción : Si un m oderador acepta el m ensaje entonces éste aparece publicado.
Si un m oderador rechaza el m ensaje entonces éste no es publicado.
N ive l de 5 N ive l de 5
sa t isfa cción de l insa t isfa cción de l
Int e re sa do: Int e re sa do:
Pr ior ida d: 5 Re qu isit os e n 055, 034, 040
Conf lict o:
M a t e r ia l de
Soport e :
Ú lt im a Modif icado 15/08/2009 – Glor ia Linares
M od if ica ción : Creado 12/02/2009 – Luis Gut ierrez
60
Ejemplo de un requisito del foro WEB
Planilla VOLERE para Documentación de Requisitos
Identificador del Requisito: 45 Tipo de Requisito: Funcional Caso de Uso/Evento: 4.2.1
Descripción:
Calcular el promedio diario, mensual y anual de precipitación en cada una de las estaciones climatológicas
del país
Justificación del requisito

Es necesario para elaborar los reportes diarios, mensuales y anuales de precipitación.
Fuente (que interesado lo propone): Unidad en la que se origina:

Juan Peña División de Climatología
Criterios de validación:
Los valores obtenidos se compararán con los obtenidos en años pasados para determinar si hay
inconsistencias.
Grado de satisfacción del interesado: 3 Grado de insatisfacción del interesado: 5
Dependencias (qué requisitos depende de este):35, 48 Conflictos (qué requisitos son incompatibles o
inconsistentes con este):
Documentos de soporte: Manual de Precipitación Histórico de cambios: 20-Mayo-2006
Proyecto: Sistema de Información Climatológica Analista: Julia Monsalve
Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006 61

Ejemplo con algunas modificaciones de la plantilla Volere
Recuerde siempre, que los requerimientos se

pueden “priorizar”, es decir, algunos requerimientos
siempre serán mas importantes para el cliente o más
críticos para el negocio que otros
En función de estas prioridades se puede decidir

cuales requerimientos entregar, cuales no y así jugar
con los costos y los tiempos de desarrollo (afectando
lo menos posible la satisfacción del cliente / usuario)
62
Cuadro Resumen de Requerimientos

(índice, importante) 63
Plantillas Volere*
http://www.volere.co.uk/
MeRinde**
http://merinde.rinde.gob.ve/
IEEE Std 830-1993

http://standards.ieee.org/reading/ieee/std_public/description/se/830-1993_desc.html
¿Otras? Sin duda alguna...
*Gracias a James Robertson de Atlantic System Guild por facilitame una copia
gratuita de las plantillas para uso académico
**MeRinde es más que un grupo de plantillas de apoyo, es una metodología de 64
desarrollo de software basada en el Proceso Unificado (UP)
Historias de Usuarios
(Modelos ágiles – XP, SCRUM)
Los requisitos del producto se capturan teniendo en

cuenta la visión del cliente y del usuario
Se recoge en unas sencillas tarjetas de forma
esquemática y en un lenguaje claro QUÉ una historia que
describe una interacción entre el usuario y el sistema
Generación de Factura
El usuario introduce la información del cliente.

Si el cliente ya está registrado con sólo
introducir la cédula se deben cargar sus
datos. Luego se ingresan los elementos a
facturar y las cantidades de cada elemento.
Finalmente el sistema registra la factura y es
capaz de imprimirla en la impresora local
asociada al terminal del usuario
Historias de Usuarios
(Modelos ágiles – XP, SCRUM)
Generación de Factura
El usuario introduce la información del cliente.

Si el cliente ya está registrado con sólo
introducir la cédula se deben cargar sus
datos. Luego se ingresan los elementos a
facturar y las cantidades de cada elemento.
Finalmente el sistema registra la factura y es
capaz de imprimirla en la impresora local
asociada al terminal del usuario
Las historias de usuario sirven de “recordatorio” de una

un grupo de características que es necesario
implementar en el sistema.
Antes de implementar la característica se produce una
discusión con el usuario, se refina y extiende la
información de la historia de usuario
Lenguajes / Notaciones Gráficas
Límites del
Sistema
Generalización /
Caso de Uso Especialización
de Actores
Asociación
Caso de Uso
/ Actor
Colaboración Actor
entre casos 67
de uso
Lenguajes / Notaciones Gráficas...
... y su respectiva descripción textual
Nombre: Crear mensaje foro
Autor: Pedro Pérez
Fecha: 21/04/09
Descripción:
Permite crear un nuevo mensaje (hilo) en el foro de discusión.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.
Flujo Normal:
1.- El actor pulsa sobre el botón para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el título del mensaje y una zona de
mayor tamaño para introducir el cuerpo del mensaje.
3.- El actor introduce el título del mensaje y el cuerpo del mismo.
4.- El sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificación de que hay un nuevo mensaje.
6.- El moderador acepta y el sistema publica el mensaje si éste fue aceptado por el moderador.
Flujo Alternativo:
4.A.- El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al
actor de ello permitiéndole que los corrija.
6.B.- El moderador rechaza el mensaje, de modo que no es publicado sino devuelto al usuario.
Poscondiciones:
El mensaje ha sido almacenado en el sistema y fue publicado. 68
Discusión
¿Cual es la diferencia entre la plantilla anterior

(Caso de Uso), una Historia de Usuario y la
ficha Volere para definir requerimientos?
(Ademas de las diferencias evidentes
de formato y campos)
69
Lenguajes Formales
Ejemplo de “Notación Z”
No cuenten conmigo... (opinión personal) 70

Otros...
Muchas veces la diferencia entre los

requerimientos y el diseño (o el modelo de
análisis en RUP) no resulta lo suficientemente
clara
(El qué con el cómo)
71
Gestión de Requerimientos
¿Cómo se pone
orden en los
requerimientos?
¿Gestión de
requerimientos?
72
¿Qué usuario definió qué

requerimiento?
¿Qué requerimientos satisfacen qué
objetivos de negocio?
¿Qué requerimiento afecta a qué otro
requerimiento?
¿Dónde están diseñados e
implementados los requerimientos?
73
¿Qué sucede si un usuario quiere

cambiar un requerimiento?
¿Cómo se manejan los cambios, cuál
es el proceso para manejar los
cambios?
...etcétera
74
Objetivos
del Negocio
(O1, O2,
O3...) X1
CU1
X2
R1 CU2
X3
R2 CU3 X4 ...
X5 ¿Será
R3 CU4
importante
X6
también tener
trazas
CU5 con los
X7 desarrolladores?
¿Por qué?
Diseño,
Componentes
Interesados Requisitos Casos de Uso 75
Implementación,
Pruebas
Ejemplo de una matriz de rastreo
R1 R2 R3 R4 R5 ... Rn
R1 X
R2 X X
R3 X X Requerimientos
R4 X X
con
R5 X X
Requerimientos
(Dependencias /
... Conflictos)
Rn X X X
U1 U2 U3 U4 U5 ... Un
R1 X
R2 X X X
R3 X X
R4 X X
Requerimientos
R5 X X X
con
Interesados
...
Rn X X X 76
Requerimientos con Casos de Uso
Requerimientos con Objetivos de Negocio
Casos de uso con “artefactos” u otros

componentes en diseño ...
(Gestión de Configuración)
Cualquier otra cosa en la que sea necesario

tener trazas o poder rastrear
¿qué va con qué? ¿qué me influencia a qué?
77
Herramientas para hacer
Gestión de Requerimientos*
DOORS (IBM / Rational) (Propietario)

http://www-01.ibm.com/software/awdtools/doors/productline/
CaliberRM (Borland) (Propietario)

http://www.borland.com/us/products/caliber/index.html
IRQA (Visure) (Propietario)

http://www.visuresolutions.com/
*Requirements Management 78
Herramientas para hacer
Gestión de Requerimientos*
RMTOO (Flonatel GmbH & Co. KG.) (Libre)

http://www.flonatel.de/projekte/rmtoo/
¡Si alguien consigue otra buena herramienta en

software libre me avisa!
*Requirements Management 79
Calidad de los Requisitos
¿Cómo sé que tengo

requisitos de calidad?
80
¿Cómo sé que tengo requisitos de calidad?
Los requisitos se expresan de una manera sencilla,

clara y sin ambigüedades
Se expresan de manera cuantitativa (Los NF)

(No diga que algo debe ser rápido; mejor diga qué
tan rápido debe ser)
Cada requisito debe identificarse de manera única

e inequívoca (Uso de un sistema de numeración)
Deben ser correctos y validados por el cliente

(muy importante)
81
Deben ser consistentes entre sí

(No debe haber conflictos o
incompatibilidad entre requisitos)
Deben ser completos (deben describir todos los

estados, entidades, entradas y salidas posibles)
¿Cómo sé que son completos?
Deben ser realistas o alcanzables

(Soñar no cuesta nada... ¡pero hacer realidad los
sueños puede llegar a salir muy caro!)
82
Deben describir algo que cliente o usuario necesita

( resuelven los problemas del cliente
¿que sentido tiene si no lo hace? )
Deben ser verificables

(medibles y sin ambigüedad, ¿se implementó o no?)
Se les debe poder puede hacer un seguimiento

(Deben estar organizados)
Deben estar redactados en un lenguaje correcto,

simple, sencillo y contundente
(no está escribiendo una novela o un poema)
83
Gracias
¡Gracias!
84

Requerimientos

Încărcat de

Informații document

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

Requerimientos

Încărcat de

Drepturi de autor:

Formate disponibile

Requisitos / Requerimientos

(!Todo lo que el cliente quiere,

Los requisitos expresan lo que el sistema debe hacer

“es un aspecto de un sistema o una descripción de

“Un requerimiento es un servicio que el sistema de

...es algo que el sistema debe ser

Los requerimientos se concentran en

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...

Los datos que Las funciones La información

Los requerimientos Funcionales

La funcionalidad o los servicios que se espera que el

La interacción entre el sistema de software y su

Como el sistema deberá actuar bajo ciertos

El sistema debe permitir el registro de nuevos usuarios en el

Los usuarios deben poder intercambiar mensajes y

Los requerimientos no Funcionales:

Definen restricciones adicionales al sistema, tales como:

Son aquellas que resultan del sistema como un todo y que es

Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad,

El todo no siempre es la simple suma de sus partes...

El sistema debe ser utilizable por medio de una interfaz WEB

Se debe utilizar RUP como proceso de desarrollo del software

El tiempo de respuesta del sistema al solicitar un reporte

Clasificación de Requerimientos no funcionales

Documento de Especificación de Requerimientos

Documento de Definición de Requerimientos

¿Por qué son

Se estima que un alto porcentaje de proyectos de

Hoy en día la Ingeniería de Requisitos

Actualmente, se considera que la

Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006 21

Más adelante, veremos que hay métodos de

¡¡¡Dos de las tres primeras causas están asociadas a los

Proceso de establecimiento de los

Ingeniería => Enfoque Sistemático

Captura Análisis Especificación Validación

Otra visión (Según Pfleeger):

... y hay otras...

Captura Análisis Especificación Validación

Es la actividad por medio de la cual se obtienen

¿Quién está detrás de la solicitud de este

¿Quién usará la solución? (Usuarios)

¿Cuál será el beneficio económico de una

¿Existe otra fuente para la solución requerida?

¿Cómo podría caracterizarse un buen resultado

¿Cuáles problemas debería atacar la solución?

¿Podría usted mostrar o describir el ambiente de

¿Hay aspectos o restricciones especiales del

En este punto, cuando el cliente ya está

¿Es usted la persona adecuada para contestar

¿Mis preguntas son relevantes para su

¿Estoy haciendo demasiadas preguntas?

¿Alguien más puede proporcionar información

¿Debería preguntarle alguna otra cosa?

¿Cómo se soluciona el problema actualmente?

¿Entre que bandas de costos se debería mover

... otras de seguro ...

Captura Análisis Especificación Validación

Captura Análisis Especificación Validación

Es la actividad por medio de la cual se

¡Si los requerimientos no están por escrito

Captura Análisis Especificación Validación