Herramientas de ayuda para la Ingeniera de Requisitos

Recopilacin de pequeas herramientas informales para IR

Andrs Silva Facultad de Informtica Universidad Politcnica de Madrid 2008

Andrs Silva asilva@.upm.es

ndice

Plantillas de requisitos! Lista de comprobacin (checklist) de requisitos! Preguntas libres del contexto! Patrones de proceso!

3 5 8 10

Andrs Silva asilva@.upm.es

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 informacin relevante durante las primeras fases del proceso.

Requisito #:
Descripcin: Razn: Origen: Dependencias: Referencias: Historia:

Clasicacin:

Tipo:

Prioridad: Conflictos:

Ejemplo de Tarjeta de Requisitos

La explicacin de cada seccin es la siguiente: Requisito #: Nmero que identifica a cada requisito Clasificacin: En qu apartado del documento de requisitos debera figurar. En otras palabras, a qu parte del sistema afecta (p. ej. pedidos, contabilidad, ventas, etc.) Tipo: Funcional, no funcional Descripcin: 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). Razn: Por qu es importante este requisito? Origen: quin lo pide?

Andrs Silva asilva@.upm.es

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

Andrs Silva asilva@.upm.es

Herramientas de IR
LISTA DE COMPROBACIN (CHECKLIST) DE REQUISITOS
La siguiente lista de comprobacin sirve para realizar una validacin guiada de un conjunto de requisitos. La lista sirve tanto para inspeccionar los requisitos contenidos en una ERS como para cualquier conjunto de requisitos almacenado en una herramienta de gestin de requisitos o en una Base de Datos. Es especialmente recomendable, no obstante, utilizarla antes de crear una lnea base. La checklist se basa en la propuesta por Karl Wiegers (www.processimpact.com), aunque ligeramente modificada. (1) Organizacin 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 diseo? Cada requisito tiene una prioridad de implementacin? Se ha especificado el origen de cada requisito? (p.ej. quin lo pide, en qu reunin se decidi incluirlo y porqu, etc.) (2) Completitud Se han definido todas las interfaces externas, hardware, software y de comunicaciones? La ERS contiene todas las necesidades del cliente? Algn requisito requiere ms informacin? 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 ms frecuentes?

Andrs Silva asilva@.upm.es

Se ha delimitado el mbito del sistema?Se ha especificado lo que el sistema no har? (3) Correccin 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, demostracin, revisin u otro anlisis? Hay algn requisito que se salga del mbito del proyecto? Algn 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 crtico? 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 ms alto nivel? (p.ej., requisitos del sistema, objetivos, casos de uso, otros documentos de nivel superior a la ERS)

Andrs Silva asilva@.upm.es

(6)

Otras caractersticas deseables Se ha diferenciado entre (i) requisitos propiamente dichos (que expresan objetivos), (ii) descripciones de dominio (realidades, como leyes fsicas o procesos), (iii) requisitos de interfaz (que especifican la conexin entorno-mquina) y (iv) especificaciones de diseo (que deberan evitarse, aunque no siempre es posible)? Se ha tenido en cuenta los estndares, 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 aplicacin de esta checklist debera conducir a una serie de acciones orientadas a corregir y mejorar la Especificacin de Requisitos Software.

Andrs Silva asilva@.upm.es

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/usuario, como actividad previa a una entrevista ms formal. (1) Respecto al proceso Quin es el cliente? Qu ventajas aportara una solucin para el cliente? Cul es la razn para resolver el problema? En el desarrollo, deberamos utilizar un solo grupo de personas, o varios grupos? Quin debera formar parte de dichos grupos? Cunto tiempo tenemos para el proyecto? Cul es el balance tiempo - dinero? Existe alguna solucin 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? Cul ser la precisin deseada del producto?

Andrs Silva asilva@.upm.es

Podra describir dos o tres situaciones-tipo de uso del producto? Qu posible carencia del producto sera la ms decepcionante? (3) Metapreguntas Estoy haciendo demasiadas preguntas? Cree que mis preguntas tocan aspectos relevantes? Si la respuesta es no, cules? por qu? Hay alguna otra persona a la que debera hacer stas, o similares, preguntas? Sus respuestas son oficiales?

Andrs Silva asilva@.upm.es

Herramientas de IR
PATRONES DE PROCESO
Estos patrones de proceso son muy tiles para llevar a la prctica en distintas circunstancias. Proceden del artculo Sharing RE Experiene Using Patterns de Hagge y Lappe, publicado en IEEE Software, Enero de 2005.

Patrn #1: Organizar la especicacin siguiendo la estructura del grupo de trabajo en el proyecto
Este patrn recomienda una manera de organizar el proceso de especificacin. Objetivo Crear una especificacin de mutuo acuerdo en un entorno donde los interesados se encuentran distribuidos en distintos grupos o equipos. Contexto Los lderes del proyecto tendrn que asignar responsabilidades para crear la especificacin desde el principio del proyecto. Problema Todos los interesados tendrn que negociar los requisitos hasta que se alcance un acuerdo, pero normalmente los tcnicos tienden a concentrarse en su trabajo y, por tanto, son de difcil acceso a la hora de realizar una negociacin. El lder del proyecto es quien deber organizar la colaboracin y el intercambio de informacin entre los distintos afectados. Solucin Organizar el proceso de especificacin siguiendo la estructura del proyecto. Cada equipo responsable de una parte del proyecto tendr un autor asignado que ser quien contribuya a la (sub)especificacin, segn el punto de vista del equipo. Un Ingeniero de Requisitos central coordinar a los autores. reas de Aplicacin

Andrs Silva asilva@.upm.es

10

ste mtodo de trabajo ha resultado til en proyectos distribuidos, tales como (i) proyectos distribuidos localmente, donde distintos equipos se encuentran repartidos en distintos lugares; (ii) proyectos donde los interesados son de muy diversa formacin, intereses o conocimiento; y (iii) proyectos donde existen grandes fluctuaciones del personal a lo largo del tiempo. 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 lder del proyecto organiz a los equipos segn los distintos componentes de una planta industrial y segn distintas disciplinas de ingeniera (haba grupos relacionados con plantas criognicas, otros con tneles y otros con componentes electrnicos). En el proyecto Y la estructura segua los distintos proceso de negocio de la organizacin, con un responsable por rea y con un equipo adicional encargado de disear la arquitectura del sistema. Experiencias Las especificaciones de requisitos deberan hacerse disponibles a todo el mundo.

Patrn #2: Crear pequeas guas para especicadores, basndose en el trabajo del analista
Este patrn recomienda generar guas siguiendo la forma de trabajar del analista. Objetivo Capacitar a los interesados (stakeholders) para que hagan contribuciones completas, consistentes y balanceadas a la especificacin. 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 mtodos y herramientas apropiadas para la escritura de requisitos. Solucin
Andrs Silva asilva@.upm.es 11

Proporcionar un documento gua que permita a los interesados construir una especificacin, en lenguaje natural, estructurada de manera similar a cmo un analista construira un modelo visual, y con una calidad similar. Para construir el documento gua, lo mejor es trazar los pasos que sigue el analista en la creacin de un modelo (de negocio, de objetos, etc.) y convertir dichos pasos en secciones del documento gua. reas de Aplicacin Se han utilizado con xito en (i) proyectos largos, donde los equipos sufren frecuentes cambios; (ii) por equipos de expertos en reas muy especializadas y (iii) por interesados distribuidos espacialmente y con dificultades para reunirse. Consecuencias Un efecto positivo es que permiten la especificacin remota, facilitando as los proyectos distribuidos. El problema es que una gua mal hecha conduce a especificaciones defectuosas. Ejemplos En el proyecto X los analistas desarrollaron una gua similar a los pasos seguidos para crear un modelo de objetos. La gua preguntaba, de manera iterativa, por la funcionalidad de ciertos componentes de una planta industrial, por su equipamiento y por los recursos necesarios. En el proyecto Y se cre una gua similar a los pasos seguidos por un analista para crear casos de uso. En la gua se preguntaba a los interesados por determinadas tareas, la informacin que requeran o producan tales tareas y la manera en que ellos introducan o reciban dicha informacin. Experiencias Dado que las guas se utilizan en las fases tempranas del proyecto, se pueden producir intercambios de informacin bastante tiles. En muchos proyectos, los analistas pudieron traducir las especificaciones en modelos UML, sin demasiada dificultad.

Patrn #3: Generar listas de comprobacin (checklists) para cada componente

Objetivo Asegurar que los desarrolladores creen una versin del producto de acuerdo con la especificacin. Contexto
Andrs Silva asilva@.upm.es 12

Los lderes del equipo tienen que comprobar una determinada versin 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 indicar si se cumple o no, porque la especificacin reutiliza requisitos asignados a distintos componentes (especificacin redundante, pero inevitable, pues distintos componentes poseen requisitos compartidos con otros componentes). Solucin Usar listas de comprobacin generadas dinmicamente que contengan los requisitos que contribuyen 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 Aplicacin La lista de comprobacin beneficia a cualquier proyecto que reutilice requisitos en varios lugares. Por ejemplo, proyectos que sigan un modelo incremental (donde los requisitos pasan por sucesivas pruebas de aprobacin) o para familias de productos. Consecuencias Se puede trazar mejor el historial de aprobacin. Mejora el control de versiones. Ejemplos En el proyecto X el equipo gener una serie de certificados de aprobacin para revisar modelos CAD de distintos edificios, para asegurar que podan albergar distintas instalaciones. En el proyecto Y se generaron listas de comprobacin 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 cumplan en su totalidad. Experiencias El filtrado por componentes proporciona un certificado completo de aprobacin para el producto global. Permite, adems, trazar mejor las responsabilidades hacia los responsables de crear cada componente.

Andrs Silva asilva@.upm.es

13