pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 3. … · Web viewpegasus.javeriana.edu.co

SOFTWARE REQUIREMENTS SPECIFICATION

HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA

DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

CARLOS DAVID DUARTE ALFONSO

PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA DE SISTEMASBOGOTÁ D.C

2014

Software Requirements Specification

Historial De Cambios

El historial de cambios es una tabla que muestra la evolución y seguimiento del documento, todos los cambios realizados permiten elaborar, corregir y controlar la calidad del documento por parte del autor.

Versión

Fecha Sección del documento modificada

Descripción de cambios

Responsable

V 0.1.0 16/02/2014 Línea base SRS Estructura general del SRS

Carlos Duarte

V 0.2.0 24/02/2014 Capítulo 1 Elaboración de propósito, objetivos, alcance.

Carlos Duarte

V 0.3.0 25/02/2014 Capítulo 3 Elaboración de las subsecciones 3.1 y 3.3.

Carlos Duarte


Carlos Duarte

V 0.4.1 03/03/2014 Capítulo 1 Corrección capítulo 1. Carlos DuarteV 0.4.2. 25/03/2014 Capítulo 2 Corrección capítulo 2. Carlos DuarteV 0.4.3. 26/03/2014 Capítulo 3 Corrección estructura

general capítulo 3.Carlos Duarte


Carlos Duarte

V 0.6.0 29/03/2014 Capítulo 2 y capitulo 3 Corrección general Carlos DuarteV 1.0.0 04/04/2014 SRS Entrega Carlos Duarte

Tabla 1 Historial de Cambios

2


Tabla de Contenido

Historial De Cambios.............................................................................................................................2

Índice de Tablas......................................................................................................................................5

1. Introducción.....................................................................................................................................6

1.1. Propósito..................................................................................................................................6

1.2. Objetivos...................................................................................................................................6

1.2.1. Objetivo general..............................................................................................................6

1.2.2. Objetivos específicos.....................................................................................................6

1.3. Propósito..................................................................................................................................6

1.4. Alcance......................................................................................................................................6

1.5. Definiciones, Acrónimos y Abreviaciones.......................................................................7

1.6. Referencias..............................................................................................................................7

2. Descripción global.........................................................................................................................9

2.1. Perspectiva del producto......................................................................................................9

2.1.1. Interfaces con el sistema..............................................................................................9

2.1.2. Interfaces con el usuario...............................................................................................9

2.1.3. Interfaces con el hardware...........................................................................................9

2.1.4. Interfaces con el software...........................................................................................10

2.1.5. Restricciones de memoria..........................................................................................11

2.1.6. Operaciones...................................................................................................................11

2.1.7. Requisitos de adaptación del sitio...........................................................................11

2.2. Funciones del producto......................................................................................................12

2.3. Características del usuario.................................................................................................12

2.4. Restricciones.........................................................................................................................13

2.5. Suposiciones.........................................................................................................................13

3. Elaboración de requerimientos.................................................................................................13

3.1. Obtención de requerimientos funcionales.....................................................................13

3.2. Obtención de requerimientos no funcionales...............................................................14

3.3. Identificación de requerimientos......................................................................................15

3.4. Especificación de requerimientos....................................................................................21

3


3.5. Distribución de requerimientos funcionales..................................................................22

3.6. Distribución de requerimientos no funcionales............................................................23

3.7. Priorización de requerimientos.........................................................................................24

3.8. Validación de requerimientos............................................................................................25

3.9. Trazabilidad de requerimientos.........................................................................................26

4


Índice de Tablas

Tabla 1 Historial de Cambios........................................................................................................2Tabla 2 Definiciones, Acrónimos y Abreviaciones.........................................................................7Tabla 3 Interfaces con el software...............................................................................................11Tabla 4 Restricciones de Memoria..............................................................................................11Tabla 5 Funciones del producto..................................................................................................12Tabla 6 Niveles de prioridad........................................................................................................23

5


1. Introducción

1.1. Propósito

El propósito de este documento es identificar, especificar, priorizar y gestionar los requerimientos funcionales y no funcionales de la herramienta ERMT (Easy Requirement Management Tool) [1], para esta segunda versión, con el fin de establecer de forma precisa y detallada, el prototipo de software que se desarrolla.

1.2. Objetivos1.2.1. Objetivo general

El objetivo general de este documento es determinar las nuevas características que tiene la herramienta ERMT 2.0, para la administración de requerimientos y gestión de riesgos de los mismos, a través de los requerimientos funcionales y no funcionales.

1.2.2. Objetivos específicos

Los objetivos específicos de ERMT 2.0 son los siguientes:

Identificar los requerimientos funcionales y no funcionales, que permita llevar a cabo la administración de requerimientos en ERMT 2.0.

Identificar los requerimientos funcionales y no funcionales, que permita gestionar los riesgos en los requerimientos en ERMT 2.0.

Priorizar los requerimientos funcionales de ERMT 2.0. Gestionar los requerimientos funcionales y no funcionales 2.0. Documentar los requerimientos funcionales y no funcionales de ERMT 2.0.

1.3. Propósito

El alcance de este documento es identificar y especificar los requerimientos funcionales y no funcionales del prototipo, con el objetivo de poder establecer los procesos de priorización, trazabilidad y validación que se debe llevar a cabo para cada requerimiento de este proyecto de software, en su nueva versión.

1.4. Alcance

El alcance de este documento es definir y especificar los requerimientos funcionales y no funcionales de ERMT 2.0, con base a las actividades de administración y gestión de riesgos en los requerimientos. Ver documentación casos de uso.

6


1.5. Definiciones, Acrónimos y Abreviaciones

Término Acrónimo Definición/Descripción

Caso de uso CU Un único uso del sistema representado como una interacción entre el usuario y el sistema. [4]

Easy Requirement Management Tool

ERMT Es una herramienta para la administración de requerimientos en un proyecto de software. [1]

Freeware Es un tipo de software que no tiene costo pero no implica que este sea de código abierto.

Java Virtual Machine JVM Es la máquina virtual de Java, que permite interpretar y ejecutar instrucciones expresadas en un código binario.

Requerimiento REQ Una descripción detallada de lo que el software tiene que hacer. [2]

StakeholderUna persona, grupo u organización que participa activamente en un proyecto, se ve afectada por su resultado, o pueden influir en su resultado. [4]

Stand Alone Significa que la aplicación no requiere necesariamente una conexión de red funcionando.

System requirements specification

SRS Es la especificación de los requerimientos que tiene un proyecto de software y una descripción general del comportamiento del sistema. [5]

Tabla 2 Definiciones, Acrónimos y Abreviaciones

1.6. Referencias

[1] “ERMT.” [Online]. Disponible: http://pegasus.javeriana.edu.co/~CIS1010IS05/index.html. [Consultado: 19-Feb-2014].

[2] “Software Project Management Boot Camp | Construx.” [Online]. Available: http://www.construx.com/Seminars/Base_Seminar/Software_Project_Management_Boot_Camp/#0. [Consultado: 27-Feb-2014].

[3] K. E. Wiegers and J. Beatty, Software requirements. 2013.

[4] “IEEE Recommended Practice for Software Requirements Specifications,” IEEE Std 830-1998, pp. 1–40, Oct. 1998.

[5] “Software Engineering Toolbox | Construx.” [Online]. Available: http://www.construx.com/Resources/Techniques/Software_Engineering_Toolbox/.

7


[6] P. Zielczynski, Requirements management using IBM Rational RequisitePro. Upper Saddle River, N.J.: IBM Press, 2008.

[7] “First Things First: Prioritizing Requirements.” [Online]. Available: http://www.processimpact.com/articles/prioritizing.html.

[8] I. Sommerville, Software Engineering. Addison-Wesley, 2007.

[9] R. R. Young, The requirements engineering handbook. Boston: Artech House, 2004.

[10] J. Beatty and A. Chen, Visual Models for Software Requirements: An Rml Handbook. [s.l.]: Microsoft Pr, 2012.

[11] C. Hood, Requirements management: interface between requirements development and all other engineering processes. Berlin; London: Springer, 2007.

[12] “IBM - Rational DOORS - Spain.” [Online]. Available: http://www-142.ibm.com/software/products/es/es/ratidoor/.

[13] “IBM - Rational RequisitePro - Spain.” [Online]. Available: http://www-142.ibm.com/software/products/es/es/reqpro/.

[14] “IT TOOLS LTDA. - Caliber RM.” [Online]. Available: http://www.ittoolsltda.com/productos/16-borland/29-caliber-rm.

[15] L. Mathiassen and T. Tuunanen, “Managing Requirements Risks in IT Projects,” IT Professional, vol. 13, no. 6, pp. 40–47, Nov. 2011.

[16] B. W. Boehm, “Software risk management: principles and practices,” IEEE Software, vol. 8, no. 1, pp. 32–41, Jan. 1991.

[17] J. M. Carrillo de Gea, J. Nicolás, J. L. Fernández Alemán, A. Toval, C. Ebert, and A. Vizcaíno, “Requirements engineering tools: Capabilities, survey and assessment,” Information and Software Technology, vol. 54, no. 10, pp. 1142–1157, Oct. 2012.

[18] “List of Requirements Management Tools.” [Online]. Available: http://makingofsoftware.com/resources/list-of-rm-tools.

[19] D. Beuche, A. Birk, H. Dreier, A. Fleischmann, H. Galle, G. Heller, D. Janzen, I. John, R. T. Kolagari, T. von der Massen, and A. Wolfram, “Using Requirements Management Tools in Software Product Line Engineering: The State of the Practice,” inSoftware Product Line Conference, 2007. SPLC 2007. 11th International, 2007, pp. 84–96.

[20] “Microsoft Application Architecture Guide, 2nd Edition,” Microsoft Download Center. [Online]. Available: http://www.microsoft.com/en-us/download/details.aspx?id=16236.

8


2. Descripción global

Este capítulo tiene como propósito, brindar una descripción completa y global sobre la funcionalidad del software y la expectativa sobre el prototipo por parte del desarrollador y de los usuarios finales.

2.1. Perspectiva del producto

Este prototipo es la continuación de ERMT [1], la cual es una herramienta para la administración de requerimientos en un proyecto de software. La adición de nuevas funcionalidades no implica que se va a desarrollar un prototipo nuevo, si no que se modifica la arquitectura ya existente para que soporte estas nuevas características.

2.1.1. Interfaces con el sistema

La interfaces con el sistema para esta segunda versión de ERMT como la primera, es generar diferentes reportes (problemas en los requerimientos, matriz de trazabilidad, entre otros), por lo cual la herramienta interactúa con procesadores de texto (Word, Excel) para poder generar estos reportes y el usuario pueda guardarlos o imprimirlos.

2.1.2. Interfaces con el usuario

Representa todos los factores que intervienen con el usuario para interactuar con la aplicación, permitiendo facilitar al usuario acceder a ella. Las interfaces con el usuario son las siguientes:

Teclado: Dispositivo de entrada utilizado para navegar e interactuar con los diferentes componentes del producto de software.

Mouse: Es necesario para navegar y controlar las diferentes características de este producto de software.

Pantalla: Recurso utilizado como dispositivo de salida, para la interacción visual del usuario con el producto de software.

Interfaz Gráfica de Usuario: Para ERMT 2.0, se manejarán los mismos colores y estilos que se usaron para ERMT 1.0. [1]

2.1.3. Interfaces con el hardware

La herramienta ERMT tanto la versión ERMT 1.0, como la versión ERMT 2.0, es una aplicación de tipo “Stand Alone”, por lo cual no necesita ningún tipo de interacción con elementos de hardware. [1]

9


2.1.4. Interfaces con el software

A continuación se muestran las interfaces con el software, que básicamente son las aplicaciones externas que interactúan con ERMT 2.0, para su correcto funcionamiento. [1]

Software Descripción Propósito Versión requerida Licencia

Windows

Es un sistema operativo desarrollado y comercializado por Microsoft, además esta acoplado con una interfaz de usuario, en versiones de 32 y 64 bits.

Es el sistema operativo requerido para el desarrollo y la ejecución de ERMT 2.0.

Windows XP Professional o superior.

Propietario

JVM

Máquina virtual de java, la cual se encarga de interpretar y ejecutar lenguaje de alto nivel a lenguaje binario.

Dado a que una de las restricciones de ERMT es el lenguaje de programación (Java), es necesario utilizar este software ya que no es un lenguaje de bajo nivel, por lo cual necesita usar este interprete que permita la ejecución de las instrucciones.

Java SE 6 o superior.

Propietario

JDBC

Es una API que permite a un programa escrito en el lenguaje de programación Java, ejecutar instrucciones SQL, para acceder a bases de datos relacionales.

Debido a que ERMT está escrito en Java, es necesario utilizar el JDBC como

4.0 o superior. Propietario

GraphViz

Es un software de código abierto, que permite la visualización de graficas (grafos y redes abstractas)

Este software permite a ERMT generar los grafos de priorización, relaciones entre requerimientos, entre otros.

2.26. Freeware

MySQL

Es un sistema de gestión de bases de datos relacional de licencia gratuita.

Proporciona un servidor de bases de datos SQL, la cual es necesaria para manejar la persistencia en ERMT y puede ser accedida desde el lenguaje de

5.1.41 o superior. Freeware

10


programación Java.Tabla 3 Interfaces con el software

2.1.5. Restricciones de memoria

Las restricciones de memoria que se tienen, son básicamente el software que se desarrolló a lo largo del semestre, es decir ERMT 2.0 y el software que se necesita para que ERMT 2.0 funcione correctamente con los requisitos mínimos que debe tener el equipo donde se ejecute. A continuación se muestran las restricciones de memoria:

Software Disco Duro Memoria RamMáquina virtual Java JRE 1.6 600 MB 64 MBERMT 2.0 120 MB 512 MBGraphviz 100 MB 512 MBMySQL 4 GB 512 MB

Tabla 4 Restricciones de Memoria

2.1.6. Operaciones

“La herramienta ERMT cuenta un único tipo de usuario, el cual contará con las siguientes operaciones”:

Crear, Modificar y eliminar un proyecto. El usuario solo puede crear un proyecto. Realizar consultas sobre el proyecto creado. El usuario podrá almacenar la información de su proyecto, mediante la operación

Guardar, la cual se realizará cada vez que el usuario ingresa y modifica la información del proyecto.

“Por otro lado, la herramienta no contará con funciones de recuperación de datos en caso de que ocurran fallos en la comunicación entre la herramienta y la base de datos en la cual va a ser almacenada la información”. [1]

2.1.7. Requisitos de adaptación del sitio

“La herramienta ERMT, se debe ejecutar sobre las máquinas instaladas en la Pontificia Universidad Javeriana, por lo tanto las maquinas externas donde se desee ejecutar deben adaptarse a las siguientes especificaciones mínimas de hardware y software” [1]:

Hardware:

Disco Duro: 120 GB. Memoria RAM: 2 GB. Procesador: Intel Core2 Dúo @2.40 GHz. Resolución de pantalla: 1600 X 900 pixeles.

11


Software:

Sistema Operativo: Windows XP o superior. Java Virtual Machine 1.6. JDK versión: 1.6.0_14. Graphviz 2.26.3 Mysql 5.1.73 [1]

2.2. Funciones del producto

A continuación se muestran las funciones de ERMT, para lo cual se muestra una tabla donde se puede ver las funcionalidades existentes frente a las nuevas, para cual se establece ERMT 1.0 como la herramienta que ya existe y ERMT 2.0 como la continuación de esta:

ERMT 1.0 ERMT 2.0Almacenamiento y Consulta derequerimientos

Línea base de requerimientos

Generación de reportes en Excel Control del conjunto de las versiones de los requerimientos.

Generación de grafos deimplementación

Proceso de control de cambios

Generación de reportes del estado decada requerimientos y del estado delproyecto en general

Seguimiento de los problemas en los requerimientos

Importación de archivos csv Matriz de trazabilidad de requerimientosPriorización de requerimientos Identificación de riesgosLocalización de archivos mediante la trazabilidad

Técnicas de mitigación de riesgos

Relación entre requerimientosDefinición de tipos derequerimientosListas de validación y verificación

Tabla 5 Funciones del producto

Para ver en más detalle las funcionalidades de ERMT 1.0 ver documentación casos de uso 1.0, y para ERMT 2.0. Ver documentación casos de uso.

2.3. Características del usuario

Los usuarios que interactúan directamente con la herramienta son básicamente estudiantes de la carrera de ingeniería de sistemas de la Pontificia Universidad Javeriana, y la usan para las materias de ingeniería y arquitectura de software. Para ver en más detalle las características de los usuario ver el capítulo 3 de la documentación de casos de uso.

12


2.4. Restricciones

A continuación se muestran las restricciones de ERMT 2.0:

Las nuevas funcionalidades se deben realizar bajo el lenguaje programación JAVA. Se debe utilizar MySQL como sistema de gestión de bases de datos para la aplicación. Se debe mantener la misma interfaz gráfica de ERMT 1.0. Las nuevas funcionalidades propuestas se deben integrar a ERMT 1.0.

2.5. Suposiciones

A continuación se muestran las suposiciones de ERMT 2.0:

La aplicación debe poder ejecutarse en los computadores de la facultad de ingeniería. Estos computadores tienen las siguientes características:

o Pantalla: LCD de 16”o Procesador: Intel® Core™2 Duo de 2.4 GHzo RAM: 2GBo Disco duro: 160GBo Sistema operativo: Windows 7

No habrá cambios en los requerimientos del producto. No se podrán solicitar funcionalidades extra para el producto. Se dispondrá de los equipos de la facultad de ingeniería tanto para el desarrollo como

para realizar pruebas del producto. Para más suposiciones ver sección 1.1.3. del documento SPMP.

3. Elaboración de requerimientos

3.1. Obtención de requerimientos funcionales

En este capítulo se explica la manera en la cual se obtuvieron los requerimientos funcionales de este proyecto de software. Es importante resaltar que este proyecto de software se basa en incorporar nuevas funcionalidades a la herramienta ERMT, basándose en la administración de requerimientos y la gestión de riesgos de los mismos. Ver documento Propuesta trabajo de grado.

Las actividades básicas de la administración de requerimientos están en cuatro categorías principales [3]:

Control de versiones

Definición de un esquema de identificación de la versión. Seguimiento individual a las versiones de requerimientos.

13


Seguimiento al conjunto de versiones de requerimientos.

Control de cambios

Proponer cambios. Análisis del impacto. Toma de decisiones. Actualización de los requerimientos individuales. Actualización del conjunto de requerimientos. Actualización de los planes. Medición de la volatilidad de los requerimientos.

Seguimiento del estado de los requerimientos

Definir posibles estados de los requerimientos. Llevar un registro de cada requerimiento. El seguimiento de la distribución del estado de todos los requerimientos.

Trazabilidad de requerimientos

Definir enlaces a otros requerimientos. Definir enlaces a otros elementos.

La preparación para la gestión de riesgos en los requerimientos implica dos pasos principales [15]:

Identificar los tipos de riesgos

Identidad Volatilidad Complejidad

Técnicas de mitigación de los riesgos

Descubrimiento Priorización Experimentación Especificación

3.2. Obtención de requerimientos no funcionales

En este capítulo se explica la manera en la cual se obtuvieron los requerimientos no funcionales de ERMT 2.0. Es importante aclarar que para esta versión se van a utilizar los mismos requerimientos no funcionales de ERMT 1.0. Para este proceso se tuvo en cuenta los siguientes factores:

Restricciones de memoria. Ver sección 2.1.5 Restricciones de memoria. Restricciones. Ver sección 2.4 Restricciones. Suposiciones. Ver sección 2.5 Suposiciones.

14


Luego de los factores ya mencionados, se listaron y se realizó el documento donde se describe cada uno de los requerimientos no funcionales del sistema en forma detallada. Ver documentación requerimientos.

3.3. Identificación de requerimientos

Para la identificación de los requerimientos, se realizó un estudio de los siguientes temas, con el fin de poder establecer los nuevos requerimientos de ERMT 2.0, que permitan agregar nuevas funcionalidades:

Análisis de ERMT 1.0 Análisis de diferentes herramientas existentes de administración de requerimientos. Bibliografía acerca de la administración de requerimientos.

Con base a estos análisis se obtuvieron las siguientes características [17]:

Categorías Descripción Funcionalidades

Obtención

Captura y seguimiento de los requerimientos de negocio o usuario, los requerimientos funcionales y la calidad (no funcionales) Requerimientos durante los trabajos de obtención.

Captura de requerimientos.

Obtención de plantillas y listas de verificación.

Importación y exportación hacia y desde otras fuentes.

Obtención de documentación.

Análisis

Incluye las capacidades destinadas a descomponer requerimientos de alto nivel en los detalles, la evaluación de viabilidad, la negociación de prioridades, identificar los conflictos, requerimientos incompletos, ambiguos o contradictorios y resolver todas estas cuestiones.

Los requerimientos de calidad de análisis.

Análisis de viabilidad.

Análisis de atributos.

Análisis de riesgos y la gestión.

Especificación

Incluye características que se centran en documentar las funciones que un software o un sistema debe proporcionar, así como las limitaciones que debe respetar. Los requerimientos deben ser especificados de manera coherente, accesible y revisable si esta meta se va a lograr.

Documentación y especificación de los requerimientos.

Incluye características centradas en la aplicación de ciertas técnicas

El análisis de modelado. Los lenguajes de

15


Modelado para producir modelos de requerimientos útiles y verificables.

modelado y especificación.

Verificación y Validación

Incluye las capacidades destinadas a apoyar las diferentes pruebas e instrumentos de evaluación que intervienen en la verificación y validación de los requerimientos.

Almacenamiento y la gestión de verificación.

Validación de los planes y procedimientos de verificación.

Validación, mediante el apoyo a la revisión e inspección de dichos planes y procedimientos.

Formato estándar para la interfaz de verificación.

Validación de herramientas.

Gestión

Se explora la capacidad de las herramientas para apoyar el seguimiento de los cambios y el mantenimiento de los requerimientos, lo que garantiza que los requerimientos reflejan con precisión el producto.

Línea de base de los requerimientos.

Requerimientos de gestión del cambio.

Gestión de proyectos. Modelo de datos

abiertos o cerrados.

Trazabilidad

Incluye capacidades de centrado en la documentación de la vida de un requisito, proporcionando mecanismos de conexión entre los requerimientos asociados, y el seguimiento de los cambios realizados a cada requisito.

Trazabilidad. Trazado flexible. Rastreo bidireccional. Análisis de trazabilidad.

Table 1 Características herramientas administración de requerimientos

Características adicionales que puede tener la herramienta:

Categoría Descripción Funcionalidades

Otras capacidadesAbarca las funciones relacionadas con la integración de la herramienta en los sistemas y el entorno de desarrollo de software.

Herramienta de información administrativa.

Interfaz gráfica de usuario (GUI).

Integración de datos.Table 2 Características adicionales herramientas administración de requerimientos

Herramientas de gestión de requerimientos

16


Administrar las versiones y los cambios

El proyecto debe definir uno o varias líneas base de requerimientos, cada uno identificado en un conjunto especifico de requerimientos destinados a un lanzamiento o iteración particular. Las herramientas también mantienen un historial de los cambios hechos a cada requerimiento. Se puede grabar la razón detrás de cada decisión de cambio y volver a una versión anterior de un requerimiento en caso de necesidad. Algunas herramientas contienen un sistema de cambio propuesto que vincula las solicitudes de cambio directamente a los requerimientos afectados [17].

Almacén de atributos de requerimientos

Se debe guardar varios atributos descriptivos para cada requerimiento, todos los que trabajan en el proyecto deben ser capaces de ver los atributos, y se les permitirá actualizar los valores de los atributos. Las herramientas generan varios atributos definidos por el sistema, como la fecha en que un requerimiento fue creado y número de versión actual y que permiten definir atributos adicionales de distintos tipos de datos.

Facilitar el análisis del impacto

Las herramientas permiten el rastreo de requerimientos, ya que permite definir los vínculos entre los diferentes tipos de requerimientos, entre los requerimientos de los distintos subsistemas y entre las necesidades individuales y los componentes con el sistema (diseños, módulos de código, pruebas y documentación del usuario). Estos vínculos ayudan a analizar el impacto que tiene un cambio propuesto en un requerimiento especifico tendrá en otros elementos del sistema. Es una buena idea para el seguimiento de cara requerimiento funcional establecer su origen o requerimiento padre para establecer de donde viene. [19]

Identificar los requerimientos faltantes y extraños

La funcionalidad de seguimiento ayuda a los interesados a identificar los requerimientos faltantes, como los requerimientos de los usuarios que no tienen los requerimientos funcionales. Del mismo modo, pueden revelar requerimientos que no se remontan a un origen razonable, planteando la cuestión de si esos requerimientos son necesarios. [19]

Seguimiento del estado de los requerimientos

Recopilación de requerimientos en una base de datos permite saber cuántos requerimientos discretos se han especificado en el producto. El seguimiento del estado de cada requerimiento durante el desarrollo apoya el seguimiento del estado general del proyecto. [17]

Acceso de control

17


Permiten definir permisos de acceso para los individuos o grupos de usuarios compartir información con un equipo geográficamente disperso a través de una interfaz web para la base de datos. Algunas herramientas permiten que varios usuarios puedan actualizar el contenido de la bases de datos al mismo tiempo.

Reutilización de requerimientos

El almacenamiento de los requerimientos en una base de datos facilita la reutilización de ellos en varios proyectos o sub proyectos. Requerimientos que se ajustan de forma lógica en varias partes de la descripción del producto se puede almacenar una vez y se hace referencia siempre que sea necesario, para evitar la duplicación de requerimientos. [18]

Seguimiento de los problemas en los requerimientos

Algunas herramientas tienen la funcionalidad para el seguimiento de los problemas en los requerimientos y una vinculación de cada tema a sus requerimientos relacionados. Como se resuelven los problemas, es fácil determinar si se deben actualizar los requerimientos. También puede encontrar rápidamente una historia del problema y su solución. El seguimiento de los problemas en una herramienta permite informar automáticamente sobre el estado de los problemas. [19]

Generación de subconjuntos adaptados

Las herramientas permiten extraer y visualizar un conjunto de requerimientos que se ajuste a un propósito particular. Por ejemplo, es posible que desee un informe que contenga todos los requerimientos para una iteración específica de desarrollo, todos los requerimientos que se relacionan con una característica particular, o de un conjunto de requerimientos que debe ser inspeccionado.

A continuación se muestran las herramientas existentes en el mercado para tener una idea general de las características de las herramientas para la administración de requerimientos:

La primera herramienta es “Rational Doors” de IBM. Estas son sus funcionalidades y características [12]:

Gestión de requerimientos

Gestiona los documentos de requerimientos mediante un repositorio central desde el que trabajan todos los usuarios.

Proporciona acceso a las funciones completas de edición, configuración, análisis y creación de informes a través de un cliente de escritorio.

Admite el formato de intercambio de requerimientos (RIF), que permite a los proveedores y a los colaboradores en desarrollo contribuir en los documentos, secciones o atributos de requerimientos que pueden remontarse a los requerimientos centrales.

Registra y muestra texto de requerimientos, gráficos, tablas, atributos de requerimientos, barras de cambio y enlaces de rastreabilidad, entre otros.

Rastreabilidad

18


Permite arrastrar y soltar elementos para vincular un requerimiento a un elemento de diseño, a un caso de prueba o a otro requerimiento.

Permite seleccionar los requerimientos de una lista o especificar números de requerimientos como atributos y que Rational DOORS haga los enlaces en su lugar.

Proporciona informes completos de rastreabilidad en una única vista para ayudar a priorizar el trabajo de desarrollo de forma eficiente y a prever el tiempo de entrega.

Da soporte a enlaces externos que permiten que los requerimientos se asocien directamente a la información de fuera del dominio de Rational DOORS.

Escalabilidad

Ofrece una jerarquía de tipo explorador con varios niveles de carpetas y proyectos para la navegación simple, sin importar cuanto crezca la base de datos.

Incluye vistas configurables y documentos compartibles, que permite a los usuarios trabajar de forma simultánea para generar un único documento.

Test Tracking Toolkit

Le permite crear enlaces desde requerimientos a pruebas.

Define casos de prueba, registros y compara ejecuciones de pruebas.

Garantiza que los casos de prueba cubran todos los requerimientos.

Integraciones

Se integra con software de gestión de cambios de Rational para el control de cambios de requerimientos y para la gestión de flujo de trabajo de requerimientos.

Se integra con otras soluciones de Rational, incluidas IBM Rational Quality Manager, IBM Rational Rhapsody e IBM Rational Focal Point, entre otras.

Se integra con HP QualityCenter para obtener visibilidad de los requerimientos y crear casos de prueba para la rastreabilidad y la generación de informes de estado sobre el cubrimiento de los requerimientos por parte de los casos de prueba.

Se integra con Microsoft Team Foundation Server (TFS) para permitir equipos de desarrollo que utilizan Microsoft Visual Studio para crear y mantener la rastreabilidad entre los requerimientos de Rational DOORS y TFS Work Items en Visual Studio.

La segunda herramienta es “CaliberRm”. Estas son sus funcionalidades y características [13]:

Sistema de gestión de requerimientos completo: Proporciona un repositorio central seguro para gestionar los requerimientos de los proyectos a través del ciclo de vida de

19


la aplicación, mejorando la comunicación a través de todos los participantes para establecer una visión consistente desde el principio del proyecto. Las capacidades sin par de edición aseguran que los usuarios puedan escribir requisitos usando su formato preferido incluyendo casos de uso, escenarios, storyboards, definiciones funcionales, y documentos del diseño.

Procesos de gestión de requisitos personalizable: se puede modificar fácilmente para soportar procesos de gestión de requisitos particulares, asegurando que las organizaciones y los equipos conserven control y trabajen en la manera que desean trabajar.

Estimación basada en los requerimientos: Las potentes capacidades de estimación basadas en los requerimientos ayudan a los gestores a planificar el alcance del proyecto, agenda, y recursos a través del ciclo de vida del desarrollo del software con gran exactitud. Enlazando el alcance del proyecto, agenda, y coste con la asignación de recursos y la gestión de riesgo, cuando una variable cambia, el impacto en otras variables se puede determinar inmediatamente.

Gestión integrada del ciclo de vida de la aplicación: La trazabilidad de los requisitos a través del proceso de desarrollo resulta ser el mejor control del proyecto. La arquitectura abierta de CaliberRM permita enlazar directamente los requerimientos con una variedad de aplicaciones - tales como gestiones de configuración de software. Esto mantiene a todos los miembros del equipo enfocados y actualizados para acelerar la producción.

Análisis de impacto: La visualización de la trazabilidad ayuda a los usuarios a evaluar el alcance de los cambios de requisitos. El rastro revela cómo los cambios afectan a los requisitos, tareas, pruebas y/o código de fuente, permitiendo el análisis en tiempo real.

Luego de este proceso se obtuvieron los siguientes requerimientos funcionales, los cuales se muestran a continuación:

El sistema debe permitir crear una línea base de requerimientos. El sistema debe permitir consultar las líneas base de requerimientos. El sistema debe permitir eliminar una línea base de requerimientos. El sistema debe permitir asociar un problema a un requerimiento. El sistema debe permitir editar un problema a un requerimiento. El sistema debe permitir eliminar un problema a un requerimiento. El sistema debe permitir generar un reporte de problemas en los requerimientos. El sistema debe permitir modificar un requerimiento. El sistema debe permitir consultar el historial de cambios en los requerimientos. El sistema debe permitir generar una matriz de trazabilidad de casos de usos

relacionados. El sistema debe permitir asociar un riesgo a un requerimiento. El sistema debe permitir editar un riesgo a un requerimiento. El sistema debe permitir genera una técnica de mitigación. El sistema debe permitir consultar los riesgos en los requerimientos.

20


Para ver la correspondiente documentación de cada requerimiento ver documentación requerimientos.

3.4. Especificación de requerimientos

Este capítulo define los parámetros necesarios para la especificación de cada uno de los requerimientos funcionales y no Funcionales de la aplicación. Para esto se define una plantilla de documentación de requerimientos que fue adaptada de “Requirements Templates - Construx” [2] a las necesidades específicas del proyecto.

Esta plantilla contiene los parámetros necesarios para llevar a cabo una adecuada documentación de los requerimientos, a continuación se muestra cada uno de los parámetros con su respectiva definición:

ID Requerimiento: Identificador único de cada requerimiento.

Versión: Representa los cambios que se efectúan en el requerimiento.

Autor: Nombre de la persona encargada de especificar el requerimiento.

Prioridad: Es la importancia de cada requerimiento dentro de la aplicación.

Fecha de Creación: Creación de cada requerimiento en formato DD/MM/AAAA.

Fecha de Modificación: Modificación de cada requerimiento en formato DD/MM/AAAA.

Descripción: Definición de cada requerimiento.

Origen: Caso(s) de Uso(s).

Verificación: Define cómo la aplicación hace para que ese requerimiento cumpla lo que especifica.

Estado: Define el seguimiento de cada requerimiento.

Propuesto: El requerimiento ha sido solicitado por una fuente autorizada.

Aprobado: El requerimiento ha sido analizado, documentado y su impacto en el proyecto se ha estimado.

Implementado: El código que implementa el requerimiento, ha sido diseñado, programado y probado unitariamente. Los requerimientos han sido asociados al diseño pertinente y al código fuente correspondiente.

Verificado: El funcionamiento correcto del requerimiento implementado ha sido conformado en el producto integrado, ha sido asociado a los pertinentes casos de pruebas. El requerimiento ahora es considerado completo.

Eliminado: Un requerimiento aprobado previamente ha sido eliminado. Incluye una explicación de por qué se tomó la decisión de eliminarlo.

21


Rechazado: El requerimiento fue propuesto, pero no está previsto para la implementación en una próxima entrega, Incluye una explicación de por qué se decidió rechazarlo.

Requerimiento(s) Asociado(s): Son aquellos requerimientos que se complementan.

3.5. Distribución de requerimientos funcionales

La distribución de requerimientos funcionales de ERMT 2.0, se organizan básicamente a las actividades principales de la administración y gestión de riesgos en los requerimientos. Ver capítulo 3.2 obtención de requerimientos.

A continuación se muestra la distribución de los requerimientos funcionales de ERMT 2.0:

Tabla 3 Distribución requerimientos funcionales

Control de versiones: Esta categoría contiene los requerimientos asociados a la definición de un esquema de identificación de la versión y el seguimiento individual y al conjunto de versiones de requerimientos.

Control de cambios: Esta categoría contiene los requerimientos asociados a proponer cambios, toma de decisiones y actualización de los requerimientos individuales y en conjunto.

22

Requ

erim

ient

os F

unci

onal

esControl de versiones

Seguimiento de estado

Control de cambios

Trazabilidad

Riesgos

Tecnicas de mitigacion


Seguimiento del estado de los requerimientos: Esta categoría contiene los requerimientos asociados a definir posibles estados de los requerimientos y llevar un registro de cada requerimiento.

Trazabilidad de requerimientos: Esta categoría contiene los requerimientos asociados a la localización de los requerimientos, a definir enlaces a otros requerimientos y definir enlaces a otros elementos.

Identificar los tipos de riesgos: Esta categoría contiene los requerimientos asociados a los riesgos se pueden presentar en el momento de desarrollar un requerimiento, para la cual es necesario identificar el tipo de riesgo correspondiente a un requerimiento.

Técnicas de mitigación de los riesgos: Esta categoría contiene los requerimientos asociados a las técnicas de mitigación que se van a usar para afrontar y minimizar el riesgo que tiene un requerimiento.

3.6. Distribución de requerimientos no funcionales

La distribución de los requerimientos no funcionales de ERMT 2.0, se basa en la misma distribución que se tiene en ERMT 1.0, ya que se definieron los mismos requerimientos no funcionales. Ver capítulo 3.2 Obtención de requerimientos no funcionales.

A continuación se muestra la distribución de los requerimientos no funcionales de ERMT 2.0:

Tabla 4 Distribución requerimientos no funcionales

23

Requ

erim

ient

os n

o Fu

ncio

nale

s

Confiabilidad

Disponibilidad

Usabilidad

Mantenibilidad

Portabilidad

Funcionalidad

Desempeño


Confiabilidad: Es la capacidad de un sistema para permanecer en funcionamiento. La fiabilidad se mide como la probabilidad de que un sistema de no dejará de realizar las funciones previstas en un determinado intervalo de tiempo. [20]

Disponibilidad: Define la proporción de tiempo en que el sistema es funcional. Se puede medir como un porcentaje de tiempo de inactividad total del sistema a través de un período determinado. La disponibilidad se verá afectada por los errores del sistema, problemas de infraestructura, ataques maliciosos y la carga del sistema. [20]

Usabilidad: Define lo bien que la solicitud cumple los requerimientos del usuario y del consumidor por ser intuitivo, fácil de localizar y globalizar, proporcionando un buen acceso para discapacitados los usuarios, y que resulta en una buena experiencia general del usuario. [20]

Mantenibilidad: Es la capacidad del sistema para experimentar cambios con un grado de facilidad. Estos cambios podrían afectar los componentes, servicios, funciones e interfaces al añadir o cambiar la funcionalidad. [20]

Portabilidad: Es la capacidad del sistema de ejecutarse en diferentes plataformas, sistemas operativos o arquitecturas con la menor cantidad de modificaciones. [20]

Funcionalidad: Hace referencia a los requerimientos que proveen la capacidad para que el sistema provea las funciones descritas con los requerimientos funcionales. [1]

Desempeño: Es la capacidad de respuesta de un sistema para ejecutar cualquier acción dentro de un intervalo de tiempo dado. Se puede medir en términos de latencia o rendimiento. [20]

3.7. Priorización de requerimientos

En este capítulo se define la priorización que se utiliza tanto para los requerimientos funcionales y no funcionales de ERMT 2.0. Para la priorización de los requerimientos se define una priorización por escalas, la cual consiste en tres diferentes niveles de prioridad e importancia dentro de la aplicación [7], la cual se explica en detalle en la siguiente tabla:

Nombres SignificadosAlto Es un requerimiento fundamental del sistema, es requerido para el siguiente

lanzamiento.Medio Apoya las operaciones necesarias del sistema y es requerido

eventualmente, pero podría esperar hasta una nueva versión posterior si es necesario.

Bajo Es una mejora funcional o mejora la calidad del sistema, sería deseable desarrollarlo, si el tiempo lo permite.

Tabla 6 Niveles de prioridad

Todos los requerimientos de ERMT 2.0 solo tienen asignado un nivel de prioridad, con el objetivo de establecer de manera única su relevancia e importancia dentro del trabajo de grado.

24


3.8. Validación de requerimientos

En este capítulo de define la validación de los requerimientos, que básicamente consiste en comprobar que los requerimientos recolectados sean consistentes con las exigencias del cliente. [8]

En esta etapa, es indispensable la corrección de los requerimientos para evitar atrasos durante el desarrollo o la implementación del producto. Esta validación comprende los siguientes pasos, que son ejecutados a lo largo del desarrollo del trabajo de grado:

Verificación de Validez: Cuando se trabajan con los requerimientos, es común analizar durante la construcción que estos enunciados carecen especificación sobre la funcionalidad. Para evitar retrasos, se redefinen estos requerimientos del sistema.

Verificación de Consistencia: Después de la recolección de requerimientos, es habitual que en cada requerimiento se encuentren contradicciones, lo cual significa que se deben analizar estas aseveraciones que especifican contrariamente lo que otros requerimientos afirman, y se decide si se debe replantearlo o rechazarlo.

Verificación de Trazabilidad: Se debe asegurar que estos requerimientos logren ser implementados completamente en el producto por entregar, teniendo en cuenta las restricciones de planeación.

Verificabilidad: Se procede a la redacción de los requerimientos con el fin de confrontar las expectativas del cliente frente a las aseveraciones recolectadas.

Todas estas exigencias, anteriormente planeadas, facilitan el control de buenos requerimientos, permitiendo llevar un seguimiento a cada requerimiento y verificar que los requerimientos propuestos se están desarrollando de manera adecuada y oportuna.

Los requerimientos deben tener los siguientes atributos:

No ambiguo: Debe ser claro, alcanzable, preciso y tener una única interpretación posible.

Correcto: Debe estar bien redactado.

Completo: Deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.

Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requisitos debe ser consistente también.

Escrito en forma de “Debe”: Debe iniciar con la palabra “Debe”.

No repetido: Puede existir uno redactado de otra forma que tenga el mismo objetivo.

Verificable: Poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

25


Escrito en lenguaje natural: Debe ser claro para los que necesitan hacer uso de los requerimientos.

Necesario: Lo que pida un requerimiento debe ser necesario para el producto.

Puede seguirse: Deben tener artefactos asociados a lo largo del ciclo de vida del producto. [3]

3.9. Trazabilidad de requerimientos

Este capítulo define la trazabilidad de los requerimientos funcionales y no funcionales del proyecto. La trazabilidad es el seguimiento que se puede hacer sobre cada uno de los requerimientos del sistema. Se puede decir que un requerimiento es trazable si se pueden identificar y relacionar con las siguientes partes de la aplicación que se muestra a continuación:

Origen (Casos de uso asociados). Relación con otros requerimientos. Relación con otros elementos (Clases, Métodos, Atributos, etc.). Pruebas unitarias.

La trazabilidad permite el por qué y cómo el desarrollo del sistema satisface los requerimientos de los stakeholders. [7]

26

pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1410IS08/Final/Anexo 3. … · Web viewpegasus.javeriana.edu.co

Documents