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.