04.0 - Ing. Requerimientos

Pre-portada (-3)
La introduccin y los conceptos

bsicos de Ingeniera de Sofware
los vemos una vez el curso est
ms adelantado
Por lo pronto, me interesa darles las
herramientas mnimas y necesarias
para comenzar a trabajar en el
producto
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.
Pre-portada (-1)
Olvide usted que est en un curso de
Ingeniera del Software, imagine que tiene a un
cliente enfrente, y que este cliente necesita un
software...
Cmo hara 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
3
Pre-portada (0)
Cmo hara para solucionar

el problema?
Para crear una solucin, primero
es necesario tener claro y
comprender el problema...
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

Demin Gutierrez
Marzo 2011
Qu es un requisito?
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 descripcin de
aquello que el sistema es capaz de hacer a fin de
cumplir su propsito
[Pfleeger, 1998]
Un requerimiento es un servicio que el sistema de
software debe satisfacer o una restriccin bajo la
cual el sistema debe operar
[Sommerville 2002]
Si me lo preguntan, en lo personal, pienso que...
Un requisito...
...es algo que el sistema debe ser
capaz de hacer (o una restriccin
que debe cumplir) para que pueda
cumplir su propsito y satisfacer a
sus usuarios
8
Los requerimientos se concentran en

el cliente y el problema a resolver
Definen (o deberan) sobre el
sistema:
Lo que el cliente quiere que haga...
Todo lo que el cliente quiere que haga...
Nada ms que lo que el cliente quiere que haga...
9
Los requisitos se
concentran en qu
debe hacer el
sistema, no en
cmo debe hacerlo!
Es decir, dejen de pensar por los momentos
en cmo lo van a programar o implementar...
10
Qu Definen los Requisitos?

Los datos que
debe capturar y
almacenar
Las funciones
que debe
ejecutar
La informacin
que debe
producir
Aplicacin
Requisitos
Restricciones
de Operacin
Interaccin Usuario /
Sistema
Atributos de Calidad
La interfaz grfica
usuario-sistema (GUI)
Seguridad, facilidad de
uso, documentacin,
utilidad, etc.
La plataforma
de operacin
del sistema
(Hardware /
Software)
La tecnologa
de informacin
que debe usar
Las interfaces
con otros
sistemas
11
Qu Tipos de Requisitos?
Funcionales
Dependiendo si
definen o no
funcionalidad
No Funcionales
Tipos de
Requisitos
De Usuario
Dependiendo de a
quienes estn
dirigidos
De Sistema
12
Requerimientos Funcionales / No Funcionales
Los requerimientos Funcionales

Describen:
La funcionalidad o los servicios que se espera que el
sistema de software proveer
La interaccin entre el sistema de software y su
ambiente o contexto
Como el sistema deber actuar bajo ciertos
estmulos o eventos
13
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 comunicacin debe
estar moderada para evitar conductas inapropiadas por parte
de los usuarios, mensajes basura y publicidad no deseada
14
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
programacin, limitaciones de presupuesto, de tiempo, de
interfaz, etctera
Propiedades Emergentes?
15
Propiedades Emergentes:
Son aquellas que resultan del sistema como un todo y que es
muy difcil o imposible atribuirle a un componente particular de
ste.
Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad,
capacidad de almacenamiento, etctera
El todo no siempre es la simple suma de sus partes...
16
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
17
Clasificacin de Requerimientos no funcionales

(no interpretar literalmente, es slo a modo de referencia)
Fuente: Sommerville 2002
18
Tipos de Requisitos (Clasificaciones)
Funcionales
Dependiendo si
definen o no
funcionalidad
No Funcionales
Tipos de
Requisitos
De Usuario
Dependiendo de a
quienes estn
dirigidos
De Sistema
19
Requerimientos de Usuario / de Sistema

Requerimientos de Usuario:
Son aquellos que estn dirigidos a los usuarios y
clientes (interesados en general) del sistema. Se
redactan usando lenguaje natural (generalmente) de
forma no tcnica con el objetivo de que el personal
no tcnico los pueda entender
Requerimientos de Sistema:
Son aquellos dirigidos a personal tcnico: analistas,
programadores, arquitectos, ingenieros, etctera.
Generalmente estn escritos en un lenguaje mucho
ms tcnico pero mucho ms preciso que los
requerimientos de usuario
20
Requerimientos de Usuario / de Sistema
Documento de Especificacin de Requerimientos

(DER)
Es el documento en el que usualmente se
especifican los requerimientos de usuario
Documento de Definicin de Requerimientos

(DDR)
Es el documento en el que usualmente se
especifican los requerimientos de sistema
21
Nuevamente...
Por qu son
importantes los
requisitos?
22
Requisitos
Se estima que un alto porcentaje de proyectos de

desarrollo de software fallan por:
Requisitos incompletos
Falta de participacin del usuario
Expectativas poco realistas
Cambios en los requisitos y las especificaciones
El sistema dej de ser necesario
23
Requisitos
Hoy en da la Ingeniera de Requisitos

se considera una etapa clave en el
desarrollo de software
Actualmente, se considera que la
satisfaccin de los clientes es la mejor
mtrica de calidad de un sistema
24
El Costo del Cambio (de requisitos)
Fase
Costo
($)
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin
Pruebas
de Unidades
Validacin
20
Puesta
en Marcha /
Operacin
100
Tomado del Taller de Ingeniera de Requisitos V 4.06, Ceisoft, Marzo 2006
25
Sin embargo...
Ms adelante, veremos que hay mtodos de

gestin y desarrollo de software que hasta cierto
punto desafan este punto de vista...
26
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
Planificacin Adecuada
9,60%
5
Expectativas Realistas
8,20%
6 Hitos pequeos 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
Visin 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 estn asociadas a los

requisitos!!!
Tomado del Standish Group Report (1995)
27
Cules han sido las mayores

amenazas en un proyecto de software?
Factores que amenazaron el Proyecto
% Respuestas
1
Falta de informacin de los usuarios
12,80%
2
Especificacin de requerimientos incompleta
12,30%
3
Requerimientos y especificacin compleja
11,80%
4
Falta de soporte ejecutivo
7,50%
5
Mala tecnologa, mal uso de la tecnologa
7,00%
6
Falta de recursos
6,40%
7
5,90%
8
Objetivos poco claros
5,30%
9 Tiempos de desarrollo poco realistas (planificacin)
4,30%
10
Tecnologa nueva (desconocimiento)
3,70%
11
Otras
23,00%
100,00%
Nuevamente:
requisitos!!!
28
Por qu fallan los

proyectos de software?
1
2
3
4
5
6
7
8
9
10
11
Factores que acabaron/cancelaron el Proyecto % Respuestas

Falta de informacin de los usuarios
13,10%
Especificacin de requerimientos incompleta
12,40%
Falta de recursos
10,60%
9,90%
Falta de soporte ejecutivo
9,30%
Requerimientos cambiantes
8,70%
Falta de planificacin
8,10%
El proyecto no se necesito ms
7,50%
Falta de gestin adecuada de IT
6,20%
Problemas tecnolgicos
4,30%
Otras
9,90%
100,00%
Nuevamente!!!
requisitos!!!
29
Bien... pero...
Cmo se obtienen
los requisitos?
30
Requisitos
Ingeniera de Requisitos?
Proceso de establecimiento de los
servicios que debe proporcionar un
sistema, as como de las restricciones
sobre las cuales debe operar
Ingeniera => Enfoque Sistemtico

31
Procesos de la Ingeniera de Requisitos
Una visin:
Captura
Anlisis
Especificacin
Validacin
Otra visin (Segn Pfleeger):

Anlisis
del
Problema
Descripcin
del
Problema
Prototipado
Elicitacin y Anlisis
... y hay otras...

(ver Sommerville cap. 6 / Pressman cap. 7)
Documentacin
y Validacin
Definicin y
Especificacin
32
Captura
Anlisis
Especificacin
Validacin
Es la actividad por medio de la cual se obtienen

(capturan) los requerimientos
Entrevistas
Observacin
Directa
Lectura /
Anlisis de
Documentos
Modelo de
Negocios
Prototipos
Otras...
33
Quin est detrs de la solicitud de este

trabajo? (Clientes)
Quin usar la solucin? (Usuarios)
Cul ser el beneficio econmico de una
solucin exitosa?
Existe otra fuente para la solucin requerida?
Tomado de Pressman 2005 / cap 7
34
Cmo podra caracterizarse un buen resultado

generado por una solucin? (Cmo s que una
solucin es buena?)
Cules problemas debera atacar la solucin?
Podra usted mostrar o describir el ambiente de
negocios en el que se utilizar la solucin?
Hay aspectos o restricciones especiales del
rendimiento que afecten la manera de enfocar la
solucin?
35
En este punto, cuando el cliente ya est

hablando, uno se transforma en pepito
preguntn:
Por qu?
Y por qu?
Qu es esto?
Y esto otro?
Cmo hacen esto?
Y esto otro?
Quin hace esto?
...
Opinin personal
36
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 ms puede proporcionar informacin
adicional?
Debera preguntarle alguna otra cosa?
37
Cmo se soluciona el problema actualmente?

Entre que bandas de costos se debera mover
una solucin para ser rentable?
... otras de seguro ...
Se le ocurre alguna?
Opinin personal
38
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
Opinin personal
39
Consejo:
Nunca vaya a una reunin de negocios o
a una entrevista de requerimientos slo.
Dos es un nmero mgico!
Por qu cree usted que esto es as?
Consejo:
Tome notas / grabe la entrevista de ser
posible, y mantenga las grabaciones
para futuras referencias
Opinin personal
40
Captura
Anlisis
Especificacin
Es la actividad por medio

de la cual se extiende el
modelo de requisitos, se
buscan y localizan
errores, inconsistencias,
limitaciones, carencias,
etctera...
Validacin
Inspecciones
de Documentos
Discusiones,
Entrevistas,
Talleres
Desarrollo de
prototipos
Muchas de las
tcnicas de la actividad
de captura
41
Captura
Anlisis
Especificacin
Validacin
Es la actividad por medio de la cual se

documentan (escriben / se ponen en blanco y
negro) los requerimientos
Documento
de Definicin de
Requerimientos
Documento
de Especificacin de
Requerimientos
Si los requerimientos no estn por escrito

(de alguna manera), entonces NO SIRVEN!
42
Captura
Anlisis
Especificacin
Validacin
Es la actividad por medio de la cual se VALIDAN

los requerimientos con el cliente
Inspecciones
de Documentos
Discusiones /
Entrevistas /
Talleres
Muchas de las
tcnicas de la
actividad
de captura
!Esta actividad es crtica. Si los requerimientos

no se han validado, entonces NO SIRVEN!
43
Quines participan
en la Ingeniera de
Requerimientos?
44
Participantes en el Desarrollo de Software

CLIENTE /
EJECUTIVO /
USUARIO
(Patrocina el
desarrollo del
sistema y
utiliza el
sistema)
Sern
el cliente y
el usuario lo
mismo en todos
los casos?
DESARROLLADOR
(Construye
el Sistema)
45

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

Otros
desarrolladores y
participantes en el
proyecto
Clientes
DESARROLLADOR
(Construye
el Sistema)
Usuarios
Otros entes,
personas,
instituciones,
afectadas o
interesadas en el
sistema
A todas las
personas
involucradas o
interesadas se
les llama
Stakeholder
47
Interesados / Actores / Protagonistas

(Stakeholders)
Consumidores
Instituciones
Gubernamentales
Usuarios
Comunidad
analistas
programadores
Empresa
Contratante
diseadores
Lderes de
proyecto
Clientes de
la Empresa
Clientes
Gerentes
Proveedores
Consultores /
asesores
arquitectos
48
Problemas
Con los Requisitos?
Dilbert!
49
Requisitos (Problemas de los)
Para poder desarrollar software se

necesitan usuarios, comprometidos,
disponibles (e involucrados en el desarrollo)!
50

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 ->
-> Especificacin -> Diseo -> Implementacin -> Usuario
Los requisitos cambian constantemente
(El cliente / usuario cambia de idea constantemente)
Fenmeno del analista sabelotodo: El analista cree que sabe
que es lo que necesita el cliente y por lo tanto no le consulta
51

El cliente / usuario no entiende a los analistas
(Lenguaje tcnico del analista)
Los analistas no entienden al cliente / usuario
(Lenguaje asociado al dominio del cliente / usuario)
Qu es el dominio del cliente?

Dominio de aplicacin?
Requisitos que: No reflejan las necesidades reales del cliente,
son inconsistentes, incompletos, no factibles, etctera
Requisitos que el cliente no necesita realmente
52
Requisitos (Tres Leyes)

(Segn Demin Gutierrez)
Primera Regla:
El usuario siempre tiene la razn

(Aunque se le puede intentar convencer de lo contrario)
Segunda Regla:
El cliente siempre tiene la razn, siempre y cuando esto no

contradiga lo establecido en le primera regla
Tercera Regla:
Usted (el desarrollador) tiene la razn, siempre y cuando esto

no contradiga la segunda o la primera regla
Conoce usted las tres leyes de la

robtica de Asimov?
53
Requisitos (Tres Leyes)

(Segn Demin Gutierrez)
Ley Cero!
Ante la duda, siempre consulte al usuario /

cliente involucrado
Nunca d nada por sentado!
54
Cmo se
documentan los
requisitos?
55
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 visin general del sistema
Usted qu cree?
El propsito del sistema
Para qu lo necesito?
Los objetivos del proyecto
(y como mido si se cumplieron o no)
Los involucrados
Fundamentado en base a la plantilla Volere, edicin 14, Enero 2009
56

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)
57

sistema?
Otros aspectos
Soluciones ya existentes
Riesgos (Ojo, algunos tratan la gestin de riesgos como algo
completamente aparte y distinto)
Costos estimados (Valoracin inicial)
Ideas de posibles soluciones
58
Cmo se definen los requerimientos?

Descripciones en Lenguaje Natural
Usted tiene que desarrollar un sistema de software para la Polica del Estado Mrida.
Entre los requerimientos, hay un proceso que consiste en la gestin de las armas y
municiones de la armera de la polica. El proceso contempla la entrega de armas a los
agentes policiales, la devolucin de las armas al parque, las pruebas y validaciones de ley
que se realizan a las armas despus de la entrega y finalmente, cualquier proceso de
investigacin posterior en caso de que el armamento haya sido disparado.
Despus de conversar con el comisario sobre el funcionamiento del proceso en discusin, se
puede resumir la conversacin de la siguiente forma:
Es necesario un proceso que sirva para gestionar la entrega de armamento del parque de
armas a los Agentes Policiales. En general, los Agentes se presentan al Encargado del
Parque de Armas y solicitan cierto armamento. El Encargado del Parque busca el
armamento solicitado en el inventario y si ste se encuentra disponible se lo entrega al
Agente. Si el armamento no se encuentra disponible el proceso termina. La entrega ocurre
slo luego de que el Agente llene y firme una Planilla de Retiro de Armamento. La
planilla tiene informacin sobre la fecha en que se entrega el arma al Agente, el serial del
arma y la cantidad y tipo de municin entregada. Luego de llenar la planilla, el Encargado
entrega el arma y las municiones al Agente, quien debe revisarlas y poner en la planilla
cualquier observacin o desacuerdo que corresponda al estado de las mismas en caso de ser
necesario.
59

Listas de Features (Caractersticas)
60

61

62

Discusin
Qu ventajas / desventajas tendrn las listas
de Features sobre las descripciones
textuales en lenguaje natural?
63

Plantillas para Definir Requerimientos
Tomado de la plantilla Volere, edicin 14, Enero 2009
64

# de
Requisito:
045
Tipo de
Requisito:
Funcional
Caso de
Uso / Evento
Relacionado:
054
Descripcin:
Los usuarios deben poder intercambiar mensajes y comunicarse por

medio del foro, toda la comunicacin debe estar moderada para
evitar conductas inapropiadas por parte de los usuarios, mensajes
basura y publicidad no deseada.
Justificacin:
Esta es la razn de ser del sistema, el objetivo principal de un foro

WEB es permitir intercambiar mensajes entre usuarios.
Origen
(Interesado):
Pedro Moreno
Criterio de
Aceptacin /
Validacin:
El usuario debe poder publicar un mensaje.

El mensaje no debe aparecer hasta que un moderador lo acepte.
Si un moderador acepta el mensaje entonces ste aparece publicado.
Si un moderador rechaza el mensaje entonces ste no es publicado.
Nivel de
satisfaccin del
Interesado:
Nivel de
insatisfaccin del
Interesado:
Prioridad:
Requisitos en
Conflicto:
055, 034, 040
Material de
Soporte:
ltima
Modificacin:
Modificado 15/08/2009 Gloria Linares

Creado 12/02/2009 Luis Gutierrez
Ejemplo de un requisito del foro WEB
65

Planilla VOLERE para Documentacin de Requisitos
Identificador del Requisito: 45
Tipo de Requisito: Funcional
Caso de Uso/Evento: 4.2.1
Descripcin:
Calcular el promedio diario, mensual y anual de precipitacin en cada una de las estaciones climatolgicas
del pas
Justificacin del requisito
Es necesario para elaborar los reportes diarios, mensuales y anuales de precipitacin.
Fuente (que interesado lo propone):
Juan Pea
Unidad en la que se origina:

Divisin de Climatologa
Criterios de validacin:
Los valores obtenidos se compararn con los obtenidos en aos pasados para determinar si hay
inconsistencias.
Grado de satisfaccin del interesado: 3
Grado de insatisfaccin del interesado: 5
Dependencias (qu requisitos depende de este):35, 48

Documentos de soporte: Manual de Precipitacin
Conflictos (qu requisitos son incompatibles o

inconsistentes con este):
Histrico de cambios: 20-Mayo-2006
Proyecto: Sistema de Informacin Climatolgica
Analista: Julia Monsalve
Tomado del Taller de Ingeniera de Requisitos V 4.06, Ceisoft, Marzo 2006

Ejemplo con algunas modificaciones de la plantilla Volere
66

Recuerde siempre, que los requerimientos se

pueden priorizar, es decir, algunos requerimientos
siempre sern mas importantes para el cliente o ms
crticos para el negocio que otros
En funcin 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 satisfaccin del cliente / usuario)
67

Cuadro Resumen de Requerimientos

(ndice, importante)
68

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 acadmico
**MeRinde es ms que un grupo de plantillas de apoyo, es una metodologa de
desarrollo de software basada en el Proceso Unificado (UP)
69
Historias de Usuarios
(Modelos giles XP, SCRUM)
Los requisitos del producto se capturan teniendo en
cuenta la visin del cliente y del usuario
Se recoge en unas sencillas tarjetas de forma
esquemtica y en un lenguaje claro QU una historia
que describe una interaccin entre el usuario y el sistema
GeneracindeFactura
Elusuariointroducelainformacindelcliente.Siel
clienteyaestregistradoconslointroducirlacdulase
debencargarsusdatos.Luegoseingresanloselementosa
facturarylascantidadesdecadaelemento.
Finalmenteelsistemaregistralafacturayescapazde
imprimirlaenlaimpresoralocalasociadaalterminaldel
usuario
Historias de Usuarios
(Modelos giles XP, SCRUM)
GeneracindeFactura
Elusuariointroducelainformacindelcliente.Siel
clienteyaestregistradoconslointroducirlacdulase
debencargarsusdatos.Luegoseingresanloselementosa
facturarylascantidadesdecadaelemento.
Finalmenteelsistemaregistralafacturayescapazde
imprimirlaenlaimpresoralocalasociadaalterminaldel
usuario
Las historias de usuario sirven de recordatorio de una

un grupo de caractersticas que es necesario
implementar en el sistema.
Antes de implementar la caracterstica se produce una
discusin con el usuario, se refina y extiende la
informacin de la historia de usuario

Lenguajes / Notaciones Grficas
Lmites del
Sistema
Generalizacin /
Especializacin
de Actores
Caso de Uso
Asociacin
Caso de
Uso / Actor
Colaboracin
entre casos
de uso
Actor
72
Lenguajes / Notaciones Grficas...

... y su respectiva descripcin textual
Nombre:
Crear mensaje foro
Autor:
Pedro Prez
Fecha:
21/04/09
Descripcin:
Permite crear un nuevo mensaje (hilo) en el foro de discusin.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.
Flujo Normal:
1.- El actor pulsa sobre el botn para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el ttulo del mensaje y una zona de
mayor tamao para introducir el cuerpo del mensaje.
3.- El actor introduce el ttulo del mensaje y el cuerpo del mismo.
4.- El sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificacin 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 permitindole 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.
73

Discusin
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)
74

Lenguajes Formales
Ejemplo de Notacin Z
No cuenten conmigo... (opinin personal)
75
Otros...
Muchas veces la diferencia entre los
requerimientos y el diseo (o el modelo de
anlisis en RUP) no resulta lo suficientemente
clara
(El qu con el cmo)
76
Gestin de Requerimientos
Cmo se pone
orden en los
requerimientos?
Gestin de
requerimientos?
77
Qu usuario defini qu
requerimiento?
Qu requerimientos satisfacen qu
objetivos de negocio?
Qu requerimiento afecta a qu otro
requerimiento?
Dnde estn diseados e
implementados los requerimientos?
78
Qu sucede si un usuario quiere

cambiar un requerimiento?
Cmo se manejan los cambios, cul
es el proceso para manejar los
cambios?
...etctera
79
Objetivos
del Negocio
(O1, O2,
O3...)
X1
CU1
X2
R1
CU2
R2
CU3
R3
CU4
X3
X4
X5
X6
CU5
X7
Interesados
Requisitos
Casos de Uso
Diseo,
Componentes
Implementacin,
Pruebas
...
Ser
importante
tambin tener
trazas
con los
desarrolladores?
Por qu?
80
Ejemplo de una matriz de rastreo
R1 R2 R3 R4 R5
R1
X
R2 X X
R3
X
R4
X
X
R5
X
X
...
Rn
X
Requerimientos
con
Requerimientos
(Dependencias /
Conflictos)
...
Rn
Requerimientos
con
Interesados
R1
R2
R3
R4
R5
U1 U2 U3 U4 U5
X
X X X
X
X
X
X
X
X
...
Un
...
Rn
81
Requerimientos con Casos de Uso

Requerimientos con Objetivos de Negocio
Casos de uso con artefactos u otros
componentes en diseo ...
(Gestin de Configuracin)
Cualquier otra cosa en la que sea necesario
tener trazas o poder rastrear
qu va con qu? qu me influencia a qu?
82
Herramientas para hacer

Gestin 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
83
Herramientas para hacer

Gestin 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
84
Calidad de los Requisitos
Cmo s que tengo

requisitos de calidad?
85
Cmo s que tengo requisitos de calidad?
Los requisitos se expresan de una manera sencilla,

clara y sin ambigedades
Se expresan de manera cuantitativa (Los NF)
(No diga que algo debe ser rpido; mejor diga qu
tan rpido debe ser)
Cada requisito debe identificarse de manera nica
e inequvoca (Uso de un sistema de numeracin)
Deben ser correctos y validados por el cliente
(muy importante)
86
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)
Cmo s que son completos?
Deben ser realistas o alcanzables
(Soar no cuesta nada... pero hacer realidad los
sueos puede llegar a salir muy caro!)
87

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 ambigedad, 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)
88
Gracias
Gracias!
89

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

04.0 - Ing. Requerimientos

Încărcat de

Drepturi de autor:

Formate disponibile

Pre-portada (-3)

La introduccin y los conceptos

Ninguna de las ideas expresadas en

Cmo hara para solucionar

Cmo hara para solucionar

Universidad de los Andes

Los requerimientos se concentran en

Qu Definen los Requisitos?

Requerimientos Funcionales / No Funcionales

Los requerimientos Funcionales

Requerimientos Funcionales / No Funcionales

Requerimientos Funcionales / No Funcionales

Los requerimientos no Funcionales:

Requerimientos Funcionales / No Funcionales

Requerimientos Funcionales / No Funcionales

Requerimientos Funcionales / No Funcionales

Clasificacin de Requerimientos no funcionales

Tipos de Requisitos (Clasificaciones)

Requerimientos de Usuario / de Sistema

Requerimientos de Usuario / de Sistema

Documento de Especificacin de Requerimientos

Documento de Definicin de Requerimientos

Se estima que un alto porcentaje de proyectos de

Hoy en da la Ingeniera de Requisitos

El Costo del Cambio (de requisitos)

Tomado del Taller de Ingeniera de Requisitos V 4.06, Ceisoft, Marzo 2006

Ms adelante, veremos que hay mtodos de

Por qu tienen xito los

Dos de las tres primeras causas estn asociadas a los

Cules han sido las mayores

Por qu fallan los

Factores que acabaron/cancelaron el Proyecto % Respuestas

Ingeniera => Enfoque Sistemtico

Procesos de la Ingeniera de Requisitos

Otra visin (Segn Pfleeger):

... y hay otras...

Procesos de la Ingeniera de Requisitos

Es la actividad por medio de la cual se obtienen

Procesos de la Ingeniera de Requisitos

Quin est detrs de la solicitud de este

Tomado de Pressman 2005 / cap 7

Procesos de la Ingeniera de Requisitos

Cmo podra caracterizarse un buen resultado

Procesos de la Ingeniera de Requisitos

En este punto, cuando el cliente ya est

Procesos de la Ingeniera de Requisitos

Es usted la persona adecuada para contestar

Procesos de la Ingeniera de Requisitos

Cmo se soluciona el problema actualmente?

Procesos de la Ingeniera de Requisitos

Procesos de la Ingeniera de Requisitos

Procesos de la Ingeniera de Requisitos

Es la actividad por medio

Procesos de la Ingeniera de Requisitos

Es la actividad por medio de la cual se

Si los requerimientos no estn por escrito

Procesos de la Ingeniera de Requisitos

Es la actividad por medio de la cual se VALIDAN

!Esta actividad es crtica. Si los requerimientos

Participantes en el Desarrollo de Software

Participantes en el Desarrollo de Software

Participantes en el Desarrollo de Software

Interesados / Actores / Protagonistas

Requisitos (Problemas de los)