Post on 03-Dec-2015
description
transcript
Requisitos
CAL/Modelo de Análisis
Conceptos
Modelos son abstracciones completas de sistemas. Se usan para capturar el conocimiento (la semántica) sobre los problemas y soluciones. Los diagramas son proyecciones gráficas de juegos de elementos del modelo. Los diagramas se usan para graficar el conocimiento (la sintaxis) sobre los problemas y soluciones.
CAL/Modelo de Análisis
Requisitos Un requisito de software se puede definir
como: una capacidad del software necesaria para que el usuario resuelva un problema o alcance un objetivo.
Una capacidad de software debe ser encontrada o poseída por un sistema o componente de sistema para satisfacer un contrato, especificación, estándar u otra documentación formalmente impuesta.
“una condición o capacidad que el sistema [en construcción] debe satisfacer“.
CAL/Modelo de Análisis
RequisitosUna lista de problemas relacionados con la
gestión de los requisitos: Los requisitos no siempre son obvios y
provienen de muchas fuentes. Los requisitos no son siempre fáciles de
expresar claramente con palabras. Existe muchos tipos diferentes de requisitos en
diferentes niveles de detalle. El número de requisitos puede ser inmanejable
si no es controlado.
CAL/Modelo de Análisis
Técnicas para Gestionar Requisitos
Analizar el problema Obtener un acuerdo sobre el problema a ser
resuelto. Identificar los stackeholders. Definir los límites del sistema. Identificar restricciones a imponerse sobre el
sistema. Comprender las necesidades del
Stakeholder. Fuentes : Clientes, socios, usuarios finales,
expertos del dominio, entre otros.
CAL/Modelo de Análisis
Técnicas para Gestionar Requisitos
Es importante saber como determinar cuales deberían ser las fuentes, como tener acceso y como obtener información de ellas. Los individuos que sirven como fuente primaria de esta información son los llamados "stakeholders" en el proyecto.
Las técnicas para obtener requisitos incluyen entrevistas, tormenta de ideas, prototipeo conceptual, cuestionarios y análisis competitivo. El resultado de obtener requisitos es una lista de pedidos o necesidades que son descritos textual o gráficamente y que tienen prioridades relativas entre si.
CAL/Modelo de Análisis
Tipos de Requisitos Tipos de requisitos
Identificando los tipos de requisitos, el equipo puede organizar un gran número de requisitos en grupos significativos y mas manejables.
Usualmente, un tipo de requisitos puede ser partido, o descompuesto en otros tipos. Las reglas del negocio y las declaraciones de visión pueden ser tipos de requisitos de alto nivel de los cuales se deriven los tipos de requisito de necesidades del usuario, de características del producto.
CAL/Modelo de Análisis
Atributos de requisitos Atributos multidimensionales
Cada tipo de requisito tiene atributos, y cada requisito individual tiene diferentes valores de atributo. Por ejemplo, a los requisitos pueden asignársele prioridades, identificarse por la fuente, delegarse a equipos específicos dentro de un área funcional, dar una denominación del grado de dificultad, o estar asociado con una iteración particular del sistema.
CAL/Modelo de Análisis
Atributos de requisitos En tipos de requisitos mas detallados, los
atributos de prioridad y esfuerzo pueden tener valores más específicos (e.g., tiempo estimado, líneas de código, etc.) con los cuales refinamos mas el alcance.
Historia de cambios A medida que los requisitos evolucionan, es
importante entender su historia: que ha cambiado?, porque?, cuando?, y con cual autorización?.
CAL/Modelo de Análisis
Existen muchas clases diferentes de requisitos. Una forma de categorizar es descrita por el modelo FURPS+, Utilizando el acrónimo FURPS para describir las categorías principales de requisitos con subcategorías como se muestra:
• Funcionality (funcionalidad)• Usability (Facilidad de uso)• Reliability (Confiabilidad)• Performance, (Rendimiento) y• Supportability (Soporte)
requisitos FURPS+
CAL/Modelo de Análisis
requisitos FURP+El "+" en FURPS+ le ayuda a recordar que
también incluye otros requisitos como:• Restricciones de diseño,• requisitos de implementación,• requisitos de interfase y• requisitos físicos.
CAL/Modelo de Análisis
requisitos FURPS+
Los requisitos Funcionales especifican acciones que un sistema de software debe ser capaz de ejecutar, sin considerar restricciones físicas. Estos se describen frecuentemente en un modelo de casos de uso. Los requisitos funcionales especifican de esta forma el comportamiento de entrada y salida de un sistema.
CAL/Modelo de Análisis
requisitos FURPS+Los requisitos funcionales pueden
incluir: Conjuntos de características, Capacidades y Seguridad.
CAL/Modelo de Análisis
Facilidad de Uso (Usability)
Puede incluir categorías como : Factores de tipo humano, Ergonómicos y estéticos, Consistencia en las interfaces de usuario, y Materiales de entrenamiento y
documentación del usuario. Ayudas sensitivas al contexto y en línea. Asistentes.
requisitos FURPS+
CAL/Modelo de Análisis
requisitos FURPS+Confiabilidad (Reliability)
Donde podemos considerar: Frecuencia / severidad de fallas, Recuperabilidad, Predictibilidad, Exactitud, y Tiempo medio entre fallas
(MTBF).
CAL/Modelo de Análisis
Performance Un requisito de rendimiento impone condiciones sobre los requisitos funcionales. Por ejemplo, para una acción dada, puede parámetros de rendimiento:
Velocidad Eficiencia, Disponibilidad, Exactitud, Throughput, Tiempo de respuesta, Tiempo de recuperación, o Utilización de recursos
requisitos FURPS+
CAL/Modelo de Análisis
Soporte puede incluir: Que esté sujeto a prueba, Que se pueda extender, Que se pueda adaptar, Que se pueda mantener, Que sea compatible, Que sea configurable, Que se pueda aplicar servicio, Que sea instalable, o Que se pueda localizar (internacionalizar)
requisitos FURPS+
CAL/Modelo de Análisis
El + indica: Restricciones de diseño requisitos de implementación:
Estándares necesarios. Lenguajes de implementación. Políticas de integridad de datos. Ambientes operacionales
requisitos FURPS+
CAL/Modelo de Análisis
requisitos de interfase especifican Un ítem externo con el cual el sistema
debe interactuar. Restricciones en el formato, tiempos y
otros factores, usados en la interacción.
requisitos FURPS+
CAL/Modelo de Análisis
requisitos físicos – especifica requisitos de hardware (redes)
Formas Tamaños Pesos Material
requisitos FURPS+
CAL/Modelo de Análisis
Lista de requisitosLista de Requerimientos del Sistema: Nombre del sistema
Clasificación Atributos
FURPS+Prioridad(A, M, B)
Categoría(P, S, O)
Dificultad(A, M, B)
Visibilidad(V,O)
Riesgo(A, M, B)
Precedencia
R1 Registrar Sucursales. F A P M V B R2 Registrar el "Producto". F A P A V M R3 Registrar los precios de los Productos. F A P B V M R2
R4Consultar los Productos en Catálogo vía WEB.
F, + A P B V M R2
R5Registrar la flota de vehículos por Sucursal.
F A P B V B R1, R2
R6 Clasificar vehículos por producto. F A P B V B R2R7 Consultar vehículos por producto. F A P B V B R5
R8Definir los años de antigüedad para dar de baja a los vehículos.
F A P B V M R2
R9Generar avisos automáticos devehículos candidatos a baja.
F M S B O B R5, R8
R10Registrar la baja de vehículos y notificar a ventas.
F A P B V B R5, R8
R11 Registrar Reservas. F A P B V B R1, R2, R3
R12Habilitar el registro de la Reserva en una página WEB para los clientes.
F, + A P B V B R11
R13Habilitar el registro de reservas en una interfaz apropiada para el
F A P B V B R11
R14Registrar a los Clientes con sus datosgenerales y comerciales.
F A P B V B
R15Habilitar una Interfaz WEB para que un cliente nuevo registre sus datos.
F, + A P B V B R14
RequerimientoNro.
CAL/Modelo de Análisis
Diagramas de Casos de Uso
Los actores son usados para modelar y representar losroles de los usuarios del sistema, que incluye usuarios
humanos y otros sistemas.
• Los Actores son externos al sistema.• Los actores interactúan con el sistema. Los actores usan
la funcionalidad proporcionada por el sistema, incluyendo la funcionalidad de la aplicación y funcionalidad de mantenimiento.
• Los actores pueden recibir información proporcionada por el sistema. Los actores pueden proporcionar información al sistema.
• Las Clases Actor tienen instancias u objetos que representan actores específicos.
CAL/Modelo de Análisis
Diagramas de Casos de Uso Los casos de uso son usados para
modelar y representar unidades de funcionalidad o servicios proporcionados por un sistema (o partes de un sistema, subsistema o clases) a un usuario. Los casos de uso son Elipses u Óvalos.
CAL/Modelo de Análisis
Diagramas de Casos de Uso
Los casos de uso son interacciones o diálogos entre un sistema y actores, incluyendo los mensajes intercambiados y las acciones ejecutadas por el sistema.
Los casos de uso pueden incluir variantes de estas secuencias, incluyendo secuencias alternativas y excepciones.
CAL/Modelo de Análisis
Diagramas de Casos de Uso
Un caso de uso es iniciado generalmente, por un actor y puede involucrar la participación de muchos actores. Los casos de uso deberían proporcionar valor al menos a uno de los participantes.
Los casos de uso pueden tener puntos de extensión que definen puntos específicos dentro de una interacción en los cuales otros casos de uso se puedan insertar.
CAL/Modelo de Análisis
Diagramas de Casos de Uso
Los casos de uso (clases) tienen una instancia de caso de uso llamada escenario la ejecución particular de un caso de uso y que representan una interacción específica.
La asociación entre actor y caso de uso indica que el actor participa y se comunica con el sistema que contiene los casos de uso.
CAL/Modelo de Análisis
Diagramas de Casos de Uso
Las asociaciones con punta de flecha pueden usarse para denotar quien inicia la interacción, éstas eran usadas en versiones anteriores de UML.
CAL/Modelo de Análisis
Actores
Deberían ser denominados con frases sustantivas.
Deberían describirse indicando el interés que tiene al interactuar con el sistema.
Definen el alcance de un sistema e identifican aquellos elementos que residen en la periferia del sistema y aquellos elementos de los cuales depende el sistema.
CAL/Modelo de Análisis
Casos de Uso Deberían denominarse usando frases
con verbo. Deberían describir como se empieza y
como termina, cualquier condición que se debe satisfacer antes de que el caso de uso empiece (pre - condición), cualquier condición que debe satisfacerse cuando el caso de uso finalice (post – condición).
CAL/Modelo de Análisis
Casos de Uso La secuencia de mensajes
intercambiados y acciones ejecutadas, los datos intercambiados, y cualquier características no funcional (Confiabilidad, rendimiento, soporte, restricciones, etc.).
Estas descripciones se pueden capturar usando texto u otros diagramas UML.
CAL/Modelo de Análisis
Casos de Uso Deberían facilitar a los actores lograr o
conseguir sus metas. Los CU son funcionalidades o responsabilidades del sistema (requisitos) que los actores usan para lograr satisfacer sus metas.
Deberían facilitar la arquitectura del sistema. Pueden ser estructurados con Include, Extend y Generalización, para identificar, extraer y manejar funcionalidad común, opcional y similar.
CAL/Modelo de Análisis
Casos de Uso Los CU proporcionan la flexibilidad y
poder a través del ciclo de vida. Los CU deberían usarse como base
para el planeamiento. Los CU deberían usarse como base
para el análisis, diseño e implementación.
CAL/Modelo de Análisis
Casos de Uso Los casos de uso deberían ser
usados como base para las pruebas. La secuencia de mensajes intercambiados y las acciones ejecutadas pueden ser usadas como un script para hacer el test.
Los CU son usados como base para la documentación.
CAL/Modelo de Análisis
Modelo de Casos de UsoUn modelo de casos de uso consiste de actores, casos
de uso y vínculos entre ellos. Los actores representan todo aquello que debe intercambiar información con el sistema, incluyendo a los llamados usuarios. Cuando un actor usa el sistema, el sistema ejecuta un caso de uso. Un buen caso de uso es una secuencia de transacciones que producen un resultado de valor mensurable para el actor. La colección de casos de uso es la funcionalidad completa del sistema.
Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software Engineering – A Use Case Driven Approach, Addison Wesley – ACM Press, 1992
CAL/Modelo de Análisis
Modelando Casos de Uso
CAL/Modelo de Análisis
Modelando Casos de Uso
CAL/Modelo de Análisis
Modelando Casos de Uso
CAL/Modelo de Análisis
Modelando Casos de Uso
CAL/Modelo de Análisis
Modelando Casos de Uso
Revise que necesidades o requisitos del usuario son Soportados por que casos de uso.