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 organización 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 diseñar 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 también 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 tamaño, 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 conexión 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 añadiran 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 tamaño 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

Pedido

Fecha_emisionDire_entrega

CuentaSaldoTitular

Articulo

DescripcionFotoPrecio

FacturaCantidad

Fecha_EmisFec_Limt_Pag

comprador

vendedor

1

1

1 ..* pagable

1..*

• 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 diseñar 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 organización. 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 también 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.

vendedor

comprador

Importe Factura

Facturacuenta

Gestor de pagoscomprador vendedor

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 también 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 pequeños 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 diseño 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, tamaño 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 Diseño: limita el diseño 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