Plan de Verificación de Requerimientos

5/17/2018 Plan de Verificaci n de Requerimientos - slidepdf.com

http://slidepdf.com/reader/full/plan-de-verificacion-de-requerimientos 1/9

Plan de Verificación de RequerimientosAutor: Canté Cauich Amado

Rev. 1.0.



Desarrollo de Requisitos de Software Amado Canté Página 2 de 9

Tabla de Contenido

Tema Página1. Introducción 3

1.1. Panorama 31.2. Propósito 31.3. Alcance 3

2. Probando los requerimientos mediante revisiones técnicas 32.1. Revisiones técnicas 3

2.1.1. Caminatas Estructuradas (Structured Walkthroughs) 32.1.1.1. Ejecución 4

2.1.2. Inspecciones 52.1.3. Checklists 5

3. Planear la revisión 64. Asegurar la trazabilidad 6

4.1. Trazabilidad hacia adelante 64.2. Trazabilidad hacia atrás 6

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

Anexo 1 8Anexo 2 9




1. Introducción

1.1. Panorama

La fase de desarrollo de requerimientos es quizá la más 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 diseño,codificación y pruebas; sin embargo la ejecución 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 especificaciónde requisitos verdaderamente adecuada y conforme a las necesidades del cliente.

1.2. Propósito

Éste Plan de Verificación de Requisitos (PVR) tiene por objetivo proporcionar unametodología para la verificación de requisitos de manera que sea posible asegurarse de quecubren las necesidades del cliente, se escriban de una forma tecnológicamente neutra yprecisa, sean trazables, no ambiguos, completos, consistentes, clasificados, verificables ymodificables.

1.3. Alcance

El presente Plan de Verificación de Requisitos se limita a proporcionar técnicasformales de verificación de requisitos y una breve descripción de la manera de ejecutar cadauna de ellas.

2. Probando los requerimientos mediante revisiones técnicas

La definición de requerimientos es el resultado del pensamiento creativo y es la basedel diseño. La fase de requerimientos es verificada con técnicas estáticas, esto es, sin laejecución de la aplicación puesto que ésta aún no existe. Ésas técnicas verifican el apego delos requisitos a las convenciones de especificación, completitud, trazabilidad, consistencia,verificabilidad y demás características mencionadas en el apartado 1.

2.1. Revisiones técnicas

2.1.1. Caminatas Estructuradas (Structured Walkthroughs)

Una Caminata Estructurada es una revisión en la cual un participante de revisión,usualmente la persona (o equipo) que desarrolló el producto a revisar narra una descripción delproducto y el resto del grupo provee retroalimentación durante la presentación.

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.




2.1.1.1. Ejecución

Idealmente se conforma un equipo que debería 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 revisión. La secretaria o el escriba, que toma notas de lo tratado en la revisión, elabora y

distribuye minutas de la reunión. El oráculo del mantenimiento, que revisa el producto desde el punto de vista del

mantenimiento futuro. Verifica la trazabilidad de los requisitos. El portador de estándares, quien se asegurará de que los procesos o

estándares 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 diseño. El cronometrador, quien se asegurará de que los límites de tiempo sean

respetados y que la reunión no sobrepase el tiempo preestablecido. Otros revisadores, que deben tener un alto entendimiento del producto que se

está revisando, en éste caso se debería incluir al resto del equipo involucradoen la obtención de los requisitos o cuando menos a una parte representativa deéste.

Antes de la revisión

Cada integrante del equipo de revisión debe prepararse mediante la pre-revisión de

una copia avanzada del documento o documentos a revisar que debe haber sido distribuida atodos los miembros del equipo de revisión. La preparación es de manera individual.

Durante la revisión

Se emplean los checklists que se hayan diseñado para corroborar el apego de losrequerimientos a las normas y estándares preestablecidas.

Después de la revisión

Se preparan los documentos de la sesión (minutas, notas tomadas por el escriba,etcétera) y se generan recomendaciones para el equipo cuyo trabajo fue revisado.

Se debe emitir un fallo que puede ser una y sólo una de las opciones siguientes: Producto totalmente aceptado, en cuyo caso significa que los requisitos están

listos para pasar a la fase de diseño. Producto parcialmente aceptado, en éste caso se harán las recomendaciones

pertinentes al equipo cuyo trabajo fue revisado para que el trabajo pueda pasara la fase de diseño.




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

2.1.2. Inspecciones

La inspección es una técnica de revisión sistemática, controlada y menos estresanteque la caminata estructurada. Una inspección 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 larevisión y la junta de revisión misma.

Las inspecciones se realizan en cuatro pasos de acuerdo con el modelo PDCA del“Círculo de Deming” que es una estrategia de mejora continua de la calidad:

Paso 1 (Plan): En éste paso se planea la inspección, involucra lacalendarización del personal que va a participar. Se prepara una panorama dela información que se va a revisar (el ERS, las plantillas de requisitos,información sobre cómo se obtuvieron los requisitos), se determinan criterios deaceptación y rechazo, se eligen a los participantes y se define lugar y fechapara la inspección. 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 revisión se prepara de maneraindividual mediante el análisis del material que se le hizo llegar. La junta deinspección 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 corrección 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 técnica de verificación de requisitos que implica ciertotrabajo para su preparación y que involucra un plan de verificación de pruebas.

Cada cheklist es diseñado 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 redacción de un requisito.




3. Planear la revisión

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

Es responsabilidad del equipo de diseño determinar lo mínimo que un ERS (y cualquierproducto de la fase de requerimientos) debe cumplir para que pueda ser aceptado comoentrada para la fase de diseño 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 laIngeniería de Requisitos de manera que nos aseguremos que cumplan las especificaciones ycualidades de un buen requerimiento.

Se tiene que considerar los aspectos de buena redacción, evitar palabras ambiguas,ser realistas en la redacción, procurar que se permita la trazabilidad de los requerimientos asícomo los demás aspectos que se mencionan al inicio del documento.

4. Asegurar la trazabilidad

Uno de los aspectos más importantes que un buen requerimiento debe poseer es latrazabilidad. Podemos identificar tres tipos de trazabilidad: hacia adelante, hacia atrás y entrerequisitos. A continuación se presenta una breve descripción de éstos tipos de trazabilidad ycómo lograr cada una de éstas cualidades. En el Anexo 2 se puede consultar un ejemplo decómo registrar requisitos haciéndolos trazables hacia adelante, hacia atrás 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 diseño hasta unidades o módulos en el sistema implementado.

Para lograr éste tipo de trazabilidad, se debe mantener un estándar de registro quepermita hacer referencia en cada requisito hacia los elementos posteriores que implementan talrequisito.

4.2. Trazabilidad hacia atrás

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.




4.3. Trazabilidad entre requisitos

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

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

4.4. Implicaciones

Es evidente la necesidad de un formato que permita reunir las característicasseñaladas anteriormente; también es necesario determinar alguna nomenclatura estándar paralos requisitos que permita y facilite la referenciación entre sí mismos con el objetivo de lograr losdistinto tipos de trazabilidad.

Es buena idea nombrar los requisitos mediante un estándar que tiene que ser definidopor la empresa y al cual todos los miembros deben apegarse.

5. Fundamento

La información aquí planteada se basa principalmente en el libro “Software Testing and

Continuous Quality Improvement” de William E. Lewis en su segunda edición y de losconocimientos adquiridos en la asignatura de “Desarrollo de Requisitos de Software” que forma

parte del plan estudio de la Licenciatura en Ingeniería de Software de la Facultad deMatemáticas de la Universidad Autónoma de Yucatán.




Anexo 1: Checklist para verificar la correcta redacción de requerimientos

AspectoValoración

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 sudescripción?¿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 técnicasque pudieran confundir a lectores notécnicos?¿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 más de”, etcétera? ¿El requerimiento evita opciones? (frases

como “si”, “siempre y cuando”, “excepto”, “amenos que”, etc.) ¿El requerimiento evita incluir el diseño ensu descripción?¿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 yortográficamente de manera correcta?

¿El requerimiento se apega al glosario?¿El requerimiento evita sinónimos?¿El requerimiento carece de pronombres ensu descripción?¿El requerimiento está escrito en formatecnológicamente neutra?




Anexo 2: Asegurando la trazabilidad de los requisitos

Requisito # Categoría: Tipo: Elija el tipo Prioridad:Prioridad

Descripción:Una breve descripción del requisito

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

Origen:

¿Quién lo solicita? Dependencias: Referenciar los requisitos con los que guarda alguna dependencia o relación.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 adelanteIdentificador del requerimiento de usuario. Debe seguir una nomenclatura estandarizada en la empresa. Ejemplo: U1

La necesidad del usuario 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 Trazabilidad hacia atrásIdentificador del requerimiento de sistema. Debe seguir una nomenclatura estandarizada en la empresa. Ejemplo: S1

El requerimiento en el cual se refleja la necesidad (total o parcialmente) del usuario.

ID del requerimiento de usuario de donde surge éste requerimiento funcional.Ejemplo: U1

Figura 3: Plantilla de registro para asegurar la trazabilidad hacia atrás.

Documents

Plan de Verificación de Requerimientos