92756471-Plan-de-Verificacion-de-Requerimientos.docx

7/29/2019 92756471-Plan-de-Verificacion-de-Requerimientos.docx

1/9

Plan de Verificacin de RequerimientosAutor: Cant Cauich Amado

Rev. 1.0.


2/9

Desarrollo de Requisitos de Software Amado Cant Pgina 2 de 9

Tabla de Contenido

Tema Pgina

1. Introduccin 31.1. Panorama 31.2. Propsito 31.3. Alcance 3

2. Probando los requerimientos mediante revisiones tcnicas 32.1. Revisiones tcnicas 3

2.1.1. Caminatas Estructuradas (Structured Walkthroughs) 32.1.1.1. Ejecucin 4

2.1.2. Inspecciones 52.1.3. Checklists 5

3. Planear la revisin 64. Asegurar la trazabilidad 6

4.1. Trazabilidad hacia adelante 64.2. Trazabilidad hacia atrs 6

4.3. Trazabilidad entre requisitos 74.4. Implicaciones 75. Fundamento 7

Anexo 1 8Anexo 2 9


3/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 alo 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 enfoquetradicional donde no stas no ocurren sino hasta el final del proceso y antes de la entrega delproducto, no se puede dejar de lado el nivel de importancia que tiene realizar una especificacinde requisitos verdaderamente adecuada y conforme a las necesidades del cliente.

1.2. Propsito

ste Plan de Verificacin de Requisitos (PVR) tiene por objetivo proporcionar unametodologa 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 yprecisa, sean trazables, no ambiguos, completos, consistentes, clasificados, verificables ymodificables.

1.3. Alcance

El presente Plan de Verificacin de Requisitos se limita a proporcionar tcnicasformales de verificacin de requisitos y una breve descripcin de la manera de ejecutar cadauna de ellas.

2. Probando los requerimientos mediante revisiones tcnicas

La definicin de requerimientos es el resultado del pensamiento creativo y es la basedel diseo. La fase de requerimientos es verificada con tcnicas estticas, esto es, sin laejecucin de la aplicacin puesto que sta an no existe. sas tcnicas verifican el apego delos 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 delproducto 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 requisitosplasmados en el ERS y/o en las plantillas de registro de requisitos.


4/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 lasplantillas 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 delmantenimiento futuro. Verifica la trazabilidad de los requisitos.

El portador de estndares, quien se asegurar de que los procesos oestndares 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 unmiembro del equipo de diseo.

El cronometrador, quien se asegurar de que los lmites de tiempo seanrespetados y que la reunin no sobrepase el tiempo preestablecido.

Otros revisadores, que deben tener un alto entendimiento del producto que seest revisando, en ste caso se debera incluir al resto del equipo involucradoen la obtencin de los requisitos o cuando menos a una parte representativa deste.

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 atodos 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 losrequerimientos 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 pasara la fase de diseo.


5/9


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

2.1.2. Inspecciones

La inspeccin es una tcnica de revisin sistemtica, controlada y menos estresanteque la caminata estructurada. Una inspeccin que es realizada correctamente se convierte enun foro en el cual el equipo o persona cuyo trabajo es evaluado no necesita volverseemocionalmente protector de su trabajo, aunque requiere de una agenda para preparar larevisin y la junta de revisin misma.

Las inspecciones se realizan en cuatro pasos de acuerdo con el modelo PDCA delCrculo de Deming que es una estrategia de mejora continua de la calidad:

Paso 1 (Plan): En ste paso se planea la inspeccin, involucra lacalendarizacin del personal que va a participar. Se prepara una panorama dela informacin que se va a revisar (el ERS, las plantillas de requisitos,informacin sobre cmo se obtuvieron los requisitos), se determinan criterios deaceptacin y rechazo, se eligen a los participantes y se define lugar y fechapara la inspeccin. Los participantes tienen que ser informados sobre lo que seva a revisar (entregar copias del material que conforma el panoramainformativo).

Paso 2 (Do): Cada miembro del equipo de revisin se prepara de maneraindividual mediante el anlisis del material que se le hizo llegar. La junta deinspeccin es llevada a cabo.

Paso 3 (Check): Se identifican los defectos que se hayan encontrado en el

material revisado (Requisitos mal escritos, inconsistentes, ambiguos oconfusos, irreales o contradictorios, etc.) y se documentan.

Paso 4 (Act): Implica la correccin de los defectos que se hayan encontrado ascomo 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 ciertotrabajo para su preparacin y que involucra un plan de verificacin de pruebas.

Cada cheklist es diseado de manera que cubra los distintos aspectos que debecumplir un producto revisado para ser aprobado. Consulte el Anexo 1 para ver un ejemplo dechecklist dirigido a verificar la correcta redaccin de un requisito.


6/9


3. Planear la revisin

Para verificar adecuadamente los requisitos se requiere determinar los distintosaspectos que se tienen que revisar y aprobar para poder decir que los requisitos estn listospara pasar a la siguiente fase.

Es responsabilidad del equipo de diseo determinar lo mnimo que un ERS (y cualquierproducto de la fase de requerimientos) debe cumplir para que pueda ser aceptado comoentrada 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 laIngeniera de Requisitos de manera que nos aseguremos que cumplan las especificaciones ycualidades 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 ascomo 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 latrazabilidad. Podemos identificar tres tipos de trazabilidad: hacia adelante, hacia atrs y entrerequisitos. A continuacin se presenta una breve descripcin de stos tipos de trazabilidad ycmo lograr cada una de stas cualidades. En el Anexo 2 se puede consultar un ejemplo decmo registrar requisitos hacindolos trazables hacia adelante, hacia atrs y entre ellosmismos.

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 quepermita hacer referencia en cada requisito hacia los elementos posteriores que implementan talrequisito.

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 delcliente de las cuales surge el requisito.


7/9


4.3. Trazabilidad entre requisitos

Se refiere a que debe ser posible identificar de cada requisito aquellos otros con loscuales guarda alguna relacin, sea por la necesidad uno del otro por la simple implicacin entreellos.

Nuevamente, para poder obtener sta cualidad, el registro del requisito debe permitirreferenciar a aquellos con los cuales guarda relacin.

4.4. Implicaciones

Es evidente la necesidad de un formato que permita reunir las caractersticassealadas anteriormente; tambin es necesario determinar alguna nomenclatura estndar paralos requisitos que permita y facilite la referenciacin entre s mismos con el objetivo de lograr losdistinto tipos de trazabilidad.

Es buena idea nombrar los requisitos mediante un estndar que tiene que ser definidopor 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 losconocimientos 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 deMatemticas de la Universidad Autnoma de Yucatn.


8/9


Anexo 1: Checklist para verificar la correcta redaccin de requerimientos

AspectoValoracin

ObservacionesS No No aplica

El requerimiento posee un tipo de usuarioque ser beneficiado o que lo utilizar?El requerimiento expresa lo que deseaalcanzar el usuario?El requerimiento posee un objeto es sudescripcin?El requerimiento posee una frase adverbial(calificador)?El requerimiento es un enunciado simple?El requerimiento est enunciado en vozactiva?El requerimiento utiliza un vocabulariolimitado?

El requerimiento evita palabras tcnicasque pudieran confundir a lectores notcnicos?El requerimiento comienza con un nombreo tipo de usuario?El requerimiento se centra en los resultadosindicados?El requerimiento evita conjunciones?El requerimiento evita el uso de frasesambiguas como aceptable, adecuado,muy til, no ms de, etctera?El requerimiento evita opciones? (frases

como si, siempre y cuando, excepto, amenos que, etc.)El requerimiento evita incluir el diseo ensu descripcin?El requerimiento evita especulaciones?(frases como usualmente, generalmente,a menudo, etc.)El requerimiento carece de expresionesirreales? (frases como seguro, totalmenteconfiable, nunca falla, etc.)El requerimiento est escrito gramatical yortogrficamente de manera correcta?

El requerimiento se apega al glosario?El requerimiento evita sinnimos?El requerimiento carece de pronombres ensu descripcin?El requerimiento est escrito en formatecnolgicamente neutra?


9/9


Anexo 2: Asegurando la trazabilidad de los requisitos

Requisito # Categora: Tipo: Elija el tipoPrioridad: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 Trazabilidad hacia adelante

Identificador del requerimientode usuario. Debe seguir unanomenclatura estandarizadaen la empresa. Ejemplo: U1

La necesidad del usuario ID del requerimiento funcional(o de los requerimientosfuncionales) donde se reflejaste requerimiento deusuario. Ejemplo: S2, S7

Figura 2: Plantilla de registro para asegurar trazabilidad hacia adelante.

ID Requerimiento funcional Trazabilidad hacia atrs

Identificador del requerimientode sistema. Debe seguir unanomenclatura estandarizadaen la empresa. Ejemplo: S1

El requerimiento en el cual serefleja la necesidad (total o

parcialmente) del usuario.

ID del requerimiento deusuario de donde surge sterequerimiento funcional.Ejemplo: U1

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

Documents

92756471-Plan-de-Verificacion-de-Requerimientos.docx