Capacitacitación Tester - QA 2

Capacitación Tester
QA

Abril, 2011

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.

Contexto del Negocio
Esfuerzo Típico para Encontrar y Corregir Defectos.

Requirements 82%
Design 13%
OTHER 4%
CODE 1%

¿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 or
achieve 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 imposed
document.”
“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 ser
implementado. Una descripción de cómo el sistema, producto o
servicio debe comportarse con sus propiedades y atributos. Inclusive
considerando también las restricciones y premisas para el proceso
de desarrollo.”

Tres Niveles de Requerimientos:
= Entrada

Requerimientos
de Negocio

= Documento Formal

Documento de Visión y Alcance
Requerimientos
de Usuario

Atributos de
Calidad

Documento de Visión y Alcance
Requerimientos
del Sistema

Reglas de
Negocio

Requerimientos
Funcionales

Interfaces
Externas
Restricciones

Especificación de Requerimientos de Software (SRS)

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 alcance
de un proyecto.

Un Objetivo del Proyecto se convertirá en un Requerimiento de
Negocio.

Requerimiento de Usuario:
Describe las tareas y procesos que se deben realizar para llevar a
buen término el producto o servicio.

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

Requerimiento Funcional:
Define la funcionalidad detallada del sistema que los
desarrolladores o áreas deben construir o elaborar en el producto o
servicio, que habiliten al usuario para llevar a cabo sus tareas y de
este modo satisfacer las necesidades del requerimiento de usuario y
de negocio en consecuencia.
Los Requerimientos Funcionales deben escribirse sin utilizar
lenguaje técnico, ni incluir partes de la solución técnica, sólo deben
avocarse a lenguaje de negocio.

Componentes de Ingeniería de Requerimientos:
Ingeniería de Requerimientos

Desarrollo de
Requerimientos

Obtención

Manejo de
Requerimientos

Análisis
(Entender)

Especificación
re-escribir

clarificar

re-evaluar
corregir y cerrar
diferencias

Verificación

Componentes de Ingeniería de Requerimientos:
Desarrollo de Requerimientos:

Manejo de Requerimientos:

• Recabe las necesidades de los
usuarios que representan todas
las clases de usuario.
• Entienda las tareas y los objetivos
del usuario.
• Entienda la importancia relativa de
la calidad de los atributos.
• Negocie las prioridades de
implementación.
• Traduzca las necesidades del
usuario a especificaciones y a
modelos escritos.
• Revise los documentos de los
requerimientos.

• Establezca y mantenga un acuerdo
con el cliente sobre los requerimientos.
• Controle los requerimientos formales del
software.
• Procese los cambios de
requerimientos propuestos a
través de un control de cambios
formal.
• Mantenga los planes y productos
consistentes con los
Requerimientos cambiantes.
• Negocie nuevos compromisos
basados en el impacto de los
cambios.

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

Caracterí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

Escribiendo Requerimientos Eficaces:
 Evalúe desde la perspectiva del desarrollador.
 Documente en una forma jerárquica y estructurada:
-Incluya comportamientos esperados y condiciones de
excepció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.

Escribiendo 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 de
nuevos
requerimientos y elementos de rastreo subsecuentes resultado de requisiciones
de cambio durante el proyecto o mejoras en subsecuentes liberaciones de
mantenimiento (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 de
nuevos
requerimientos y elementos de rastreo subsecuentes resultado de requisiciones
de cambio durante el proyecto o mejoras en subsecuentes liberaciones de
mantenimiento (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 comportamiento
esperado.
– Revise los casos de prueba contra los requerimientos y modelos.

Maneje las Versiones de los documentos de requerimientos.

Adopte y haga cumplir un Proceso de control de cambios de
requerimientos:
– Defina el procedimiento para proponer, evaluar, decidir
sobre cambios.
– Apoye el procedimiento con una herramienta de seguimiento de
defectos.
– Defina el estatus de una requisición de cambios y un modelo
estado-transición (antes-después).
– Establezca un Consejo de Control de Cambios para tomar
decisiones 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.

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 la
construcció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, de
seguimiento de estatus.

Capacitacitación Tester - QA 2

Más contenido relacionado

Destacado (20)

Similar a Capacitacitación Tester - QA 2 (20)

Más de Professional Testing (20)

Último (20)

Capacitacitación Tester - QA 2