Instituto Universitario Experimental de Tecnologa La Victoria Programa Nacional de Formacin en Informtica Unidad Curricular: Ingeniera del Software II Mdulo:

Fundamentos de Ingeniera de Requisitos y Anlisis

Casos de Uso

PROCESO DE DESARROLLO DE SOFTWARE

Define quin est haciendo qu, cundo y cmo para alcanzar un determinado objetivo

Transforma

Aplicando

Se Genera

Requisitos del Usuario

Sistema Informtico
2

PROCESO DE DESARROLLO DE SOFTWARE

PROCESO DE DESARROLLO DE SOFTWARE

PROCESO DE DESARROLLO DE SOFTWARE

Un proceso de desarrollo debe especificar:

La secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividades

Productos que deben crearse: qu y cundo Asignacin de tareas a cada miembro del equipo y al equipo como un todo Proporcionar criterios para controlar el proceso

PROCESO DE DESARROLLO DE SOFTWARE - UML

Ivar Jacobson Grady Booch

James Rumbaugh

EL LENGUAJE UNIFICADO DE MODELADO

Puede ser un seudocdigo, cdigo, imgenes, diagramas o largos paquetes de descripcin; es decir, cualquier cosa que ayude a describir un sistema Lenguaje de = Notacin + Metamodelo Modelado

Forma de expresar el modelo

Descripcin de lo que significa esa modelacin

7

EL LENGUAJE UNIFICADO DE MODELADO

Caractersticas: Basado en las experiencias personales de los autores Incorpora contribuciones de otras metodologas Ofrece un estndar para describir un plano del sistema Incluye aspectos conceptuales y aspectos concretos
Procesos de negocio y Funciones del sistema Espresiones de Lenguajes de Programacin, Esquemas de BD y Componentes de Software Reutilizables
8

EL LENGUAJE UNIFICADO DE MODELADO

El UML es una gua al desarrollador para realizar el anlisis y diseo orientado a objetos, es un proceso.

El UML es un lenguaje que permite la modelacin de sistemas con tecnologa orientada a objetos

Aprobado como estndar por OMG (Object Management Group) en noviembre de 1997
9

PREMISAS DE UML
SEGN BOOCH, JACOBSON Y RUMBAUGH:
Modelar sistemas, a partir de los conceptos hacia los artefactos ejecutables, utilizando tcnicas orientadas a objeto. Enfocarnos en las cuestiones de escala inherentes a sistemas complejos, crticos en su misin. Crear un lenguaje de modelacin utilizable tanto por los humanos, como por las mquinas.
10

VENTAJAS DEL UML

Es un lenguaje formal, ya que cada elemento del lenguaje tiene un significado fuerte que ayuda a modelar un aspecto particular del sistema Es conciso con una notacin simple y comprensible porque describe todos los aspecto importante del sistema Es escalable por lo que permite describir proyectos de diferentes tamaos Es un estndar abierto Da soporte a todo el ciclo de vida de desarrollo del software Da soporte a diversas reas de aplicacin
11

LIMITACIONES DEL UML

Carece de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva en ocasiones. No se presta con facilidad al diseo de sistemas distribuidos. En estos sistemas son importantes factores como transmisin, serializacin, persistencia, etc. No se puede sealar si un objeto es persistente o remoto.

12

UML: PRODUCTOS
Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto de software desde cada una de las perspectivas de inters

13

UML: PRODUCTOS
Un producto de software es el cdigo mquina y los ejecutables de un sistema
Un producto de software es el conjunto de artefactos que se necesitan para representarlo en forma comprensible para: Las mquinas Los trabajadores Los usuarios Los interesados
14

UML: ARTEFACTOS
Trmino general aplicable a cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema
Ejemplos: Diagramas UML y su texto Bocetos de interfaz Planes de prueba Prototipos
Casos de Uso

Entre otros
15

UML: MODELOS - DIAGRAMAS

Un Modelo, captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle.
Un Diagrama, es la representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos.

16

Casos de uso

Diagrama de casos de uso

17

CASOS DE USO
Casos de Uso, es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitos
Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno Segn Ivar Jacobson, describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario
18

CASOS DE USO
Son descripciones de la funcionalidad del negocio/ sistema independientes de la implementacin

Cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos Particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo
Estn basado en el lenguaje natural, es decir, es accesible por los usuarios
19

CASOS DE USO
Un Caso de Uso es una funcin (servicio o transaccin) atmica ofrecida por el sistema al entorno (actores) Un proceso de un Diagrama de Flujo de Datos puede ser detallado en un DFD hijo. As, el concepto de explosin de proceso slo se aplica a los DFDs

CASOS DE USO VS DFD

20

CASOS DE USO

Para construir un sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean.

21

CASOS DE USO
La captura de los requisitos tiene 2 objetivos: Encontrar los verdaderos requisitos Representarlos de un modo adecuado para los usuarios, clientes y desarrolladores
Cuando se implementen aadirn el valor esperado para los usuarios

Su descripcin debe ser comprensible

22

CASOS DE USO PROCESO DE ING. DE REQUISITOS

Anlisis Tareas Elaboracin Negociacin Levantamiento y Recoleccin Tareas Inicio Obtencin

Especificacin SRS

Validacin

Proceso de Ing. de Requisitos

23

CASOS DE USO PROCESO DE ING. DE REQUISITOS

1. Levantamiento y Recoleccin: (Pasos) a) Identificacin de los interesados. Todos aquellos que se benefician en una forma directa o indirecta del sistema que est en desarrollo. b) Reconocimiento de mltiples puntos de vista clientes diferentes implican diversos puntos de vistas. c) Trabajo con respecto a la colaboracin. La colaboracin no significa, necesariamente que los requisitos se definan por consenso. Los interesados colaboran al proporcionar su visin de los requisitos. d) Formulacin de las primeras preguntas. Las preguntas formuladas deben ser libres de contexto
24

CASOS DE USO PROCESO DE ING. DE REQUISITOS

El primer conjunto de preguntas libres de contexto se enfoca en el cliente y otros interesados , metas generales y en los beneficios.. Por ejemplo, el ingeniero de requisitos podra preguntar:

Quin est detrs de la solucin de este trabajo?

Quin usar la solucin? Cul ser el beneficio econmico de una solucin exitosa? Existe otra fuente para solucin requerida?
25

CASOS DE USO PROCESO DE ING. DE REQUISITOS

Estas preguntas ayudan a identificar a todos los participantes que tendran inters en el software que ser construido. Adems, identifican el beneficio medible de una implementacin exitosa.

La siguiente serie de preguntas permite que el equipo de software comprenda mejor el problema y deja que el cliente exprese sus percepciones acerca de una solucin:

26

CASOS DE USO PROCESO DE ING. DE REQUISITOS

Cmo podra caracterizarse un buen resultado generado por una solucin exitosa? Cules problemas debera atacar esta solucin?

Podra usted describir o mostrar el ambiente de negocios en el que se utilizar la solucin?

Los aspectos especiales del desempeo o las restricciones afectarn la forma en que se busque la solucin?

27

CASOS DE USO: ARTEFACTOS

Casos de Uso

Son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores.
Descripcin de un conjunto de secuencia de acciones, incluyendo variaciones, que un sistema lleva a cabo y que conduce a un resultado observable de inters para un determinado actor
28

CASOS DE USO: ARTEFACTOS

Casos de Uso

Alistairn Cockburn:
un caso de uso captura un contrato que describe el comportamiento del sistema en diferentes condiciones mientras ste responde a la peticin de uno de sus usuarios En esencia:

Un caso de uso cuenta una historia estilizada de la manera en que un usuario final interacta con el sistema en un conjunto especfico de circunstancias
29

CASOS DE USO: ARTEFACTOS

Actores

Se refiere no slo a humanos sino tambin a otros sistemas; por lo que representa a alguien o algo (como otro sistema fuera del sistema en consideracin), que interacta con el sistema que se est desarrollando.
Pueden ser internos o externos al sistema.

Conjunto coherente de roles que los usuarios de casos de uso desempean cuando interactan con dichos casos de uso

Actores

30

CASOS DE USO
Diagrama de Casos de Uso

Muestra un conjunto de casos de uso, actores y sus relaciones

Los diagramas de casos de uso muestran la descripcin del sistema desde un punto de vista esttico.

Clientes

31

CASOS DE USO
Modelo de Casos de Uso

Permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos (sobre las condiciones y posibilidades que debe cumplir el sistema).
Modelo del sistema que contiene actores, casos de uso y sus relaciones; describiendo lo que hace el sistema para cada tipo de usuario.

Clientes

Usuarios 32

CASOS DE USO
Los sistemas normalmente tienen muchos tipos de usuarios y cada tipo de usuario se representa por un actor
Usuarios Clientes Usuarios Clientes

Los actores utilizan el sistema interactuando con los casos de uso

Usuarios Clientes Desarrolladores
33

CASOS DE USO
Un caso de uso es una secuencia de acciones que el sistema lleva a cabo para ofrecer algn resultado de valor para un actor

Clientes

Clientes

El Modelo de casos de uso est compuesto por todos los actores y todos los casos de uso de un sistema.

Usuarios

Desarrolladores
34

CASOS DE USO

Puede decirse que una especificacin funcional contesta a la pregunta: Qu debe hacer el sistema? La estrategia de los casos de uso puede describirse aadiendo tres palabras al final de esta pregunta: para cada usuario? Por lo que la pregunta clave sera: Qu debe hacer el sistema para cada usuario?

35

CASOS DE USO: RELACIONES

Relacin de Comunicacin
Clientes

Relacin de inclusin
Clientes

<<include>>

Relacin de extensin
Clientes

<<extend>>

Relacin de Generalizacin-especializacin

Clientes
36

CASOS DE USO: RELACIN DE COMUNICACIN

Este elemento representa la relacin que existe entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una lnea
Clientes

recta que se extiende de la figura del actor hacia el ovalo

del uso-caso.

37

CASOS DE USO: RELACIN DE INCLUSIN

Relacin que especifica un <<include>> comportamiento definido para el Caso de Uso de Clientes inclusin que se inserta explcitamente dentro del comportamieto definido para el Caso de Uso base.

El flujo de trabajo del proceso entero est en el caso de uso base y el (los) caso(s) de uso incluido(s).
Se justifica cuando: Se puede reusar en otros Casos de Uso el comportamiento incluido en el caso de uso base, o Simplifica la comprensin del caso de uso base.
38

CASOS DE USO: RELACIN DE INCLUSIN

Reutilizar
Pasajero
Chequear Individual <<include>>

Gua de Turismo

Chequear en Grupo

Manipular Equipaje <<include>>

Particionar
Cliente
Vender Producto <<include>> Verificar poltica de descuento
39

CASOS DE USO: RELACIN DE EXTENSIN

Una vez definido el flujo de trabajo de un caso de uso, se puede encontrar alguna conducta opcional u optativa.
<<extend>>

Clientes

Tiene sentido definir un nuevo Caso de Uso cuando: Modelar un flujo de trabajo complejo o un subflujo separado, que raramente ocurre u ocurre bajo ciertas condiciones. Flujos distintos que pueden ejecutarse en base a la seleccin del actor.
40

CASOS DE USO: RELACIN DE EXTENSIN

SOLO PARA ALGUNOS PASAJEROS HAY QUE IR AL COUNTER DE EQUIPAJE ESPECIAL

Pasajero

Chequear Individual

<<extend>>

Manejo especial de Equipaje

41

CASOS DE USO: RELACIN DE GENERALIZACIN

Se usa para mostrar flujos de trabajo que comparten estructuras, propsito y comportamiento.

Clientes

Un caso de uso padre se puede especificar en uno o ms casos de uso hijos que representan formularios ms especficos del padre. Se utiliza para:

Para no tener que describir el mismo flujo varias veces, se puede colocar el comportamiento comn en un Caso de Uso.
42

CASOS DE USO: RELACIN DE GENERALIZACIN

Se puede afirmar que constituyen tipos de procesos. Generalmente tienen un comportamiento similar pero con diferencias sustanciales que provocan que sean considerados Casos de Uso diferentes.

Realizar visitas

Jefe Zonal
Realizar visitas a clientes potenciales Realizar visitas a clientes registrados
43

CASOS DE USO: RELACIN DE GENERALIZACIN

Varios actores del negocio pueden jugar el mismo rol en un caso de uso particular del negocio.

El rol compartido se modela como el actor del cual heredan los actores con roles compartidos (slo se representan si interactan como actor con otro Caso de Uso)
44

CASOS DE USO: LMITE DE SISTEMA

(System Boundry) Empleado para delimitar los lmites del sistema, y representado por un rectngulo con color de fondo

distintivo.

Usuarios

Usuarios
45

VISIN DE LA CAPTURA DE REQUISITOS

Trabajo a Realizar
Enumerar requisitos candidatos
Comprender el contexto del sistema Capturar los requisitos funcionales Capturar los no requisitos funcionales

Artefacto Resultante
Lista de Caractersticas
Modelo del Dominio o del Negocio Modelo de Casos de Uso Requisitos Adicionales o Casos de Uso Concretos Definen la Especificacin De Requisitos

46

VISIN DE LA CAPTURA DE REQUISITOS

Capturar Requisitos funcionales y no funcionales

Identificar Actores y Casos de Uso para: Delimitar el sistema de su entorno Esbozar quin y qu (actores) interactan con el sistema, y qu funcionalidad (casos de uso) se espera del sistema Capturar y definir un Glosario de trminos comunes esenciales para la creacin de descripciones detalladas de las funcionalidades del sistema, es decir, de los casos de uso
47

VISIN DE LA CAPTURA DE REQUISITOS

Identificar Actores y Casos de Uso

Encontrar los Actores Encontrar los Casos de Uso

Describir brevemente cada caso de uso

Describir el Modelo de Casos de Uso completo (incluye la preparacin del Glosario de trminos)

48

CMO SE REPRESENTA UNA HISTORIA?

Puede ser:

Un texto narrativo
Un esquema de tareas e interacciones Una descripcin basada en una plantilla Una representacin a travs de diagramas Sin importar su forma:

Un caso de uso muestra el software o sistema desde el punto de vista de usuario final.
49

PASOS PARA ESCRIBIR UN CASO DE USO

1. Definir el conjunto de actores involucrados Un actor: Es algn elemento que se comunica con el sistema o producto Es externo al sistema en s mismo Tiene una o mas metas cuando utiliza el sistema No es necesariamente un usuario final Un usuario puede desempear varios papeles al usar un sistema mientras que un actor representa una clase de entidad externa que desempea solo un papel en el contexto del caso de uso.
50

PASOS PARA ESCRIBIR UN CASO DE USO

1. Definir el conjunto de actores involucrados Un actor: No siempre se identifica durante la primera iteracin. Aquellos que se identifican en este punto se llaman actores primarios mientras que los actores secundarios se identifican conforme se aprende ms acerca del sistema. Primario: interacta para lograr la funcin requerida del sistema y obtiene el beneficio que se espera de ste. Secundario: da soporte al sistema de manera que los actores primarios puedan hacer su trabajo.
51

PASOS PARA ESCRIBIR UN CASO DE USO

2. Desarrollar los casos de uso Jacobson sugiere varias preguntas: Quin (es) es (son) el (los) actor (es) primario (s)? Cules son las metas del actor? Cules son las condiciones previas que deben existir antes de comenzar la historia? Cules son las tareas o funciones principales que realiza el actor? Cules excepciones podran considerarse mientras se describe la historia? Cules son las variaciones posibles en la interaccin del actor?
52

PASOS PARA ESCRIBIR UN CASO DE USO

2. Desarrollar los casos de uso Jacobson sugiere varias preguntas: Cul es la informacin del sistema que el actor adquirir, producir o cambiar?

El actor tendr que informar al sistema acerca de cambios en el medio ambiente externo?
Cul es la informacin que el actor desea del sistema? El actor quiere ser informado acerca de cambios inesperados?
53

EJEMPLO: HOGAR SEGURO

La mayora de las personas est familiarizada con los sistemas de alarma, por lo que sera pertinente y aceptable sacar al mercado una funcin de seguridad en el hogar para estos sistemas. La funcin de seguridad en el hogar protegera contra o reconocera una variedad de situaciones indeseables como una entrada ilegal, fuego, inundaciones, niveles de monxido de carbono y otras. Utilizar los sensores inalmbricos para detectar cada situacin, el usuario podr programarla y llamar por telfono automticamente a una oficina de monitoreo cuando detecte alguna situacin.
54

EJEMPLO: HOGAR SEGURO

El equipo de recopilacin de requisitos lo componen representantes de los departamentos de: Mercadotecnia Ingeniera de software y hardware

Manufactura
Cada una de estas personas desarrollan listas de requisitos

Luego se crea una lista combinada y condensada, a partir de los requisitos presentados (objetos, servicios, restricciones y propiedades)
55

EJEMPLO: HOGAR SEGURO

Una vez completadas las listas condensadas, el equipo se subdivide en sub-equipos menores; cada uno deber trabajar para desarrollar miniespecificaciones y presentarlas al resto Se realizan adiciones, anulaciones y elaboraciones posteriores. En algunos casos se descubrirn nuevos requisitos de objetos, servicios, restricciones y propiedades

Se hace una lista de criterios de validacin para el producto sistema

Se escriben las especificaciones completas mediante el uso de todos los asuntos tratados
56

EJEMPLO: HOGAR SEGURO

Los objetos descritos para Hogar Seguro podran incluir:

El panel de control Detectores de humo Sensores en puertas y ventanas Detectores de movimiento Una alarma Un evento (cuando algn sensor se active) Una plantilla Una PC Nmeros telefnicos, una llamada telefnica y otros
57

EJEMPLO: HOGAR SEGURO

La lista de servicios para Hogar Seguro podran incluir:

Configuracin del sistema

Colocacin de la alarma Monitoreo de los sensores Marcacin telefnica Programacin del panel de control Lectura de pantalla Observe que los servicios actan sobre los objetos
58

EJEMPLO: HOGAR SEGURO

Algunas restricciones para Hogar Seguro: El sistema debe reconocer cuando los sensores no estn en funcionamiento Debe ser usable para el usuario (interfaz directa con la lnea telefnica) Criterios de rendimiento (Ej., el evento de un sensor debe ser reconocido en un segundo o menos; se debe implementar un esquema para la prioridad de los eventos)

59

EJEMPLO: HOGAR SEGURO

Los requisitos bsicos de Hogar Seguro definen cuatro actores: El propietario de la casa (usuario) Administrador de la configuracin (probablemente la misma persona que el propietario, pero en una funcin diferente) Los sensores (dispositivos agregados al sistema) Subsistema de monitoreo (la estacin central que monitorea la funcin de seguridad en el hogar donde est instalado Hogar seguro)
60

EJEMPLO: HOGAR SEGURO

Para el ejemplo, consideremos el actor propietario, quien interacta con la funcin seguridad en el hogar en diferentes formas mediante el uso del panel de control de la alarma o una PC: Ingresa una contrasea para permitir todas las dems interacciones Indaga acerca del status de una zona de seguridad Indaga acerca del status de un sensor

Presiona el botn de pnico en caso de emergencia

Activa desactiva el sistema de seguridad
61

EJEMPLO: HOGAR SEGURO

Considerndose la situacin en la cual el propietario utiliza el panel de control, el caso de uso bsico para la activacin del sistema de presenta de la siguiente manera: HogarSeguro
apagado salida en casa

2
prueba

3
desviacin

01
alarma verificar fuego

salida en casa instante desviacin no listo

max

4
instante

5
cdigo

6
repicar

7
listo

8 0
pnico

9 #

activado encendido

62

EJEMPLO: HOGAR SEGURO

El propietario observa el panel de control para determinar si el sistema est listo para entrar.

Si el sistema no est listo se despliega un mensaje de no listo sobre la pantalla LCD, y el propietario debe cerrar en forma fsica puertas y ventanas para que el mensaje desaparezca.
El propietario utiliza una contrasea de cuatro dgitos. La contrasea se compara con la clave almacenada en el sistema. Si la contrasea es incorrecta, el panel de control esperar la siguiente accin.

63

EJEMPLO: HOGAR SEGURO

El propietario selecciona e introduce en casa o salida para activar el sistema. En casa activa slo los sensores del permetro (los sensores para la deteccin de movimiento interno se desactivan). Salida activa todos los sensores. Cuando se realiza la activacin, el propietario puede observar una luz roja de alarma.

64

EJEMPLO: HOGAR SEGURO

Plantilla para las descripciones detalladas de los casos de uso, segn Cockburn
Caso de Uso: Actor primario:
Meta en el contexto:

Inicio de monitoreo Propietario de la casa

Establecer el sistema para monitorear los sensores cuando el propietario salga de la casa o permanezca dentro de ella. El sistema ha sido programado para una contrasea y para reconocer diferentes sensores. El propietario decide iniciar el sistema, es decir, encender las funciones de la alarma.

Condiciones previas:

Activador:

65

EJEMPLO: HOGAR SEGURO

Escenarios: 1. 2. 3. 4. Propietario: observa el panel de control Propietario: introduce la contrasea Propietario: selecciona en casa o salida Propietario: observa la luz roja de alarma para indicar que Hogar Seguro est en operacin El panel de control no est listo: el propietario verifica todos los sensores para determinar cules estn abiertos La contrasea es incorrecta (el panel de control emite un sonido): el propietario introduce de nuevo la contrasea correcta La contrasea no es reconocida: debe contactarse el subsistema de monitoreo y respuesta para reprogramar la contrasea
66

Excepciones: 1.

2.

3.

EJEMPLO: HOGAR SEGURO

Excepciones: 4. Se selecciona en casa: el panel de control emite un sonido doble y se enciende la luz de en casa; se activan los sensores del permetro. Se selecciona salida: el panel de control emite un sonido triple y se enciende la luz de salida, se activan todos los sensores.

5.

67

EJEMPLO: HOGAR SEGURO

Activar/Desactivar Sistema

Propietario de la casa

Entrar en el sistema por internet

Responder al evento de alarma Encontrar una condicin de error

Sensores

Administrador del Sistema

Reconfigurar los sensores y las caractersticas del sistema relacionadas

68

REQUISITOS ADICIONALES
Son requerimientos No funcionales que no pueden asociarse a ningn caso de uso en particular.

Algunos ejemplos son: el rendimiento, las interfaces, y los requisitos de diseo fsico, as como las restricciones arquitectnicas. Los requisitos adicionales se capturan de forma muy parecida a como se haca en la especificacin de requisitos tradicional, es decir con una lista de requisitos. Luego se utilizan durante el anlisis junto al modelo de casos de uso.
69

TIPOS DE RELACIONES (RESUMEN)

Comunicacin
Actor <<include>> Caso de Uso

Inclusin
Caso de Uso Origen <<extend>> Caso de Uso Destino

Extensin
Caso de Uso Origen Caso de Uso Destino

Generalizacin
Caso de Uso Hijo Caso de Uso Padre 70

ERROR COMN EN LOS CASOS DE USO

Representar pasos como Caso de Uso
Ej.

Imprimir Recibo
Es un paso del proceso ms amplio Comprar Productos

Los casos de uso describen los procesos de principio a fin.

Se Nombran: Utilizando verbos fuertes en infinitivo

71

ERROR COMN EN LOS CASOS DE USO

Describir de manera insuficiente el caso de uso en aras de ganar tiempo

72

73

REQUISITOS - UML

74

REQUISITOS
Objetivos de la reutilizacin de requisitos:

Reducir el coste de desarrollo

Reducir el time to market Mejorar la calidad de los requisitos

Mejorar la productividad del equipo de Requisitos

Las estrategias sencillas de reutilizacin son eficaces y bien aceptadas por los usuarios y analistas.

Es necesario disponer de herramientas de soporte.

75