Captura de requisitos.

Captura de requisitos.Por qu es complicadoCapturar requisitos es muy complicado:no haces sw para ti sino para otrosse supone que los otros saben EXACTAMENTE lo que quierense supone que los otros te van a explicar perfectamente lo que quierense supone que los otros hablan tu mismo idiomaEl analista debe hablar el mismo idioma que el usuario, lo cul implica:conocer el modelo de negociotener cuidado a la hora de formalizar informacin

Cmo lo conseguimos (I)Lista de requisitos candidatosPara cada requisito:Descripcin.Estado -propuesto, aprobado, incorporado, validado-Coste estimado para implantarlo -en trminos de recursos y hora/persona-Prioridad.Nivel de riesgo.Comprender el contexto del sistemaModelo de dominio: describe los conceptos importantes del contexto como objetos del dominio, y los enlaza entre s.Modelo de negocio: en ocasiones puede ser necesario conocer el proceso de negocio en el que estamos involucrados -p.e. renta fija para la realizacin de una aplicacin de tiempo real-Este es el concepto clsico de consultor.

Cmo lo conseguimos (y II)Capturar los requisitos funcionalesAqu es donde modelamos nuestros casos de uso.Capturar los requisitos no funcionalesEspecificacin de propiedades del sistema -entorno, restricciones de implementacin, prestaciones, dependencias de plataforma, -Tipos de RequisitosFuncionales: diferentes tareas del sistema futuro.De Interfaz: de usuario, entre mdulos SW, Operacionales: uso futuro del sistema -backups, recuperaciones, -De Documentacin.De Seguridad: proteccin, niveles de acceso, histricos, De mantenibilidad y portabilidad.De recursos: limitaciones de memoria, discos, De verificacin y fiabilidad: qu errores se pueden producir, cules soporta, De rendimiento.De comportamiento.Resultados

Actividades de RequisitosEncontrar actores y casos de usoPriorizar casos de usoDetallar un caso de usoPrototipado de interfaz de usuarioEstructurar el modelo de casos de usoActividad: Encontrar actores y casos de uso (I)Actividad realizada por el analista.Encontrar actoresHabr tpicamente un actor por cada tipo de usuario del sistema y por cada sistema externo que interactue con l.Para cada actor, debe haber al menos un usuario real.Encontrar casos de usoSi no hay modelo de negocio (lo habitual), el analista identifica los casos de uso mediante reuniones de trabajo con los actores.Actividad: Encontrar actores y casos de uso (II)Describir brevemente cada caso de usoPrecondiciones, flujos alternativos, postcondiciones, etc.El caso de uso ha de ser:CorrectoNo ambiguoVerificableClasificableRealista.Actividad: Encontrar actores y casos de uso (y III)Describir el modelo de casos de uso globalEl objetivo es explicar cmo se relacionan los casos de uso entre ellos y con los actores. Si hay muchos casos de usos pueden agruparse en paquetes.No se trata slo de listar casos de uso. Hay que identificar casos de uso contenidos en otros (y probablemente compartidos en otros), generalizaciones y extensiones de caso de uso.El modelo ha de ser:CompletoConsistente

Actividad: Priorizar casos de usoActividad realizada por el arquitecto.En las primeras iteraciones, los casos de uso relevantes para la arquitectura tienen mayor prioridad.En la priorizacin se tienen en tambin en cuenta aspectos econmicos, de negocio, etc.Actividad: Detallar un caso de usoActividad realizada por el especificador de casos de uso.Datos por cada caso de uso:PrecondicionesPostcondicionesSecuencia de acciones:Flujo bsico.Flujos alternativos.Describir exactamente qu hace el sistema y qu hacen los actores.Los requerimientos no funcionales (eficiencia, etc.) se aaden en una seccin aparte.Actividad: Prototipado de interfaz de usuarioActividad realizada por el diseador de interfaz de usuario.El objetivo es decidir la interfaz de usuario detalladamente para cada actor. Esta actividad no va a ser generalmente requerida, aunque en proyectos innovadores puede ser necesario.Actividad: Estructurar el modelo de casos de usoActividad realizada por el analista.La idea es bsicamente :Encontrar comportamientos comunes en diferentes casos de uso, de manera que podamos agrupar ese comportamiento comn en un caso de uso reutilizado por otros (caso de uso abstracto).Encontrar casos de uso que son extensiones de otros casos de uso. Por ejemplo, si en un caso de uso de una transferencia bancaria no hay fondos en la cuenta origen, se inicia el caso de uso de reclamar a un moroso. Es decir un caso de uso B aparece cuando en la ejecucin de un caso de uso A ocurren unas ciertas condiciones.EjemploAplicacin de realizacin de Tests por ordenadorCliente: PblicoObjetivo: pruebas de comprobacin de prerrequisitos para las asignaturas.Premisas:El proyecto ha sido aceptado financieramente.Se parte de una reunin informal con el cliente, a partir del cual hay que establecer la lista de requisitos. Se supone que la lista bsica de requisitos ya existe.A partir de la lista de requisitos, hay que construir el sistema software utilizando el proceso unificado.TareaInvestigar Ciclos de vida del softwareMetodologa de desarrollo del softwareDesarrollo interactivo e incremental.Desarrollo gil

Indicar cual utilizaras y por que?Trabajo a realizarArtefactos resultantes

Listar requisitos candidatosLista de caractersticas

Comprender el contexto del sistemaModelo de negocio o de dominio

Capturar requisitos funcionalesModelo de casos de uso

Capturar requisitos no funcionalesRequisitos suplementarios o casos de uso individuales