requisitos y cu

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.


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“.


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.


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.


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.


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.


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.


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?.


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+


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.


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.


requisitos FURPS+Los requisitos funcionales pueden

incluir: Conjuntos de características, Capacidades y Seguridad.


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+


requisitos FURPS+Confiabilidad (Reliability)

Donde podemos considerar: Frecuencia / severidad de fallas, Recuperabilidad, Predictibilidad, Exactitud, y Tiempo medio entre fallas

(MTBF).


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+


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+


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+


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+


requisitos físicos – especifica requisitos de hardware (redes)

Formas Tamaños Pesos Material

requisitos FURPS+


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.


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.


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.



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.



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.



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.



Las asociaciones con punta de flecha pueden usarse para denotar quien inicia la interacción, éstas eran usadas en versiones anteriores de UML.


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.


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).


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.


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.


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.


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.


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


Modelando Casos de Uso


Modelando Casos de Uso

Revise que necesidades o requisitos del usuario son Soportados por que casos de uso.

requisitos y cu

Documents