SRS plantillas

Herramienta para la administración de requerimientos de los proyectos de las asignaturas de Ingeniería de Software y Arquitectura de Software de la Pontificia Universidad Javeriana

HISTORIAL DE CAMBIOS

FECHA VERSIÓN

DESCRIPCIÓN RESPONSABLE

12-10-10 1.0 Secciones 1,2 Vanesa Carolina Loaiza, Laura Catalina Zorro

13-10-10 1,1 Secciones 3.1 y 3.2 Vanesa Carolina Loaiza, Laura Catalina Zorro

23-10-10 1.2 Secciones 3.3 , 3.4 y 3.5

Vanesa Carolina Loaiza, Laura Catalina Zorro

25-10-10 1.3 Sección 3.1.1. 2.5 Vanesa Carolina Loaiza, Laura Catalina Zorro

31-10-10 1.4 Sección 3.6 Vanesa Carolina Loaiza, Laura Catalina Zorro

01-11-10 1.5 Correcciones varias Vanesa Carolina Loaiza, Laura Catalina Zorro

16-11-10 1.6 Correcciones Interfaces Externas


30-11-10 1.7 Actualización de tablas de requerimientos








2





Tabla 1: Historial de cambios

3

TABLA DE CONTENIDOHISTORIAL DE CAMBIOS.....................................................................................................................2TABLA DE CONTENIDO.......................................................................................................................3ÍNDICE DE TABLAS..............................................................................................................................51. INTRODUCCIÓN..........................................................................................................................6

1.1. Propósito............................................................................................................................61.2. Alcance...............................................................................................................................61.3. Definiciones, acrónimos y abreviaciones............................................................................71.4. Referencias.........................................................................................................................71.5. Apreciación global..............................................................................................................9

2. DESCRIPCIÓN GLOBAL..............................................................................................................112.1. Perspectiva del producto..................................................................................................11

2.1.1. Interfaces con el Sistema..........................................................................................112.1.2. Interfaces con el Usuario.........................................................................................112.1.3. Interfaces con el Hardware......................................................................................122.1.4. Interfaces con el Software.......................................................................................122.1.5. Interfaces de comunicación......................................................................................132.1.6. Restricciones de Memoria........................................................................................132.1.7. Operaciones..............................................................................................................142.1.8. Requerimientos de Adaptación del Sitio...................................................................14

2.2. Funciones del producto....................................................................................................142.3. Características del Usuario...............................................................................................152.4. Restricciones....................................................................................................................172.5. Modelo del Dominio.........................................................................................................172.6. Suposiciones y Dependencias...........................................................................................17

2.6.1. Suposiciones.............................................................................................................172.6.2. Dependencias...........................................................................................................18

2.7. Distribución de Requerimientos.......................................................................................182.7.1. Distribución de los requerimientos Funcionales.......................................................182.7.2. Distribución de los Requerimientos No Funcionales................................................20

2.8. Trazabilidad y Localización...............................................................................................212.9. Priorización de Requerimientos.......................................................................................222.10. Relación entre Requerimientos....................................................................................24

3. REQUERIMIENTOS ESPECÍFICOS...............................................................................................253.1. Requerimientos de Interfaces Externas............................................................................26

3.1.1. Interfaces con el Usuario..........................................................................................263.1.2. Interfaces con el Hardware.......................................................................................263.1.3. Interfaces con el Software........................................................................................263.1.4. Interfaces de Comunicación.....................................................................................26

3.2. Características del Producto de Software.........................................................................27

4

3.2.1. Atributos y Clasificación...........................................................................................273.2.2. Administración del Cambio.......................................................................................273.2.3. Priorización...............................................................................................................273.2.4. Localización y trazabilidad........................................................................................273.2.5. V&V..........................................................................................................................273.2.6. Visualización y reportes............................................................................................273.2.7. Proyecto...................................................................................................................27

3.3. Requerimientos de Desempeño.......................................................................................283.4. Restricciones de Diseño....................................................................................................283.5. Atributos del Sistema.......................................................................................................29

3.5.1. Confiabilidad.............................................................................................................293.5.2. Disponibilidad...........................................................................................................293.5.3. Usabilidad.................................................................................................................293.5.4. Mantenibilidad.........................................................................................................293.5.5. Portabilidad..............................................................................................................303.5.6. Funcionalidad...........................................................................................................30

3.6. Requerimientos de la Base de Datos................................................................................304. ANEXOS....................................................................................................................................31

4.1. Anexo 1: Tabla de priorización.........................................................................................314.2. Anexo 2: Relaciones entre los requerimientos.................................................................314.3. Anexo 3: Grafo de implementación..................................................................................314.4. Anexo 4: Modelo del dominio..........................................................................................31

5

ÍNDICE DE TABLAS

TABLA 1: HISTORIAL DE CAMBIOS...........................................................................................2TABLA 2: DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES..............................................................7TABLA 3. INTERFACES CON EL SOFTWARE..............................................................................13TABLA 4: RESTRICCIONES DE MEMORIA..................................................................................13TABLA 5: CASOS DE USO....................................................................................................15TABLA 6. USUARIOS...........................................................................................................16TABLA 7. TRAZABILIDAD Y LOCALIZACIÓN...............................................................................21TABLA 8: PLANTILLA DE ESPECIFICACIÓN DE REQUERIMIENTOS. TOMADO DE [13][14]....................26TABLA 30. RESTRICCIONES DE DISEÑO..................................................................................29

6

1. INTRODUCCIÓN

1.1. Propósito

El objetivo de éste documento es proporcionar una guía de desarrollo [1] para el grupo de trabajo, además de una descripción detallada del sistema de administración de requerimientos que se quiere implementar. Esta especificación está conformada por una definición y descripción del software con relación a las necesidades que se quieren suplir, es decir los requerimientos funcionales y no funcionales.

Adicional a la especificación de los requerimientos, este documento delimita el sistema a los recursos que se poseen, es decir que tiene en cuenta las restricciones que intervienen en el desarrollo del proyecto y las interfaces con otros sistemas a manejar.

1.2. Alcance

Este documento describe de manera detallada los requerimientos de la herramienta ERMT, la cual será desarrollada como Trabajo de Grado de las estudiantes Vanesa Carolina Loaiza y Laura Catalina Zorro, y está dirigida a los estudiantes y profesores de las asignaturas de IS y AS de la Pontificia Universidad Javeriana.

La Herramienta tiene como objetivo agilizar el proceso de administración de requerimientos en los proyectos de las asignaturas IS y AS, por medio de las funcionalidades que se describen a continuación.

Las funcionalidades que estarán disponibles en la herramienta son:

- Administración de los atributos de un requerimiento.

- Administración del cambio en los requerimientos.

- Clasificación los requerimientos.

- Priorización de los requerimientos.

- Localización de los requerimientos.

- Trazabilidad de los requerimientos.

- Validación y Verificación de los requerimientos.

- Visualización de requerimientos.

- Generación de reportes.

7

Es importante resaltar, que para la administración del cambio, solo será almacenado el porqué del cambio y se actualizara la versión del requerimiento, esta funcionalidad no almacenara el historial en donde se encuentren las versiones anteriores del requerimiento, además el procesos de verificación y validación será apoyado a través de listas de comprobación.

1.3. Definiciones, acrónimos y abreviaciones

CONCEPTO DESCRIPCIÓN

AS Arquitectura de Software

IS Ingenierías de Software

ERMT Hace referencia a las iniciales del Nombre designado para la herramienta, el cual es: Easy Requirement Management Tool.

JavaDoc Es una herramienta que permite generar la documentación del código Java [15]

Stand Alone Es un sistema el cual no depende de otros sistemas para su funcionamiento [7].

Tabla 2: Definiciones, acrónimos y abreviaciones

1.4. Referencias

[1]. Thayer Richard, Dorfman Merlin. SOFTWARE REQUIREMENTS ENGINEERING. Segunda

Edición. Los Alamitos, California. Estados Unidos: IEEE COMPUTER SOCIETY, 2000.

[2]. Microsoft, disponible en: http://www.microsoft.com/about/default.mspx. [Última

consulta: Septiembre 30 de 2010]

[3]. JVM, disponible en: http://java.sun.com/javase/6/docs/technotes/guides/vm/index.html?

intcmp=3170 [Última consulta: Septiembre 30 de 2010]

8

http://www.microsoft.com/about/default.mspx

[4]. JDBC, disponible en: http://java.sun.com/products/jdbc/overview.html [Última consulta:

Septiembre 30 de 2010]

[5]. Generadores de reportes, disponible en: http://www.adobe.com/es/products/reader/

[Última consulta: Septiembre 30 de 2010]

[6]. Laboratorios Ingeniería de sistemas. [Homepage] Disponible en: http://puj-

portal.javeriana.edu.co/portal/page/portal/Facultad%20de%20Ingenieria/plt_dpto_sistemas/

Laboratorios [Última consulta: Septiembre 30 de 2010]

[7]. About.com. Stand Alone Software, Definition. [Homepage en Internet]. Disponible en:

http://financialsoft.about.com/od/glossaryindexs/g/StandAlone.htm. [Última Fecha de consulta:

Octubre 4 de 2010].

[8]. IEEE std. 830-1998. IEEE recomended practice for software requirements specifications,

IEEE, 1998.

[9]. JavaDocx. [Homepage en Internet]. Disponible en http://www.javadocx.com/. [Última

Fecha de consulta: Noviembre 16 de 2010].

[10]. ISO 9126. [Documento en Internet] Disponible en:

http://www.cis.gsu.edu/~ghubona/cis8300/ISO9126.pdf [Ultima consulta: Septiembre 23 de

2010].

[11]. IEEE std. 830-1998. IEEE recomended practice for software requirements specifications,

IEEE, 1998Wiegers, Karl. FIRST THING FIRST; PRIORITIZING REQUIREMENTS. Process Impact,

Disponible en: http://www.processimpact.com/articles/prioritizing.html. [Última Fecha de

Consulta: Octubre. 12 de 2010].

[12]. Berander, P. Andrews, A. Engineering and Managing Software Requirements. [Libro en

Internet]. Springer Berlin Heidelberg. 2005. Pg. 69-94. [Fecha de consulta: Octubre 12 de 2010].

[13]. Buitrago M, Cáceres D, Loaiza C, Medina O, Muños R, Tenjo J. SRS: Pirate Risk. Versión 3.2.

9

http://puj-portal.javeriana.edu.co/portal/page/portal/Facultad%20de%20Ingenieria/plt_dpto_sistemas/Laboratorios



http://www.adobe.com/es/products/reader/

http://java.sun.com/products/jdbc/overview.html

[14]. González A, Jaramillo C, Narváez M, Oquendo T, Villalobos V, Zorro L. Demented Movie

Game. Especificación de Requerimientos de Software. Versión 4.1

[15]. JAVADOC Documentation Tool. [Homepage en Internet]. Disponible en:

http://www.oracle.com/technetwork/java/javase/documentation/index-jsp-135444.html. [Última

Fecha de consulta: Octubre 25 de 2010]

[16]. Graphviz - Graph Visualization Software. [Homepage en Internet]. Disponible en:

http://www.graphviz.org/About.php. [Última Fecha de consulta: Octubre 26 de 2010]

[17]. Loaiza C, Zorro L. 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,

Marco Teórico.

[18]. Marquez, Mercedes. Ventajas y desventajas sobre la base de datos. [Homepage].

Disponible en: http://www3.uji.es/~mmarques/f47/apun/node7.html [ültima fecha de consulta:

Octubre 31 de 2010].

[19]. Carreño, Julio. SQL/PM y PL. Presentación 1: Store Procedures[Presentación de clase].

[20]. MySQL: Información general. [Homepage]. Disponible en:

http://dev.mysql.com/doc/refman/5.0/es/introduction.html [Última fecha de consulta: Octubre

31 de 2010].

1.5. Apreciación global

Este documento se organiza en cuatro partes principales, las cuales tienen como objetivo dar a conocer los aspectos más importantes del desarrollo de la herramienta, y establecer un entendimiento común entre los Stakeholders del proyecto.

Primera parte – Introducción (ver Sección 1)

o esta sección se encarga de presentarle al lector cuales son las razones por las

cuales se desarrolla el documento, cual es el propósito y el alcance de la

10

herramienta a desarrollar y finalmente para generar el contexto adecuado, las

definiciones de los términos y abreviaciones utilizadas en el documento.

Segunda Parte – Descripción Global (ver Sección 2)

o Esta sección se encarga de especificar los aspectos directamente relacionados con

el software en desarrollo, mostrando las diferentes interfaces con las que la

herramienta interactuará para lograr un rendimiento óptimo.

Tercera Parte – Requerimientos Específicos (ver Sección 3)

o En esta sección se encuentra la unidad que representa la mayor importancia en

este documento debido a que se especifican de manera detallada los

requerimientos funcionales y no funcionales que debe suplir la herramienta para

cumplir con las necesidades expuestas por los clientes.

Cuarta Parte – Métricas de los requerimientos (ver Sección 4)

o Finalmente esta sección explica las métricas que se van a aplicar sobre los

requerimientos.

11

2. DESCRIPCIÓN GLOBAL

2.1. Perspectiva del producto

Ver Sección 4.1 Perspectiva del producto del documento de Visión

2.1.1. Interfaces con el Sistema

ERMT, como ya fue descrito en la sección 1.2 Alcance, tiene como objetivo agilizar el proceso de administración de requerimientos, para lo cual es necesario que dentro de las funcionalidades se encuentre la generación de reportes. Es por esto que la herramienta debe interactuar con procesadores de texto, los cuales permitirán la generación de los reportes.

12

2.1.2. Interfaces con el Usuario

La herramienta ERMT, tendrá diferentes interfaces con el usuario, la cual se enumera según el hardware utilizado. Entre los dispositivos necesarios para el producto se tienen:

Ilustración 1: Interfaces con el usuario

2.1.3. Interfaces con el Hardware

Debido a que la Herramienta ERMT será una aplicación Stand Alone, esta no contará con ningún tipo de interacción con elementos de hardware.

2.1.4. Interfaces con el Software

Las interfaces con el software, son las diferentes aplicaciones que interactúan con la herramienta ERMT para poder cumplir con las necesidades del usuario. En la Tabla 3 se describen cada uno de los productos que deberán interactuar con el sistema.

TECLADOSe utiliza para la entrada de datos al sistema por parte del usuarios, relacionados con los requerimientos y su información detallada.

MOUSESe utiliza para la entrada de instrucciones dentro de un entorno gráfico facilitando al usuario su desenvolvimiento dentro del sistema.

PANTALLASe utiliza para mostrar información como los resultados por parte del sistema, ya que a través de la pantalla el usuario, con ayuda de la GUI, el usuario puede desarrollar las diferentes tareas y ver los resultados de sus peticiones en resumen, es el principal medio de comunicación del sistema con el usuario.

13

Producto de

Software

Descripción Propósito de Uso Versión Fuente

Windows Sistema operativo desarrollado por Microsoft, basado en Windows NT,

Es el sistema operativo sobre el cual se desarrollara y ejecutará el sistema.

Windows XP Professional SP 2 o Superior

Microsoft Corporation.[2]

JVM Máquina virtual de Java, se encarga de traducir lenguaje de alto nivel a lenguaje binario

Puesto que el lenguaje de programación que se usará para el desarrollo de la aplicación, que es Java, no es un lenguaje de bajo nivel o de máquina es necesario usar un intérprete que permita la correcta ejecución de estas instrucciones.

Java SE 6 Sun Microsystems [3]

JDBCJava Database Connectivity, es una API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java, emplea el lenguaje de query SQL.

Proporciona un acceso confiable a los datos de las bases de datos SQL, debido a que la aplicación requiere realizar operaciones de consulta y actualización en la base de datos.

4.0Sun Microsystems, Inc. [4]

GraphViz Software de código libre para la visualización de grafos [16].

Es una herramienta que permite la generación de grafos.

2.26 Graphviz[16]

MySQL Software que proporciona un servidor de base de datos SQL (Structured Query Language) muy rápido, multi-threaded, multi usuario y robusto. [20]

Se utiliza para la gestión de los datos dentro de una base de datos relacional

5.1.41 MySQL [20]

14

Tabla 3. Interfaces con el Software

2.1.5. Interfaces de comunicación

La única comunicación que se mantendrá, es la que se establece entre el procesador de texto de Microsoft Office conocido como Word y la herramienta, para lo cual se utilizará la librería Javadox [9] la cual permite la interacción entre el lenguaje de programación Java y Microsoft Office.

2.1.6. Restricciones de Memoria

Para asegurar el buen funcionamiento de la herramienta ERMT, se necesita que los equipos donde se ejecutará la aplicación, cumplan con los requerimientos mínimos de memoria que se encuentran enumerados en la Tabla 4.

Programa Disco Duro Memoria Ram

Maquina virtual java JRE 1.6 600 MB 64 MB

NetBeans IDE 6.7 750 MB 512 MB

Tortoise SVN 40 MB 512 MB

Windows XP 1.5 GB 128 MB

MySQL 4 GB 512 MBTabla 4: Restricciones de memoria

2.1.7. 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.

15

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.

2.1.8. Requerimientos 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 [6]:

Disco Duro: 120 GB. Memoria RAM (Principal): 2 GB. Procesador: Intel Core2 Dúo @2.40 GHz. Resolución de pantalla: 1600 X 900 pixeles. Sistema Operativo: Windows XP o superior. Java Virtual Machine 1.6. JDK versión: 1.6.0_14.

2.2. Funciones del producto

En la Tabla 5, se muestra los casos de uso que representan las funcionalidades del sistema:

Identificador NombreCU01 Actualizar control de cambiosCU02 Actualizar relaciones entre requerimientosCU03 Actualizar requerimientoCU04 Actualizar valor atributosCU05 Actualizar valores de lista V&VCU06 Actualizar valores de localizaciónCU07 Actualizar valores de priorizaciónCU08 Actualizar valores de trazabilidadCU09 Calcular grafoCU10 Calcular valor de priorización totalCU11 Clasificar requerimientoCU12 Consulta atributos plantillaCU13 Consultar CambiosCU14 Consultar estado requerimientoCU15 Consultar estado totalCU16 Consultar grafoCU17 Consultar lista de priorizaciónCU18 Consultar lista de V&V

16

CU19 Consulta localización CU20 Consultar requerimientosCU21 Consultar requerimientos clasificadosCU22 Consultar requerimientos rechazadosCU23 Consultar trazabilidadCU24 Consultar valore de atributosCU25 Crear requerimientoCU26 Eliminar requerimientoCU27 Generar reportes en WordCU28 Reanudar o rechazar requerimientoCU29 Seleccionar atributosCU30 Seleccionar métodos de priorizaciónCU31 Generar reportes en ExcelCU32 Crear ProyectoCU33 Eliminar ProyectoCU34 Abrir ProyectoCU34 Modificar Proyecto

Tabla 5: Casos de uso

Para más información Ver el documento de casos de uso anexo, Documento de CU.docx.

2.3. Características del Usuario

Los usuarios finales de ERMT son los que se describen a continuación:

Nombre Descripción

Profesor Hace referencia a los encargados de impartir las materias de IS y AS en la pontificia universidad Javeriana. Este tipo de usuarios se divide en:

- Profesores de Ingeniería de Software- Profesores de Arquitectura de Software

Su interacción con ERMT se limita a la generación y revisión de los reportes de los requerimientos. Para mayor información ver Documento Vision.docx Sección 3.3 Resumen

17

de Usuario

Estudiante Hace referencia a las personas que cursan las materias de IS y AS, las cuales deben llevar a cabo la especificación de requerimientos de software del proyecto que se debe desarrollar en cada una. Al igual que el usuario profesor, este se divide en :

- Estudiante de Ingeniería de Software.- Estudiante de Arquitectura de Software

(Para mayor información ver Documento Vision.docx Sección 3.3 Resumen de Usuario).

Este tipo de usuario es considerado como el usuario principal de la herramienta, ya que es el, quien hará uso de las funciones descritas en la sección 2.2 Funciones del producto.

Tabla 6. Usuarios

Para poder hacer uso de la herramienta, los usuarios, descritos en la Tabla 6. Usuarios, deben contar con las siguientes características y conocimientos básicos para hacer un buen uso de esta.

- Experiencia Técnica: El usuario debe contar con conocimientos básicos de computación

- Conocimientos Académicos: El usuario debe estar cursando o haber cursado la asignatura

Ingeniería de Software, esto con el fin de que este tenga claros conceptos como por

ejemplo que es un requerimiento, que es localización y trazabilidad, verificación y

validación.

- Privilegios: El usuario podrá utilizar todas las funcionalidades descritas en los casos de uso

listados en la sección 2.2 Funciones del Producto.

2.4. Restricciones

A continuación se presentan las restricciones de la herramienta de administración de requerimientos.

RESTRICCIONES GENERALES

18

o Restricción de Idioma: El idioma español ha sido seleccionado para toda la

documentación relacionada con el desarrollo y los manuales de la Herramienta

ERMT.

RESTRICCIONES DE SOFTWARE

o Restricción de licencia: Los programas necesarios para el desarrollo de ERMT

contaran con el esquema de licencia libre.

o Restricción de maquina virtual: Cada equipo donde se desee correr la aplicación

deberá contar con Java Virtual Machine (JVM)

o Restricción de lenguajes de programación: el lenguaje seleccionado para el

desarrollo de la parte de persistencia de bases de datos y la parte lógica será JAVA.

RESTRICCIONES DE HARDWARE

o Teniendo en cuenta las maquinas donde deberá correr la aplicación, las

restricciones de hardware se encuentran descritas en la sección 2.1.8

(Requerimientos de Adaptación del Sitio).

2.5. Modelo del Dominio

Para ver toda la información relacionada con el diagrama del modelo del dominio y el detalle de cada elemento ir al Anexo 4

2.6. Suposiciones y Dependencias

2.6.1. Suposiciones

Los usuarios finales deben cumplir con las características descritas en la sección 2.3

Características del Usuario.

Las Estudiantes Vanesa Carolina Loaiza y Laura Catalina Zorro, cuentan con los

conocimientos técnicos necesarios para realizar la implementación de la herramienta.

El cliente, en este caso los profesores Miguel Eduardo Torres y Jamir Ávila tienen la

disponibilidad de tiempo suficiente para solucionar cualquier duda referente al

proyecto.

El cliente no realizará cambios significativos en los requerimientos.

Para más suposiciones ver Sección 4.3.1 Suposiciones en el documento de Visión.

19

2.6.2. Dependencias

Para el correcto funcionamiento de la herramienta, es adecuado que se cumplan los

requerimientos descritos en la sección 3.1 Requerimientos de Interfaces Externas.

Los usuarios finales utilizaran la aplicación en equipos que cuentan con las

características de hardware, software mínimas descritas en la sección 2.3

Restricciones.

Para más suposiciones ver Sección 4.3.2 Dependencias en el documento de Visión.

2.7. Distribución de Requerimientos

Para realizar la distribución de los requerimientos de manera más detallada, es necesario dividirlos en dos tipos, los requerimientos funcionales y los requerimientos no funcionales. Una vez distribuidos de esta manera, es necesario definir las sub categorías de estos requerimientos, es por esto que se han definido las secciones 2.7.1 Distribución de los Requerimientos Funcionales y 2.7.2 Distribución de los Requerimientos No Funcionales.

2.7.1. Distribución de los requerimientos Funcionales

La distribución de los Requerimientos Funcionales de la herramienta se agrupan en seis categorías (ver Ilustración 2) principales que son: “Atributos y Clasificación”, “Administración de Cambios”, “Priorización”, “Localización y Trazabilidad”, “Validación y Verificación” y “Visualización y Reportes”, para ver los requerimientos pertenecientes a estas categorías dirigirse a la Sección 3.2 Características del Producto de Software.

20

Ilustración 2. Distribución de Requerimientos Funcionales.

La Ilustración 2 muestra la clasificación de los requerimientos funcionales, mencionada anteriormente en donde:

- Atributos y Clasificación: Esta categoría comprende los requerimientos que describen las

funcionalidades que permiten clasificar los requerimientos y asignar los atributos que

estarán disponibles en la especificación.

- Administración de Cambios: contiene los requerimientos que describen a cabalidad las

funciones que se deben llevar a cabo para la administración de cambios en los

requerimientos.

- Priorización: Hace referencia a los requerimientos concernientes a la priorización de los

requerimientos.

- Localización y Trazabilidad: Esta categoría hace referencia a los requerimientos que

permitirán que la herramienta soporte los procesos de localización y trazabilidad de los

requerimientos.

Requerimientos

Funcionales

Atributos y Clasificación

Administración de Cambios

Priorización

Localización y Trazabilidad

Validación y Verificación

Visualización y Reportes

Proyecto

21

- Validación y Verificación: contiene los requerimientos relacionados con la verificación y

validación de requerimientos.

- Visualización y Reportes: esta contiene los requerimientos que hacen referencia a los

reportes que debe generar la herramienta, y a la visualización que permita obtener

conclusiones acerca del estado de implementación del proyecto.

- Proyecto: Contiene los requerimientos relacionados con el manejo del proyecto en

general.

2.7.2. Distribución de los Requerimientos No Funcionales

La ilustración 3, muestra como se distribuyen los requerimientos no Funcionales, teniendo en cuenta el ISO 9126, el cual se encarga de definir estas categorías como las características básicas para la calidad de software [10]. Para más información ver documento Marco Teórico.

Ilustración 3. Distribución de los Requerimientos No Funcionales.

La Ilustración 3 muestra la distribución que será utilizada para definir los requerimientos no funcionales de la herramienta, dentro de los cuales se encuentran:

- Confiabilidad: esta categoría permite especificar los requerimientos relacionados con la

administración de los fallos en los que puede incurrir el sistema [10].

Requerimientos No

Funcionales

Confiabilidad

Disponibilidad

Usabilidad

Mantenibilidad

Portabilidad

Funcionalidad

22

- Disponibilidad: Estos requerimientos hacen referencia a la “capacidad que debe tener el

sistema, para mantener un nivel de rendimiento bajo las condiciones como velocidad, uso

de memoria, precisión” [17].

- Usabilidad: en esta categoría se encontrarán los requerimientos asociados a la “capacidad

que debe tener el sistema de ser comprendido, aprendido y usable bajo las condiciones de

uso estipuladas en los requerimientos del sistema” [17].

- Mantenibilidad: estos requerimientos están asociados a la capacidad que tendrá el

sistema de ser modificado, ya sea para actualizar el sistema, ó incluir correcciones [17].

- Portabilidad: estos requerimientos reflejan “la capacidad del sistema de cambiar de un

ambiente a otro. El ambiente puede ser organizacional, de hardware o software” [17].

- Funcionalidad: esta categoría “hace referencia a los requerimientos que proveen la

capacidad para que el sistema provea las funciones descritas con los requerimientos

funcionales” [17].

2.8. Trazabilidad y Localización

Con el fin de seguir el ciclo de vida del requerimiento, de tal manera que se pueda justificar y verificar el estado de implementación del proyecto, se ha definido la Tabla 7 de trazabilidad y localización , la cual contiene el origen y las referencias a los demás artefactos del proyecto en donde se encontrará el requerimiento.

ID Fuente del Requerimiento

Razón de ser

Caso de uso

SRS SAD Componente Documento de Pruebas

Manual

Tabla 7. Trazabilidad y Localización

En la Ilustración 4 se encuentra una descripción breve de cada campo que compone la tabla de trazabilidad:

23

Ilustración 4. Explicación ítems de Trazabilidad. Adaptado de [13][14].

2.9. Priorización de Requerimientos

Para saber lo “esencial”, se requiere organizar los requerimientos de tal forma que se tenga un conjunto de requerimientos indispensables dentro del producto [13]. Para esto se realiza un proceso de priorización de requerimientos que permita saber en qué orden implementar.

La priorización que se quiere usar es una adaptación del modelo de Wiegers [12], el cual solo tiene en cuenta dos valores el costo y el beneficio para poder obtener la priorización. Esto se debe a que en este proceso solo se tomará en cuenta el criterio del grupo de trabajo, omitiendo las variables relacionadas con el usuario final.

La relación de las variables se muestra en la Ilustración 5:Identificador único del requerimiento.

I D

Hace referencia al origen del requerimiento.

F u e n t e d e l R e q u e r i m i e n t o

Muestra la razon del porque el requerimiento fue especificado.

R a z ó n d e S e r

Caso de uso relacionado con el requerimiento.

C a s o d e U s o

Sección del documento de especificacion en donde se encentra el requerimiento.

S R S

Sección del documento de diseño en el cual se encuentra el requerimiento

S A D

Componente, clase o método del codigo de implementación en donde se encuentra el requerimiento

C o m p o n e n t e

Sección del documento en donde se encontrará el requerimiento.

D o c u m e n t o d e P r u e b a s

Sección del manual de usuario en donde se encontrará el requerimiento.

M a n u a l

24

Ilustración 5: Relación costo-beneficio

Estos dos ítems son fundamentales dentro del desarrollo de software porque afectan directamente al desarrollo del sistema.

BENEFICIO: Es el valor que tiene el requerimiento para el cliente, cuanto cree que le

beneficia el requerimiento si éste se encuentra aplicado dentro del sistema [12]. El grupo

de trabajo tomó por un momento el rol de cliente para poder llevar a cabo este proceso

de priorización.

COSTO: Este costo se refiere al esfuerzo que incurre para llevar a cabo el requerimiento en

su totalidad [12], esto incluye desde la definición hasta su validación en la fase de pruebas.

Para llevar a cabo el proceso, es necesario seguir los siguientes pasos:

1. Según el criterio del grupo de desarrollo, se le debe asignar el peso que debe tener cada una de las variables dentro del proyecto.

2. Calificar cada requerimiento, teniendo en cuenta el criterio que se está calificando(Costo y Beneficio).

3. Calcular el porcentaje del valor asignado por los integrantes del grupo a cada requerimiento.

4. Tomando la formula de la ilustración 4. Se calcula el valor de prioridad de cada requerimiento.

Para ver la tabla resultante de la priorización diríjase al Anexo 1.

Beneficio

Costo

Valor%(%Costo∗PesoCosto)

25

2.10. Relación entre Requerimientos

La relación entre los requerimientos es muy importante ya que permite organizarlos de tal manera que se puedan observar las dependencias entre ellos y así, teniendo en cuenta la priorización, establecer un orden de desarrollo y evitar contratiempos. La organización del sistema en componentes funcionales del sistema es realizada, en parte, gracias a la agrupación de los requerimientos en módulos, los cuales se obtienen de las relaciones entre los requerimientos.

Para ver la tabla de relaciones entre los requerimientos ver Anexo 2 y para ver el grafo de implementación resultante ver Anexo 3.

26

3. REQUERIMIENTOS ESPECÍFICOS

En esta sección se detallaran cada uno de los requerimientos, en la Tabla 8 se muestra como está organizada la plantilla y que significa cada campo. La organización en que serán presentados los requerimientos funcionales se presenta en la sección 2.7 Distribución de requerimientos.

La tabla que se va a manejar para presentar los requerimientos es la siguiente:

Identificador: Identificación única del requerimiento dentro del documento SRS.

Prioridad: Es la importancia otorgada por el grupo para manejar el orden de implementación. En la sección 2.9 Priorización de Requerimientos se encuentra expuesto el método que se usa para llevar a cabo este proceso.

definición Especific. diseño Implem. pruebas

Estado En donde se encuentra en este momento el requerimiento, en fase se encuentra, cuando ha finalizado

Versión: Versión de modificación de la especificación del requerimiento

Fecha última modificación

Fecha en que se modificó por última vez, el requerimiento

responsable de modificación

Responsable de la última modificación del requerimiento.

Dueño: Encargado de supervisar y ayudar a implementar ese requerimiento

Costo Promedio Valor asociado al esfuerzo incurrido para llevar a cabo este requerimiento. (ver sección 2.9 Priorización de Requerimientos)

Razón de ser: Explicación del porqué el requerimiento se encuentra en el documento SRS.

27

Descripción Descripción breve del requerimiento (enunciado).

Criterios de aceptación:

Argumento con el cual se definirá después de la implementación si el requerimiento es aceptado o no.

Requerimientos asociados

Requerimientos Asociados a éste. Para realizar este ítem se elaboró una tabla donde se señala las relaciones entre los requerimientos. Ver Anexo 4

Casos de uso asociados:

Casos de uso origen del requerimiento (aplica solo para los requerimientos funcionales)

Tabla 8: Plantilla de especificación de requerimientos. Tomado de [13][14]

3.1. Requerimientos de Interfaces Externas

3.1.1. Interfaces con el Usuario

Dentro de esta sección se enuncia y se describe las diferentes interfaces que se pretenden tener en el sistema, para así obtener una interacción con el usuario y las funcionalidades del sistema. Para consultar la definición de los requerimientos de Interfaces de usuario ver el documento anexo de Excel “Plantilla de requerimientos.xlsx” en la hoja “REQUERIMIENTOS”. Para consultar la especificación de estos requerimientos, remítase a la hoja “RF” del mismo documento.

3.1.2. Interfaces con el Hardware

De acuerdo con lo descrito en la sección 2.1.4 Interfaces con el Hardware, la herramienta no cuenta con interfaces de hardware.

3.1.3. Interfaces con el Software

Conforme a lo planteado en la sección 2.1.4 Interfaces con el Software, los requerimientos de interfaces con el software se encuentran definidos bajo la etiqueta “Interfaces Software” en el documento Anexo de Excel “Plantilla de requerimientos.xlsx” en la hoja “REQUERIMIENTOS”. Para consultar la especificación de estos requerimientos, remítase a la hoja “RF” del mismo documento.

3.1.4. Interfaces de Comunicación

La única interfaz de comunicación a tener en cuenta para la implementación de la herramienta, ya fue citada en la sección 2.1.5 Interfaces de comunicación, pero esta será descrita con mayor detalle a en el documento anexo de Excel “Plantilla de requerimientos.xlsx” en la hoja

28

“REQUERIMIENTOS”. Para consultar la especificación de estos requerimientos, remítase a la hoja “RF” del mismo documento.

3.2. Características del Producto de Software

En esta sección se muestra las diferentes funcionalidades de la herramienta, que se encuentra desglosada en requerimientos, a su vez están distribuidos según su funcionalidad presentada en la sección 2.7 Distribución de Requerimientos.

3.2.1. Atributos y Clasificación

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “REQUERIMIENTOS”. Para consultar la especificación de estos requerimientos, consultar la hoja “Atributos y clasificación” del mismo documento.

3.2.2. Administración del Cambio

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “H.Cambio” del mismo documento.

3.2.3. Priorización

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “Prio” del mismo documento.

3.2.4. Localización y trazabilidad

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “Loc y Tra” del mismo documento.

29

3.2.5. V&V

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “V&V” del mismo documento.

3.2.6. Visualización y reportes

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “Gra y Rep” del mismo documento.

3.2.7. Proyecto

Para consultar la definición de los requerimientos asociados a esta categoría, ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Para consultar la especificación de estos requerimientos, consultar la hoja “Proy” del mismo documento.

3.3. Requerimientos de Desempeño

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “REQUERIMIENTOS”. Los requerimientos asociados al desempeño se encuentran especificados bajo los identificadores únicos 51, 52, 53.

3.4. Restricciones de Diseño

Las restricciones de diseño a tener en cuenta para el desarrollo de ERMT, se tienen las siguientes:

Restricción Nombre Diseño

Paradigma de Programación Orientado a Objetos Debido a la experiencia con la que cuentan las integrantes del grupo, se decidió que este será el paradigma de programación para la

30

implementación.

Lenguaje de programación Java Este lenguaje de programación fue elegido ya que el paradigma de programación que se utilizara para implementar la herramienta ERMT es el Orientado a Objetos. Además de esto en la sección 2.1.4 Interfaces con el Software, se definieron restricciones que tienen que ver con el lenguaje.

Herramientas CASE Netbeans 6.9.1 Esta será la herramienta utilizada para la implementación de la herramienta.

Enterprise Architect El cual será utilizado para la generación de los diagramas de casos de uso, modelo del dominio y las vistas de implementación, diseño, lógica y física por medio de las cuales se lleva a cabo el diseño de ERMT.

Tabla 9. Restricciones de Diseño

3.5. Atributos del Sistema

3.5.1. Confiabilidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la confiabilidad se encuentran especificados bajo los identificadores únicos 54 y 55.

31

3.5.2. Disponibilidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Disponibilidad se encuentran especificados bajo los identificadores únicos 56 y 57.

3.5.3. Usabilidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Usabilidad se encuentran especificados bajo los identificadores únicos 58, 59, 60, 61, 62.

3.5.4. Mantenibilidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Mantenibilidad se encuentran especificados bajo los identificadores únicos 63,64.

3.5.5. Portabilidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Portabilidad se encuentran especificados bajo los identificadores únicos 65,66.

3.5.6. Funcionalidad

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Funcionalidad se encuentran especificados bajo los identificadores únicos 67,68.

3.6. Requerimientos de la Base de Datos

Para llevar a cabo la persistencia del sistema, el grupo de proyecto ha escogido utilizar bases de datos relacionales debido a que tiene muchas ventajas como la

o Robustez.o Portabilidad.o Garantiza la no redundancia de registros

32

o La integridad referencial, que en el caso de la herramienta ERMT es muy importante dado que se posee una fuerte relación entre el requerimiento con sus demás características

o Una base de datos relacional puede ayudar a ejecutar consultas desde la capa de datos, así mejorar el desempeño de la aplicación, en la generación de algunas consultas.[19]

Mientras que con archivos planos o XML, la mantenibilidad y gestión de los datos es mas complicada en el momento del desarrollo. Además, no garantiza totalmente la seguridad de los datos ya que si un archivo es modificado, la integridad puede verse cuestionada [18].

Ver documento de Excel Anexo “Plantilla de requerimientos.xlsx” en la hoja “ESPECIFICACIÓN DE REQUERIMIENTO”. Los requerimientos asociados a la Funcionalidad se encuentran especificados bajo el identificador únicos 69, 84, 85, 86, 87, 88, 89, 90 y 91.

33

4. ANEXOS

4.1. Anexo 1: Tabla de priorización

VER DOCUMENTO DE EXCEL ANEXO “Plantilla de requerimientos.XLSX” pestaña PRIORIZACION (NO TOCAR)

4.2. Anexo 2: Relaciones entre los requerimientos

VER DOCUMENTO DE EXCEL ANEXO “Plantilla de requerimientos.XLSX” pestaña Asocia. Requerimientos

4.3. Anexo 3: Grafo de implementación

VER IMAGEN ANEXA “Grafo de Implementación.PNG”

4.4. Anexo 4: Modelo del dominio

VER DOCUMENTO DE WORD ANEXO “Documentación Modelo del Dominio.docx”

34

SRS plantillas

Documents

Transcript of SRS plantillas