Está en la página 1de 24

Anlisis Orientado a Objetos

El anlisis consiste en producir un documento de especificaciones de requisitos que


describa lo que el futuro debe hacer, pero no como debe hacerlo. Por ello algunos autores lo
llaman determinacin de requisitos.
Qu es anlisis de Requisito?
El anlisis de requisitos permite al ingeniero de sistemas especificar las caractersticas
operacionales del software (funcin, datos y rendimientos), indica la interface del software
con otros elementos del sistema y establece las restricciones que debe cumplir el software.
Puede dividirse en 5 reas de esfuerzo:
Reconocimiento del problema.
Evaluacin y sntesis.
Modelado.
Especificacin.
Revisin.

Principios del anlisis?
Todos los mtodos de anlisis se relacionan por un conjunto de principios operativos:

1. Debe representarse y entenderse el dominio de informacin de un problema.

2. Debe definirse las funciones que debe realizar el software.

3. Debe representarse el comportamiento del software.

4. Debe dividirse los modelos que representan informacin, funcin y comportamiento de
manera que se descubran los detalles por capas.

5. El proceso de anlisis deriva ir desde la informacin esencial hasta el detalle de la
implementacin.

Anlisis de Viabilidad
El anlisis de la viabilidad es el estudio que dispone el xito o fracaso de un proyecto a
partir de una serie de datos base de naturaleza emca: medio ambiente del proyecto,
rentabilidad, necesidades de mercado, factibilidad poltica, aceptacin cultural, legislacin
aplicable, medio fsico, flujo de caja de la operacin, haciendo un nfasis en viabilidad
financiera y de mercado. Es por lo tanto un estudio dirigido a realizar una proyeccin del
xito o fracaso de un proyecto.
Tipos de viabilidad?
El estudio de viabilidad evala criterios: operacional, tcnico, econmico, del proyecto
propuesto.
Hay 3 tipos de viabilidad:
Tcnica: Esta evala, si los recursos tcnicos actuales son suficientes para el nuevo sistema
Econmica: determina si el tiempo y el dinero estn disponibles para desarrollar el sistema.
Incluye la compra de: equipo nuevo, hardware, software.
Operacional: Determina los recursos humanos que estn disponibles para operar el sistema
una vez que este sea instalado.
REQUERIMIENTOS
En la ingeniera de sistemas, un requisito es una necesidad documentada sobre el contenido,
forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la
ingeniera de sistemas, ingeniera de software e ingeniera de requisitos.
En la ingeniera clsica, los requisitos se utilizan como datos de entrada en la etapa de
diseo del producto. Establecen qu debe hacer el sistema, pero no cmo hacerlo.
TIPOS
En ingeniera de sistemas existen tres tipos de requisitos.
Un requisito funcional puede ser una descripcin de lo que un sistema debe hacer.
Este tipo de requisito especfica algo que el sistema entregado debe ser capaz de
realizar.
Un requisito no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el
propio sistema, y cmo debe realizar sus funciones. Algunos ejemplos de aspectos
solicitarles son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso,
etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto.
Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la
adecuacin a leyes o regulaciones aplicables al producto
Una coleccin de requisitos describe las caractersticas o atributos del sistema deseado. Se
omite el cmo debe lograrse su implementacin, ya que esto debe ser decidido en la etapa
de diseo por los diseadores.
En la ingeniera de software se aplica el mismo significado, slo que el nfasis est puesto
en el propio software.
Pseudorrequisitos: Son aquellos referidos al entorno donde sera instalado o implementado
el sistema, que determinan en gran medida su desarrollo, pueden ser cuestiones como
hardware y software.
INGENIERA DE REQUERIMIENTOS
En la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o
Ingeniera de requerimientos
1
comprende todas las tareas relacionadas con la determinacin
de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado,
tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en
conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala
traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras
que requerimiento se traduce al ingls como request.
El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado
ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser
medibles, comprobables, sin ambigedades o contradicciones, etc.
Requerimientos orientados a objetos

La captura de requisitos es el proceso de averiguar, normalmente en circunstancias
difciles, lo que se debe construir
La captura de requisitos es complicada
Los usuarios habitualmente no saben expresar exactamente lo que quieren
Es difcil tener una visin global del problema a resolver
La especificacin de requisitos es un documento ms tcnico y elaborado de los
documentos de anlisis
Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de
desarrollo de software
Se puede utilizar una especificacin jerrquica
Estn todos codificados por niveles, al igual que las leyes.
Se desea que en las actas quede reflejado lo ms exactamente posible el problema a
resolver, y que en las reuniones de anlisis se determine exactamente qu requisitos se
aaden o se eliminan
Los requisitos relacionados se organizan dentro de un mismo nivel
Cada nivel 1 se puede hacer corresponder posteriormente con un caso de uso
Cada nivel 2 se puede hacer corresponder posteriormente con un escenario
Cada nivel 3 se puede hacer corresponder posteriormente con un sub-escenario
Ejemplos de requisitos
R.0
Requisitos generales
R.0.1Tendremos en cuenta trabajar con fechas que codifiquen el ao con cuatro cifras.
R.0.2Las unidades monetarias debern poder trabajar con cifras decimales con vistas al
inmediato cambio de moneda que se nos aproxima.
R.1Gestin de clientes
R.1.0Requisitos generales de los clientes
R.1.0.1Los clientes pueden ser fijos o eventuales
R.1.0.2A los clientes se les asignan un nmero identificativo
R.1.0.3Los clientes se definen por D.N.I., nombre, direccin, ciudad, telfono, y
departamento.
R.1.1Aadir clientes
R.1.1.1Solamente los Usuarios con permiso de Administrador podrn aadir clientes fijos.
R.1.2Borrado de clientes.
R.1.2.1Solamente los Usuarios con permiso de Administrador podrn borrar clientes.
R.1.2.2Para poder borrar clientes es necesario que este no tenga ningn albarn pendiente
de facturacin y que estos tengan una antigedad mayor a cinco aos.
R.1.2.3Tambin es necesario que no tenga ninguna mquina reparndose
R.1.3Modificar clientes.
R.1.3.1Solo los usuarios con permiso de Administrador pueden modificar los datos de un
cliente.
R.1.4Buscar clientes.
R.1.5Paso de cliente fijo a cliente eventual y viceversa.
R.1.5.1Solo los usuarios con permiso de Administrador pueden hacer clientes fijos.

REQUERIMIENTOS FUNCIONALES
Un requisito funcional define una funcin del sistema de software o sus componentes. Una
funcin es descrita como un conjunto de entradas, comportamientos y salidas. Los
requerimientos funcionales pueden ser: clculos, detalles tcnicos, manipulacin de datos y
otras funcionalidades especficas que se supone, un sistema debe cumplir. Los
requerimientos de comportamiento para cada requerimiento funcional se muestran en los
casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en
cambio en el diseo o la implementacin.
Como se define en la ingeniera de requisitos, los requisitos funcionales establecen los
comportamientos del sistema.
Tpicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los
casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software
es un proceso iterativo y algunos requisitos son previos al diseo de los casos de uso.
Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.
Un requisito funcional tpico contiene un nombre y un nmero de serie nico y un resumen.
Esta informacin se utiliza para ayudar al lector a entender por qu el requisito es
necesario, y para seguir al mismo durante el desarrollo del producto.
El ncleo del requisito es la descripcin del comportamiento requerido, que debe ser clara y
concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o
ser descubiertas por interaccin con usuarios, inversores y otros expertos en la
organizacin.

REQUERIMIENTOS NO FUNCIONALES
Un requisito no funcional o atributo de calidad es, en la ingeniera de sistemas y la
ingeniera de software, un requisito que especifica criterios que pueden usarse para juzgar
la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos
corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que
no describen informacin a guardar, ni funciones a realizar.
Algunos ejemplos de requisitos no funcionales tpicos son los siguientes:
rendimiento
disponibilidad
seguridad
accesibilidad
usabilidad
estabilidad
portabilidad
costo
operatividad
interoperabilidad
escalabilidad
concurrencia
mantenibilidad
interfaz
REQUERIMIENTOS DE SISTEMAS
Los Sistemas de Informacin por computadora normalmente estn integrados por muchos
componentes. En la mayor parte de los casos, es difcil para los analistas entender todos
estos componentes an mismo tiempo; por lo tanto los investigadores tienen que comenzar
con preguntas de tipo general con relacin al propsito del sistema sus entradas y salidas de
los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una investigacin en
forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda
trabajar en forma independiente.
Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de
informacin. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de
Informacin.

REQUERIMIENTOS DE USUARIO
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el
sistema provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean
comprensibles por los usuarios del sistema que no posean un conocimiento tcnico
detallado. nicamente especifican el comportamiento externo del sistema y evitan, tanto
como sea posible, las caractersticas de diseo del sistema. Por consiguiente, los
requerimientos del usuario no se deben definir utilizando un modelo de implementacin.
Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos
sencillos.
Sin embargo, pueden surgir diversos problemas cuando se redactan en lenguaje natural:
falta de claridad, confusin de requerimientos y conjuncin de requerimientos.
REQUERIMIENTOS DE INTERFAZ
Los requerimientos de interfaz son todos aquellos elementos que debe proveer el sistema
para permitir la interaccin entre el usuario y las funcionalidades que este tiene, con el fin
de que en el proceso de diseo se tenga claridad de las interfaces que se deben crear y la
relacin que debe existir entre ellas.
Para la definicin de los requerimientos de interfaz se deben identificar los siguientes
elementos:
Id: Identifica de manera nica una interfaz grfica
Descripcin: Indica los elementos que debe tener la interfaz.
Requerimientos asociados: Indican las funcionalidades asociadas a la interfaz grfica.
En este nivel, no se va definir de manera detallada la interfaz, solo se pretende tener una
primera aproximacin a los elementos que deben ser tenidos en cuenta en el desarrollo de
estas.

ANALISIS DE REQUERIMIENTOS
Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y
detallados, y adems contienen mltiples relaciones entre s. Lo que nos da a concluir, de
acuerdo a lo expuesto anteriormente, que el conjunto de requerimientos de un sistema
computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones
simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y
organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus
requerimientos.
El anlisis de requerimientos consiste brevemente en los siguientes pasos:
Obtener informacin acerca de lo que los usuarios desean
Clasificar esos deseos para comenzar a estructurar requerimientos
Identificar los niveles de jerarqua del sistema y empezar a alojar los ya clasificados
requerimientos en cada nivel.
Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.
Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de
software, este entendimiento es necesario para poder construir software que satisfaga las
necesidades de nuestro cliente.
Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lgico
que para recabarlos haya que obtener la informacin de primera mano.
Esto es, mediante entrevistas con el cliente o recabando documentacin que describa la
manera que el cliente desea que funcione el sistema de software.

NEGOCIACION DE REQUERIMIENTOS
La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una
evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino
"adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en
cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados
completos, correctos y sin ambigedades.
En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando
como referencia los niveles de abstraccin y descomposicin de cada problema presentado.
Los principales pasos de esta actividad son:
Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas de
los requerimientos estn presentes en cada uno de los ellos, es decir, se identifican aquellos
requerimientos ambiguos, incompletos, inconsistentes, etc.


ESPECIFICACION DE REQUERIMIENTOS

La especificacin de requisitos de software (ERS) es una descripcin completa del
comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso
que describe todas las interacciones que tendrn los usuarios con el software. Los casos de
uso tambin son conocidos como requisitos funcionales. Adems de los casos de uso, la
ERS tambin contiene requisitos no funcionales (o complementarios). Los requisitos no
funcionales son requisitos que imponen restricciones en el diseo o la implementacin,
como, por ejemplo, restricciones en el diseo o estndares de calidad.
Est dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su
redaccin debe ser informal, de forma que sea fcilmente comprensible para todas las
partes involucradas en el desarrollo.


ESPECIFICACION DE ENTRADA
Las especificaciones de entrada describen la manera en que los datos ingresarn al sistema
para su procesamiento. Las caractersticas de diseo de la entrada pueden asegurar la
confiabilidad del sistema y producir resultados a partir de datos exactos, o tambin pueden
dar como resultado la produccin de informacin errnea. Asimismo, el diseo de la
entrada determina s el usuario puede interactuar con el sistema de manera eficiente. El
diseo de la entrada es el enlace que une al sistema de informacin con el mundo y sus
usuarios. Algunos aspectos del diseo cambian, lo que depende si el sistema est orientado
hacia lotes o en lnea. Pero sin considerar el sistema, existen aspectos generales en la
entrada que todos los analistas deben tener en cuenta.

El diseo de la entrada consiste en el desarrollo de especificaciones y procedimientos para
la preparacin de datos, la realizacin de los pasos necesarios para poner los datos de una
transaccin en una forma utilizable para su procesamiento, as como la entrada de stos. La
entrada de estos los datos se logra al instruir la computadora para que los lea ya sea de
documentos escritos o impresos, o por personas que los escriben directamente en el
sistema.

ESPECIFICACION DE PROCESO
Los procedimientos especifican qu tareas deben efectuarse al utilizar en sistema y quines
son los responsables de llevarlas a cabo. Entre los procedimientos importantes se
encuentran:
Procedimientos para entrada de datos. Mtodos para la captura de datos de las
transacciones y su ingreso en el sistema de informacin.
Procedimientos durante la ejecucin. Pasos y acciones emprendidos por los
operadores del sistema y, en ciertos casos, por los usuarios finales que interactan
con el sistema para alcanzar los resultados deseados.
Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan
resultados inesperados.
Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus
recursos contra posibles daos.
ESPECIFICACION DE SALIDA
El trmino salida, como es probable que el lector lo conozca, se refiere a los resultados e
informacin generados por el sistema. Para muchos usuarios finales, la salida es la nica
razn para el desarrollo del sistema y la base sobre la que ellos evaluarn la utilidad de la
aplicacin. En la realidad, muchos usuarios no operan el sistema de informacin y tampoco
ingresas datos en l, pero utilizan la salida generada por el sistema. Cuando disean la
salida, los analistas deben de realizar lo siguiente:
Determinar qu informacin presentar.
Decidir si la informacin ser presentada en forma visual, verbal o impresa y
seleccionar el medio de salida.
Disponer la presentacin de la informacin en un formato aceptable.
Decidir cmo distribuir la salida entre los posibles destinatarios.
Para llevar a cabo las actividades antes mencionadas, se requieren decisiones especficas
tales como el empleo de formatos ya impresos cuando se preparan reportes, cuntas lneas
planear sobre una pgina impresa o si se debe emplear grficas y colores.

La salida es la nica razn para el desarrollo del sistema y la base sobre la que ellos
evaluarn la utilidad de la aplicacin. En la realidad, muchos usuarios no operan el sistema
de informacin y tampoco ingresan datos en l, pero utilizan la salida generada por el
sistema.

ESPECIFICACIONES DE SISTEMA
El objetivo principal de la Especificacin de Requisitos del Sistema (ERS) es servir como
medio de comunicacin entre clientes, usuarios, ingenieros de requisitos y desarrolladores.
En la ERS deben recogerse tanto las necesidades de clientes y usuarios (necesidades del
negocio, tambin conocidas como requisitos de usuario, requisitos de cliente, necesidades
de usuario, etc.) como los requisitos que debe cumplir el sistema software a desarrollar para
satisfacer dichas necesidades (requisitos del producto, tambin conocidos como requisitos
de sistema o requisitos software).
La ERS debe ser un documento consensuado entre todas las partes y tener un carcter
contractual, de forma que cualquier cambio que se desee realizar en l una vez acordada la
primera lnea base deba aplicarse siguiendo el Procedimiento de Control de Cambios
establecido en el proyecto.

ESPECIFICACIONES DE INTERFAZ
El desarrollo de interfaces de usuario es una tarea que consume grandes cantidades de
recursos. Por otro lado, las tcnicas de modela conceptual han demostrado ser muy valiosas
para incrementar el nivel de abstraccin a la hora de construir sistemas, sin embargo,
histricamente dejaban de lado el modelado de la interfaz de usuario. La presente tesis
proporciona una extensin para la especificacin de interfaces de usuario sobre modelos
conceptuales orientados a objetos. El modelo propuesto explora los lenguajes de patrones
conceptuales como herramientas para la e licitacin de requisitos, especificacin y
generacin de cdigo. Como herramientas de soporte, se han construido editores de
modelos, especificaciones, prototipos y generadores de cdigo. Como herramientas de
soporte, se han construido editores de modelos, especificaciones, prototipos y generadores
de cdigo. Todo ello, ha sido refinado y validado empricamente en un entorno industrial
tras varios ciclos de desarrollo iterativo. El proceso de desarrollo de interfaces de usuario
propuesto reduce drsticamente los tiempos de desarrollo as como los recursos necesarios
gracias a las tcnicas de generacin de cdigo y prototipacin rpida introducidas. El
anlisis basado en Modelizacin Conceptual y apoyado sobre tcnicas de generacin de
cdigo acerca un poco ms la utopa del Paradigma de la Programacin Automtica
enunciada por Balzer. Ms an, la construccin de sistemas pierde caractersticas de
artesana para convertirse en un mtodo de ingeniera de produccin de software que
asegura la calidad del producto software.

VALIDACION DE REQUERIMIENTOS





GESTION DE REQUERIMIENTOS
es el tratamiento y control de las actualizaciones y cambios a los mismos. Debido a que un
proyecto informtico es susceptible de cambios, habra que proceder a su actualizacin o a
la incorporacin de nuevas funcionalidades o eliminar otras, esto obliga a mantener
controlado y documentado el producto. Los cambios de requisitos deben ser gestionados
para asegurar que la calidad de los mismos se mantenga, los problemas suscitados por los
cambios de requisitos podran incurrir en altos costos, siendo el requisito factor crtico de
riesgo.
Ms formalmente el Manejo de Requisitos es una forma sistemtica de descubrir, organizar
y documentar los requisitos del sistema. Adems es el proceso que establece y mantiene un
consenso entre el cliente y el grupo del proyecto en el cambio de los requisitos del sistema.
El trmino Gestin de Requisitos incluye:
Tcnicas para Descubrimiento/Recogida de Requisitos
Recoger las peticiones del usuario y determinar las verdaderas necesidades de ste.
Tcnicas de Anlisis
Especificacin y verificacin
Manejo de Requisitos
Tareas principales de la Gestin de Requisitos.
Durante el proceso de la gestin de requisitos, hay que planear algunas actividades, dentro
de las que se pueden mencionar las siguientes: la identificacin de los requisitos, en
proceso de gestin de los cambios, las polticas de trazabilidad, la cantidad de informacin
sobre las relaciones entre los requisitos que se mantiene, entre otras.
Actividades y su descripcin:
Recoleccin: Recoleccin y documentacin de requisitos es una actividad de comunicacin
iterativa entre clientes, gerentes y practicantes, para descubrir, definir, refinar y registrar
una representacin precisa de los requisitos del producto. Varios mtodos son utilizados
para la recoleccin de requisitos. Algunos anlisis iniciales como es la agrupacin,
categorizacin, priorizacin son desarrollados durante esta actividad.
Documentacin: Despus que los requisitos han sido recolectados, hay que analizarlos a
detalle y documentarlos en una especificacin de requisitos. El resultado de la
especificacin de requisitos y de cualquier especificacin de requisitos de componentes
hardware/software derivado sirve como registro de convenio con el cliente y compromiso
con el proveedor. Estas especificaciones son rastreadas utilizando una matriz de
trazabilidad de requerimientos y son sujetos a verificacin y gestin de cambio a travs del
ciclo de vida del producto.
Verificacin: Una vez que la especificacin de requisitos ha sido desarrollada, los
requisitos son verificados. La verificacin de requisitos es un proceso para asegurar que la
especificacin de requisito del producto es una representacin exacta de las necesidades del
cliente. Este proceso tambin asegura que los requisitos sean trazados y verificados a travs
de varias fases del ciclo de vida; particularmente en el diseo, implementacin y pruebas.
Adems, todos estos requerimientos deben ser trazados al diseo, implementacin y
pruebas para asegurarse que los requerimientos han sido satisfechos.
Gestin de Cambios: Gestin de cambios es un proceso formal para identificar, evaluar,
trazar y reportar cambios propuestos y aprobados a la especificacin del producto. Como el
proyecto va evolucionando, los requerimientos pueden cambiar o expandirse para ajustar
algunas modificaciones en el alcance o diseo del proyecto. Un proceso de gestin de
cambios proporciona un rastreo completo y preciso de todos los cambios que son
pertinentes al proyecto. El proceso del ciclo de vida de la Gestin de Requisitos, debe ser
flexible y adaptable para reunir las necesidades del proyecto. Las caractersticas del alcance
e implementacin del proceso del ciclo de vida de la Gestin de Requisitos en un proyecto,
variar dependiendo de algunos factores claves.
Tamao y complejidad del proyecto
Experiencia del personal del proyecto
Experiencia de los clientes del proyecto
Dominio de la aplicacin
El propsito y uso de esta aplicacin
Las Herramientas de Gestin de Requisitos
El uso de herramientas de la gestin de requisitos es alentado para mejorar tanto la
productividad como la calidad en el desarrollo de un proyecto software. Existen varias
herramientas tanto hechas en casa como en el mercado que auxilian a las tareas de gestin.
Rational RequisitePro, es una herramienta centrada en documentos, que almacena los
requisitos asocindolos a documentos (aunque tambin permite guardarlos directamente en
la base de datos), mientras que las otras herramientas estn orientadas a requisitos.
Se auxilia especialmente en el control de cambio de requisitos, con trazabilidad para
especificaciones de software y pruebas. La herramienta permite el uso de Oracle sobre Unix
o Windows y tambin soporta SQL Server sobre Windows. Beneficios de RequisitePro
Permite el trabajo en equipo por medio de un repositorio compartido de informacin.
Permite la clasificacin de requerimientos, en base a las necesidades de cada empresa.
Define atributos para todos los tipos de requerimientos especificados.
Ayuda a manipular el alcance del proyecto mediante la asignacin de prioridad de
desarrollo a cada uno de los requerimientos planteados.
Permite caractersticas avanzadas de rastreo, por medio de matrices, que permiten
visualizar las dependencias entre requerimientos dentro de un proyecto o en diferentes
proyectos.
Administracin de cambios mediante el rastreo y la visualizacin histrica de los cambios
efectuados al requerimiento, cundo y quin los realiz.
Interacta con los dems productos Rational para el ciclo de vida, as como con
herramientas de Microsoft Office.
Ayuda a determinar en forma automatizada cuntos requerimientos tiene el proyecto.
Ayuda a determinar responsables y actores en cada uno de los requerimientos.
RequisitePro, permite organizar los requerimientos, establecer y mantener relaciones
padre/hijo entre ellos.
El uso de una herramienta de gestin de requisitos proporciona al proyecto:
Ahorro en costes de especificacin y de desarrollo minimizando el impacto de errores.
Mejora la calidad mediante un adecuado anlisis y gestin de los requisitos.
Reduce las no-conformidades del sistema.
Permite controlar la especificacin.
Permite administrar ms fcilmente la especificacin.
Ayuda a cumplir con estndares de calidad.
Permite centralizar toda la informacin del problema.
Proporciona una trazabilidad completa de la especificacin, etc.
Otras Herramientas de la Gestin de Requisitos en el Mercado
Las herramientas seleccionadas proporcionan casi todas las necesidades bsicas exigibles.
Adems, estas herramientas estn ampliamente difundidas y son muy reconocidas. Todas
las herramientas asumen que la estructura de los requisitos es jerrquica, de forma que un
requisito puede estar formado o tener asociados otros requisitos de nivel inferior, y la
mayora permite extraer prrafos de ficheros generados por procesadores de texto
comerciales y convertirlos en requisitos. Otras de las caractersticas comunes a la mayor
parte de las herramientas es la posibilidad de realizar consultas sobre los requisitos en
funcin de determinados valores de sus atributos. Estas herramientas son: IRqA 3.0,
CaliberRM y DOORS IRqA 3.0 es una herramienta de ingeniera de requisitos
especialmente diseada para soportar el proceso completo de ingeniera de requisitos. En
IRqA el ciclo de especificacin completo incluye la captura de requisitos, anlisis,
especificacin de sistema, validacin y la organizacin de requisitos es soportada por
modelos estndares. ( Lan A, 1994).
CaliberRM es para sistemas grandes y complejos y proporciona una base de datos de
requisitos con trazabilidad. Se ve a los requisitos como parte del proceso al igual de gestin
de la calidad del software, las pruebas (testing) y el trazado de defectos (defect tracking).
Caliber est basado en internet y maneja referencia de documentos, responsabilidad de
usuario, trazabilidad, prioridad y estado entre otras caractersticas.
DOORS a diferencia del resto de las herramientas, considera los requisitos como objetos y
los documentos como mdulos. Tiene una orientacin basada en objetos, frente a
RequisitePro y Caliber-RM, que manejan solamente requisitos y sus atributos. Es una
herramienta para organizaciones grandes que necesitan controlar complejos conjuntos de
usuarios y requisitos de sistemas con una completa trazabilidad. Proporciona buena
visualizacin de tales documentos como jerrquicas, y su lenguaje de extensin permite una
gran variedad de soporte de herramientas a ser construidas.


DOCUMENTO DE REQUERIMIENTO DE SOTWARE
Propsito del documento
Entregar al usuario informacin detallada sobre la obtencin de requerimientos.
Alcance de este documento
Nuestra empresa Creep Co. y en particular nuestro grupo de ingenieros de software: Juan
Jaime del Solar, Oscar Granadino y lvaro Vsquez, quiere alcanzar el entendimiento de
las materias tratadas en este documento por parte del usuario.
CASOS DE USO
Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para
llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso
se denominan actores. En el contexto de ingeniera del software, un caso de uso es una
secuencia de interacciones que se desarrollarn entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicacin y el comportamiento de un sistema mediante su
interaccin con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra
la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin
entre los elementos del modelo, por ejemplo la especializacin y la generalizacin son
relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar cmo reacciona a eventos que se producen en su mbito o en l mismo.
Los ms comunes para la captura de requisitos funcionales, especialmente con el desarrollo
del paradigma de la programacin orientada a objetos, donde se originaron, si bien puede
utilizarse con resultados igualmente satisfactorios con otros paradigmas de programacin.
Pasos para la Definicin de un Caso de Uso:
ID
NOMBRE
REFERENCIAS CRUZADAS
CREADO POR
ULTIMA ACTUALIZACION POR
FECHA DE CREACION
FECHA DE ULTIMA ACTUALIZACION
ACTORES
DESCRIPCION
TRIGGER
PRE-CONDICION
POST-CONDICION
FLUJO NORMAL
FLUJOS ALTERNATIVOS
INCLUDES
FRECUENCIA DE USO
REGLAS DE NEGOCIO
REQUERIMIENTOS ESPECIALES
NOTAS Y ASUNTO

MODELADO UML
Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en
la actualidad; est respaldado por el OMG (Object Management Group).
Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema.
UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos
concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y
compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para
describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos
en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est
descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o
RUP), pero no especfica en s mismo qu metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una
utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de
programar como lo es la orientacin a objetos, la programacin orientada a objetos viene
siendo un complemento perfecto de UML, pero no por eso se toma UML slo para
lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.
Tipos de Diagramas de UML
Estructura
Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de estructura compuesta
Diagrama de paquetes
Diagrama de despliegue
Comportamiento
Diagrama de casos de uso
Diagrama de actividades
Diagrama de estado
Interaccin
Diagrama de secuencia
Diagrama de colaboracin UML 1.X / Diagrama de comunicacin UML 2.0
Diagrama de tiempo
Diagrama de interaccin


DIRAGRAMA DE CASO DE USOS
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de
diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML),
define una notacin grfica para representar casos de uso llamada modelo de casos de uso.
UML no define estndares para que el formato escrito describa los casos de uso, y as
mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso;
sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso
o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos
con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son
mucho ms detallados que los diagramas de casos de uso. En los conceptos se debe detallar
ms de un caso de uso para poder identificar que es lo que hace un caso de uso.

La descripcin escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripcin se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios humanos u
otros sistemas.
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organizacin, un conjunto de casos de uso coherentes y consistentes
promueven una imagen fcil de comprender del comportamiento del sistema, un
entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.
En esta prctica es comn crear especificaciones suplementarias para capturar detalles de
requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de
esos temas incluyen restricciones de diseo como: rendimiento, temas de
escalabilidad/gestin, o cumplimiento de estndares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple.
Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos
de uso se muestran como parte del sistema que est siendo modelado, los actores no.
La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es
esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del
sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin
entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los
actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios
papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.







DIAGRAMA DE SECUENCIA
El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre
objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence
diagram", "event-trace diagrams", "event scenarios" o "timing diagrams.
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama
de casos de uso permite el modelado de una vista business del escenario, el diagrama de
secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y
clases que se usan para implementar el escenario y mensajes intercambiados entre los
objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son
necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada
caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos
pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un
diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas
discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes sincrnicos se
corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que enva
el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se
representan con flechas con la cabeza llena. Los mensajes asincrnicos terminan
inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia. Se representan
con flechas con la cabeza abierta.
Tambin se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas
De instancia: describe un escenario especfico (un escenario es una instancia de la
ejecucin de un caso de uso).
Genrico: describe la interaccin para un caso de uso. Utiliza ramificaciones
("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte
inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el
modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje.
Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del
mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado o invocado
pertenece al objeto receptor del mensaje.


DIAGRAMA DE CLASE
Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un
sistema mostrando sus clases, orientados a objetos.
Diagramas
Propiedad de objetos que tienen propiedades y/u operaciones que contienen un
contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero
clase de lgica de negocio, dependiendo de quin disee el sistema se pueden unir
los datos con las operaciones.
El diagrama de clases incluye mucha ms informacin como la relacin entre un
objeto y otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz grfica.
Presenta las clases del sistema con sus relaciones estructurales y de herencia.
El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.


DIAGRAMA DE OBJETO
En UML, diagrama que muestra una vista completa o parcial de los objetos de un sistema
en un instante de ejecucin especfico.
El Object Management Group, en la especificacin UML (versiones 2.1 y anteriores),
defina al diagrama de objetos como:
"Un diagrama de objetos es un grfico de instancias, incluyendo objetos y datos.
Un diagrama de objetos es una instancia de un diagrama de clases; muestra una
'foto' del estado de un sistema en un punto de tiempo determinado."
Los diagramas de objeto estn ligados a los diagramas de clase y comparten virtualmente
los mismos smbolos para la notacin. Los diagramas de objetos pertenecen a la categora
de diagramas estructurales en UML.
Generacin y Uso
Los diagramas de objetos se generan en las disciplinas de Arquitectura y diseo. Se utilizan
para mostrar estructuras de datos y las interacciones que existen entre objetos en tiempo de
ejecucin.

También podría gustarte