Captura de los requisitos.

De la vision a los requisitos

Lic. Espinoza Robles.

Captura de requisitos
Llamanos captura de requisitos : al acto de
descubrir o averiguar en circunstancias
dificiles lo que se debe construir.
De hecho es tan dificil para los equipos de
proyecto que estos empiezan a ha escribir
codigo antes de determinar lo que este
codigo debe hacer.

 Porque la captura de requisitos es

Complicada:
Los usuarios son una fuente imperfecta de
recolectar informacion, pues existe muchos
tipos de usuarios, los cuales saben lo que hacen
pero carecen de una vision global del sistema.
La mayoria de los usuarios no saben que parte de
su trabajo puede transformarce en softw.
No saben cuales son los requisitos ni como
especificarlos. De forma precisa.

 La manera tradicional de resolver esto era

asignar un analista para obtener una lista de
requisitos de cada usuario para luego
integrarlo en una vision global del
problema.
Aveces los usuarios incluso con la ayuda de
los analistas no comprendian del todo lo que
el sistema softw., debia hacer, hasta que el
sistema estaba casi terminado.

 Es un error suponer que los usuarios saben

cuales son los requisitos y lo unico que
debemos hacer es entrevistarnos con ellos.
Los sistemas deben dar soporte a los
usuarios, sin embargo es mas importante
que los sistemas den soporte a la mision
para la cual se construye.
La industria biene buscando un proceo
bueno, sistematico para llevar a cabo la
captura de requisitos

 El Objeto del flujo de trabajo de los

requisitos.
El proposito fundamental del flujo de
trabajo de los requisitos es guiar el
desarrollo hacia el sistema correcto
Esto se consiguie mediante una descripcion
de los requisitos del sistema a traves del
cual se pueda llegar a un acuerdo entre el
cliente y los desarrolladores sobre lo que
debe hacer el sistema.

 Es un reto que el cliente (no informatico)

debe ser capaz de leer y comprender el
resultado de la captura de requisitos, para lo
cual debemos usar el lenguaje del cliente en
la descripcion de los resultados.

Vision General de la Captura de

requisitos
Cada proyecto de Softw. Es diferente
porque los sistemas son diferentes, los
clientes, la organizacin de desarrollo, la
tecnologia etc.

 hay diferentes puntos de partida para la

captura de de requisitos. En algunos casos
comenzamos haciendo un modelo del
negocio, o sobre algo que otra empresa
comenzo, o sobre las especificaciones de
requisitos propuesta por el cliente, a partir
de los cuales podemos negociar cambios.
Por otro lado tenemos clientes que solo
tienen una vaga idea de lo que debera ser su
sistema.

 Entre estos extremos tenemos una serie de

combinaciones. Tomando como punto de
partida la Vaga Nocion presentamos un
ejemplo.
Ejemplo: El consorcio Interbank, estudia un sistema
informatico, este consorcio, se enfrenta a los cambios
debido a la desregulacion, la nueva competencia y las
posibilidades de la www.
El consorcion quiere desarrollar aplicaciones nuevas
que soporte los rapidos y cambientes mercados
financieros.

 Interbank Software, desea disear el sistema de

Pagos y Facturacion. El sistema utilizara Internet
para el envio de pedidos, facturas y pagos entre
compradores y vendedores. La motivacion del
Banco es atraer nuevos clientes ofreciendo
comiciones bajas por el proceso de pagos. El
banco podra tambin reducir sus costos laborales
procesando las solicitudes de cambio por internet.
La motivacion para compradores y vendedores es
reducir costos, papeleo y tiempo de proceso.El
pago de facturas se llevara a cabo entre
computadoras del comprador y vendedor
------------------------------------------------------------

 Los diferentes puntos de partida plantean

diferentes tipos de riesgos, por el que el
analista debera elegir las tecnicas que
reduscan riesgos.
Se puede seguir unos pasos que son
generales a cualquier punto de partida:

Enumerar los requisitos.

Comprender el contexto del sistema
Capturar requisitos funcionales
Capturar requisitos no funcionales.

 Enumerar los requisitos Candidatos:

Durante la vida del sistema los clientes,
usuarios, analistas y desarrolladores,
aparecen con ideas que podran convertirce
en verdaderos requisitos, mantener una lista
de estas ideas, los cuales seran un conjunto
de requisitos candidatos. Esta lista se usa
para planificar el trabajo.

 En esta lista de caracteristicas cada una

tiene un nombre corto y una breve
explicacion, y un conjunto de valores que
podra ser :
Estado ( propuesto, aprobado, inducido o
valido)
Costo estimado de implementacion (en
terminos hora-persona)
Prioridad (critico, importante, secundario)
Estos valores se usan para estimar el tamao, del
proyecto y decidir como dividir el proyecto en
una secuencia de iteraciones.

 Comprender el Contexto del Sistema

Para capturar los requisitos correctos los
desarrolladores (arquitecto y analista senior)
requieren un firme conocimiento del
contexto en el que se emplaza el sistema.
Existe dos aproximaciones para expresar el
contexto del sistema.
Modelado del Dominio
Modelado del Negocio.

 Modelado del Dominio: describe los aspectos

importantes del contexto como objetos del

dominio y enlaza estos objetos unos a otros.
Los objetos del dominio nos ayudan a
identificar clases.
Un modelado del Negocio: puede describirse
como un supra conjunto de un modelo del
Dominio e incluye algo mas que objetos. El
objetivo del modelo de negocion es
describir procesos para comprenderlos.

 A medida que los analistas modelan el

negocio aprenden mucho sobre el contexto
del sisitema y lo describen en un modelo de
negocio.
El modelo de negocio especifica que
proceso de negocios soportara el sistema.
Este modelo establece las competencias
requiridas en cada proceso; sus
trabajadores, sus responsabilidades y las
operaciones que llevan a cabo.

 Captura de Requisitos Funcionales

La tecnica inmediata para identificar los
requisitos del sistema se basa en los caso de
uso, estos casos de uso capturan los
requistos funcionales como los no
funcionales
Cada usuario quiere que el sistema haga
algo para el es decir lleve ha cabo ciertos
casos de uso
Para el usuario un caso de uso es un modo
de usar el sistema.

 En consecuencia si los analistas puden

describir todos los caso de uso que necesita
el usuario sabran lo que debe hacer el
sistema.
La captura de los casos de uso realmente
necesarios, como aquelos que soportan el
negocio y que le permitira al usuario
realizar mas comodamente su trabajo
requiere conocer en profundidad las
necesidades de los usuarios y clientes, para
lo cual se debe conocer el contexto del
sistema

 Captura de los requisitos no Funcionales

Los requisitos no funcionales especifican
propiedades del sistema como restricciones
de entorno, o implementacion, rendimiento,
dependencias de la plataforma, facilidad de
mantenimiento, extencibilidad, fiabilidad.
Ej. Requisitos especiales para el caso de uso
Pagar Factura.
Requisito de Rendiminento:
Cuando un comprador envia una factura para su pago,
el sistema debera responder con una

 Verificacion de la solicitud a menos de 0.1 seg. En el

90% de los casos. La duracion de esta verificacion
nunca debera exederlos 10 seg. A menos que la
conexin de red no funcione, en cuyo caso se devera
informar al usuario.
------------

Algunos requisitos no funcionales hacen

referencia a fenomenos del mundo real,
como las cuentas en un sistema bancario.
Algunos requerimientos no funcionales son
mas genericos y no pueden relacionarce con
un caso de uso concreto o una clase del
mundo real estos se gestionaran en lista
aparte de requistos adicionales.

 Resumen
Para capturar los requisitos de manera
eficaz los analistas necesitan un conjunto de
tecnicas y artefactos que les ayude a obtener
una vision suficentemente buena del sistema
para avanzar en los flujos de trabajo.
Llamamos a este conjunto de artefactos el
conjunto de requistos agrupados en :
El modelo de casos de uso
Los requisitos adicionales.

 Los artefactos necesarios para establecer el

contexto del sistema son:
Los modelos de dominio
Los modelos de negocio.
Trabajo a realizar
Artefacto resultante
Enume.Requi. Candidatos Lista de Caracteres
Comprender el contexto
Modelo de dominio
Del sistema
modelo de Negocio
Captura Requ. Func.
Modelo casos de uso
Captura Requ. No Func.
Requisitos adiciona.
caso de uso concreto

 Los casos de uso cambian constantemente

por lo que se necesita alguna forma de
actualizaras de manera controlada. Lo
hacemos en las iteraciones donde cada
iteracion reflejara algun cambio en el
conjunto de requisitos; el numero de
cambios disminuira cuando nos adentremos
en la fase de construccion.

 El Papel de los requisitos en el Ciclo

de Vida del Software
El modelo de casos de uso se desarrolla a lo
largo de varios incrementos del desarrollo,
donde las iteraciones aadiran nuevos casos
de uso y /o detalles a las descripciones de
los casos de uso existentes.

 Durante el Inicio: los analistas identifican la

mayoria de los casos de uso para delimitar
el sistema y el alcance del proyecto
Durante la Fase de Elaboracion: los
analistas capturan la mayoria de los casos
de uso restantes para que los desarrolladores
puedan estimar el tamao del esfuerzo de
desarrollo. El objetivo es capturar el 80% de
los requisitos y describir la mayoria de los
casos de uso.

 Los requisitos restantes se capturan e

implementan durante la fase de
construccion
Casi no hay captura de requisitos en la fase
de transicion a menos que haya requisitos
que cambien.

Comprension del Contexto del Sistema

Mediante un Modelo del Dominio
Que es un Modelo de Dominio:
Un modelo de dominio captura los tipos
mas importantes de objetos en el contexto
del sistema.
Los Objetos del Dominio representan las
cosas que existen o los eventos que suceden
en el entorno en el que trabaja el sistema.

 Muchos de los objetos del dominio o clases

pueden obtenerce de una especificacion de
requisitos o mediante la entrevista con los
expertos del dominio. Las clases del
dominio aparecen en tres formas:
Objetos del negocio que representan cosas que
se manipulan en el negocio (pedidos, cuentas,
contratos).
Objetos del mundo real y conceptos de los que
el sistema debe hacer un seguimiento.
Sucesos que ocurriran o han ocurrido. Como la
llegada de un avion, su salida, la hora de la
comida.

 El modelo del dominio se describe mediante

diagramas de UML (especificamente
diagramas de clase)
Este modelo muestra las clases del dominio
y como se relacionan unas con otras.
Ejem. Las clases del dominio: pedido,
factura, articulo y cuenta.
El sistema utilizara internet para enviar
pedidos, facturas y pagos entre compradores y
vendedores. El sistema ayuda el comprador a
confeccionar sus pedidos.

 Al vendedor a evaluar los pedidos a enviar las

facturas, y el comprador a validar las facturas
hacer efectivos los pagos de sus cuentas.
Un pedido es la solicitud de un comprador a un
vendedor de un numero de articulos. Cada
articulo ocupa una linea en el pedido. Un
pedido posee atributos como la fecha de
emision y la direccion de entrega.
----------------------------------------------------------

Diag.de clase en un modelo de dominio

Articulo
Pedido
Fecha_emision
Dire_entrega
1 ..*

1..*

Descripcion
Foto
Precio

pagable

comprador
Factura
Cantidad
Fecha_Emis
Fec_Limt_Pag

1
vendedor
1

Cuenta
Saldo
Titular

 Desarrollo de un Modelo del Dominio

El modelado del domino se realiza
habitualmente en reuniones organizadas por
los analistas del dominio, que usan UML o
otro lenguaje para documentar los resultados.
Para formar un equipo eficaz estas reuniones
deberan incluir tanto expertos del domino
como a gente con experiencia en modelado.
El objetivo del modelado del Dominio es
comprender y describir las clases mas
importantes dentro del contexto del sistema.

 Algunas veces no es necesario desarrollar

un modelo de objetos para el dominio, en su
lugar puede ser suficiente un glosario de
terminos .
El glosario y el modelo ayudan a los
usuarios, clientes, desarroladores y otros
interesados a utilizar un vocabulario comun.
El objetivo del modelo del Dominio, es
contribuir a la comprension del contexto del
sistema y contribuir a comprender los
requisitos del sistema.

 Uso del Modelo del Dominio

La clase del dominio y el glosario de
terminos se utilizan en el desarrollo de los
modelos de caso de uso y de analisis :
Al describir los casos de uso y al disear la
interfaz de usuario.
Para sugerir clases internas al sistema en
desarrollo durante el analisis.

 Comprension del contexto del Sistema

mediante un modelo de Negocio.
El modelo del negocio es una tecnica para
comprender los procesos de negocio de la
organizacin. Pero que pasa si tratamos con
un sistema que no tiene nada que ver con lo
que la mayoria de nosotros considera un
negocio Ejem. Desarrollo de un marcapaso,
un sistema de frenos de un controlador de
camara, o sistema de telecomunicaciones .

 Este sistema es el Sistema de Negocio del

sistema software empotrado.
El objetivo es identificar los casos de uso
del software y las entidades de negocio
relevantes, de forma que modelemos solo lo
necesario para comprender el contexto.
El modelo de negocio esta soportado por:
Modelos de casos de Uso y Modelo de
Objetos.

 Que es un Modelo de Negocios

En primer lugar, un modelo de casos de uso
del negocio describe los procesos de
negocio de una empresa en terminos de
casos de uso de negocio y actores del
negocio que se corresponden con los
procesos del negocio y los clientes
respectivamente.
Ej. Caso de uso del negocio:
El ejemplo del interbank tiene un caso de uso
de negocio que comprende el envio de pedidos

 Facturas y pagos entre un comprador y un

vendedor. En este caso de uso de negocio, un
comprador sabe lo que tiene que comprar y a
quien. En la siguiente secuencia, Interbank
actua como el agente de negocios en el caso de
uso del negocio, conectando al comprador y al
vendedor proporcionando rutinas seguras para
el pago de las facturas.

1. El comprador hace pedidos de bienes o servicios

2. El vendedor entrega los bienes o servicios
3. El vendedor envia la factura al comprador
4. El comprador paga

 En este contexto el comprador y vendedor son

los actores del negocio.
Un negocio proporciona normalmente muchas
casos de uso de negocio. Describimos dos de
estos casos de uso solo para situarnos en el
contexto.
En el caso de uso Gestion de Prestamo: de la
Solicitud al desembolso, un cliente del banco
envia una solicitud de prestamo a Interbank y
recibe fondos del banco.
El cliente del banco representa un cliente
generico para el banco. El comprador y el
vendedor son dos tipos mas especificos de
clientes.

 En los casos de uso de Negocio: Hacer

Transferencia y Sacar e Ingresar Dinero, un
cliente del banco realiza transferencias entre
cuentas y retira o ingresa dinero. Este caso de
uso de negocio tambin permitira a un cliente
del banco establecer transferencias automaticas
futuras.
-------------------------------------------------------El modelo de casos de uso del negocio se
describe mediante diagramas de casos de uso
Un modelo de objetos del negocio es un modelo
interno al negocio.

 Describe como cada caso de uso de negocio

es llevado a cabo por parte de un conjunto
de trabajadores que utilizan un conjunto de
entidades del negocio y de unidades de
trabajo.
Una entidad del Negocio representa algo,
como una factura, que los trabajadores
manipulan, producen o utilizan en un caso
de uso del negocio.
Una unidad de Trabajo: es un conjunto de
entidades que conforman un todo
reconocible para un usuario final.

 Las entidades del negocio y las unidades de

trabajo se usan para representar los mismos
tipos de conceptos que las clases del
Dominio, como Pedidos, Articulos, Factura.
Por tanto podemos confeccionar un
diagrama de las entidades del negocio.
Cada trabajador, entidad del negocio y
unidad de trabajo pueden participar en la
realizacion de mas de un caso de uso del
negocio por ejemplo, la clase Cuenta
participa en tres casos de uso del negocio:

 Gestion de Prestamo: el dinero que se adquiere

por el prestamo se desembolsa en una cuenta
Hacer transferencias y Sacar e Ingresar Dinero:
el dinero se retira e ingresa en cuentas.
Ventas: del pedido a la Entrega implica la
transferencia de dinero de la cuenta del
comprador a la del vendedor.

 Ejem. El caso de uso del Negocio Ventas: Del

Pedido a la Entrega.
Los trabajadores dan los siguientes pasos en el
caso de uso del negocio Ventas: del pedido a la
entrega:
1. El comprador solicita bienes o servicios contactando
con el vendedor.
2. El vendedor envia la factura al comprador a travez
del gestor de pagos.
3. El vendedor entrega los bienes o servicios al
comprador
4. El comprador paga mediante el gestor de pagos,
transfiriendo dinero de la cuenta del comprador al
vendedor.

 El comprador, vendedor y gestor de pagos estan en el caso de uso del

negocio ventas: del Pedido a la entrega. El gestor de pagos tranf. Dinero
de una cta. A otra tal como especif. La Fact.

Gestor de
pagos

comprador

vendedor
Importe
Factura

comprador
vendedor

cuenta

Factura

Como Desarrolar un Modelo de

Negocios
Se desarrola en dos pasos :
1. Los modelos de negocio deben
confeccionar un modelo de casos de uso del
negocio que identifique los actores del
negocio y los casos de uso del negocio que
utilicen los actores. Esto permite
comprender mejor que valor proporciona el
negocio a sus actores.

 2. Los modeladores deben desarrolar un

modelo de objetos del negocio compuesto
por trabajadores, entidades del negocio, y
unidades de trabajo que juntos realizan los
caso de uso del negocio. Se asocian a estos
objetos las reglas del negocio y otras
normas del negocio. El objetivo es crear
trabajadores entidades del negocio y
unidades de trabajo que realicen los casos
de uso de manera eficas y a bajo costo.

 El modelado del negocio y el modelo del

dominio se parecen en muchos aspectos. El
modelado del dominio es una variente
simplificada del modelo del negocio.
Por tanto las clases del dominio, y las
entidades del negocio son conceptos
parecidos.
Sin embargo existen algunas diferencias
ente modelo de negocios y modelo de
dominio como:

 Las clases del dominio se obtienen de la

base del conocimiento de unos pocos
expertos del dominio. Las entidades del
negocio se derivan a partir de los clientes
del negocio
Las clases del domino tienen atributos pero
normanlmente pocas operaciones. No asi las
entidades del negocio. La tecnica de
modelado del negocio identifica tambin los
trabajadores que participan en la realizacion
de los casos de uso del negocio.

 Ademas identifica como usaran los

trabjadores las entidades atraves de
operaciones.
Los trabajadores identificados se usan como
punto de partida para derivar un primer
conjunto de actores y casos de uso para el
sistema.
El modelado de negocio y la tecnica de
ingenieria de software combinados nos
permite hacer el seguimiento de las
necesidades del cliente.

 Busqueda de Casos de Uso a Partir

de un Modelo
Mediante la utilizacion de un modelo de
negocios como entrada se crea un modelo
tentativo de casos de uso.
En primer lugar se identifica al actor por
cada trabajador y por cada actor del negocio
que se convertira en usuario del sistema.

 Ejem. El actor Comprador.

El conprador utiliza el sisitema de facturacion y
Pagos para solicitar bienes o servicios y pagar
facturas. Por lo que el comprador es un cliente
como un actor ya que utiliza el sistema para
pagar y pedir medinate dos caos de uso:
Solicitar Bienes, Pagar Factura.
-------------------------------------------------Cada trabajador usuario del sistema requiere un
soporte. Para cada trabajador identificamos los
casos de uso del negocio donde participa . El
trabajador cumple un papel en cada una.

 Una vez ubicado todos los roles de un

trabajador o de un actor del negocio,
podemos encontrar los casos de uso de los
actores del sistema.
La manera mas directa de identificar los
casos de uso es crear un caso de uso para el
actor correspondiente a cada rol de cada
trabajador.

 Ejemp. Identificacion de casos de uso a

partir de un modelo de negocio.
Prosiguiendo con el ejemplo, un caso de uso
tentativo llamado Compra de Bienes o
Servicios, que podria dar soporte al actor
Comprador en su papel de actor del negocio
durante le caso de uso Ventas: del Pedido a la
Entrega. Este caso de uso se descompondra
luego en otros mas pequeos tales cono
Solicitar Bienes o Servicios, Pagar Factura.

 Requisitos Adicionales.
Son fundamentalmente requistos no
funcionales que no pueden asociarce a
ningun caso de uso en concreto, en cambio
estos tienen impacto en varios casos de uso.
Los requisitos adicionales se capturan en
una lista de requisitos que luego se usan
durante el analisi y diseo junto al modelo
de casos de uso.

 Un requisito de Interfaz: especifica una

interfaz con un elemento externo con el cual
interactua el sistema, o que establece
restricciones en formatos, tiempos u otros
factores.
Un requisito Fisico: especifica las
carateristicas fisicas que debe poseer el
sistema, como su material, forma, tamao
peso. Por ejemplo para representar
requisitos de hardware

 Ejemplo: Requisitos de plataforma de

hardware
Servidor: SUN SPARC 20 o PC Pentium
Clientes: PC procesador Pentium
--------------------------------------------------------Una restriccion de Diseo: limita el diseo de un
sisitema
Una restriccion de Implementacion: especifica o
limita la codificacion o construccion de un
sistema. Ejem. Los estandares de codificacion,
los lenguajes de programacion, politicas de
integridad de BD.

 Ejemplo: restricciones en formatos de

ficheros.
La version 1.2 del sistema de facturacion y
pagos debe soportar nombres largos de fichero
Ejem. Restricciones en la Plataforma Software.
Software del sistema: SO. Cliente WNT 2000
SO. Servidor WNT 2000
Software para internet: Netscape 4.0 internet
explorer 5.0
Ejem.otros requistos: Seguridad, Disponibilidad,
facilidad de Aprendizaje