capacitacitación tester - qa 2

Capacitación TesterQA

Abril, 2011

REQUERIMIENTOSMódulo 1

Creando Requerimientos Eficaces

Razones Claves de los Fracasos de Proyectos

Requerimientos vagos, ambiguos, incorrectos, inconsistentes, y/o incompletos.

No se involucra al usuario, el usuario no participa y no acepta los resultados.

Muchos cambios a través de la vida del proyecto.

Creando Requerimientos EficacesContexto del Negocio

Esfuerzo Típico para Encontrar y Corregir Defectos.

Requirements 82%

Design 13%

OTHER 4%

CODE 1%

Creando Requerimientos Eficaces¿Qué es un Requerimiento?

WEBSTER’S DICTIONARY:“Something wanted or needed.”

“Algo deseado o necesario.”

IEEE STD. 610.12-1990, GLOSSARY OF SOFTWARE ENGINEERING TERMINOLOGY:“(1) A condition or capability needed by a user to solve a problem orachieve an objective.”

“Una condición o capacidad necesaria por un usuario para resolver un problema o alcanzar un objetivo.”

“(2) A condition or capability that must be met or possessed by a system ... to satisfy a contract, standard, specification, or other formally imposeddocument.”

“Una condición o capacidad que debe alcanzar o poseer un sistema … para satisfacer un contrato, estándar,especificación o un documento impuesto formalmente.”


¿Qué es un Requerimiento Efectivo?

“Los Requerimientos son … las especificaciones de lo que debe serimplementado. Una descripción de cómo el sistema, producto oservicio debe comportarse con sus propiedades y atributos. Inclusiveconsiderando también las restricciones y premisas para el procesode desarrollo.”

Creando Requerimientos EficacesTres Niveles de Requerimientos:

Requerimientosde Negocio

Requerimientosde Usuario

RequerimientosFuncionales

Documento de Visión y Alcance

Especificación de Requerimientos de Software (SRS)

Requerimientosdel Sistema

Reglas deNegocio

Atributos deCalidad

InterfacesExternas

Restricciones

Documento de Visión y Alcance

= Entrada

= Documento Formal


Requerimiento de Negocio:

Están ligados a los objetivos de alto nivel de una organización,proyecto o cliente, requiriendo un producto, servicio o sistema.

Son contenidos en el documento que describe la visión y alcancede un proyecto.

Un Objetivo del Proyecto se convertirá en un Requerimiento deNegocio.


Requerimiento de Usuario:

Describe las tareas y procesos que se deben realizar para llevar abuen término el producto o servicio.

Ejemplo:Puede haber un Requerimiento de Usuario de tipo “CambioOrganizacional”, de “Sistemas”, de “Procesos y Procedimientos”, etc.


Requerimiento Funcional:

Define la funcionalidad detallada del sistema que losdesarrolladores o áreas deben construir o elaborar en el producto oservicio, que habiliten al usuario para llevar a cabo sus tareas y deeste modo satisfacer las necesidades del requerimiento de usuario yde negocio en consecuencia.

Los Requerimientos Funcionales deben escribirse sin utilizarlenguaje técnico, ni incluir partes de la solución técnica, sólo debenavocarse a lenguaje de negocio.

Creando Requerimientos EficacesComponentes de Ingeniería de Requerimientos:

Verificación

corregir y cerrar diferencias

Ingeniería de Requerimientos

Desarrollo de

Requerimientos

Manejo de

Requerimientos

ObtenciónAnálisis

(Entender) Especificación

re-evaluar

re-escribirclarificar

Creando Requerimientos EficacesComponentes de Ingeniería de Requerimientos:

Desarrollo de Requerimientos:

• Recabe las necesidades de los usuarios que representan todaslas clases de usuario.

• Entienda las tareas y los objetivos del usuario.

• Entienda la importancia relativa de la calidad de los atributos.

• Negocie las prioridades deimplementación.

• Traduzca las necesidades del usuario a especificaciones y a modelos escritos.

• Revise los documentos de losrequerimientos.

La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

Manejo de Requerimientos:

• Establezca y mantenga un acuerdocon el cliente sobre los requerimientos.

• Controle los requerimientos formales delsoftware.

• Procese los cambios derequerimientos propuestos através de un control de cambiosformal.

• Mantenga los planes y productosconsistentes con losRequerimientos cambiantes.

• Negocie nuevos compromisosbasados en el impacto de loscambios.

Creando Requerimientos EficacesCaracterísticas:

1. Correcto

2. Viable

3. Necesario

4. Priorizado

5. Inequívoco

6. Verificable

7. Completo

8. Consistente

9. Modificable

10.Fácil de Seguir

Creando Requerimientos EficacesEscribiendo Requerimientos Eficaces:

Evalúe desde la perspectiva del desarrollador. Documente en una forma jerárquica y estructurada:

-Incluya comportamientos esperados y condiciones deexcepción.

-No restrinja las opciones de diseño.

Mantenga cortas las frases y párrafos:-Utilice gramática, ortografía y puntuación apropiada.-Utilice los términos consistentemente.-Defina los términos en un glosario.

Evite requerimientos redundantes.

Evite requerimientos contradictorio.

Creando Requerimientos EficacesEscribiendo Requerimientos Eficaces:

Escriba los requerimientos a un alto grado de detalle:– Evite los párrafos largos.– Tenga cuidado con el uso de "y" y "o", que sugieren que hay

requerimientos múltiples combinados.– Evite listas en viñetas (Bullets).– Identifique cada requerimiento.– Organice en tablas los requerimientos similares.

Sea preciso y específico:– Use “debería” o “debe”, no use “podría,” “pudo,” “pueda”.– Evite palabras ambiguas: minimizar, maximizar, optimizar,rápido, de uso amigable, fácil, simple, intuitivo, robusto,avanzado, mejorado, eficiente, flexible, opcionalmente,suficiente, razonable.


Lineamientos de Identificadores:

Utilice una convención simple, consistente.

Utilice abreviaciones alfabéticas para categorizar por tipo (por ejem. BR para“Business Requirements”).

Combine el identificador de categoría alfabético con un numero único.

Numere en incrementos de por lo menos 10 para permitir la inserción denuevosrequerimientos y elementos de rastreo subsecuentes resultado de requisicionesde cambio durante el proyecto o mejoras en subsecuentes liberaciones demantenimiento (por ejemplo: BR010, BR020, BR030).



Ejemplo de Esquema de Identificadores:

Requerimientos de Negocios BR + número único Requerimientos de Usuarios UR + número único Requerimientos de Sistema SR + número único Diseño de Arquitectura AD + número único Diseño Detallado DD + número único Componente de Aplicación AC + número único Caso de Prueba:

-Prueba de Aceptación de Usuario UAT + número único-Prueba de Aceptación Operacional OAT + número único-Prueba de Desempeño PT + número único-Prueba de Sistema ST + número único



Utilice una convención simple, consistente.

Utilice abreviaciones alfabéticas para categorizar por tipo (por ejemplo BR para“Business Requirements”).

Combine el identificador de categoría alfabético con un numero único.

Numere en incrementos de por lo menos 10 para permitir la inserción denuevosrequerimientos y elementos de rastreo subsecuentes resultado de requisicionesde cambio durante el proyecto o mejoras en subsecuentes liberaciones demantenimiento (por ejemplo: BR010, BR020, BR030).


Mejores Prácticas para Documentar Requerimientos:

Inspección formal de documentos de requerimientos:– Mucho más barato encontrar y corregir defectos en la etapa de

requerimientos.– Incluir a los clientes, diseñadores, probadores.– Utilice listas de comprobación de los errores comunes de

requerimientos.

Pruebas basadas en requerimientos:– Derive los casos de prueba de los casos de uso y

requerimientos funcionales.– Los casos de prueba cristalizan una visión de comportamientoesperado.

– Revise los casos de prueba contra los requerimientos y modelos.

Creando Requerimientos EficacesMejores Prácticas para Documentar Requerimientos:

Maneje las Versiones de los documentos de requerimientos.

Adopte y haga cumplir un Proceso de control de cambios derequerimientos:

– Defina el procedimiento para proponer, evaluar, decidirsobre cambios.

– Apoye el procedimiento con una herramienta de seguimiento dedefectos.

– Defina el estatus de una requisición de cambios y un modeloestado-transición (antes-después).

– Establezca un Consejo de Control de Cambios para tomardecisiones y que haga cumplir el proceso de control de cambios.

Análisis de impacto de cambios de requerimientos:– Involucre al usuario, diseñador, probador.– Identifique los componentes del sistema afectados por el cambio.– Identifique las tareas que se tendrían que efectuar.– Estime el esfuerzo, costo, otros impactos.


Mejores Prácticas para Documentar Requerimientos:

Matriz de seguimiento de requerimientos:- Ligar requerimientos a su origen.- Ligar requerimientos a diseño, código, casos de prueba.- Ayuda a evitar pasar por alto requerimientos durante laconstrucción.- Facilita el mantenimiento y análisis de impacto.

Seguimiento de estatus de requerimientos:- Propuestos, aprobados, implementados, verificados, suprimidos.- Permite un más preciso seguimiento de estatus del proyecto.

Utilice una herramienta de manejo de requerimientos:- Guarde los requerimientos y sus atributos en una base de datos.-Defina ligas de seguimiento, formalice los requerimientos, deseguimiento de estatus.

capacitacitación tester - qa 2

Technology