Plan de Elicitacin de Requisitos 1.

Objetivo Definiremos las tareas que realizaremos, los productos a obtener y las tcnicas 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. !l producto entregable luego de hacer la elicitaci"n de requisitos que entregaremos es el Documento de !specificaci"n de requisitos #D!$%. La estructura de este documento es la siguiente: en la secci"n & describiremos las tareas recomendadas para realizar una correcta elicitacion de requisitos, en la secci"n ' se definen los productos entregables, en este caso el D!$, y por (ltimo, en la secci"n ) describimos las tcnicas recomendadas que podemos usar para obtener los productos. 2. Tareas recomendadas Las tareas recomendadas para obtener los productos son los siguientes: Tarea 1: *btendremos informaci"n sobre el dominio del problema y el sistema actual. Tarea 2: +repararemos y realizaremos las reuniones de elicitaci"n,negociaci"n. Tarea 3: -dentificaremos,revisaremos los ob.etivos del sistema. Tarea 4: -dentificaremos,revisaremos los requisitos de informaci"n. Tarea 5: -dentificaremos,revisaremos los requisitos funcionales. Tarea : -dentificaremos,revisaremos los requisitos no funcionales. Tarea !: +riorizaremos ob.etivos y requisitos. !l orden que recomendamos para la realizaci"n de estas tareas es: /01, aunque las tareas ), 2, y 3 podemos realizarla simult neamente o en cualquier orden que se considere oportuno. La tarea / es opcional y depender del conocimiento previo que tenga el equipo de desarrollo sobre el dominio del problema y el sistema actual. !n las siguientes secciones describiremos cada una de las tareas mencionadas. 2.1 obtener in"ormacin sobre el dominio del #roblema $ el sistema actual 2.1.1. Objetivos 4onocer el dominio del problema. 4onocer la situaci"n actual.

2.1.2. %escri#cin 5ntes de reunirnos con los clientes y usuarios e identificar los requisitos es fundamental que conozcamos el dominio del problema y los conte6tos organizacional y operacional, es decir, la situaci"n actual. !nfrentarnos a un desarrollo sin conocer las caracter7sticas principales ni el vocabulario propio de su dominio provocar que el producto final no sea el esperado por nuestros clientes y usuarios. +or otro lado, si mantenemos reuniones con nuestros clientes y usuarios sin conocer las caracter7sticas de su actividad har que probablemente no entendamos sus necesidades y que su confianza inicial hacia el desarrollo se vea deteriorada enormemente. !sta tarea es opcional, ya que nuestro equipo de desarrollo tiene e6periencia en el dominio del problema y el sistema actual a desarrollar. 2.1.3. Productos internos -nformaci"n recopilada: libros, art7culos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc. 2.1.4. Productos entre&ables -ntroducci"n, participantes en el proyecto, principalmente clientes y desarrolladores, descripci"n del sistema actual y glosario de trminos como parte del D!$ #Documento de !specificaci"n de $equisitos% #ver secciones './.28 './.1 y '././1 paginas%. 2.1.5. T'cnicas recomendadas *btendremos informaci"n de fuentes e6ternas al negocio del cliente: folletos, informes sobre el sector o rea, publicaciones, consultas con e6pertos, etc. !n el caso de requisitos muy espec7ficos del dominio ser necesario que recurramos a fuentes internas al propio negocio del cliente, en cuyo caso podemos utilizar las tcnicas au6iliares de elicitaci"n de requisitos como el estudio de documentaci"n, observaci"n in situ, cuestionarios, inmersi"n o aprendizaje, etc. 4onstrucci"n de glosarios de trminos. 2.2. Tarea 2: Pre#arar $ reali(ar las sesiones de elicitacin)ne&ociacin 2.2.1. Objetivos -dentificaremos a los usuarios participantes. 4onoceremos las necesidades de clientes y usuarios. $esolveremos posibles conflictos. 2.2.2. %escri#cin 9eniendo 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 ob.eto de obtener sus necesidades y resolver posibles conflictos que se hayan detectado en iteraciones previas del proceso. !sta tarea es especialmente cr7tica y la realizaremos con especial cuidado, ya que si nuestro equipo de desarrollo no conoce los detalles espec7ficos 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 :otas que tomaremos durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o v7deo de las reuniones o cualquier otra documentaci"n que se considere oportuna. 2.2.4. Productos entre&ables +articipantes en el proyecto, en concreto los usuarios participantes, como parte del D!$. *b.etivos, requisitos o conflictos, que hayamos identificado claramente durante las sesiones de elicitaci"n, como parte del D!$ #ver secciones './.;8'./.< y '././;, p gs.%. 2.2.5. T'cnicas recomendadas 9cnicas de elicitaci"n de requisitos incluyendo las plantillas de ob.etivos, requisitos y conflictos, que podremos usar directamente durante las sesiones de elicitaci"n. 9cnicas de negociaci"n. 2.3. Tarea 3: *denti"icar)revisar los objetivos del sistema 2.3.1. Objetivos -dentificaremos los ob.etivos que esperamos alcanzar mediante el sistema software a desarrollar. $evisaremos, en el caso de que haya conflictos, los ob.etivos previamente identificados. 2.3.2. %escri#cin 5 partir de la informaci"n obtenida en la tarea anterior, en esta tarea se debemos identificar qu ob.etivos esperamos alcanzar una vez que el sistema software a desarrollar se encuentre en e6plotaci"n o revisarlos en funci"n de los conflictos identificados. 2.3.3. Productos internos :o hay productos internos en esta tarea. 2.3.4. Productos entre&ables *b.etivos del sistema como parte del D!$ #ver secci"n './.;, p g. %. 2.3.5. T'cnicas recomendadas 5n lisis de factores cr7ticos de 6ito o alguna tcnica similar de identificaci"n de ob.etivos. +lantilla para especificar los ob.etivos del sistema 2.4. Tarea 4: *denti"icar)revisar los requisitos de in"ormacin 2.4.1. Objetivos

-dentificaremos los requisitos de almacenamiento de informaci"n que deber cumplir el sistema software a desarrollar. -dentificaremos los requisitos de restricciones de informaci"n o reglas de negocio que deber cumplir el sistema software a desarrollar. $evisaremos, en el caso de que haya conflictos, los requisitos de almacenamiento y,o de restricciones de informaci"n previamente identificados.

2.4.2. %escri#cin 5 partir de la informaci"n obtenida en la tareas / y &, y teniendo en cuenta los ob.etivos identificados en la tarea ' y el resto de los requisitos, en esta tarea debemos identificar, o revisar si e6isten conflictos, qu informaci"n relevante para el cliente deber gestionar y almacenar el sistema software a desarrollar as7 como qu restricciones o reglas de negocio debe cumplir dicha informaci"n. -nicialmente partiremos de conceptos generales para posteriormente ir detall ndolos hasta obtener todos los datos relevantes. 2.4.3. Productos internos :o hay productos internos en esta tarea. 2.4.4. Productos entre&ables $equisitos de almacenamiento de informaci"n como parte del D!$ #ver secci"n '././=, p g. %. 2.4.5. T'cnicas recomendadas +lantilla para requisitos de almacenamiento de informaci"n +lantilla para requisitos de restricciones de informaci"n. 2.5. Tarea 5: *denti"icar)revisar los requisitos "uncionales 2.5.1. Objetivos -dentificaremos los actores del sistema software a desarrollar. -dentificaremos los requisitos funcionales, e6presados de forma tradicional o como casos de uso, que deber cumplir el sistema software a desarrollar. $evisaremos, en el caso de que haya conflictos, los requisitos funcionales previamente identificados. 2.5.2. %escri#cin 5 partir de la informaci"n que obtengamos en las tareas / y &, y teniendo en cuenta los ob.etivos identificados en la tarea ' y el resto de los requisitos, en esta tarea identificaremos, o revisaremos si e6isten conflictos, qu debe hacer el sistema a desarrollar con la informaci"n identificada en la tarea anterior. -nicialmente identificaremos los actores que interactuar n con el sistema, es decir aquellas personas u otros sistemas que ser n los or7genes o destinos de la informaci"n que consumir o producir el sistema a desarrollar y que forman su entorno.

5 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 e6cepciones hasta definir todas las situaciones posibles. !n el caso de que se considere necesario, se optaremos por e6presar algunos o todos los requisitos funcionales de la forma tradicional, es decir, mediante un p rrafo en lengua.e natural, en lugar de hacerlo mediante casos de uso. 2.5.3. Productos internos :o hay productos internos en esta tarea. 2.5.4. Productos entre&ables $equisitos funcionales como parte del D$> #ver secci"n '././/, p g. %. 2.5.5. T'cnicas recomendadas 4asos de uso. +lantilla para actores. +lantilla para casos de uso. +lantilla para requisitos funcionales. 2. . Tarea : *denti"icar)revisar los requisitos no "uncionales 2. .1. Objetivos -dentificaremos los requisitos no funcionales del sistema software a desarrollar. $evisaremos, en el caso de que haya conflictos, los requisitos no funcionales previamente identificados. 2. .2. %escri#cin 5 partir de la informaci"n obtenida en las tareas / y &, y teniendo en cuenta los ob.etivos identificados en la tarea ' y el resto de los requisitos, en esta tarea identificaremos, o revisaremos si e6isten conflictos en los requisitos no funcionales, normalmente de car cter tcnico o legal. 5lgunos tipos de requisitos que podemos incluir en esta secci"n son los siguientes: Requisitos de comunicaciones del sistema >on requisitos de car cter tcnico relativos a las comunicaciones que deber soportar el sistema software a desarrollar. +or e.emplo: el sistema deber utilizar el protocolo TCP/IP para las comunicaciones con otros sistemas. Requisitos de inter"a( de usuario !ste tipo de requisitos especifica las caracter7sticas que deber tener el sistema en su comunicaci"n con el usuario. +or e.emplo: la interfaz de usuario del sistema deber ser consistente con los estndares definidos en IBMs Common User Access. Debemos ser cuidadosos con este tipo de requisitos, ya que en esta fase de desarrollo todav7a 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 espec7ficos.

Requisitos de "iabilidad Los requisitos de fiabilidad deben establecer los factores que se requieren para la fiabilidad del software en tiempo de e6plotaci"n. La fiabilidad mide la probabilidad del sistema de producir una respuesta satisfactoria a las demandas del usuario. +or e.emplo: la tasa de fallos del sistema no podr ser superior a fallos por semana. Requisitos de entorno de desarrollo !ste tipo de requisitos especifican si el sistema debe desarrollarse con un producto espec7fico. +or e.emplo: el sistema deber desarrollarse con !racle "# como ser$idor % clientes &isual C'(net( . Requisitos de #ortabilidad Los requisitos de portabilidad definen qu caracter7sticas deber tener el software para que sea f cil utilizarlo en otra m quina o ba.o otro sistema operativo. +or e.emplo: el sistema deber funcionar en los sistemas operati$os )indo*s +P, )indo*s -e$en % )indo*s -er$er ##., siendo adems posible el acceso al sistema a tra$/s de Internet usando cual0uier na$egador compatible. 2. .3. Productos internos :o hay productos internos en esta tarea. 2. .4. Productos entre&ables $equisitos no funcionales del sistema como parte del D$> #ver secci"n '././2, p g. %. 2. .5. T'cnicas recomendadas +lantilla para requisitos no funcionales. 3. Productos entre&ables !l producto entregable es el 1ocumento de 2specificaci3n de re0uisitos #D!$%. 3.1. %ocumento de requisitos del sistema La estructura del D!$ puede verse en la figura &. !n las siguientes secciones describimos con detalle cada secci"n del D!$. 3.1.1. Portada La portada del D!$ tendr el formato que puede verse en la figura '. Los elementos aparecer n son los siguientes: +ombre del #ro$ecto: el nombre del proyecto al que pertenece el D!$. ,ersin: la versi"n del D!$ que entregaremos al cliente. La versi"n se compondr de dos n(meros X e Y. !l primero indicar la versi"n, y incrementaremos cada vez que se hace una nueva entrega formal al cliente. 4uando incrementemos el primer n(mero, el segundo volver a comenzar en cero. !l 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 todav7a. !ste tipo de versiones podr n ser internas al equipo de desarrollo o entregadas al cliente a t7tulo orientativo.

-ec.a: fecha de la publicaci"n de la versi"n. Equi#o de desarrollo: nombres de los integrantes de nuestro equipo de desarrollo. /liente: nombre del cliente , empresa. 3.1.2. 0ista de cambios !l 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 ). +ara cada cambio realizado incluiremos el n(mero de orden, la fecha, una descripci"n y los autores.
+ortada Lista de cambios @ndice Lista de figuras Lista de tablas /. -ntroducci"n &. +articipantes en el proyecto '. Descripci"n del sistema actual ). *b.etivos del sistema 2. 4at logo de requisitos del sistema 2./ $equisitos de informaci"n 2.& $equisitos funcionales 2.&./ Diagramas de casos de uso 2.&.& Definici"n de actores 2.&.' 4asos de uso del sistema 2.' $equisitos no funcionales 3. Aatriz de rastreabilidad ob.etivos,requisitos 1. Blosario de trminos ;. 4onflictos pendientes de resoluci"n 4opcional, pueden ir en un documento aparte5 5pndices 4opcionales5

-i&ura 2: Estructura del %ocumento de Requisitos del 1istema

Pro$ecto nombre del pro%ecto %ocumento de Requisitos del 1istema Cersi"n X:Y Decha fec6a $ealizado por e0uipo de desarrollo $ealizado para cliente

-i&ura 3: Portada del %ocumento de Requisitos del 1istema

+um = / 0 :

-ec.a Decha = Decha / 0 Decha :

descri#cin
Cersi"n 6.y descripci3n cambio"
1

3
descripci3n cambio 7
n

2utores 5utor = 5utor / 0 5utor :

-i&ura 4: 0ista de cambios del %ocumento de Requisitos del 1istema 3.1.3. 4ndice !l 7ndice del D$> indicar la p gina en la que comienza cada secci"n, subEsecci"n o apartado del documento. !n la medida de lo posible, sangraremos las entradas del 7ndice para ayudar a comprender la estructura del documento. 3.1.4. 0istas de "i&uras $ tablas !l D!$ incluir listas de las figuras y tablas que aparezcan en el mismo. Dichas listas ser n dos 7ndices que indicar n el n(mero, la descripci"n y la p gina en que aparece cada figura o tabla del D!$. 3.1.5. *ntroduccin !sta secci"n contendr una descripci"n breve de las principales caracter7sticas 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 conte6to oportuno para comprender el resto del documento. 3.1. . Partici#antes en el #ro$ecto !sta secci"n contendr una lista con todos los participantes en el proyecto, tanto desarrolladores como clientes y usuarios. +ara 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.!. %escri#cin del sistema actual !sta secci"n contendr una descripci"n del sistema actual en el caso de que se haya acometido su estudio. +ara describir el sistema actual puede utilizarse cualquier tcnica que se considere oportuno, por e.emplo las descritas en FLaguna et al. /<<<G #Diagrama Documentos89area, DD9% o en F*rt7n et al. &==/G #Diagramas de 5ctividad, tambin descritos en FHooch et al. /<<<G%. 3.1.5. Objetivos del sistema !sta secci"n contendr una lista con los ob.etivos que esperamos alcanzar cuando el sistema software a desarrollar est en e6plotaci"n, especificados mediante la plantilla para ob.etivos.

3.1.6. /at7lo&o de requisitos del sistema !sta secci"n ser dividida en las siguientes subEsecciones en las que se describiremos los requisitos del sistema. 4ada uno de los grandes grupos de requisitos, de informaci"n, funcionales y no funcionales, dividindose para ayudar a la legibilidad del documento, por e.emplo dividiendo cada subEsecci"n en requisitos asociados a un determinado ob.etivo, requisitos con caracter7sticas comunes, etc. 3.1.18. Requisitos de in"ormacin !sta subEsecci"n contendr la lista de requisitos de almacenamiento y de restricciones de informaci"n que se identifiquemos, utilizando +ara especificarlos las plantillas para requisitos de informaci"n. 3.1.11. Requisitos "uncionales !sta subEsecci"n debe contendr la lista de requisitos funcionales, e6presados de la forma tradicional o mediante casos de uso, que hayamos identificado, dividindose en los siguientes apartados que se describen a continuaci"n. 3.1.12. %ia&ramas de casos de uso !ste apartado contendr los diagramas de casos de uso del sistema que hayamos realizado. 3.1.13. %e"inicin de los actores !ste apartado contendr una lista con los actores que hayamos identificado, especificados mediante la plantilla para actores de casos de Iso. 3.1.14. /asos de uso del sistema !ste apartado contendr los casos de uso que hayamos identificado, especificados mediante la plantilla para requisitos funcionales. !n el caso de que consideremos oportuno, tambin podremos e6presar algunos o todos los requisitos funcionales de la forma tradicional, usando para ello la misma plantilla. 3.1.15. Requisitos no "uncionales !sta subEsecci"n contendr la lista de los requisitos no funcionales del sistema que hayamos identificado, especificados mediante la plantilla para requisitos no funcionales. 3.1.1 . 9atri( de rastreabilidad objetivos)requisitos !sta secci"n contendr una matriz ob.etivo8requisito, de forma que para cada ob.etivo se pueda conocer con qu requisitos est asociado. !l formato de la matriz de rastreabilidad puede verse en la figura 2.

-i&ura 5: 9atri( de rastreabilidad del %ocumento de Requisitos del 1istema 3.1.1!. :losario de t'rminos !sta secci"n, contendr una lista ordenada alfabticamente de los trminos espec7ficos del dominio del problema, acr"nimos y abreviaturas que aparezcan en el documento y que consideremos que su significado deba ser aclarado. 4ada trmino ser acompa?ado de su significado. 3.1.15. /on"lictos #endientes de resolucin !sta 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.16. 2#'ndices Los apndices los usaremos para proporcionar informaci"n adicional a la documentaci"n obligatoria del documento. >"lo aparecer n si los consideramos oportunos y los identificaremos con letras ordenadas alfabticamente: 5, H, 4, etc.

4.; <erramientas #ara la es#eci"icacin de requisitos !6isten varias formas de conseguir informaci"n de los requisitos del sistema a desarrollar: por entrevistas, J5D, brainstorming, dise?o de prototipos con.unto etc. In paso previo a la !licitaci"n de requisitos es la educci"n de requisitos donde conseguimos los requisitos y con qu ob.etivos est relacionado, esta fase la hacemos de manera con.unta entre el,los analista#s% y el,los usuario#s%, adem s de puntualizar los ob.etivos principales del sistema. Ina plantilla que usaremos para la educci"n de requisitos la mostramos a continuaci"n.