Análisis de Requisitos de un Software de Gestión de Requisitos
por fabio cachi condori
1. RESULTADOS. En este apartado se recogen los resultados obtenidos de aplicar la metodología descrita anteriormente.
1.1. ANALISIS DE SISTEMAS EXISTENTES. Al analizar los diferentes softwares de gestión del mercado hemos observado que la mayoría comparten muchas características comunes, las cuales hacen que la recogida y documentación de requisitos sea mucho más sencilla. PRINCIPALES FUNCIONALIDADES IDENTIFICADAS. 1. Tiene que ser capaz de gestionar un sistema de carpetas donde se tienen que crear una o varias carpetas 2. tiene que tener una buena gestión de requisitos en donde tiene que dar soporte a todas las tareas relacionadas con los requisitos de un proyecto. 3. tiene que dar soporte a la creación, modificación y eliminación de usuarios que han accedido al sistema. 4. debe de permitir las salidas de información sobre la trazabilidad que tienen los diferentes requisitos de un proyecto. DIAGRAMAS DE CLASES. Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos. DIAGRAMAS DE ACTIVIDADES. El diagrama de actividades es la representación gráfica de un determinado proceso, es decir, representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. CASOS DE USO. Los casos de uso son una descripción de los pasos o las actividades que tienen que realizarse para llevar a cabo algún proceso. DOCUMENTO DE VISION. hemos definido el alcance de alto nivel y propósito del programa, producto o proyecto. Es una declaración clara del problema, 3.7 SRS. La especificación de requisitos de software o SRS es una descripción completa del comportamiento del sistema a desarrollar. PORTAFOLIO. Durante el desarrollo de todo el TFG, hemos ido recopilando mucha información, redactado informes y confeccionando diagramas
2. CONCLUSIÓN. El objetivo del proyecto era realizar un análisis de requisitos de un software de gestión de requisitos. El análisis se realizó mediante la comparativa de diferentes softwares que había disponibles en el mercado, el análisis documental de dichas herramientas y la lectura de mate-rial adicional con relación a la recogida de los requisitos.
3. 1.INTRODUCCION. La mayoría de los proyectos son finalizados inadecuadamente, esto debido al recojo malo de requisitos para un software de gestión de requisitos falto de recursos entre otros,
3.1. Elicitación.- traspaso de información de una persona a otra de forma fluida. Documentación.- guardar y ordenar datos obtenidos en la elicitación Validación.- se valida dicha documentación para determinar si el proceso de obtención de los requisitos son los adecuados o no.
4. METODOLOGÍA. En todo proceso de investigación y desarrollo se necesitan unas pautas concretas para poder llegar a determinar con éxito el objetivo propuesto en un proyecto
4.1. Elicitacion. es la definición de las tare-as a realizar, los productos a obtener y las técnicas a em-plear durante la actividad de elicitación de requisitos.
4.1.1. Estudio del Dominio. es fundamental conocer el dominio del problema y los contextos organizacional y operacional, es decir, la situación actual. Selección de fuentes. Como fuentes tuvimos tres pilares básicos, los stakeholders, la revisión de otros softwares de gestión de requisitos disponibles en el mercado actual y la lectura de la documentación sobre dichos softwares. El prototipo. Realizar un posible prototipo para ver más o menos como estará el proyecto
4.2. DOCUMENTACION. En la ingeniería de requisitos, toda la información que ha sido trabajada durante las diferentes fases de elicitación, tienen que ser documentadas.
4.2.1. documento de visión. describe el plan general para un determinado proceso de software. SRS. se definen todos los requisitos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.