Celulares y
Laptops
Tiempo del
curso
Asistencia
Preguntas
Break
Evaluacin
Agenda
Creando Requerimientos Eficaces
Anlisis de Ambigedades
Proceso de Pruebas Basadas en Requerimientos (RBT)
Revisin de Ambigedad
Ejercicio Prctico
Objetivo
Proporcionar a los participantes los conceptos del Proceso de
Administracin de Requerimientos, tomando en cuenta Requirements &
Testing
Describir los detalles del proceso para desarrollar un conjunto de
requerimientos claros y entendibles
Proporcionar una aplicacin prctica a travs de ejemplos
Requirements
Requerimientos
56%
Diseo
Design
27%
Codificacin
Code
Otros
Other
10%
7%
Source: James Martin
Requerimientos
Requirements
82%
Diseo
Design
13%
Otros
Other
Codificacin
Code
4%
1%
Source: James Martin
Qu es un Requerimiento Efectivo?
Requerimientos
de Negocio
= Documento Formal
Documento de Visin y Alcance
Reglas de
Negocio
Requerimientos
de Usuario
Atributos de
Calidad
Requerimientos
Funcionales
Interfaces
Externas
Restricciones
10
Ingeniera de Requerimientos
Manejo de
Requerimientos
Desarrollo de
Requerimientos
Obtencin
Anlisis
(Entender)
clarificar
Especificacin
Verificacin
re-escribir
re-evaluar
corregir y cerrar
diferencias
11
12
13
14
Desarrollo de Requerimientos
Manejo de Requerimientos
15
10.Fcil de Seguir
16
17
18
Inequvoco
Cada lector obtiene solamente una interpretacin del requerimiento
Mltiples lectores llegan la misma interpretacin
Escrito en un lenguaje simple, claro y conciso del rea de la aplicacin
Verificable
Se puede verificar la implementacin correcta a travs:
Pruebas
Inspeccin
Demostracin
No se puede verificar si es ambiguo, inconsistente, incorrecto o no viable
19
Completo
No faltan requerimientos o informacin esencial!
Use TBD (A Ser Determinado) para sealar lo que esta incompleto
Documentar como los TBDs sern resueltos
Contine con el diseo y el desarrollo a su propio riesgo!
Lo completo tambin se aplica a los requerimientos individuales (por
ejemplo un requerimiento funcional especifica lo que debe y no debe
hacer el sistema)
Consistentes
No existe conflicto con requerimientos de alto nivel
No existe conflicto con otros requerimientos funcionales
20
Modificable
Cada requerimiento tiene un identificador nico
Los requerimientos son expresados individualmente/singularmente
Los requerimientos no contienen redundancias
Fcil de Seguir
Cada requerimiento tiene un identificador nico
Todos los requerimientos son escritos con un alto grado de detalle
No contiene listas en vietas (Bullets) ni prrafos largos
21
22
23
Reglas de Negocio
Validaciones
24
Reglas de Negocio
Ejemplos:
Cuando un cliente desea cancelar una tarjeta de crdito se requiere verificar que
no exista saldo pendiente en la tarjeta a cancelar. Si la tarjeta a cancelar no
presenta saldo pendiente proceder a cancelar la tarjeta; en caso contrario, se le
notifica al cliente que tiene un adeudo y no se puede cancelar su tarjeta.
No se puede dar de alta un cliente si no tiene algn producto o servicio
asociado.
25
Validaciones
A nivel de requerimientos, son las condiciones especficas que deben ser
consideradas para cumplir con l.
La diferencia con una Regla de Negocio, radica en que la Regla describe la
forma de operacin del negocio, mientras que las validaciones son
caractersticas especficas que deben cumplir un componente de software.
Son aquellas preferencias que se tengan en la operacin del requerimiento.
Normalmente las validaciones ayudan a que se cumplan las reglas de negocio.
26
Validaciones
Ejemplos:
Verificar que en una pantalla de captura de informacin, se haya introducido
primero el nmero del cliente antes de seleccionar un producto asociado.
Verificar que el nmero de cliente contenga todos los dgitos necesarios sea
un nmero vlido.
Que algn archivo cumpla con cierto layout antes de cargarlo.
Si se introduce el nmero de telfono, que se inhabilite la captura del correo
electrnico.
27
28
29
Valor %
costo % + riesgo %
Copyright 2013 HITSS
30
31
32
Lineamientos de Identificadores
Utilice una convencin simple, consistente
Utilice abreviaciones alfabticas para categorizar por tipo (por ejem. BR para Business
Requirements)
Combine el identificador de categora alfabtico con un numero nico
Numere en incrementos de por lo menos 10 para permitir la insercin de nuevos
requerimientos y elementos de rastreo subsecuentes resultado de requisiciones de
cambio durante el proyecto o mejoras en subsecuentes liberaciones de mantenimiento
(por ejem., BR010, BR020, BR030)
Ejemplo de Esquema de Identificadores
33
Descomposicin de Requerimientos
Cambios Organizacionales
Equipo
Infraestructura de Negocio
Procesos y Procedimientos
Pruebas
Productos y Servicios
Red
Recursos Humanos
Seguridad
Sistemas
RF0001
Proyecto:
CM/BE001
RU001
RU002
RF0002
RF0003
RU003
34
35
36
37
38
39
Sintomas
Los interesados (stakeholders) discuten requerimientos" sin adjetivo
calificativo.
El patrocinador de proyecto presenta un concepto de alto nivel como "los
requerimientos.
Las pantallas de interfase de usuario son vistas como los
requerimientos.
Los usuarios proporcionan requerimientos, pero los desarrolladores
todava no saben qu construir.
Los requerimientos se enfocan solo en funcionalidad, y descuidan otras
categoras de requerimientos.
Puede sugerir algunas soluciones?
40
41
Sntomas
Algunas clases de usuario se pasan por alto
Algunas clases de usuario no tienen voz
Sustitutos de usuarios tratan de hablar por ellos, por ejemplo:
gerentes de los usuarios
mercadotecnia
desarrolladores
Los desarrolladores tienes que hacer muchas decisiones
requerimientos
Los usuarios rechazan el producto cuando lo ven por primera vez
de
42
Soluciones
Identifique y defina todas las clases de usuarios
Identifique a los dueos del producto como un representante de
usuarios
Convoque a grupos de enfoque
Identifique al personal autorizado para hacer decisiones e involcrelos
Haga que los usuarios evalen los prototipos
Haga que los representantes de usuarios revisen a fondo los
documentos de requerimientos
43
Sntomas
Los lectores interpretan un requerimiento de diversas maneras
Falta informacin en los requerimientos que los desarrolladores necesitan
Los requerimientos no son verificables (es decir., falta informacin que los
probadores necesitan)
Los desarrolladores/probadores tienen que hacer muchas preguntas
Los desarrolladores/probadores tienen que suponer muchas cosas
44
45
46
Soluciones
Alinee los requerimientos funcionales con los requerimientos del negocio
Alinee los requerimientos funcionales con los requerimientos de
usuario/casos de uso prioritarios, basados en:
Frecuencia de uso
Procesos de negocio medulares
Cumplimiento de regulaciones obligatorias
Defina categoras de prioridad sin ambigedades
Asigne requerimientos o caractersticas a las liberaciones
Priorice analticamente los requerimientos
47
Sntomas
Los usuarios exigen ciertas caractersticas, despus nadie las usa
La funcionalidad propuesta no est relacionada con las tareas del negocio
Los desarrolladores agregan una funcin porque a los usuarios les
gustar
Los usuarios no distinguen lo trivial" de lo importante
Puede sugerir algunas soluciones?
48
Soluciones
Derive los requerimientos funcionales de los casos de uso
Ligue cada requerimiento funcional a su origen en una tarea de negocio
Identifique las clases de usuarios que se beneficiarn con cada
caracterstica
Analticamente priorice los requerimientos, casos de uso, o caractersticas
Haga que los clientes estimen el valor (Beneficio o Consecuencia)
Haga que los desarrolladores estimen el costo y riesgo
Evite los requerimientos de alto costo y bajo valor
Recuerde que lo est bien hecho es porque se hace bien
49
Sntomas
El desarrollo de requerimientos parece nunca acabar
Se liberan continuamente nuevas versiones de los requerimientos
Los requerimientos nunca son formalizados
Todos los requerimientos se modelan repetidamente, en mltiples formas
Diseo y codificacin no empiezan hasta que el documento de
requerimientos esta perfecto
Puede sugerir algunas soluciones?
50
51
52
53
54
Soluciones
Defina un proceso prctico de control de cambios
Establezca un Consejo de Control de Cambios
Grupo diverso
Hacen decisiones de cambios que comprometen
Utilice una herramienta para recabar, darle seguimiento, y comunicar los
cambios
Una herramienta de seguimiento de problemas que trabaje bien
Una herramienta no es un proceso!
Establezca y haga cumplir las polticas de control de cambios
Compare las prioridades contra los requerimientos restantes.
55
Sntomas
La gente acuerda precipitadamente en hacer cambios
Un cambio es mas complejo que lo anticipado
Un cambio lleva mas tiempo de lo prometido
Un cambio no es tcnicamente viable
Un cambio causa retrasos en el proyecto
Los desarrolladores encuentran mas componentes del sistema afectados
por el cambio
Los probadores siguen encontrando mas pruebas afectadas por el cambio
56
Soluciones
Analice sistemticamente el impacto de cada cambio propuesto
identifique todas las tareas posibles (cambiantes o nuevas)
considere otras implicaciones de aceptar el cambio
estime el esfuerzo y el impacto al programa
Utilice informacin de seguimiento de los requerimientos para identificar
todos los componentes del sistema y casos de prueba afectados
Estime los costos y beneficios antes de hacer compromisos
57
Sntomas
No se incorporan los cambios aceptados en los documentos apropiados de
requerimientos
No puede distinguir las diferentes versiones de los documentos de
requerimientos
diferentes versiones tienen el mismo identificador
documentos idnticos tienen diferentes identificadores
La gente trabaja de diferentes versiones de requerimientos
los desarrolladores implementan caractersticas canceladas
los probadores hacen pruebas en requerimientos equivocados
Se pierde la historia de cambios y versiones de documentos anteriores
58
Soluciones
Incorpore los cambios en los documentos de requerimientos apropiados
Adopte un esquema de versiones para los documentos
Ponga los documentos de requerimientos bajo un control de versiones
Restringa el acceso de leer/escribir
Haga las versiones actuales inalterables a todos los miembros del
proyecto
Comunique las revisiones a todos los afectados
Guarde los requerimientos en un deposito de requerimientos
Registre la historia completa de cada cambio del requerimiento
59
ANLISIS DE AMBIGEDADES
60
2.Inequvoco
3.Correcto
11.Explicito
4.Completo
5.No-redundante
14.Conciso y preciso
15.Priorizado
16.Viable
61
62
Proceso RBT:
Que es Pruebas Basadas en Requerimientos?
63
Proceso RBT
Definir
Requerimientos
Documento de
Requerimientos
Constru Correctamente el Sistema?
Pruebas de
Sistema
Control de
Liberacin
Especificaciones
Funcionales
Diseo de
Arquitectura
Pruebas de
Integracin
Documentos
de Diseo
Identificar
Casos de
Prueba
Diseo Tcnico
Detallado
Crear
Procedimientos
de Prueba
Pruebas
Unitarias
Documentos
de Diseo
Construccin
Verificacin
(Pruebas Estticas)
Tiempo
Validacin
(Pruebas Dinmicas)
Prueba de
Sanidad
Desarrollo y Ejecucin
Desarrollar
Escenarios de
Prueba
Anlisis del
Diseo
Funcional
Ambiente
Controlado
Casos de Prueba/Datos
Preparar la
Estrategia
de Pruebas
Pruebas de
Desempeo y
Aprobacion
64
Sin RBT
UAT
5%
Entregado
al Cliente
15%
65
Inspeccin
RBT
65 - 90%
Con RBT
Aprox.
10-35%
Pruebas
10 - ~35%
Entregado al Cliente
.015%
66
Proceso RBT:
Pasos Bsicos
1. Validar requerimientos
comparado con los objetivos
2. Aplicar casos de uso en base a
los requerimientos
3. Realizar un anlisis inicial de
ambigedad
4. Realizar una revisin de
contenido por especialistas en
la materia
5. Graficacin de causa-efecto
6. Realizar revisiones de
consistencia lgica y diseo de
casos de pruebas
67
Proceso RBT:
Principales Tcnicas Especficas Para Pruebas
Revisin de Ambigedad
Utilizado en la fase de la determinacin de los requerimientos de un
proyecto para identificar cualquier cosa que sea confusa, ambigua,
inconsistente o incompleta en los requerimientos, con el objetivo de
mejorar su calidad
Llevada a cabo con una inspeccin formal (es decir, componente de
Revisin de Productos de Trabajo [WPR])
Es el enfoque de esta sesin de entrenamiento
Graficacin de Causa-Efecto
Una tcnica de diseo de casos de prueba, utilizada una vez que los
requerimientos han sido revisados por ambigedad y contenido
Obtenga el mnimo de casos de prueba para cubrir el 100% de los
requerimientos funcionales
Apoyado por la herramienta BenderRBT
68
Proceso RBT:
69
Revisin de Ambigedad:
Un Ejemplo Simple
70
Revisin de Ambigedad:
Ejercicio de Practica #3
Requerimiento de Negocio Antes de la Revisin de
Ambigedad
El Cajero Automtico (ATM) enviar una alarma al
departamento de tecnologa de la informacin (IT) cuando
el ATM se ha tratado de forzar. En caso que el ATM se
abra sin la llave y el cdigo de seguridad, el ATM alertar
al departamento inmediatamente para que pueda tomar la
accin apropiada.
71
Resumen
Claves para Requerimientos Excelentes
72
La meta fundamental es
NO
SORPRESAS!
73
GRACIAS