Plan de Verificacin de Requerimientos

Autor: Cant Cauich Amado Rev. 1.0.

Tabla de Contenido
Tema 1. Introduccin 1.1. Panorama 1.2. Propsito 1.3. Alcance 2. Probando los requerimientos mediante revisiones tcnicas 2.1. Revisiones tcnicas 2.1.1. Caminatas Estructuradas (Structured Walkthroughs) 2.1.1.1. Ejecucin 2.1.2. Inspecciones 2.1.3. Checklists 3. Planear la revisin 4. Asegurar la trazabilidad 4.1. Trazabilidad hacia adelante 4.2. Trazabilidad hacia atrs 4.3. Trazabilidad entre requisitos 4.4. Implicaciones 5. Fundamento Anexo 1 Anexo 2 Pgina 3 3 3 3 3 3 3 4 5 5 6 6 6 6 7 7 7 8 9

Desarrollo de Requisitos de Software

Amado Cant

Pgina 2 de 9

1. Introduccin 1.1. Panorama La fase de desarrollo de requerimientos es quiz la ms importante en el ciclo de vida del desarrollo de software en cuanto a asegurar la exactitud del producto de software respecto a lo esperado por el cliente. De sta fase dependen las subsecuentes fases de diseo, codificacin y pruebas; sin embargo la ejecucin de pruebas no debe limitarse al enfoque tradicional donde no stas no ocurren sino hasta el final del proceso y antes de la entrega del producto, no se puede dejar de lado el nivel de importancia que tiene realizar una especificacin de requisitos verdaderamente adecuada y conforme a las necesidades del cliente. 1.2. Propsito ste Plan de Verificacin de Requisitos (PVR) tiene por objetivo proporcionar una metodologa para la verificacin de requisitos de manera que sea posible asegurarse de que cubren las necesidades del cliente, se escriban de una forma tecnolgicamente neutra y precisa, sean trazables, no ambiguos, completos, consistentes, clasificados, verificables y modificables. 1.3. Alcance El presente Plan de Verificacin de Requisitos se limita a proporcionar tcnicas formales de verificacin de requisitos y una breve descripcin de la manera de ejecutar cada una de ellas. 2. Probando los requerimientos mediante revisiones tcnicas La definicin de requerimientos es el resultado del pensamiento creativo y es la base del diseo. La fase de requerimientos es verificada con tcnicas estticas, esto es, sin la ejecucin de la aplicacin puesto que sta an no existe. sas tcnicas verifican el apego de los requisitos a las convenciones de especificacin, completitud, trazabilidad, consistencia, verificabilidad y dems caractersticas mencionadas en el apartado 1. 2.1. Revisiones tcnicas 2.1.1. Caminatas Estructuradas (Structured Walkthroughs) Una Caminata Estructurada es una revisin en la cual un participante de revisin, usualmente la persona (o equipo) que desarroll el producto a revisar narra una descripcin del producto y el resto del grupo provee retroalimentacin durante la presentacin. En el caso de los requisitos, bastar con la lectura de cada uno de los requisitos plasmados en el ERS y/o en las plantillas de registro de requisitos.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 3 de 9

2.1.1.1.

Ejecucin

Idealmente se conforma un equipo que debera incluir cuando menos: El presentador, que es la persona o equipo que presentar el trabajo revisado, en ste caso el equipo de personas o la persona que realiz el ERS y/o las plantillas de requisitos. El coordinador, que se encargar de coordinar el flujo de la revisin. La secretaria o el escriba, que toma notas de lo tratado en la revisin, elabora y distribuye minutas de la reunin. El orculo del mantenimiento, que revisa el producto desde el punto de vista del mantenimiento futuro. Verifica la trazabilidad de los requisitos. El portador de estndares, quien se asegurar de que los procesos o estndares preestablecidos se sigan. El representante de usuario, que representar a la comunidad para la cual el producto es desarrollado, es de suma importancia entonces incluir a un miembro del equipo de diseo. El cronometrador, quien se asegurar de que los lmites de tiempo sean respetados y que la reunin no sobrepase el tiempo preestablecido. Otros revisadores, que deben tener un alto entendimiento del producto que se est revisando, en ste caso se debera incluir al resto del equipo involucrado en la obtencin de los requisitos o cuando menos a una parte representativa de ste.

Antes de la revisin Cada integrante del equipo de revisin debe prepararse mediante la pre-revisin de una copia avanzada del documento o documentos a revisar que debe haber sido distribuida a todos los miembros del equipo de revisin. La preparacin es de manera individual. Durante la revisin Se emplean los checklists que se hayan diseado para corroborar el apego de los requerimientos a las normas y estndares preestablecidas. Despus de la revisin Se preparan los documentos de la sesin (minutas, notas tomadas por el escriba, etctera) y se generan recomendaciones para el equipo cuyo trabajo fue revisado. Se debe emitir un fallo que puede ser una y slo una de las opciones siguientes: Producto totalmente aceptado, en cuyo caso significa que los requisitos estn listos para pasar a la fase de diseo. Producto parcialmente aceptado, en ste caso se harn las recomendaciones pertinentes al equipo cuyo trabajo fue revisado para que el trabajo pueda pasar a la fase de diseo.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 4 de 9

Producto totalmente rechazado, entonces se har una recomendaciones sobre el producto al equipo que lo desarroll.

serie

de

2.1.2. Inspecciones La inspeccin es una tcnica de revisin sistemtica, controlada y menos estresante que la caminata estructurada. Una inspeccin que es realizada correctamente se convierte en un foro en el cual el equipo o persona cuyo trabajo es evaluado no necesita volverse emocionalmente protector de su trabajo, aunque requiere de una agenda para preparar la revisin y la junta de revisin misma. Las inspecciones se realizan en cuatro pasos de acuerdo con el modelo PDCA del Crculo de Deming que es una estrategia de mejora continua de la calidad: Paso 1 (Plan): En ste paso se planea la inspeccin, involucra la calendarizacin del personal que va a participar. Se prepara una panorama de la informacin que se va a revisar (el ERS, las plantillas de requisitos, informacin sobre cmo se obtuvieron los requisitos), se determinan criterios de aceptacin y rechazo, se eligen a los participantes y se define lugar y fecha para la inspeccin. Los participantes tienen que ser informados sobre lo que se va a revisar (entregar copias del material que conforma el panorama informativo). Paso 2 (Do): Cada miembro del equipo de revisin se prepara de manera individual mediante el anlisis del material que se le hizo llegar. La junta de inspeccin es llevada a cabo. Paso 3 (Check): Se identifican los defectos que se hayan encontrado en el material revisado (Requisitos mal escritos, inconsistentes, ambiguos o confusos, irreales o contradictorios, etc.) y se documentan. Paso 4 (Act): Implica la correccin de los defectos que se hayan encontrado as como el aseguramiento de que dichas correcciones realmente se lleven a cabo.

2.1.3. Checklists Los checklists conforman una tcnica de verificacin de requisitos que implica cierto trabajo para su preparacin y que involucra un plan de verificacin de pruebas. Cada cheklist es diseado de manera que cubra los distintos aspectos que debe cumplir un producto revisado para ser aprobado. Consulte el Anexo 1 para ver un ejemplo de checklist dirigido a verificar la correcta redaccin de un requisito.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 5 de 9

3. Planear la revisin Para verificar adecuadamente los requisitos se requiere determinar los distintos aspectos que se tienen que revisar y aprobar para poder decir que los requisitos estn listos para pasar a la siguiente fase. Es responsabilidad del equipo de diseo determinar lo mnimo que un ERS (y cualquier producto de la fase de requerimientos) debe cumplir para que pueda ser aceptado como entrada para la fase de diseo en el ambiente de trabajo de la empresa donde se implemente, sin embargo es posible y necesario determinar stos aspectos desde el punto de vista de la Ingeniera de Requisitos de manera que nos aseguremos que cumplan las especificaciones y cualidades de un buen requerimiento. Se tiene que considerar los aspectos de buena redaccin, evitar palabras ambiguas, ser realistas en la redaccin, procurar que se permita la trazabilidad de los requerimientos as como los dems aspectos que se mencionan al inicio del documento. 4. Asegurar la trazabilidad Uno de los aspectos ms importantes que un buen requerimiento debe poseer es la trazabilidad. Podemos identificar tres tipos de trazabilidad: hacia adelante, hacia atrs y entre requisitos. A continuacin se presenta una breve descripcin de stos tipos de trazabilidad y cmo lograr cada una de stas cualidades. En el Anexo 2 se puede consultar un ejemplo de cmo registrar requisitos hacindolos trazables hacia adelante, hacia atrs y entre ellos mismos. 4.1. Trazabilidad hacia adelante Implica poder identificar todos y cada uno de los componentes que realizan el requisito. Va desde elementos de diseo hasta unidades o mdulos en el sistema implementado. Para lograr ste tipo de trazabilidad, se debe mantener un estndar de registro que permita hacer referencia en cada requisito hacia los elementos posteriores que implementan tal requisito. 4.2. Trazabilidad hacia atrs Significa poder identificar de qu necesidad surge el requisito funcional de que se trate. Se requiere que los registros de requisitos permitan referenciar a las necesidades del cliente de las cuales surge el requisito.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 6 de 9

4.3. Trazabilidad entre requisitos Se refiere a que debe ser posible identificar de cada requisito aquellos otros con los cuales guarda alguna relacin, sea por la necesidad uno del otro por la simple implicacin entre ellos. Nuevamente, para poder obtener sta cualidad, el registro del requisito debe permitir referenciar a aquellos con los cuales guarda relacin. 4.4. Implicaciones Es evidente la necesidad de un formato que permita reunir las caractersticas sealadas anteriormente; tambin es necesario determinar alguna nomenclatura estndar para los requisitos que permita y facilite la referenciacin entre s mismos con el objetivo de lograr los distinto tipos de trazabilidad. Es buena idea nombrar los requisitos mediante un estndar que tiene que ser definido por la empresa y al cual todos los miembros deben apegarse. 5. Fundamento La informacin aqu planteada se basa principalmente en el libro Software Testing and Continuous Quality Improvement de William E. Lewis en su segunda edicin y de los conocimientos adquiridos en la asignatura de Desarrollo de Requisitos de Software que forma parte del plan estudio de la Licenciatura en Ingeniera de Software de la Facultad de Matemticas de la Universidad Autnoma de Yucatn.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 7 de 9

Anexo 1: Checklist para verificar la correcta redaccin de requerimientos Aspecto El requerimiento posee un tipo de usuario que ser beneficiado o que lo utilizar? El requerimiento expresa lo que desea alcanzar el usuario? El requerimiento posee un objeto es su descripcin? El requerimiento posee una frase adverbial (calificador)? El requerimiento es un enunciado simple? El requerimiento est enunciado en voz activa? El requerimiento utiliza un vocabulario limitado? El requerimiento evita palabras tcnicas que pudieran confundir a lectores no tcnicos? El requerimiento comienza con un nombre o tipo de usuario? El requerimiento se centra en los resultados indicados? El requerimiento evita conjunciones? El requerimiento evita el uso de frases ambiguas como aceptable, adecuado, muy til, no ms de, etctera? El requerimiento evita opciones? (frases como si, siempre y cuando, excepto, a menos que, etc.) El requerimiento evita incluir el diseo en su descripcin? El requerimiento evita especulaciones? (frases como usualmente, generalmente, a menudo, etc.) El requerimiento carece de expresiones irreales? (frases como seguro, totalmente confiable, nunca falla, etc.) El requerimiento est escrito gramatical y ortogrficamente de manera correcta? El requerimiento se apega al glosario? El requerimiento evita sinnimos? El requerimiento carece de pronombres en su descripcin? El requerimiento est escrito en forma tecnolgicamente neutra? Valoracin
S No No aplica

Observaciones

Desarrollo de Requisitos de Software

Amado Cant

Pgina 8 de 9

Anexo 2: Asegurando la trazabilidad de los requisitos Requisito # Categora: Tipo: Elija el tipo Prioridad: Prioridad

Descripcin: Una breve descripcin del requisito Razn: Por qu es importante el requisito? Origen: Quin lo solicita? Dependencias: Referenciar los requisitos con los que guarda alguna dependencia o relacin. Referencias: Listar los documentos que sean necesarios para entender el requisito. Conflictos: Referenciarlos requisitos que, de alguna manera, contradicen a ste. Historial de cambios: Historia de los cambios realizados al requisito. Figura 1: Plantilla de registro de requerimientos, asegurando trazabilidad entre requisitos. ID Requerimiento de usuario Identificador del requerimiento La necesidad del usuario de usuario. Debe seguir una nomenclatura estandarizada en la empresa. Ejemplo: U1 Trazabilidad hacia adelante ID del requerimiento funcional (o de los requerimientos funcionales) donde se refleja ste requerimiento de usuario. Ejemplo: S2, S7

Figura 2: Plantilla de registro para asegurar trazabilidad hacia adelante. ID Requerimiento funcional Identificador del requerimiento El requerimiento en el cual se de sistema. Debe seguir una refleja la necesidad (total o nomenclatura estandarizada parcialmente) del usuario. en la empresa. Ejemplo: S1 Trazabilidad hacia atrs ID del requerimiento de usuario de donde surge ste requerimiento funcional. Ejemplo: U1

Figura 3: Plantilla de registro para asegurar la trazabilidad hacia atrs.

Desarrollo de Requisitos de Software

Amado Cant

Pgina 9 de 9