<ingeniería de Requisitos (IR)A nivel de tiempo-espacio-sociedad uno de los principales problemas que enfrenta la Ingeniería de Software es una definición errada de lo que se debe de construir."Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difícil de rectificar a posteriori... F. P. Brooks, 1987" F. P. Brooks es el autor de “The Mythical Man-Month”, quizá el único libro “clásico” de la Ingeniería del Software (Addison-Wesley, 1975). Brooks fue jefe de proyecto del OS/360, el sistema operativo del IBM/360. A lo largo de este enorme proyecto, Brooks padeció todos

los males que constituyren lo que habitualmente se conoce como “crisis del software”. Y ¿Qué podemos hacer? Pues, no se ha encontrado solución universalmente válida, hay serias dudas acerca de si dicha solución existe, nos movemos en la frontera socio-técnica de los sistemas: borrosa, voluble e inconsistente. Debemos reconocer que los requisitos poseen vida y situaciones propias, son dinámicos y se mueven según interés de los interesados.

Para remediar en lo posible esta situación, surge la Ingeniería de Requisitos (IR). Según[Leite89] "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos". Otro concepto de la IR sería, "Trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora propias de las necesidades de los clientes, de forma sistemática y repetible. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta, completa y no ambigua. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos".

Desde los años 50 hasta la fecha, la tasa de proyectos de ingeniería de software ha disminuido, aunque no lo suficiente ¿Por qué?

Debemos comprender que si no se entiende el problema no podremos realizar una solución. En este artículo descubriremos pasos a seguir para aplicar una correcta IR, respondiendo preguntas como. ¿Qué?: Los diferentes niveles y tipos de requisitos que deben definirse

¿Por qué?: Los beneficios de tener los requisitos de software correctos

¿Quién?: Las partes interesadas en los requisitos de software

¿Cuándo?: Requisitos de las actividades durante todo el ciclo de desarrollo de software

¿Cómo?: Técnicas que permitan deducir, analizar, especificar y validar el software requisitos

¿Qué son los requisitos?

Veamos este concepto que ofrece Jackson & Zave: Todo problema sw. consiste en configurar una máquina para que ejerza unos efectos R en un dominio K. La conexión se realiza a través de una interfaz S. Los efectos R son los requisitos: Necesidades, metas, objetivos 

El conocimiento del dominio K describe el contexto.

La máquina (hw+sw) es la que realizará los requisitos R, gracias a S, que describe la conexión con el dominio K.

En la fase de requisitos tan sólo necesitamos K, S y R. No necesitamos describir el comportamiento interno de la máquina

Idealmente: K y S => R

R: NO son realidades, pero serán realidades cuando construyamos el sistema.K: Describe realidades. Afirmaciones cuya verdad es independiente de la existencia, o no, del sistema.S: Describe comportamiento externo del sistema (interfaz)

Aplicamos un ejemplo para entender el concepto. Sistema de control de una caldera de vapor:

K: “el agua entra en ebullición a 100 Grados Centígrados y a 1 atm. de presión”

R: “El sistema evitará que el agua entre en ebullición”

S: “El sistema leerá la temperatura del agua por medio del sensor S342”, “El sistema podrá subir la temperatura del agua por medio del regulador R452”

Propiamente hablando tan sólo R son “requisitos”, pero a la Ingeniería de Requisitos le interesan también K y S, pues todas son necesarias.

Pero K, S y R no son suficientes...

Debemos de considerar que existe información importante, no sólo del tipo que debe de hacer el software sino necesidades adyacentes no visibles en muchos casos. Estos otros datos de la información acerca del problema a solucionar como propiedades y comportamiento del sistema, restricciones de diseño y fabricación del producto, descripciones acerca de cómo el futuro sistema ayudará a sus usuarios a realizar mejor sus tareas, restricciones acerca de la tecnología que será utilizada en la construcción del sistema (protocolos, SSOO, COTS, etc.), restricciones acerca de las propiedades emergentes del sistema (requisitos no funcionales).

Un concepto importante es que el “qué” de una persona es el “cómo” de otra. Por ejemplo: Qué: minimizar el número de personas que circulan por las escaleras

Cómo: Instalando un ascensor.

PERO para la empresa instaladora de ascensores, instalar un ascensor es un qué, no un cómo. El cómo del ascensorista es, ¿qué herramientas utilizo?, ¿qué proceso sigo? ¿qué medidas de seguridad aplicar?

En su artículo "Software Requirements Engineering: What, Why, Who, When, and How", Linda Westfall nos ofrece unos niveles y tipos de requisitos:

Niveles y tipos de requisitos

Por ejemplo, el requisito de negocio para permitir que el cliente pague en el grifo su consumo podría traducirse en múltiples necesidades de los usuarios, incluidos los requisitos para que el usuario: Pase de crédito o débito

Introduzca un número de PIN de seguridad

Solicite un recibo en el grifo

Los requisitos funcionales del producto, que definen la funcionalidad del software debe ser construido en el producto para que los usuarios puedan realizar sus tareas, respondiendo así a los requisitos de las empresas. Múltiples requisitos de nivel funcional pueden ser necesarios para cumplir con un requisito de un usuario. Por ejemplo, los requisitos que los usuarios puedan pasar su tarjeta de crédito podría traducirse en múltiples requerimientos funcionales como requisitos para el software: Preguntar al cliente poner su tarjeta en el lector

Detectar que la tarjeta haya sido pasada

Determine si la tarjeta se lee correctamente y rápido que el cliente pase la tarjeta de nuevo

Analizar la información de la banda magnética de la tarjeta

A diferencia de los requisitos de negocio, las reglas de negocio son las políticas específicas, normas, prácticas, reglamentos y directrices que definen cómo los usuarios hacer negocios (y por tanto se consideran los requisitos de nivel de usuario). El producto de software debe cumplir a estas reglas para funcionar adecuadamente en el dominio del usuario. Una visión comercial de los requisitos resumen la siguiente gráfica.

Visión comercial de requisitos

En la siguiente figura, Noritaki Kano ha desarrollado un modelo de la relación entre la satisfacción del cliente y la calidad requisitos (Pyzdek 2000). La la línea de espera de calidad representa los los requisitos de explícitos de calidad que espera  el cliente. Por ejemplo, expresa sus preferencias por la marca, modelo, opciones y rendimiento de la gasolina al comprar un coche. Los clientes no estarán satisfechos (e ir a comprar un coche en otro lugar) si sus requisitos explícitos no se cumplen. La satisfacción del cliente aumenta a medida que sus requisitos explícitos se van cumpliendo. Cuando un número suficiente de sus requisitos explícitos se cumplen, el cliente pasa de ser satisfecho con el producto a ser un cliente satisfecho. 

Modelo de relación Satisfacción Cliente - Calidad/Requisito de Kano

Hay un nivel básico de los requisitos de calidad que un cliente espera que el producto tenga. Estos son requisitos que son asumidos por el cliente y generalmente no son expresados. Por ejemplo, se espera un coche que tiene cuatro ruedas, un motor en funcionamiento, y un volante. Este nivel de exigencia no satisface al cliente. La emoción representa los elementos inesperados. Se trata de artículos que los clientes ni siquiera saben que quieren, pero les encanta cuando los ven. 

¿Cómo escribir los requisitos?

La “mejor forma” de escribir requisitos no existe. Lo más utilizado es el lenguaje natural. Cada requisito expresado en una frases corta (“el sistema hará X ...”, “se facilitará Y...”, etc), o lenguaje natural complementado con diagramas y/o notaciones formales. Por ejemplo:

El sistema mantendrá la temperatura de la caldera entre 70º y 80º

El sistema mantendrá un registro de todos los materiales de la biblioteca, incluyendo libros, periódicos, revistas, videos y CDRoms 

El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN

El interfaz de usuario se implementará sobre un navegador Web

El sistema deberá soportar al menos 20 transacciones por segundo

El sistema permitirá que los nuevos usuario se familiaricen con su uso en menos de 15 minutos.

Aquí puede verse que los requisitos son de muy distintos tipos:

Requisitos que definen efectos sobre el entorno 

Requisitos muy generales

Requisitos funcionales

Requisitos de implementación

Requisitos de rendimiento

Requisitos de usabilidad

Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma estándar de escribirlos. Tampoco es posible decir cual es “la mejor forma” de especificarlos. Todo depende mucho de quien los escribe, quien los va a leer, el dominio de la aplicación, etc. Podemos dar una aproximación a la clasificación de los tipos de requisitos. Por ejemplo:

Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema: El sistema aceptará pagos con VISA

Los requisitos no funcionales son restricciones sobre los requisitos funcionales: El sistema aceptará pagos con VISA de forma segura y con un tiempo de respuesta menor de 5 segundos (si fuera de forma arbitaria diría: El sistema aceptará pagos con VISA a través del protocolo SET).

Tipos de requisitos no funcionales:

Orientados al usuario: Fiabilidad, Seguridad (“security”), Seguridad (“safety”), Usabilidad, Robustez, Disponibilidad, Rendimiento, Tiempo de respuesta, Capacidad (carga), otros.

Orientados al desarrollador: Disponibilidad, Portabilidad, Adaptabilidad, Testabilidad, Comprensibilidad, otros.

Debemos tener en cuenta que se debe escribir los requisitos tanto positivos como negativos. Los negativos es lo que el sistema NO va a realizar, ya que se evita ambigüedad y restringe el alcance, lo aclara desde el inicio.

Requerimientos de software y requisitos de sistemas

Existe un relación de requisitos y arquitectura de software, teniendo en cuenta los siguiente putnos:La elección de una determinada arquitectura sw. debe tener en cuenta los requisitos funcionales pero, sobretodo, los requisitos no funcionalesNo hay una regla definitiva para establecer, dados los requisitos, el tipo de arquitectura Tan sólo hay una serie de heurísticas para, dados unos requisitos, elegir la arquitectura.En la práctica, es difícil desarrollar uno sin el otro

Procesos de Ingeniería de RequisitosA la pregunta de cómo podemos realizar las actividades para poder manejar los requisitos a un nivel formal y que pueda indicar el camino adecuado, la respuesta de la IR lo plasma en los procesos que se sigue.

Procesos de la Ingeniería de Requisitos (basado en Wiegers 2003)

Los requisitos son formalmente documentados durante la fase de especificación para que puedan ser comunicados a los interesados del producto. La especificación de requisitos puede tomar una de muchas formas. Por ejemplo, en proyectos pequeños de la información sobre los requisitos puede ser documentada en un solo documento de Especificación de Requisitos de Software (SRS). En proyectos más complejos, los requisitos pueden ser indicados en varios documentos. Por ejemplo:

Los requisitos de negocio pueden ser documentados en un Documento de Requisitos de  Negocio (Business Requirement Document  BRD), Documento de Requisitos de Marketing (Marketing Requirement Document - MRD), o en un documento de la Visión del proyecto.

Los requisitos de usuario puede ser documentados en una serie de casos de uso de una herramienta o en un documento de Especificaciones de Requisitos de Usuario (URS).

Si el software es parte de un sistema mayor, los requisitos a nivel de producto puede ser documentado en la Especificación de Requisitos del Sistema y un sistema especificación de arquitectura puede documentar las asignaciones de los requisitos al software, el hardware y los componentes de las operaciones manuales de ese sistema.

El software de los requisitos funcionales y no funcionales y las restricciones puede ser documentado en un SRS, asimismo las interfaces externas pueden ser incluidos en el SRS o por separado

Una buena práctica para la especificación de los requisitos es contar con los requisitos predefinidos, es decir, plantillas de especificación. Estas plantillas permiten que el analista de requisitos se centre en el contenido en lugar del formato y puede ayudar a garantizar que los elementos clave no se pasan por alto. Otra buena práctica es utilizar una herramienta de requisitos (o base de datos). Una herramienta de requisitos puede ser un activo importante en tanto para la gestión y administración de proyectos.

En el siguiente gráfico observamos el proceso de Ingeniería de Requisitos en un modelo

de espiral.

Gestión de requisitos

En el dibujo, los cuadros redondeados son tareas. Los cuadrados son productos (inputs o outputs). En el resto de esta presentación se explicará cada componente de este proceso. La separación que aquí se ofrece es más conceptual que real. Las distintas tareas que se ejecutan durante el proceso de requisitos suceden en paralelo y se solapan unas con otras. Por ejemplo, durante un proceso de elicitación (obtener de una manera provocada información de una fuente) de requisitos empleando prototipado, es inevitable realizar una pequeña validación de los requisitos que se van obteniendo, o incluso una pequeña negociación, si estamos tratando con varios usuarios a la vez.

I. ELICITACIÓN DE REQUISITOS

Se refiere a la capturay descubrimiento de los requisitos. Es una actividad más “humana” que técnica, además se identifican a los interesados (stakeholders) y se establecen las primeras relaciones entre ellos. Los requisitos pueden proceder de varias fuentes como:

Metas: Factores críticos de éxito

Conocimiento del dominio de la aplicación. Por ejemplo, si el analista tiene experiencia en realizar sistemas para compañías de seguros, puede sugerir requisitos que no son obvios para los usuarios, o puede deducir mejor las consecuencias de los requisitos propuestos por los usuarios. Por ejemplo, un usuario quiere consultar por pantalla todas las pólizas que venzan durante el mes. Para que ello sea posible, el software deberá obligar, cada vez que se crea una póliza, a que se introduzca su fecha de vencimiento. Esto puede resultar obvio para un informático, pero no lo es tanto para un usuario inexperto.

Interesados. Afectados por el cambio

El entorno que rodea al sistema

La organización. Los procesos de negocio.

Existen problemas a la hora de elicitar los requisitos, pues los usuarios no pueden o no saben describir muchas de sus tareas, esta información importante no llega

a verbalizarse. Ocurre también que a veces hay que “inventar” los requisitos, o los sistemas orientados a miles de usuarios: web, mercado, son demasiado complejo en relación a los tiempos que se tiene para obtener la información. Esta etapa requiere que el aprendizaje del conocimiento del negocio no sea pasivo, sino colaborativo.

Algunas técnicas para obtener requisitos:

Preliminares: Utilizar preguntas libres de contexto

Brainstorming (lluvia de ideas)

Creatividad (herramientas como ideafisher, curio, mindjet, etc.)

Entrevistas: Es el método “tradicional”

Observación y análisis de tareas

Casos de uso / Escenarios: requisitos en contexto de uso

Prototipado: Útiles cuando la incertidumbre es total acerca del futuro sistema. Hay dos tipos principales: Evolutivo, de usar y tirar (prototipos en papel, mago de Oz, etc.).

II. ANÁLISIS DE REQUISITOS

Consiste en detectar y resolver conflictos entre requisitos, además se precisan los límites del sistema y la interacción con su entorno. Es la etapa donde se trasladan los requisitos de usuario a requisitos del software (implementables). Se realizan tres tareas fundamentales: Clasificación, Modelización, Negociación.

Clasificación de los requisitos

En el análisis de requisitos, éstos se clasifican En funcionales vs. no funcionales (Capacidades vs. Restricciones). Tenemos en cuenta los ciertas clasificaciones como: Por prioridades, Por coste de implementación, Por niveles (alto nivel, bajo nivel), Según su volatilidad/estabilidad, si son requisitos sobre el proceso o sobre el producto.En Ingeniería de Sistemas, además, se realiza la ubicación de requisitos (Requirements Allocation)

Modelización conceptual

Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc. La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente). El tipo de modelo elegido depende de: La naturaleza del problema, La experiencia del modelizador, La disponibilidad de herramientas, Por decreto (El cliente impone una notación).

Tradicionalmente se entendía que “el análisis” se reducía a modelizar (DFDs, modelos de objetos, etc), pero el análisis de requisitos NO es exclusivamente un proceso de modelización, como ya se ha dicho. Por otro lado, no existe “la mejor” forma de modelizar requisitos. En realidad, no hay evidencia empírica que demuestre, en general, la superioridad de unas notaciones de modelización frente a otras.

Negociación de requisitos

En todo proceso de IR intervienen distintos individuos con distintos y, a veces, enfrentados intereses. Estos conflictos entre requisitos se descubren durante el análisis. Incluso a veces, detrás de un requisito ambiguo lo que hay, en realidad, es un conflicto no resuelto. Es durante el análisis cuando muchos de los conflictos entre requisitos son descubiertos. EL CONFLICTO NO ES RECHAZABLE y no debe resolverse por decreto, sino mediante un proceso de negociación. Desde este punto de vista, los conflictos son positivos, pues SON FUENTE DE NUEVOS REQUISITOS.

Los acuerdos alcanzados deben ser convenientemente anotados, favoreciéndose así la trazabilidad de los requisitos a sus orígenes (“el requisito 987 surge como resultado de la reunión entre x, y z el día tal del tal...”) Existe, incluso, un subcampo de la IR dedicada a este tipo de temas: la IR orientada a Puntos de Vista o “Viewpoint-Based Requirements Engineering”.

III. ESPECIFICACIÓN DE REQUISITOS

Es el modo habitual de guardar y comunicar requisitos. Es buena práctica a utilizar, al menos, dos documentos, a distinto nivel de detalle DRU/URD: Documento de Requisitos de Usuario/User Requirements Document. ERS/SRS: Especificación de Requisitos Software/Software Requirements Specification.

La pregunta que surge es ¿en qué se diferencian los “requisitos de usuario” de los “requisitos del software”?.  Pues como lo vimos más arriba, podemos resumir en lo siguiente, el NIVEL DE DETALLE:

El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los requisitos de usuario, contenidos en la DRU, no poseen demasiado nivel de detalle. Se incluye la descripción del problema actual (razones por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema.La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software contenidos en la ERS son, por tanto, más detallados. Contiene la respuesta a la pregunta ¿Qué características debe poseer un sistema que nos permita alcanzar los objetivos, y evitar los problemas, expuestos en la DRU.

Existen estándares para la documentación de requisitos, entre los cuáles tenemos:

IEEE Std. 1362 (ConOps)

IEEE Std. 830 (SRS)

PSS-05 de la Agencia Espacial Europea (ESA)

Las herramientas de gestión de requisitos permiten generar documentación en los anteriores formatos, apartir de una base de datos de requisitos. Es importante tener en cuenta que los requisitos deberían de cumplir ciertas características, en total son 24:

1. No ambigua: La ERS es no ambigua si todo requisito posee una sóla interpretación

2. Completa: Una ERS es completa si todo lo que se supone que el software debe hacer está incluído en la ERS. Por completitud, deberían describirse todas las posibles respuestas a todas las posibles entradas y en todas las situaciones posibles. Además, la ERS no contendrá secciones de tipo “por determinar...”

3. Correcta: Todo requisito de la ERS contribuye a satisfacer una necesidad real.

4. Comprensible: Todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de pruebas, gestores, etc.) entienden la ERS.

5. Verificable: Si para cada requisito expresado en la ERS existe un procedimiento de prueba finito y no costoso para demostrar que el futuro sistema lo satisface.

6. Internamente Consistente: No existen subconjuntos de requisitos contradictorios.

7. Externamente Consistente: Ninguno de los requisitos está en contradicción con lo expresado en documentos de nivel superior. Por ejemplo, en un sistema (hardware+software), los requisitos del software no pueden contradecir los requisitos del sistema.

8. Realizable: Si, dados los actuales recursos, la ERS es implementable

9. Concisa: La ERS debe ser lo más breve posible, sin que esto afecte al resto de atributos de calidad

10. Independiente del diseño: Existen más de un diseño e implementación que realizan la ERS. Para ello la ERS debería limitarse a describir el comportamiento externo del sistema.

11. Trazable: Cada requisito se puede referenciar de forma unívoca. Es fundamental para precisar qué requisitos son implementados por qué componente del diseño, lo cual es imprescindible a la hora de realizar las pruebas de dicho componente

12. Modificable: Los cambios son fáciles de introducir.

13. Electrónicamente almacenada: Se encuentra en un archivo de texto, en una base de datos o, mejor aún, ha sido creada con una herramienta de gestión de requisitos (RequisitePro, Doors, etc.)

14. Ejecutable/Interpretable/Prototipable/Animable: Si existe una herramienta software que, recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan sólo a ciertas notaciones como las notaciones formales o los diagramas de transición de estados.

15. Anotada por importancia relativa: Si los requisitos se clasifican según su importancia. Como mínimo un requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sirve para no asignar demasiados recursos a la implementación de requisitos no esenciales.

16. Anotada por estabilidad relativa: Los requisitos son, en general, inestables y volátiles. A cada requisito se le asigna una probabilidad de cambio (p.ej. “Alta, Media o Baja”). Esto ayudará a los diseñadores a diferenciar los componentes más flexibles de los más estables.

17. Anotada por versión: Si un lector de la ERS puede determinar qué requisitos serán satisfechos por qué versión del producto.

18. No redundante: Cada requisito se expresa en un solo lugar de la ERS. La redundancia, de todas formas, no es del todo mala si aumenta la legibilidad.

19. Al nivel adecuado de abstracción: Ni demasiado detallada ni demasiado vaga.

20. Precisa: Una ERS es precisa si hace uso de valores numéricos para precisar las características del sistema. La precisión es aplicable, ante todo, a los requisitos no funcionales. Por ejemplo, no es útil decir “El tiempo de respuesta será más bien rápido”, sino “El tiempo de respuesta será menor que dos segundos”. En la práctica diaria, la precisión es dificilísima de conseguir pues es fuertemente dependiente de la tecnología disponible, la cual no siempre se conoce al principio de un proyecto.

21. Reutilizable: Si ciertas secciones de la ERS se pueden reutilizar

22. Trazada: Si está claro el orígen de cada requisito (quién o qué lo pide)

23. Organizada: Si el lector puede fácilmente encontrar la información buscada.

24. Con referencias cruzadas: Si se utilizan referencias entre requisitos relacionados (trazabilidad intra-ERS) o entre secciones relacionadas.

Debemos de considerar que una ERS perfecta es imposible, la calidad de la ERS es muy difícil de cuantificar, en general, una ERS de calidad NO garantiza la ausencia de problemas, pero una ERS pésima

garantiza su presencia.

IV. VALIDACIÓN DE REQUISITOS

El objetivo de esta etapa es descubrir problemas en el Documento de Requisitos antes de comprometer recursos a su implementación. como resultado se produce una línea-base (baseline).

En el contexto de la Ingeniería de Requisitos, una línea base es un conjunto de requisitos que han sido formalmente aceptados por todas las personas implicadas en el proyecto. Una vez que se establece una línea base, futuros cambios a tales requisitos sólo podrán realizarse por medio de un proceso formal de gestión y aprobación de cambios.

La revisión del documento es la fórmula más empleada para validación, puede ser realizada por un grupo de personas (incluyendo usuarios) y se ocupan de revisar el documento de requisitos. Pueden establecerse tres fases: Busqueda de problemas, reunión y acuerdos. Como guía para identificar problemas habituales, sepueden utilizar listas de comprobación (“checklists”, existen plantillas adaptadas a distintos tipos de sistemas).

El 33% de los errores de requisitos en la especificación del sistema fueron detectados mediante revisión manual. El resto se descubrieron en posteriores fases, con el consiguiente incremento en el coste.Curiosamente, las revisiones parecen funcionar también con el código ejecutable: se descubren más errores inspeccionando el código fuente que ejecutando el programa. ¿Radica aquí el éxito de los desarrollos Open Source?

Cada organización, según su experiencia y según el dominio de las aplicaciones que

desarrolle, debería desarrollar su lista de comprobación o “checklist” particular. Un ejemplo de cuestiones que deberían figurar en una lista de comprobación podría ser esta:

¿Están todos los requisitos convenientemente numerados?

¿El mismo servicio es solicitado en distintos requisitos? ¿Existen contradicciones entre ellos?

¿Los requisitos relacionados se encuentran agrupados en el documento?

¿Los requisitos son fácilmente comprensibles? ¿Por todo tipo de lectores?

En general, una lista de comprobación debería girar alrededor de los 24 atributos de calidad que debería poseer una ERS. Para cada atributo de calidad, se pueden plantear una serie de cuestiones que sirvan para confeccionar la lista de comprobación.

Otros métodos de validación como: Prototipado (Permite descubrir con rapidez si el usuario se encuentra satisfecho, o no, con los requisitos), Uso de escenarios/casos de uso, Validación de modelos (Cuando los requisitos se expresan por medio de modelos (de objetos, DFDs, etc.), Validación de su “testabilidad” (El equipo de pruebas debe revisar los requisitos).

Al finalizar esta etapa, el documento generado debe de cumplir como mínimo con las siguientes características luego de la revisión:

Completa. El documento de requerimientos incluye todos los requisitos necesarios de la información. Por ejemplo, el SRS incluye todas las funciones y no funcionales requerimientos, restricciones, requisitos de interfaz externa, y datos requeridos que deben ser satisfechas.

Consistente. Los conflictos internos no existen entre los requisitos del documento. Los requisitos no entrar en conflicto con los requisitos de alto nivel, incluidos empresarios, usuarios, o sistemas. La terminología también se usan de manera habitual dentro de la documentación, es decir, una palabra tiene el mismo significado que cada vez que se utiliza, o dos palabras diferentes que no se utilizan para significar la misma cosa.

Modificable. El documento de requerimientos es organizado y escrito de una manera que facilitará hacer cambios en el futuro.

El proceso de revisión también debe mirar a todos los requisitos y asegurarse como mínimo que cumpla lo siguiente:

Inequívoca. Cada declaración requisito debe tener una sola interpretación, y cada requisito se debe especificar de forma coherente, fácil de entender manera. Por ejemplo, las búsquedas de autor de las palabras que terminan en "mente" (por ejemplo, rápida y fácil de usar, de forma automática), ya que los adverbios, por naturaleza, son casi siempre ambiguos.

Conciso. Cada requisito debe ser declarado en breve, específico, orientado a la acción del idioma.

Finitos. El requisito no debe plantearse de una manera abierta. Para ejemplo, palabras como "todos", "todos", y "todo" se debe evitar en los requisitos de las declaraciones.

Medibles. Los límites específicos, mensurables o valores deben ser establecidos para cada requisito según el caso.

Factible. El requisito se puede implementar utilizando las tecnologías disponibles, técnicas, herramientas, recursos y personal en el costo y el horario especificado restricciones.

Comprobable. Existe una forma razonablemente rentable para determinar que el software cumple con los requisitos.

Trazabilidad. Cada requisito debe permitir rastrear el origen de su fuente (por ejemplo, a nivel de requisitos de usuario, los requisitos de nivel de sistema, estándar, mejora petición). También se debe especificar de una manera que permita seguir adelante en el diseño, implementación y pruebas.

V. GESTIÓN DE REQUISITOS

Requirements Management (RM), consiste, básicamente, en gestionar los cambios a los requisitos. Esto asegura la consistencia ente los requisitos y el sistema construido (o en construcción), pero consume grandes cantidades de tiempo y esfuerzo, y abarca todo el ciclo de vida del producto.

Debemos de gestionar, porque entendemos que los requisitos son volátiles, el entorno físico cambia (en el caso de trasladar un sistema de un entorno a otro requiere modificaciones), el entorno organizacional cambia (Las políticas cambian, Cambios en las reglas y en los procesos del negocio provocan cambios en el sistema), y la propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios.

Para la gestión debemos de definir lo siguiente:

Definir procedimientos de cambios: definen los pasos y los análisis que se realizarán antes de aceptar los cambios propuestos (una Software Change Request (SCR) de la NASA ocupa más de 500 páginas !!!).

Cambiar los atributos de los requisitos afectados

Mantener la trazabilidad: hacia atrás, hacia delante y entre requisitos (P.ej. Proyectos para la FDA)

Control de versiones del documento de requisitos

Existen herramientas de gestión que facilitan las tareas relacionadas con la escritura, trazabilidad y gestión de cambios, Organizan los requisitos en bases de datos, Gestionan incrementalmente teniendo una línea base, además de clasificar los requisitos mediante atributos. Por ejemplo: DOORS (de QSS/Telelogic), RequisitePro (de Rational), IRqA, icConcept, etc.

Proceso de elaboración de línea base de documento

Una línea base (baseline) es un conjunto de requisitos que, mediante acuerdo entre las partes implicadas, se ha decidido no modificar. Son aquellos requisitos más importantes que el desarrollador se compromete a implementar. A lo largo de un proceso de requisitos pueden crearse (incrementalmente) varias líneas base.Las herramientas de gestión de requisitos permiten gestionar fácilmente las líneas base. Por ejemplo, los requisitos que forman parte de una línea base no podrán ser modificados, salvo por usuarios privilegiados.

Prefacio

Hoy el software es parte casi imprescindible de todo tipo de dispositivos. El software se utiliza para proporcionar valor añadido a productos tradicionales (teléfonos, refrigeradores, coches) y para diferenciarse de los productos de la competencia. Basta con decir que, hoy día, el componente más complejo de un coche es el software (por ejemplo, modelos de Mercedes contienen sistemas empotrados que suman casi 5 Mbytes de código ejecutable), Industrias tradicionalmente alejadas del software hoy tienen problemas de requisitos. Introducir componentes software es distinto a introducir nuevos componentes físicos. La complejidad que añade el software es de varios órdenes de magnitud respecto a lacomplejidad que añadiría un nuevo componente físico.

Introducir el software en industrias tradicionales está produciendo choques culturales. Estas industrias poseen tradiciones, normas y procedimientos que no son aplicables al desarrollo de software. El mismo concepto de “prototipo” posee significados muy distintos en Ingeniería Aeronáutica, por ejemplo, y en Ingeniería del Software. Muchas veces hay que desarrollar un software cuando no se conocen todos los detalles del hardware u otros subsistemas. Además, los plazos de entrega normalmente son cortos e innegociables. Frecuentemente, deberá trabajarse con una arquitectura software lo suficientemente flexible (aún a costa de su eficiencia) que permita incorporar futuros aspectos: patrones que permitan un futuro plug-in de componentes, desarrollos iterativos y/o incrementales, etc. [IEEE Computer, Nov. 2001].

Actualmente, los requisitos no funcionales (seguridad, fiabilidad, tiempo de respuesta, disponibilidad, etc.) ocupan más espacio en el documento de requisitos que los requisitos puramente funcionales. Los requisitos ya no son un problema exclusivo de la

industria del software y, desde luego, no son un problema exclusivo de los Sistemas de Información tradicionales. Pero es el software, precisamente, lo que provoca los problemas de requisitos, debido al gran potencial que posee para aumentar la complejidad de un sistema. Más información en: Juristo, N.; Moreno, A.M.; Silva, A. Is the European industrymoving toward solving requirements engineering problems? IEEE Software, 19(6),Nov/Dec. 2002, page(s): 70- 77.

Si no ha quedado claro el tema de requisitos y su importancia lo podemos resumir en una frase:

"Definir formalmente el deseo del cliente para minimizar el riesgo de desarrollar algo que no desea".

Plan de Elicitación de Requisitos

1. Objetivo

Definiremos las tareas que realizaremos, los productos a obtener y las técnicas que emplearemos durante la actividad de elicitacion de requisitos para el desarrollo del software.

Hay dos tipos de productos: los productos entregables y los no entregables o internos. Los productos entregables los entregaremos oficialmente al cliente como parte del desarrollo en fechas previamente acordadas, mientras que los no entregables son productos internos que no se entregarán al cliente.

El producto entregable luego de hacer la elicitación de requisitos que entregaremos es el Documento de Especificación de requisitos (DER).

La estructura de este documento es la siguiente: en la sección 2 describiremos las tareas recomendadas para realizar una correcta elicitacion de requisitos, en la sección 3 se definen los productos entregables, en este caso el DER, y por último, en la sección 4 describimos las técnicas recomendadas que podemos usar para obtener los productos.

2. Tareas recomendadas

Las tareas recomendadas para obtener los productos son los siguientes:

Tarea 1: Obtendremos información sobre el dominio del problema y el sistema actual.

Tarea 2: Prepararemos y realizaremos las reuniones de elicitación/negociación.

Tarea 3: Identificaremos/revisaremos los objetivos del sistema.

Tarea 4: Identificaremos/revisaremos los requisitos de información.

Tarea 5: Identificaremos/revisaremos los requisitos funcionales.

Tarea 6: Identificaremos/revisaremos los requisitos no funcionales.

Tarea 7: Priorizaremos objetivos y requisitos.

El orden que recomendamos para la realización de estas tareas es: 1…7, aunque las tareas 4, 5, y 6 podemos realizarla simultáneamente o en cualquier orden que se considere oportuno. La tarea 1 es opcional y dependerá del conocimiento previo que tenga el equipo de desarrollo sobre el dominio del problema y el sistema actual.

En las siguientes secciones describiremos cada una de las tareas mencionadas.

2.1 obtener información sobre el dominio del problema y el sistema actual

2.1.1. Objetivos

Conocer el dominio del problema. Conocer la situación actual.

2.1.2. Descripción

Antes de reunirnos con los clientes y usuarios e identificar los requisitos es fundamental que conozcamos el dominio del problema y los contextos organizacional y operacional, es decir, la situación actual.

Enfrentarnos a un desarrollo sin conocer las características principales ni el vocabulario propio de su dominio provocará que el producto final no sea el esperado por nuestros clientes y usuarios.

Por otro lado, si mantenemos reuniones con nuestros clientes y usuarios sin conocer las características de su actividad hará que probablemente no entendamos sus necesidades y que su confianza inicial hacia el desarrollo se vea deteriorada enormemente.

Esta tarea es opcional, ya que nuestro equipo de desarrollo tiene experiencia en el dominio del problema y el sistema actual a desarrollar.

2.1.3. Productos internos

Información recopilada: libros, artículos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc.

2.1.4. Productos entregables

Introducción, participantes en el proyecto, principalmente clientes y desarrolladores, descripción del sistema actual y glosario de términos como parte del DER (Documento de Especificación de Requisitos) (ver secciones 3.1.5–3.1.7 y 3.1.17 paginas).

2.1.5. Técnicas recomendadas

Obtendremos información de fuentes externas al negocio del cliente: folletos, informes sobre el sector o área, publicaciones, consultas con expertos, etc.

En el caso de requisitos muy específicos del dominio será necesario que recurramos a fuentes internas al propio negocio del cliente, en cuyo caso podemos utilizar las técnicas auxiliares de elicitación de requisitos como el estudio de documentación, observación in situ, cuestionarios, inmersión o aprendizaje, etc.

Construcción de glosarios de términos.

2.2. Tarea 2: Preparar y realizar las sesiones de elicitación/negociación

2.2.1. Objetivos

Identificaremos a los usuarios participantes. Conoceremos las necesidades de clientes y usuarios. Resolveremos posibles conflictos.

2.2.2. Descripción

Teniendo en cuenta la información recopilada en la tarea anterior, en esta tarea prepararemos y realizaremos las reuniones con los clientes y usuarios participantes con objeto de obtener sus necesidades y resolver posibles conflictos que se hayan detectado en iteraciones previas del proceso.

Esta tarea es especialmente crítica y la realizaremos con especial cuidado, ya que si nuestro equipo de desarrollo no conoce los detalles específicos de lo que necesita la organización para la que se va a desarrollar el sistema y, por otra parte, si los clientes y posibles usuarios no saben qué es lo que necesita saber nuestro equipo de desarrollo para llevar a cabo nuestra labor.

2.2.3. Productos internos

Notas que tomaremos durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o vídeo de las reuniones o cualquier otra documentación que se considere oportuna.

2.2.4. Productos entregables

Participantes en el proyecto, en concreto los usuarios participantes, como parte del DER.Objetivos, requisitos o conflictos, que hayamos identificado claramente durante las sesiones de elicitación, como parte del DER (ver secciones 3.1.8–3.1.9 y 3.1.18, págs.).

2.2.5. Técnicas recomendadas

Técnicas de elicitación de requisitos incluyendo las plantillas de objetivos, requisitos y conflictos, que podremos usar directamente durante las sesiones de elicitación.

Técnicas de negociación.

2.3. Tarea 3: Identificar/revisar los objetivos del sistema

2.3.1. Objetivos

Identificaremos los objetivos que esperamos alcanzar mediante el sistema software a desarrollar.

Revisaremos, en el caso de que haya conflictos, los objetivos previamente identificados.

2.3.2. Descripción

A partir de la información obtenida en la tarea anterior, en esta tarea se debemos identificar qué objetivos esperamos alcanzar una vez que el sistema software a desarrollar se encuentre en explotación o revisarlos en función de los conflictos identificados.

2.3.3. Productos internos

No hay productos internos en esta tarea.

2.3.4. Productos entregables

Objetivos del sistema como parte del DER (ver sección 3.1.8, pág. ).

2.3.5. Técnicas recomendadas

Análisis de factores críticos de éxito o alguna técnica similar de identificación de objetivos. Plantilla para especificar los objetivos del sistema

2.4. Tarea 4: Identificar/revisar los requisitos de información

2.4.1. Objetivos

Identificaremos los requisitos de almacenamiento de información que deberá cumplir el sistema software a desarrollar.

Identificaremos los requisitos de restricciones de información o reglas de negocio que deberá cumplir el sistema software a desarrollar.

Revisaremos, en el caso de que haya conflictos, los requisitos de almacenamiento y/o de restricciones de información previamente identificados.

2.4.2. Descripción

A partir de la información obtenida en la tareas 1 y 2, y teniendo en cuenta los objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea debemos identificar, o revisar si existen conflictos, qué información relevante para el cliente deberá gestionar y almacenar el sistema software a desarrollar así como qué restricciones o reglas de negocio debe cumplir dicha información.

Inicialmente partiremos de conceptos generales para posteriormente ir detallándolos hasta obtener todos los datos relevantes.

2.4.3. Productos internos

No hay productos internos en esta tarea.

2.4.4. Productos entregables

Requisitos de almacenamiento de información como parte del DER (ver sección 3.1.10, pág. ).

2.4.5. Técnicas recomendadas

Plantilla para requisitos de almacenamiento de información Plantilla para requisitos de restricciones de información.

2.5. Tarea 5: Identificar/revisar los requisitos funcionales

2.5.1. Objetivos

Identificaremos los actores del sistema software a desarrollar. Identificaremos los requisitos funcionales, expresados de forma tradicional o como casos

de uso, que deberá cumplir el sistema software a desarrollar. Revisaremos, en el caso de que haya conflictos, los requisitos funcionales previamente

identificados.

2.5.2. Descripción

A partir de la información que obtengamos en las tareas 1 y 2, y teniendo en cuenta los objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea identificaremos, o revisaremos si existen conflictos, qué debe hacer el sistema a desarrollar con la información identificada en la tarea anterior.

Inicialmente identificaremos los actores que interactuarán con el sistema, es decir aquellas personas u otros sistemas que serán los orígenes o destinos de la información que consumirá o producirá el sistema a desarrollar y que forman su entorno.

A continuación identificaremos los casos de uso asociados a los actores, los pasos de cada caso de uso y posteriormente se detallarán los casos de uso con las posibles excepciones hasta definir todas las situaciones posibles.

En el caso de que se considere necesario, se optaremos por expresar algunos o todos los requisitos funcionales de la forma tradicional, es decir, mediante un párrafo en lenguaje natural, en lugar de hacerlo mediante casos de uso.

2.5.3. Productos internos

No hay productos internos en esta tarea.

2.5.4. Productos entregables

Requisitos funcionales como parte del DRS (ver sección 3.1.11, pág. ).

2.5.5. Técnicas recomendadas

Casos de uso. Plantilla para actores. Plantilla para casos de uso. Plantilla para requisitos funcionales.

2.6. Tarea 6: Identificar/revisar los requisitos no funcionales

2.6.1. Objetivos

Identificaremos los requisitos no funcionales del sistema software a desarrollar. Revisaremos, en el caso de que haya conflictos, los requisitos no funcionales previamente

identificados.

2.6.2. Descripción

A partir de la información obtenida en las tareas 1 y 2, y teniendo en cuenta los objetivos identificados en la tarea 3 y el resto de los requisitos, en esta tarea identificaremos, o revisaremos si existen conflictos en los requisitos no funcionales, normalmente de carácter técnico o legal.

Algunos tipos de requisitos que podemos incluir en esta sección son los siguientes:

Requisitos de comunicaciones del sistema

Son requisitos de carácter técnico relativos a las comunicaciones que deberá soportar el sistema software a desarrollar. Por ejemplo: el sistema deberá utilizar el protocolo TCP/IP para las comunicaciones con otros sistemas.

Requisitos de interfaz de usuario

Este tipo de requisitos especifica las características que deberá tener el sistema en su comunicación con el usuario. Por ejemplo: la interfaz de usuario del sistema deberá ser consistente con los estándares definidos en IBM’s Common User Access.

Debemos ser cuidadosos con este tipo de requisitos, ya que en esta fase de desarrollo todavía no conocemos bien las dificultades que pueden surgir a la hora de diseñar e implementar las interfaces, por esto no es conveniente que entremos en detalles demasiado específicos.

Requisitos de fiabilidad

Los requisitos de fiabilidad deben establecer los factores que se requieren para la fiabilidad del software en tiempo de explotación. La fiabilidad mide la probabilidad del sistema de producir una respuesta satisfactoria a las demandas del usuario. Por ejemplo: la tasa de fallos del sistema no podrá ser superior a 2 fallos por semana.

Requisitos de entorno de desarrollo

Este tipo de requisitos especifican si el sistema debe desarrollarse con un producto específico. Por ejemplo: el sistema deberá desarrollarse con Oracle 10 como servidor y clientes Visual C#.net.

.

Requisitos de portabilidad

Los requisitos de portabilidad definen qué características deberá tener el software para que sea fácil utilizarlo en otra máquina o bajo otro sistema operativo. Por ejemplo: el sistema deberá funcionar en los sistemas operativos Windows XP, Windows Seven y Windows Server 2008, siendo además posible el acceso al sistema a través de Internet usando cualquier navegador compatible.

2.6.3. Productos internos

No hay productos internos en esta tarea.

2.6.4. Productos entregables

Requisitos no funcionales del sistema como parte del DRS (ver sección 3.1.15, pág. ).

2.6.5. Técnicas recomendadas

Plantilla para requisitos no funcionales.

3. Productos entregables

El producto entregable es el Documento de Especificación de requisitos (DER).

3.1. Documento de requisitos del sistema

La estructura del DER puede verse en la figura 2. En las siguientes secciones describimos con detalle cada sección del DER.

3.1.1. Portada

La portada del DER tendrá el formato que puede verse en la figura 3. Los elementos aparecerán son los siguientes:

Nombre del proyecto: el nombre del proyecto al que pertenece el DER. Versión: la versión del DER que entregaremos al cliente. La versión se compondrá de

dos números X e Y. El primero indicará la versión, y incrementaremos cada vez que se hace una nueva entrega formal al cliente. Cuando incrementemos el primer número, el segundo volverá a comenzar en cero. El segundo número indicará cambios dentro

de la misma versión aún no entregada, y incrementaremos cada vez que publiquemos una versión con cambios respecto a la última que se publicó y que no entreguemos formalmente todavía. Este tipo de versiones podrán ser internas al equipo de desarrollo o entregadas al cliente a título orientativo.

Fecha: fecha de la publicación de la versión. Equipo de desarrollo: nombres de los integrantes de nuestro equipo de desarrollo. Cliente: nombre del cliente / empresa.

3.1.2. Lista de cambios

El documento incluirá una lista de cambios en la que se especifiquen, para cada versión del documento, los cambios producidos en el mismo con un formato similar al que puede verse en la figura 4. Para cada cambio realizado incluiremos el número de orden, la fecha, una descripción y los autores.

Portada

Lista de cambios

Índice

Lista de figuras

Lista de tablas

1. Introducción

2. Participantes en el proyecto

3. Descripción del sistema actual

4. Objetivos del sistema

5. Catálogo de requisitos del sistema

5.1 Requisitos de información

5.2 Requisitos funcionales

5.2.1 Diagramas de casos de uso

5.2.2 Definición de actores

5.2.3 Casos de uso del sistema

5.3 Requisitos no funcionales

6. Matriz de rastreabilidad objetivos/requisitos

7. Glosario de términos

8. Conflictos pendientes de resolución [opcional, pueden ir en un documento aparte]

Apéndices [opcionales]

Figura 2: Estructura del Documento de Requisitos del Sistema

Proyecto nombre del proyecto

Documento de

Requisitos del Sistema

Versión X:Y

Fecha fecha

Realizado por equipo de desarrollo

Realizado para cliente

Figura 3: Portada del Documento de Requisitos del Sistema

Num Fecha descripción Autores

0 Fecha 0 Versión x.y Autor 0

1 Fecha 1 descripción cambio11 Autor 1

… … … …

N Fecha N descripción cambio Nn Autor N

Figura 4: Lista de cambios del Documento de Requisitos del Sistema

3.1.3. Índice

El índice del DRS indicará la página en la que comienza cada sección, sub-sección o apartado del documento. En la medida de lo posible, sangraremos las entradas del índice para ayudar a comprender la estructura del documento.

3.1.4. Listas de figuras y tablas

El DER incluirá listas de las figuras y tablas que aparezcan en el mismo. Dichas listas serán dos índices que indicarán el número, la descripción y la página en que aparece cada figura o tabla del DER.

3.1.5. Introducción

Esta sección contendrá una descripción breve de las principales características del sistema software que se va a desarrollar, la situación actual que genera la necesidad del nuevo desarrollo, la problemática que se acomete, y cualquier otra

consideración que sitúe al posible lector en el contexto oportuno para comprender el resto del documento.

3.1.6. Participantes en el proyecto

Esta sección contendrá una lista con todos los participantes en el proyecto, tanto desarrolladores como clientes y usuarios. Para cada participante indicaremos su nombre, el papel que desempeña en el proyecto, la organización a la que pertenece y cualquier otra información adicional que se considere oportuna.

3.1.7. Descripción del sistema actual

Esta sección contendrá una descripción del sistema actual en el caso de que se haya acometido su estudio. Para describir el sistema actual puede utilizarse cualquier técnica que se considere oportuno, por ejemplo las descritas en [Laguna et al. 1999] (Diagrama Documentos–Tarea, DDT) o en [Ortín et al. 2001] (Diagramas de Actividad, también descritos en [Booch et al. 1999]).

3.1.8. Objetivos del sistema

Esta sección contendrá una lista con los objetivos que esperamos alcanzar cuando el sistema software a desarrollar esté en explotación, especificados mediante la plantilla para objetivos.

3.1.9. Catálogo de requisitos del sistema

Esta sección será dividida en las siguientes sub-secciones en las que se describiremos los requisitos del sistema. Cada uno de los grandes grupos de requisitos, de información, funcionales y no funcionales, dividiéndose para ayudar a la legibilidad del documento, por ejemplo dividiendo cada sub-sección en requisitos asociados a un determinado objetivo, requisitos con características comunes, etc.

3.1.10. Requisitos de información

Esta sub-sección contendrá la lista de requisitos de almacenamiento y de restricciones de información que se identifiquemos, utilizando

Para especificarlos las plantillas para requisitos de información.

3.1.11. Requisitos funcionales

Esta sub-sección debe contendrá la lista de requisitos funcionales, expresados de la forma tradicional o mediante casos de uso, que hayamos identificado, dividiéndose en los siguientes apartados que se describen a continuación.

3.1.12. Diagramas de casos de uso

Este apartado contendrá los diagramas de casos de uso del sistema que hayamos realizado.

3.1.13. Definición de los actores

Este apartado contendrá una lista con los actores que hayamos identificado, especificados mediante la plantilla para actores de casos de

Uso.

3.1.14. Casos de uso del sistema

Este apartado contendrá los casos de uso que hayamos identificado, especificados mediante la plantilla para requisitos funcionales. En el caso de que consideremos oportuno, también podremos expresar algunos o todos los requisitos funcionales de la forma tradicional, usando para ello la misma plantilla.

3.1.15. Requisitos no funcionales

Esta sub-sección contendrá la lista de los requisitos no funcionales del sistema que hayamos identificado, especificados mediante la plantilla para requisitos no funcionales.

3.1.16. Matriz de rastreabilidad objetivos/requisitos

Esta sección contendrá una matriz objetivo–requisito, de forma que para cada objetivo se pueda conocer con qué requisitos está asociado. El formato de la matriz de rastreabilidad puede verse en la figura 5.

Figura 5: Matriz de rastreabilidad del Documento de Requisitos del Sistema

3.1.17. Glosario de términos

Esta sección, contendrá una lista ordenada alfabéticamente de los términos específicos del dominio del problema, acrónimos y abreviaturas que aparezcan en el documento y que consideremos que su significado deba ser aclarado. Cada término será acompañado de su significado.

3.1.18. Conflictos pendientes de resolución

Esta sección, la incluiremos en el caso de que no optemos por registrar los conflictos en un documento aparte, contendrá los conflictos identificados durante el proceso y que aún están pendientes de resolución, descritos mediante la plantilla para conflictos.

3.1.19. Apéndices

Los apéndices los usaremos para proporcionar información adicional a la documentación obligatoria del documento. Sólo aparecerán si los consideramos oportunos y los identificaremos con letras ordenadas alfabéticamente: A, B, C, etc.

4.- Herramientas para la especificación de requisitos

Existen varias formas de conseguir información de los requisitos del sistema a desarrollar: por entrevistas, JAD, brainstorming, diseño de prototipos conjunto etc.

Un paso previo a la Elicitación de requisitos es la educción de requisitos donde conseguimos los requisitos y con qué objetivos está relacionado, esta fase la hacemos de manera conjunta entre el/los analista(s) y el/los usuario(s), además de puntualizar los objetivos principales del sistema.

Una plantilla que usaremos para la educción de requisitos la mostramos a continuación.