30
07/03/2011 1 Captura de Requisitos Captura de Requisitos Informática Industrial Informática Industrial A/DOO A/DOO EUITI EUITI – UPM UPM Lo mejor es enemigo de lo bueno (Voltaire) Índice Índice Fase de Inicio Fase de Inicio Comprensión de los requisitos Comprensión de los requisitos Requisitos Requisitos – Modelo de Casos de Uso Modelo de Casos de Uso Identificarlos Identificarlos Formatos Formatos UML UML – Especificaciones complementarias Especificaciones complementarias – Vision Vision – Glosario Glosario

cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

Embed Size (px)

Citation preview

Page 1: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

1

Captura de RequisitosCaptura de Requisitos

Informática IndustrialInformática IndustrialA/DOOA/DOOEUITI EUITI –– UPMUPM

Lo mejor es enemigo de lo bueno (Voltaire)

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– Especificaciones complementariasEspecificaciones complementarias–– VisionVision–– GlosarioGlosario

Page 2: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

2

Comprensión de los Comprensión de los requisitosrequisitos

Gestión de Gestión de requisitosrequisitos–– No se refiere al ciclo No se refiere al ciclo

en cascada, en cascada, congelar requisitoscongelar requisitos

–– RUP: “Encontrar, RUP: “Encontrar, documentar, documentar, organizar y seguir la organizar y seguir la pista a los requisitos pista a los requisitos cambiantes”cambiantes”

Talleres de Talleres de requisitosrequisitosCasos de usoCasos de uso

Costes proyecto

Tipos de requisitosTipos de requisitosFURPS+FURPS+–– FunctionalFunctional: Características: Características–– UsabilityUsability (Facilidad de uso): Factores humanos, (Facilidad de uso): Factores humanos,

documentacióndocumentación–– ReliabilityReliability (Fiabilidad): Fallos, recuperación.(Fiabilidad): Fallos, recuperación.–– Performance (Rendimiento): tiempos, carga, Performance (Rendimiento): tiempos, carga,

productividad, uso de recursosproductividad, uso de recursos–– SupportabilitySupportability (Soporte): Adaptabilidad, mantenimiento, (Soporte): Adaptabilidad, mantenimiento,

internacionalización, internacionalización, configurabilidadconfigurabilidad++–– Implementación: lenguajes, herramientas, hardwareImplementación: lenguajes, herramientas, hardware–– Interfaz: relación con sistemas externosInterfaz: relación con sistemas externos–– Operaciones: Gestión del sistema en puesta en marchaOperaciones: Gestión del sistema en puesta en marcha–– EmpaquetamientoEmpaquetamiento–– Legales: LicenciaLegales: Licencia

EJEMPLO: Maquina de refrescosEJEMPLO: Maquina de refrescos

Page 3: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

3

Clasificación y artefactosClasificación y artefactos

Funcionales (que)Funcionales (que)–– Artefacto:Artefacto:

Modelo de Casos de UsoModelo de Casos de UsoNo Funcionales, requisitos de calidad (como)No Funcionales, requisitos de calidad (como)–– Artefactos:Artefactos:

Casos de Uso relacionadosCasos de Uso relacionadosEspecificación complementariaEspecificación complementaria

–– Influyen fuertemente en el diseño de la arquitectura del Influyen fuertemente en el diseño de la arquitectura del sistemasistema

Artefactos comunes a Funcionales y Calidad:Artefactos comunes a Funcionales y Calidad:–– Visión: Resume los requisitos anteriores a alto nivelVisión: Resume los requisitos anteriores a alto nivel–– Glosario: diccionario con la terminología del dominio, Glosario: diccionario con la terminología del dominio,

valores aceptablesvalores aceptables

Bibliografía:Bibliografía:

Bibliografía existenteBibliografía existente–– Condicionado al ciclo en cascadaCondicionado al ciclo en cascada–– Casos de uso como complementarioCasos de uso como complementario

Page 4: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

4

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– VisiónVisión–– GlosarioGlosario–– Especificaciones complementariasEspecificaciones complementarias

Modelo de Casos de UsoModelo de Casos de Uso

Escritura de los requisitos en un contextoEscritura de los requisitos en un contexto..–– En contraposición a la lista de la compraEn contraposición a la lista de la compra

¿Qué son los casos de Uso? Historias del ¿Qué son los casos de Uso? Historias del uso de un sistemauso de un sistema¿Dónde se ubican? En la disciplina de ¿Dónde se ubican? En la disciplina de RequisitosRequisitosRequisitos funcionalesRequisitos funcionalesModelo de Casos de Uso: El conjunto de Modelo de Casos de Uso: El conjunto de todos los casos de uso, es un modelo de la todos los casos de uso, es un modelo de la funcionalidadfuncionalidad y entorno del sistemay entorno del sistema

Page 5: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

5

Objetivos e HistoriasObjetivos e Historias

Los clientes tienen Los clientes tienen objetivosobjetivos (necesidades) y quieren que el (necesidades) y quieren que el sistema les ayude a conseguirlossistema les ayude a conseguirlosEj: Aplicación PDV (Punto de Venta)Ej: Aplicación PDV (Punto de Venta)–– Terminal, lector de código de barras.Terminal, lector de código de barras.–– Conexión a otros sistemas: inventario, pago con tarjetaConexión a otros sistemas: inventario, pago con tarjeta

Formato breveFormato breve::–– Procesar VentaProcesar Venta: Un cliente llega a la caja con artículos. El cajero : Un cliente llega a la caja con artículos. El cajero

utiliza el sistema PDV para registrar los artículos. El sistema utiliza el sistema PDV para registrar los artículos. El sistema presenta una suma parcial y detalles de los productos. El cliente presenta una suma parcial y detalles de los productos. El cliente introduce los datos del pago que el sistema valida y registra. El introduce los datos del pago que el sistema valida y registra. El sistema actualiza el inventario. El cliente recibe un recibo y se va sistema actualiza el inventario. El cliente recibe un recibo y se va con los artículos.con los artículos.

A menudo requieren mayor descripción, pero la esencia es A menudo requieren mayor descripción, pero la esencia es esta: historias del uso del sistema que ayudan a cumplir los esta: historias del uso del sistema que ayudan a cumplir los objetivos de las personas involucradasobjetivos de las personas involucradas

ActoresActores

ActorActor: algo con comportamiento, como : algo con comportamiento, como una persona, un sistema informatizado una persona, un sistema informatizado u organización. u organización. –– Principales (Cajero)Principales (Cajero)–– Apoyo (Servicio autorización de pago)Apoyo (Servicio autorización de pago)–– Pasivos (Hacienda)Pasivos (Hacienda)

Page 6: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

6

EscenariosEscenariosEscenarioEscenario: Una secuencia especifica de acciones : Una secuencia especifica de acciones entre los actores y el sistema = Instancia de caso entre los actores y el sistema = Instancia de caso de uso. Dentro del mismo caso de uso hay de uso. Dentro del mismo caso de uso hay escenarios de éxito y escenarios de fallo.escenarios de éxito y escenarios de fallo.Un Un Caso de UsoCaso de Uso es una colección de escenarios es una colección de escenarios de éxito y fallo relacionadosde éxito y fallo relacionados–– Ej. PDV: Gestionar Devoluciones (Ej. PDV: Gestionar Devoluciones (Formato InformalFormato Informal))

Escenario principal de éxito: Cliente llega a caja con articulos Escenario principal de éxito: Cliente llega a caja con articulos para devolver. El cajero utiliza el sistema PDV para registrar para devolver. El cajero utiliza el sistema PDV para registrar los articulos. Se actualiza el inventario. El cajero devuelve el los articulos. Se actualiza el inventario. El cajero devuelve el dinero al cliente.dinero al cliente.Escenarios alternativosEscenarios alternativos

–– Si se pago con tarjeta, y el sistema rechaza el reembolso, Si se pago con tarjeta, y el sistema rechaza el reembolso, informar al cliente y pagar en efectivo.informar al cliente y pagar en efectivo.

–– Si el identificador del articulo no se lee correctamente, Si el identificador del articulo no se lee correctamente, introducirlo a mano.introducirlo a mano.

Valor añadidoValor añadido¿Cómo puedo, utilizando el sistema, ¿Cómo puedo, utilizando el sistema, proporcionar un proporcionar un valor añadidovalor añadido al usuario o al usuario o cumplir sus objetivos?cumplir sus objetivos?–– Valor añadido parece obvio, pero la industria Valor añadido parece obvio, pero la industria

del software esta plagada de fracasos por este del software esta plagada de fracasos por este motivo. El enfoque “lista de la compra” lo motivo. El enfoque “lista de la compra” lo acentua, mientras que los casos de uso lo acentua, mientras que los casos de uso lo evitanevitan

Casos de uso = Requisitos funcionalesCasos de uso = Requisitos funcionales–– Aunque no todosAunque no todos

Page 7: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

7

Porque casos de usoPorque casos de uso

Casos de Uso no son Casos de Uso no son POOPOO–– Pero son útiles como Pero son útiles como

entrada al procesoentrada al proceso–– Son conocidos, Son conocidos,

extendidos y entendidos extendidos y entendidos (historias) por personal (historias) por personal no técnicono técnico

–– Tienen notación en UMLTienen notación en UML–– Ayudan a poner en Ayudan a poner en

contexto las cosascontexto las cosasVs. Lista de la compraVs. Lista de la compra

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– Especificaciones complementariasEspecificaciones complementarias–– VisionVision–– GlosarioGlosario

Page 8: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

8

Descubrir actores principales, Descubrir actores principales, objetivos y casos de usoobjetivos y casos de uso

1. Elegir los limites del sistema1. Elegir los limites del sistema–– Software, hardware, etc.Software, hardware, etc.–– Ej. ¿Se encuentra el sistema de autorización de pagos dentro del Ej. ¿Se encuentra el sistema de autorización de pagos dentro del

sistema? No, es un actor externosistema? No, es un actor externo2. Identificar actores principales y objetivos2. Identificar actores principales y objetivos–– Complicado: Talleres de requisitos, tormentas de ideas, etc.Complicado: Talleres de requisitos, tormentas de ideas, etc.–– Preguntas útiles:Preguntas útiles:

¿Quién arranca y para el sistema?¿Quién arranca y para el sistema?¿Quién gestiona los usuarios y la seguridad?¿Quién gestiona los usuarios y la seguridad?¿Quién se encarga de administrar el sistema?¿Quién se encarga de administrar el sistema?¿Quién evalúa la actividad o rendimiento del sistema?¿Quién evalúa la actividad o rendimiento del sistema?¿Cómo se gestionan las actualizaciones?¿Cómo se gestionan las actualizaciones?

–– El actor principal y los objetivos dependen del limite del sistemaEl actor principal y los objetivos dependen del limite del sistema3. Definir los casos de uso3. Definir los casos de uso–– Comenzar los casos de uso por un verboComenzar los casos de uso por un verbo

Actores dependen del Actores dependen del limite del sistemalimite del sistema

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collecttaxes on sales Sales Activity

System

Goal: Analyze salesand performance data

Page 9: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

9

Listas actorListas actor--objetivoobjetivo

Identificar casos de usoIdentificar casos de uso

Difícil identificar casos de uso Difícil identificar casos de uso Ej: ¿Cuáles son casos de uso?Ej: ¿Cuáles son casos de uso?–– Negociar un contrato con suministradorNegociar un contrato con suministrador–– Identificarse en el sistemaIdentificarse en el sistema–– Procesar una ventaProcesar una venta–– Arrancar el sistemaArrancar el sistema–– Parar el sistemaParar el sistema

Page 10: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

10

Identificar casos de usoIdentificar casos de usoRespuesta:Respuesta:–– Todos: Grano muy fino, demasiados, poco útil para A/DOOTodos: Grano muy fino, demasiados, poco útil para A/DOO–– Arrancar el sistema son siempre casos de uso.Arrancar el sistema son siempre casos de uso.

Quizás trivialesQuizás trivialesQuizás críticos (avionica)Quizás críticos (avionica)

–– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de uso grande: “Manejar el sistema”, tampoco utiltampoco util

Elementary Business Processes: EBPElementary Business Processes: EBP–– Una tarea realizada por una persona en un lugar, en un instante, como Una tarea realizada por una persona en un lugar, en un instante, como

respuesta a un evento del negocio, que le añade respuesta a un evento del negocio, que le añade valor cuantificable y valor cuantificable y deja los datos en un estado consistentedeja los datos en un estado consistente

Prueba del jefe: ¿Qué has hecho hoy?Prueba del jefe: ¿Qué has hecho hoy?–– Me he identificado en el sistemaMe he identificado en el sistema–– He iniciado el negociado de un contratoHe iniciado el negociado de un contrato

EBP:EBP:–– Generalmente involucran a 1 personaGeneralmente involucran a 1 persona–– Están formados por varios pasos 5Están formados por varios pasos 5--10 (con posibles alternativas)10 (con posibles alternativas)–– Se realizan en una sesiónSe realizan en una sesión–– Ej: Procesar una venta. Los otros se pueden, pero es mejor enfocarse en Ej: Procesar una venta. Los otros se pueden, pero es mejor enfocarse en

EBPEBP

Identificar casos de usoIdentificar casos de uso

Algunas preguntas rutinarias de Algunas preguntas rutinarias de comprobación:comprobación:–– ¿Existe un administrador?¿Existe un administrador?–– ¿Existe un caso de uso ¿Existe un caso de uso

ConfigurarSistema?ConfigurarSistema?–– ¿Existen casos de uso Arrancar y Parar?¿Existen casos de uso Arrancar y Parar?

Page 11: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

11

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– Especificaciones complementariasEspecificaciones complementarias–– VisionVision–– GlosarioGlosario

Tipos de formalidadTipos de formalidad

BreveBreveInformalInformalCompletoCompleto

Page 12: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

12

Formato completoFormato completowww.usecases.orgwww.usecases.orgPROCESAR VENTAPROCESAR VENTAActor principalActor principal

–– CajeroCajeroPersonal involucrado e intereses:Personal involucrado e intereses:

–– Cajero: quiere entradas rápidas y sin erroresCajero: quiere entradas rápidas y sin errores–– Vendedor: que las comisiones estén actualizadasVendedor: que las comisiones estén actualizadas–– Agencia tributaria: tener conocimiento de los impuestosAgencia tributaria: tener conocimiento de los impuestos

Precondiciones:Precondiciones:–– El cajero se identificaEl cajero se identifica

PostcondicionesPostcondiciones::–– Se registra la venta, se registra el impuesto, se registran las comisiones, se genera recibo, se actualizan la Se registra la venta, se registra el impuesto, se registran las comisiones, se genera recibo, se actualizan la

contabilidad y el inventario.contabilidad y el inventario.Escenario principal de éxito. (Sin bifurcaciones!)Escenario principal de éxito. (Sin bifurcaciones!)

–– 1. El cliente llega con mercancías al PDV1. El cliente llega con mercancías al PDV–– 2. El cajero comienza una venta2. El cajero comienza una venta–– 3. El cajero introduce el identificador del articulo3. El cajero introduce el identificador del articulo–– 4. El sistema presenta la descripción y la suma parcial4. El sistema presenta la descripción y la suma parcial

ExtensionesExtensiones–– A. En cualquier momento el sistema fallaA. En cualquier momento el sistema falla

El cajero reinicia el sistemaEl cajero reinicia el sistemaEl sistema recupera los datosEl sistema recupera los datos

–– 3.a El sistema no reconoce el identificador.3.a El sistema no reconoce el identificador.El cajero introduce a mano el identificadorEl cajero introduce a mano el identificador

Requisitos especiales:Requisitos especiales:–– El cajero utiliza una pantalla táctilEl cajero utiliza una pantalla táctil–– El tiempo de respuesta de reconocer una tarjeta inferior a 30 segundosEl tiempo de respuesta de reconocer una tarjeta inferior a 30 segundos

Lista de tecnología y variaciones de datos:Lista de tecnología y variaciones de datos:–– La firma del cliente se hace en papel, pero se pronostica que en dos años será una firma digitalLa firma del cliente se hace en papel, pero se pronostica que en dos años será una firma digital

Frecuencia:Frecuencia:–– Podría ser casi continuoPodría ser casi continuo

Temas abiertos:Temas abiertos:–– ¿Cuáles son las variaciones de la ley de impuestos?¿Cuáles son las variaciones de la ley de impuestos?–– ¿Puede el cliente utilizar el lector de tarjetas o lo tiene que hacer el cajero?¿Puede el cliente utilizar el lector de tarjetas o lo tiene que hacer el cajero?–– ¿Se le puede pedir al cliente el DNI?¿Se le puede pedir al cliente el DNI?

Formato completoFormato completo

Pagina web de la asignaturaPagina web de la asignaturaFlujos alternativosFlujos alternativos–– X.YX.Y

ExcepcionesExcepciones–– X.Y.E.ZX.Y.E.Z

Page 13: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

13

EjemploEjemplo

EjemploEjemplo

Page 14: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

14

Formato completo (2 col)Formato completo (2 col)

Escenario de éxitoEscenario de éxito Acción (intención) Acción (intención) del actordel actor

1.1. El cliente El cliente llega con llega con artículos al artículos al PDVPDV

2.2. El cajero El cajero comienza una comienza una ventaventa

3.3. El cajero El cajero introduce el introduce el identificador identificador del articulodel articulo

Responsabilidad del Responsabilidad del sistemasistema

4. Registra el 4. Registra el articulo, muestra la articulo, muestra la descripción y la descripción y la suma parcialsuma parcial

Recordar: ¡No son Recordar: ¡No son perfectos!perfectos!

Necesidad de comunicación y Necesidad de comunicación y participación:participación:–– Conexión directa entre programadores y Conexión directa entre programadores y

cajeroscajeros–– Desarrollo iterativoDesarrollo iterativo–– Comunicación personal continua y directa Comunicación personal continua y directa

(diaria)(diaria)

Page 15: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

15

Reglas de escrituraReglas de escritura

No considerar la interfaz de usuario: centrarse en la No considerar la interfaz de usuario: centrarse en la intención.intención.–– NO: El usuario teclea su login y contraseña con el teclado NO: El usuario teclea su login y contraseña con el teclado

en un cuadro de dialogoen un cuadro de dialogo–– SI: El usuario se autentica en el sistemaSI: El usuario se autentica en el sistema–– ¿Por qué? Objetivos del usuario (Cajero):¿Por qué? Objetivos del usuario (Cajero):

Que la venta quede registrada como suya.Que la venta quede registrada como suya.Que sea seguro y antirobo.Que sea seguro y antirobo.

–– A veces es inevitable, cuando se detallan los casos de uso.A veces es inevitable, cuando se detallan los casos de uso.Si falla la autenticacion, introducir por teclado…Si falla la autenticacion, introducir por teclado…

Poner los actores y casos de uso con MayusculasPoner los actores y casos de uso con MayusculasConcretos, compactos, simples. A la gente no le Concretos, compactos, simples. A la gente no le gusta leer requisitosgusta leer requisitos

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– Especificaciones complementariasEspecificaciones complementarias–– VisionVision–– GlosarioGlosario

Page 16: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

16

Casos de Uso en UMLCasos de Uso en UML

SecundariosSecundarios–– Lo importante es el texto (mas tiempo)Lo importante es el texto (mas tiempo)–– UML (menos tiempo):UML (menos tiempo):

Identificar nombresIdentificar nombresCrear un contexto visualCrear un contexto visual

RepresentaciónRepresentación–– Actores:Actores:

Muñeco (personas)Muñeco (personas)Caja (<actor>) sistemasCaja (<actor>) sistemas

Casos de uso:Casos de uso:–– ElipseElipse

EjemploEjemploNextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

Actores primarios en la izquierda

Actores apoyo en la derecha

EBP

Page 17: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

17

EjemploEjemplo

EjemploEjemplo

Page 18: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

18

Inclusión y extensiónInclusión y extensión

Ejemplo maquina de refrescosEjemplo maquina de refrescos–– “Abrir puerta”, relacion <<include>>“Abrir puerta”, relacion <<include>>

GeneralizaciónGeneralización

Los casos de uso admiten Los casos de uso admiten generalización y herenciageneralización y herencia–– Relacion <<extend>>Relacion <<extend>>

Los actores tambiénLos actores también

Page 19: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

19

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– VisiónVisión–– GlosarioGlosario–– Especificaciones complementariasEspecificaciones complementarias

Visión del proyectoVisión del proyecto¿Es viable?¿Es viable?¿Comprar o construir?¿Comprar o construir?1000 1000 €€ o 10000000 o 10000000 €€¿Seguimos o no?¿Seguimos o no?

Vislumbrar el alcance del producto, visión y análisis del negocio

Responder la pregunta: ¿Esta de acuerdo el personal en la visión del proyecto y merece la pena invertir en un estudio mas serio?

-Es necesaria una exploración de los requisitos (preliminar)

-Puede ser una etapa muy breve (1-2 semanas), especialmente si se tiene experiencia; obvio

Page 20: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

20

Visión del proyectoVisión del proyecto

Grandes ideasGrandes ideas–– Porque se propone el proyectoPorque se propone el proyecto–– Cuales son los problemasCuales son los problemas–– Que personas hay involucradas y que Que personas hay involucradas y que

necesitannecesitan–– Apariencia de la solución propuestaApariencia de la solución propuesta

Visión: Ejemplo PDVVisión: Ejemplo PDVHistoria de revisionesHistoria de revisiones

–– Borrador #, fecha, descripcion, autorBorrador #, fecha, descripcion, autorIntroducciónIntroducción

–– Una aplicación PDV, tolerante a fallos, múltiples interfaces, integracion con sistemas de Una aplicación PDV, tolerante a fallos, múltiples interfaces, integracion con sistemas de terceros…terceros…

OrientaciónOrientación–– Oportunidad del negocioOportunidad del negocio

Lo que existe no es adaptable, no extensibleLo que existe no es adaptable, no extensible–– Enunciado del problemaEnunciado del problema

Los sistemas son inflexibles, dando problemas a los cajerosLos sistemas son inflexibles, dando problemas a los cajeros–– Posición en el mercadoPosición en el mercado

A quien esta dirigidoA quien esta dirigidoAlternativas, competencia, y en que se diferenciaAlternativas, competencia, y en que se diferencia

Descripción del personal involucradoDescripción del personal involucrado–– Demografía de mercado, no usuariosDemografía de mercado, no usuarios–– Resumen de usuariosResumen de usuarios–– Objetivos de alto nivel: procesar ventas rapida y robustamenteObjetivos de alto nivel: procesar ventas rapida y robustamente–– Objetivos de usuarios: Listas de actorObjetivos de usuarios: Listas de actor--objetivosobjetivos

CajeroCajero--Procesar ventasProcesar ventasAdministradorAdministrador--Gestionar usuariosGestionar usuarios

Visión general del productoVisión general del producto–– Perspectiva: Estará en las tiendas o en terminales móviles cercanos a las tiendasPerspectiva: Estará en las tiendas o en terminales móviles cercanos a las tiendas–– Resumen de beneficiosResumen de beneficios–– Licencia e instalaciónLicencia e instalación

Etc.Etc.

Page 21: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

21

Visión: PlantillaVisión: Plantilla

No confundir con No confundir con característicascaracterísticas

Page 22: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

22

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– VisionVision–– Glosario Glosario –– Especificaciones complementariasEspecificaciones complementarias

Glosario: EjemploGlosario: Ejemplo

Page 23: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

23

Glosario: EjemploGlosario: Ejemplo

GlosarioGlosario

Comenzarlo cuanto antesComenzarlo cuanto antes–– Palabras que tienen distinto significadoPalabras que tienen distinto significado

Historia de revisionesHistoria de revisiones–– Borrador #, fecha, descripcion, autorBorrador #, fecha, descripcion, autor

Termino Termino –– Definicion Definicion –– Alias.Alias.–– Formato: Tipo, longitud, unidadFormato: Tipo, longitud, unidad–– Relaciones con otros elementosRelaciones con otros elementos–– Rango de valoresRango de valores–– Reglas de validacionReglas de validacion

Page 24: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

24

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– VisionVision–– Glosario Glosario –– Especificaciones complementariasEspecificaciones complementarias

Especificación Especificación complementariacomplementaria

IntroducciónIntroducciónFuncionalidadFuncionalidad

–– Funcionalidad básica común a muchos casos de usoFuncionalidad básica común a muchos casos de usoRegistro y gestión de erroresRegistro y gestión de errores

–– Todos los errores se registraran en almacenamiento persistenteTodos los errores se registraran en almacenamiento persistenteSeguridadSeguridad

–– Lo referente a la autenticación de usuarios (claves, protocolos)Lo referente a la autenticación de usuarios (claves, protocolos)Facilidad de usoFacilidad de uso

–– Factores humanosFactores humanosLegibilidad y visibilidad del textoLegibilidad y visibilidad del textoErgonomía, saludErgonomía, saludUtilizar sonidos, ya que el cajero mira al clienteUtilizar sonidos, ya que el cajero mira al cliente

FiabilidadFiabilidad–– Capacidad de recuperación. (Mucho analisis)Capacidad de recuperación. (Mucho analisis)

RendimientoRendimiento–– Cuellos de botella potenciales.Cuellos de botella potenciales.

SoporteSoporte–– AdaptabilidadAdaptabilidad–– ConfigurabilidadConfigurabilidad

Restricciones de implementaciónRestricciones de implementación–– Java, C++Java, C++

Page 25: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

25

Especificación Especificación complementariacomplementaria

Componentes adquiridosComponentes adquiridosComponentes de libre distribuciónComponentes de libre distribución–– Intentar maximizarlosIntentar maximizarlos

Interfaces y hardwareInterfaces y hardware–– Pantalla táctilPantalla táctil–– Escaner laserEscaner laser–– Impresora de recibosImpresora de recibos

Interfaces softwareInterfaces softwareReglas del dominioReglas del dominio–– Ej: Reglas de descuento del comprador, empleado 20%. Ej: Reglas de descuento del comprador, empleado 20%.

Variabilidad: alta. Fuente: politica de tienda.Variabilidad: alta. Fuente: politica de tienda.Cuestiones legalesCuestiones legales–– Licencias propias y ajenas.Licencias propias y ajenas.

Especificacion complementariaEspecificacion complementaria

Page 26: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

26

Relacion con otros Relacion con otros componentescomponentes

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

Secuencia de capturaSecuencia de captura

¿Por donde empezamos?¿Por donde empezamos?No estrictoNo estricto–– Borrador breve de la Visión del proyectoBorrador breve de la Visión del proyecto–– Identificar los objetivos de usuarioIdentificar los objetivos de usuario–– Escribir algunos casos de uso y comenzar Escribir algunos casos de uso y comenzar

el documento de especificaciones el documento de especificaciones complementariascomplementarias

–– Refinar la Visión, resumiendo a partir de Refinar la Visión, resumiendo a partir de la informacion de casos de uso.la informacion de casos de uso.

Page 27: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

27

EsfuerzoEsfuerzo

Gestión de documentosGestión de documentos

Artefactos recogidos solo digitalmente, Artefactos recogidos solo digitalmente, online y accesibles.online y accesibles.No se trata de poner información No se trata de poner información duplicada: gestionar correctamente la duplicada: gestionar correctamente la información mediante enlaces o información mediante enlaces o hipervínculos. hipervínculos.

Page 28: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

28

ÍndiceÍndice

Fase de InicioFase de InicioComprensión de los requisitosComprensión de los requisitosRequisitosRequisitos–– Modelo de Casos de UsoModelo de Casos de Uso

IdentificarlosIdentificarlosFormatosFormatosUMLUML

–– Especificaciones complementariasEspecificaciones complementarias–– VisionVision–– GlosarioGlosario

Artefactos Fase InicioArtefactos Fase InicioModelo de Casos de UsoModelo de Casos de Uso¿Mucha documentación?¿Mucha documentación?

–– GuíaGuía–– Solo se completan Solo se completan

parcialmente en esta parcialmente en esta fasefase

–– Lo importante no es el Lo importante no es el documento, sino pensar documento, sino pensar los problemas y luego los problemas y luego “Registrar” esos “Registrar” esos pensamientospensamientos

OnOn--LineLine–– No si no aportan valor No si no aportan valor

añadidoañadido–– Ej. Casos de UsoEj. Casos de Uso

Lista generalLista general10% en detalle10% en detalle

–– Reutilización de Reutilización de documentacióndocumentación

Orden, nomenclaturaOrden, nomenclatura

ProgramaciónProgramación–– Algunas pruebas de Algunas pruebas de

conceptos (Interfaz) y conceptos (Interfaz) y experimentación criticaexperimentación critica

Page 29: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

29

Recordar: Fase de InicioRecordar: Fase de Inicio

CompletoCompleto InformalInformal BreveBreve

Procesar VentaProcesar Venta Procesar AlquilerProcesar Alquiler Abrir cajaAbrir caja

Gestionar Gestionar devolucionesdevoluciones

Analizar Analizar actividad de actividad de ventasventas

Cerrar cajaCerrar caja

Gestionar Gestionar usuariosusuarios

Poner en marchaPoner en marcha

Etc.Etc.

No se entiende Fase No se entiende Fase Inicio si:Inicio si:

La duración > pocas semanasLa duración > pocas semanasSe intenta definir la mayoría de los requisitosSe intenta definir la mayoría de los requisitosSe piensa que las estimación son fiablesSe piensa que las estimación son fiablesSe define la arquitecturaSe define la arquitecturaSe cree que la secuencia esSe cree que la secuencia es–– Definición de requisitosDefinición de requisitos–– Diseño arquitecturaDiseño arquitectura–– ImplementaciónImplementación

No hay artefacto de Visión y Análisis del NegocioNo hay artefacto de Visión y Análisis del NegocioNo se identificaron la mayoría de los casos de usoNo se identificaron la mayoría de los casos de usoSe escribieron con detalle la mayoría de los casos de usoSe escribieron con detalle la mayoría de los casos de usoNinguno de los casos de uso se escribió con detalleNinguno de los casos de uso se escribió con detalle

Page 30: cap2Requisitos.ppt [Modo de compatibilidad] - elai.upm.es · –– Podemos acabar con un único caso de uso grande: “Manejar el sistema”, Podemos acabar con un único caso de

07/03/2011

30

EjerciciosEjercicios

JuegoJuego