IDENTIFICACIN DE OTROS REQUISITOS

7 Introduccin
No es suficiente escribir casos de uso. Existen otros tipos de requisitos que son necesarios identificar, como: o Especificacin Complementaria: documentacin, empaquetamiento, soporte, licencia, etc. o Glosario: almacena los trminos y definiciones. o Visin: resume la visin del proyecto. Sirve para comunicar de manera concisa las grandes ideas acerca de por qu se propuso el proyecto, cuales son los problemas, quienes son las personas involucradas, qu necesitan y cul podra ser la apariencia de la solucin propuesta.

7.1 Ejemplos del PDV NuevaEra 7.2 Ejemplo NuevaEra: Especificacin Complementaria (Parcial)
Historia de revisiones Introduccin Funcionalidad o Registro y gestin de errores o Reglas de negocio conectables o Seguridad Facilidad de uso o Factores humanos Fiabilidad o Capacidad de recuperacin o Rendimiento Soporte o Adaptabilidad o Facilidad para cambiar la configuracin Restricciones de Implementacin Componentes adquiridos Componentes de libre distribucin Interfaces o Interfaces hardware destacables o Interfaces software Reglas de dominio (negocio) Cuestiones legales Informacin en dominios de inters o Fijacin de precios o Gestin de pagos a crdito y dbito o Impuesto de ventas o Identificadores de artculos

7.3 Comentario: Especificacin Complementaria

Los elementos de la especificacin complementaria podra comprender: o Requisitos FURPS+. o Informes. o Restricciones de software y hardware (SSOO, red, ...).

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

o o o o o o o o o o o

Restricciones de desarrollo. Otras restricciones de diseo e implementacin. Cuestiones de internacionalizacin (unidades, idiomas, ...). Documentacin y ayuda. Licencia y otras cuestiones legales. Empaquetado Estndares (tcnico, seguridad, calidad). Cuestiones del entorno fsico (calor, vibracin). Cuestiones operacionales. Reglas de dominio o negocio. Informacin en los dominios de inters.

Atributos de calidad Algunos requisitos se denominan atributos de calidad (-ilities) de un sistema. Estos incluyen facilidad de uso, fiabilidad, etc. Hay de dos tipos: 1. Observables en la ejecucin. 2. No observables en la ejecucin. Aunque la funcionalidad es un atributo de calidad vlido, en su uso comn, el trmino atributo de calidad casi siempre se refiere a cualidades del sistema que no sean la funcionalidad. Reglas del domino (negocio) Las reglas del dominio o negocio dictan el modo en el que podra operar un dominio o negocio. No son requisitos de ninguna aplicacin, aunque, a menudo, los requisitos de una aplicacin se ven afectados por las reglas del dominio. Con frecuencia, resulta til identificar y registrar aquellas reglas del domino que afectan a los requisitos, normalmente materializados en casos de uso, porque pueden clarificar el contenido de un caso de uso ambiguo o incompleto. Las reglas no son requisitos de la aplicacin. Informacin en los dominios de inters A menudo, a los expertos del dominio que se est estudiando, les resulta til escribir explicaciones de dominios relacionados con el nuevo sistema software, para representar el contexto y ayudar a la comprensin por parte del equipo de desarrollo.

7.4 Ejemplo NuevaEra: Visin (Parcial)

Historia de revisiones Introduccin Orientacin o Oportunidad del negocio o Enunciado del problema o Enunciado de la posicin en el mercado del producto o Alternativas y competencia Descripcin del personal involucrado o Demografa de mercado o Resumen del personal involucrado (No usuarios) o Resumen de Usuarios o Objetivos de alto nivel y problemas claves del personal involucrado o Objetivos de nivel de usuario

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

o Entorno de usuario Visin general del producto o Perspectiva del producto o Resumen de beneficios o Suposiciones y dependencias o Coste y fijacin del precio o Licencia e instalacin Resumen de las caractersticas del sistema Otros requisitos y restricciones

7.5 Comentario: Visin

Estamos solucionando el mismo problema? El problema es correcto? El enunciado del problema Durante el trabajo de requisitos en la fase de inicio, hay que colaborar para definir un enunciado del problema conciso. Algunas veces, este trabajo revela diferencias de opinin fundamentales en lo que las partes estn tratando de conseguir. Una alternativa al simple texto es el formato de tabla propuesto en la plantilla del RUP para el enunciado del problema:
El problema de Afecta El impacto de lo cual es Una solucin de xito sera

Los objetivos de alto nivel y problemas claves del personal involucrado Esta tabla resume los objetivos y problemas a un nivel ms alto que los caso de uso de nivel de tarea y muestra importantes objetivos no funcionales y de calidad que podran pertenecer a un caso de uso o abarcar a muchos. Cules son los problemas y objetivos esenciales? El analista del sistema, necesita estudiar la cadena de problemas y objetivos para aprender los problemas subyacentes y su importancia e impacto relativos y de este modo priorizar y solucionar las cuestiones ms relevantes con una solucin ingeniosa. Mtodos para facilitar la idea del grupo Algunas tcnicas tiles de ayuda al grupo para el descubrimiento de los problemas y objetivos esenciales y para ayudar a la generacin de ideas y su priorizacin: o Mapas mentales. o Diagramas causa-efecto (fish-bone). o Diagramas pareto. o Tormenta de ideas (brainstroming). o Multimotivacin. o Votacin por puntos (dot voting). o Tcnica de grupo nominal. o Escribir ideas en silencio (brainwriting).

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

Diagramas de afinidad.

Caractersticas del sistema, requisitos funcionales Un modo alternativo, complementario para expresar las funciones del sistema, es mediante las caractersticas, o ms concretamente en este contexto, caractersticas del sistema, que son sentencias concisas, de alto nivel, que resumen las funciones del sistema. Ms formalmente, en UP, una caracterstica del sistema es un servicio observable externamente proporcionado por el sistema que cumple directamente una necesidad del personal involucrado. Ej.: El sistema deber hacer la autorizacin del pago Recordemos que la Visin podra utilizarse como contrato formal o informal entre los desarrolladores y la empresa. Las caractersticas del sistema constituyen un mecanismo para resumir, en este contrato, lo que el sistema har.

Notacin y organizacin Ante todo, son importantes las descripciones breves de alto nivel. Uno debera ser capaz de leer la lista de caractersticas del sistema rpidamente. Ej.: Las caractersticas principales incluyen: Servicios PDV Gestin de inventario Compras basadas en la web

Es deseable un documento de Visin con menos de 50 caractersticas. Si hay ms, considere la posibilidad de agrupar y abstraer las caractersticas.

Otros requisitos en la Visin La visin puede resumir otros requisitos que se detallan en la seccin de Requisitos Especiales de los casos de uso y en la Especificacin Complementaria (Supplementary Specification) como la fiabilidad y facilidad de uso, por ejemplo. Sin embargo hay peligro de duplicaciones intiles y tal cosa es inevitablemente difcil de mantener. Visin, caractersticas o caso de uso, qu va primero? No es til ser estricto en el orden de algunos artefactos. Sin embargo, la secuencia recomendada es: 1. Escribir un primer borrador breve de la Visin. 2. Identificar los objetivos de usuario y los casos de uso de apoyo. 3. Escribir algunos casos de uso y comenzar la Especificacin Complementaria. 4. Refinar la Visin, resumiendo la informacin a partir de stos.

7.6 Ejemplo NuevaEra: un Glosario (Parcial)

Historia de revisiones Definiciones

7.7 Comentario: Glosario (Diccionario de Datos)

El Glosario es una lista de los trminos relevantes y sus definiciones. El objetivo no es recoger todos los posibles trminos, sino aquellos que no estn claros, son ambiguos o que requieren algn tipo de elaboracin relevante, como el formato de la informacin o las reglas de validacin.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

El Glosario como diccionario de datos En el UP, el Glosario tambin juega el rol de diccionario de datos, un documento que recoge los datos sobre los datos, es decir, metadatos. Unidades Se deben tener en cuenta la unidades (moneda, medidas, ), especialmente en esta era de aplicaciones software internacionalizadas. Trminos compuestos El Glosario no est destinado solo a trminos atmicos como el precio del artculo, pude y debe incluir trminos compuestos como venta, que incluye otros elementos tales como fecha y ubicacin.

7.8 Especificaciones fiables: Un Oxmoron?

Ningn artefacto de requisitos forman una especificacin fiable. Slo escribiendo cdigo, probndolo, obteniendo retroalimentacin, manteniendo una estrecha colaboracin los usuarios y los clientes y adaptando, se da realmente en el blanco.

7.9 Artefactos disponibles en el sitio web del proyecto 7.10 Otros artefactos de requisitos en el UP
Disciplina Modelado del Negocio Requisitos Artefacto Iteracin Modelo del Dominio Modelos de Casos de Uso Visin Especificacin Complementaria Glosario Modelo de Diseo Documentacin de Arquitectura SW Modelo de Datos Modelo de Implementacin Plan de Desarrollo SW Modelo de Pruebas Marco de Desarrollo Inicio I1 c c c c Elab. E1En c r r r r c c c c r c r Const. C1Cn Trans. T1T2

Diseo

r r r r r

Implementacin Gestin del Proyecto Pruebas Entorno

c c

r r

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com