Herramientas de ayuda para la

Ingeniería de Requisitos
Recopilación de pequeñas herramientas informales para IR

Andrés Silva
Facultad de Informática • Universidad Politécnica de Madrid • 2008

Andrés Silva • asilva@fi.upm.es 1

Índice

Plantillas de requisitos! 3

Lista de comprobación (checklist) de requisitos! 5

Preguntas libres del contexto! 8

Patrones de proceso! 10

Andrés Silva • asilva@fi.upm.es 2

Herramientas de IR
PLANTILLAS DE REQUISITOS

Aquí se presenta una “plantilla de requisitos” o “tarjeta de requisitos” (inspirada en el libro

de S. Robertson y J. Robertson “Mastering the Requirements Process”, Addison-Wesley,
1999) que puede ser útil en proyectos reales. Imprimiendo varias de éstas tarjetas, se pueden
utilizar para recoger información relevante durante las primeras fases del proceso.

Requisito #: Clasificación: Tipo:

Descripción:

Razón:

Origen: Prioridad:

Dependencias: Conflictos:

Referencias:

Historia:

Ejemplo de Tarjeta de Requisitos

La explicación de cada sección es la siguiente:

Requisito #: Número que identifica a cada requisito

Clasificación: En qué apartado del documento de requisitos debería figurar. En otras pa-
labras, a qué parte del sistema afecta (p. ej. pedidos, contabilidad, ventas, etc.)

Tipo: Funcional, no funcional

Descripción: Una frase que describe el requisito, tipo “feature” (es decir, frase breve y
directa, como las que podemos encontrarnos en un folleto publicitario del producto).

Razón: ¿Por qué es importante este requisito?

Origen: ¿quién lo pide?

Andrés Silva • asilva@fi.upm.es 3

 Prioridad: Importancia del requisito. Puede valorarse de 0 a 3, por ejemplo.

Dependencias: Otros requisitos de los que depende

Conflictos: Requisitos que, de alguna forma, contradicen a éste

Referencias a otros documentos necesarios para comprender el requisito

Historia: Historia de los cambios al requisito

Andrés Silva • asilva@fi.upm.es 4

Herramientas de IR
LISTA DE COMPROBACIÓN (CHECKLIST) DE REQUISITOS

La siguiente lista de comprobación sirve para realizar una validación guiada de un conjunto
de requisitos. La lista sirve tanto para inspeccionar los requisitos contenidos en una ERS co-
mo para cualquier conjunto de requisitos almacenado en una herramienta de gestión de re-
quisitos o en una Base de Datos. Es especialmente recomendable, no obstante, utilizarla an-
tes de crear una línea base. La checklist se basa en la propuesta por Karl Wiegers
(www.processimpact.com), aunque ligeramente modificada.

(1) Organización del documento:

¿Las referencias internas entre requisitos son todas correctas?

¿Los requisitos se han escrito a un nivel de detalle apropiado?

¿Los requisitos constituyen una base adecuada para el diseño?

¿Cada requisito tiene una prioridad de implementación?

¿Se ha especificado el origen de cada requisito? (p.ej. quién lo pide, en qué reu-
nión se decidió incluirlo y porqué, etc.)

(2) Completitud

¿Se han definido todas las interfaces externas, hardware, software y de comuni-
caciones?

¿La ERS contiene todas las necesidades del cliente?

¿Algún requisito requiere más información? Si es así, ¿Se ha identificado como

TBD? (Nota: TBD es “To Be Determined”, es decir, “pendiente”)

¿Se ha especificado el comportamiento del sistema para todos los tipos de

errores más frecuentes?

Andrés Silva • asilva@fi.upm.es 5

 ¿Se ha delimitado el ámbito del sistema?¿Se ha especificado lo que el sistema no
hará?

(3) Corrección

¿Existen requisitos en conflicto unos con otros?

¿Hay requisitos duplicados?

¿Cada requisito se ha especificado en un lenguaje claro, conciso y no ambiguo?

¿Cada requisito es verificable mediante prueba, demostración, revisión u otro

análisis?

¿Hay algún requisito que se salga del ámbito del proyecto?

¿Algún requisito contiene errores de contenido o gramaticales?

¿Los requisitos son implementables?

¿Se han especificado claramento los mensajes de error posibles?

(4) Atributos de calidad

¿Se han especificado los requisitos de rendimiento? ¿Cuantitativamente?

¿Se han identificado las funciones cuyo tiempo de respuesta es crítico?

¿Se han especificado los aspectos de seguridad (“security” y “safety”)?

¿Se han especificado otros atributos de calidad? ¿Cuantitativamente?

(5) Trazabilidad

¿Posee cada requisito un identificador único?

¿Los requisitos son trazables a requisitos de más alto nivel? (p.ej., requisitos del
sistema, objetivos, casos de uso, otros documentos de nivel superior a la ERS)

Andrés Silva • asilva@fi.upm.es 6

(6) Otras características deseables

¿Se ha diferenciado entre (i) “requisitos” propiamente dichos (que expresan

objetivos), (ii) descripciones de dominio (realidades, como leyes físicas o proce-
sos), (iii) requisitos de interfaz (que especifican la conexión entorno-máquina) y
(iv) especificaciones de diseño (que deberían evitarse, aunque no siempre es po-
sible)?

¿Se ha tenido en cuenta los estándares, las leyes aplicables y las imposiciones de
posibles entidades certificadoras?

Hay que tener en cuenta que algunas de las anteriores preguntas se dirigen a cada requisito
individual, mientras que otras afectan al documento en general. El resultado de la aplicación
de esta checklist debería conducir a una serie de acciones orientadas a corregir y mejorar la
Especificación de Requisitos Software.

Andrés Silva • asilva@fi.upm.es 7

Herramientas de IR
PREGUNTAS LIBRES DEL CONTEXTO

Estas preguntas (basadas en las de Gause & Weinberg) son útiles en las fases preliminares,
cuando no tenemos ni idea de por donde empezar a preguntar. Sirven para “romper el hielo”
al inicio del proyecto. Por ejemplo, se pueden solicitar respuestas por e-mail a un cliente/u-
suario, como actividad previa a una entrevista más formal.

(1) Respecto al proceso

¿Quién es el cliente?

¿Qué ventajas aportaría una solución para el cliente?

¿Cuál es la razón para resolver el problema?

En el desarrollo, ¿deberíamos utilizar un solo grupo de personas, o varios grupos?

¿Quién debería formar parte de dichos grupos?

¿Cuánto tiempo tenemos para el proyecto?

¿Cuál es el balance tiempo - dinero?

¿Existe alguna solución alternativa para este problema?

¿Podemos imitar algo que ya existe?

(2) Respecto al producto

¿Qué problema resolverá el producto?

¿Qué problemas creará el producto?

¿En qué ambiente funcionará el producto?

¿Cuál será la precisión deseada del producto?

Andrés Silva • asilva@fi.upm.es 8

 ¿Podría describir dos o tres situaciones-tipo de uso del producto?

¿Qué posible carencia del producto sería la más decepcionante?

(3) Metapreguntas

¿Estoy haciendo demasiadas preguntas?

¿Cree que mis preguntas tocan aspectos relevantes? Si la respuesta es “no”, ¿cuáles?
¿por qué?

¿Hay alguna otra persona a la que debería hacer éstas, o similares, preguntas?

¿Sus respuestas son “oficiales”?

Andrés Silva • asilva@fi.upm.es 9

Herramientas de IR
PATRONES DE PROCESO

Estos patrones de proceso son muy útiles para llevar a la práctica en distintas circunstancias.
Proceden del artículo “Sharing RE Experiene Using Patterns” de Hagge y Lappe, publicado
en IEEE Software, Enero de 2005.

Patrón #1: Organizar la especificación siguiendo la estructura del

grupo de trabajo en el proyecto
Este patrón recomienda una manera de organizar el proceso de especificación.

Objetivo

Crear una especificación de mutuo acuerdo en un entorno donde los interesados se encuen-
tran distribuidos en distintos grupos o equipos.

Contexto

Los líderes del proyecto tendrán que asignar responsabilidades para crear la especificación
desde el principio del proyecto.

Problema

Todos los interesados tendrán que negociar los requisitos hasta que se alcance un acuerdo,
pero normalmente los técnicos tienden a concentrarse en su trabajo y, por tanto, son de difí-
cil acceso a la hora de realizar una negociación. El líder del proyecto es quien deberá organi-
zar la colaboración y el intercambio de información entre los distintos afectados.

Solución

Organizar el proceso de especificación siguiendo la estructura del proyecto. Cada equipo

responsable de una parte del proyecto tendrá un “autor” asignado que será quien contribuya
a la (sub)especificación, según el punto de vista del equipo. Un Ingeniero de Requisitos cen-
tral coordinará a los autores.

Áreas de Aplicación

Andrés Silva • asilva@fi.upm.es 10

Éste método de trabajo ha resultado útil en proyectos distribuidos, tales como (i) proyectos
distribuidos localmente, donde distintos equipos se encuentran repartidos en distintos luga-
res; (ii) proyectos donde los interesados son de muy diversa formación, intereses o conoci-
miento; y (iii) proyectos donde existen grandes fluctuaciones del personal a lo largo del tiem-
po.

Consecuencias

Un efecto positivo es el derivado de la multiplicidad de puntos de vista en juego. Otro aspecto

positivo es el relacionado con el papel de moderador del Ingeniero de Requisitos central.

Ejemplos

En el proyecto X el líder del proyecto organizó a los equipos según los distintos componentes
de una planta industrial y según distintas disciplinas de ingeniería (había grupos relacionados
con plantas criogénicas, otros con túneles y otros con componentes electrónicos). En el pro-
yecto Y la estructura seguía los distintos proceso de negocio de la organización, con un res-
ponsable por área y con un equipo adicional encargado de diseñar la arquitectura del sistema.

Experiencias

Las especificaciones de requisitos deberían hacerse disponibles a todo el mundo.

Patrón #2: Crear pequeñas guías para especificadores, basándose

en el trabajo del analista
Este patrón recomienda generar guías siguiendo la forma de trabajar del analista.

Objetivo

Capacitar a los interesados (stakeholders) para que hagan contribuciones completas, consis-
tentes y balanceadas a la especificación.

Contexto

Para proyectos distribuidos, donde hay equipos independientes que tienen que desarrollar o
educir requisitos.

Problema

Los expertos en el dominio no pueden delegar la escritura de requisitos en otros, pero esos
expertos, en muchos casos, carecen del conocimiento sobre los métodos y herramientas
apropiadas para la escritura de requisitos.

Solución

Andrés Silva • asilva@fi.upm.es 11

Proporcionar un “documento guía” que permita a los interesados construir una especifica-
ción, en lenguaje natural, estructurada de manera similar a cómo un analista construiría un
modelo visual, y con una calidad similar. Para construir el documento guía, lo mejor es trazar
los pasos que sigue el analista en la creación de un modelo (de negocio, de objetos, etc.) y
convertir dichos pasos en secciones del documento guía.

Áreas de Aplicación

Se han utilizado con éxito en (i) proyectos largos, donde los equipos sufren frecuentes cam-
bios; (ii) por equipos de expertos en áreas muy especializadas y (iii) por interesados distri-
buidos espacialmente y con dificultades para reunirse.

Consecuencias

Un efecto positivo es que permiten la especificación remota, facilitando así los proyectos dis-
tribuidos. El problema es que una guía mal hecha conduce a especificaciones defectuosas.

Ejemplos

En el proyecto X los analistas desarrollaron una guía similar a los pasos seguidos para crear
un modelo de objetos. La guía preguntaba, de manera iterativa, por la funcionalidad de cier-
tos componentes de una planta industrial, por su equipamiento y por los recursos necesarios.
En el proyecto Y se creó una guía similar a los pasos seguidos por un analista para crear casos
de uso. En la guía se preguntaba a los interesados por determinadas tareas, la información
que requerían o producían tales tareas y la manera en que ellos introducían o recibían dicha
información.

Experiencias

Dado que las guías se utilizan en las fases tempranas del proyecto, se pueden producir inter-
cambios de información bastante útiles. En muchos proyectos, los analistas pudieron traducir
las especificaciones en modelos UML, sin demasiada dificultad.

Patrón #3: Generar listas de comprobación (checklists) para cada

componente

Objetivo

Asegurar que los desarrolladores creen una versión del producto de acuerdo con la especifi-
cación.

Contexto

Andrés Silva • asilva@fi.upm.es 12

Los líderes del equipo tienen que comprobar una determinada versión del producto para
evaluar el grado de cumplimiento de las especificaciones.

Problema

Los ingenieros de requisitos no pueden poner una marca al lado de cada requisito para indi-
car si se cumple o no, porque la especificación reutiliza requisitos asignados a distintos com-
ponentes (especificación redundante, pero inevitable, pues distintos componentes poseen
requisitos compartidos con otros componentes).

Solución

Usar listas de comprobación generadas dinámicamente que contengan los requisitos que con-
tribuyen a cada componente, en el formato “Componente+{Lista de requisitos asociados al
componente}”. Puede realizarse a partir de la base de datos de requisitos.

Áreas de Aplicación

La lista de comprobación beneficia a cualquier proyecto que reutilice requisitos en varios lu-
gares. Por ejemplo, proyectos que sigan un modelo incremental (donde los requisitos pasan
por sucesivas pruebas de aprobación) o para familias de productos.

Consecuencias

Se puede trazar mejor el historial de aprobación. Mejora el control de versiones.

Ejemplos

En el proyecto X el equipo generó una serie de certificados de aprobación para revisar mode-
los CAD de distintos edificios, para asegurar que podían albergar distintas instalaciones. En
el proyecto Y se generaron listas de comprobación para distintos grupos de trabajo, donde
cada grupo era responsable de ciertas partes de cada requisito. El objetivo era comprobar si
los requisitos globales se cumplían en su totalidad.

Experiencias

El filtrado por componentes proporciona un certificado completo de aprobación para el pro-

ducto global. Permite, además, trazar mejor las responsabilidades hacia los responsables de
crear cada componente.

Andrés Silva • asilva@fi.upm.es 13