Análisis de Requerimientos

ANLISIS DE REQUERIMIENTOS
Taxonoma de pruebas de software

Reglas del Curso
Celulares y
Laptops
Tiempo del
curso
Asistencia
Preguntas
Break
Evaluacin
Copyright 2013 HITSS
Agenda
Creando Requerimientos Eficaces
Contexto Del Negocio

Que son Requerimientos?
Definiciones
Tres Niveles de Requerimientos
Componentes de Ingeniera de Requerimientos
Caractersticas de Requerimientos Eficaces
Escribiendo Requerimientos Eficaces
Mejores Prcticas Para Desarrollo de Requerimientos
Mejores Prcticas Para Manejo de Requerimientos
Riesgos en la Creacin de los Requerimientos y Cmo Evitarlos
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
Contexto del Negocio:
Razones Claves de los Fracasos de Proyectos
Indefinicin de la visin y alcance del proyecto

Desorden en las prioridades entre los clientes y
proveedores
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 travs de la vida del proyecto
Desorden en el seguimiento de los procesos
Distribucin Tpica de Defectos
Requirements
Requerimientos
56%
Diseo
Design
27%
Codificacin
Code
Otros
Other
10%
7%
Source: James Martin
Esfuerzo Tpico para Encontrar y Corregir Defectos
Requerimientos
Requirements
82%
Diseo
Design
13%
Otros
Other
Codificacin
Code
4%
1%
Source: James Martin
Que es un Requerimiento? - Perspectiva del Cliente

WEBSTERS 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 condicin 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 condicin o capacidad que debe alcanzar o poseer un sistema
para satisfacer un contrato, estndar, especificacin o un documento impuesto
formalmente
Qu es un Requerimiento Efectivo?
Los Requerimientos son las especificaciones de lo que debe ser

implementado. Una descripcin de cmo el sistema, producto o servicio
debe comportarse con sus propiedades y atributos. Inclusive considerando
tambin las restricciones y premisas para el proceso de desarrollo.
Deben Describir QU es lo que har

el sistema, NO el CMO lo har.
Tres Niveles de Requerimientos

= Entrada
Requerimientos
de Negocio
= Documento Formal
Documento de Visin y Alcance
Reglas de
Negocio
Requerimientos
de Usuario
Atributos de
Calidad
Documento de Casos de Uso

Requerimientos
del Sistema
Requerimientos
Funcionales
Interfaces
Externas
Restricciones
Especificacin de Requerimientos de Software (SRS)

Matriz de Administracin de Requerimientos
10
Componentes de Ingeniera de Requerimientos
Ingeniera de Requerimientos
Manejo de
Requerimientos
Desarrollo de
Requerimientos
Obtencin
Anlisis
(Entender)
clarificar
Especificacin
Verificacin
re-escribir
re-evaluar
corregir y cerrar
diferencias
11
Revisin de la ingeniera de Requerimientos:

Los Tres niveles de Requerimientos
Requerimiento de Negocio
Estn ligados a los objetivos de alto nivel de una organizacin, proyecto o
cliente, requiriendo un producto, servicio o sistema.
Son contenidos en el documento que describe la visin y alcance de un
proyecto.
Un Objetivo del Proyecto se convertir en un Requerimiento de Negocio.
12

Requerimiento de Usuario
Describe las tareas y procesos que se deben realizar para llevar a buen
trmino el producto o servicio
Ejemplo: Puede haber un Requerimiento de Usuario de tipo
Cambio Organizacional, de Sistemas, de Procesos y Procedimientos,
etc
13

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
tcnico, ni incluir partes de la solucin tcnica, slo deben avocarse a
lenguaje de negocio.
14
Desarrollo y Manejo 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
implementacin
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 travs 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
15

1.Correcto
2.Viable
3.Necesario
4.Priorizado
5.Inequvoco
6.Verificable
7.Completo
8.Consistente
9.Modificable
10.Fcil de Seguir
16

Correcto
Describe exactamente la funcionalidad que debe ser construida
El origen es una necesidad del usuario
Los usuarios deben participar en las revisiones de los requerimientos
Viable
Debe poderse implementar dentro de los lmites y restricciones
Basados en acuerdo entre los desarrolladores y los analistas del
negocio
Provee un chequeo de realidad en viabilidad y costo
17
Caractersticas de Requerimientos Eficaces cont..

Necesario
Originados de una autoridad conocida para especificar los requerimientos,
basados en:
Algo que los usuarios realmente necesitan
En conformidad a un estndar
Algo asignado o derivado de un requisito del sistema
Una regulacin del gobierno
Priorizado
Alto
=
Debe ser incluido en la siguiente liberacin
Mediano
=
Puede esperar a una liberacin futura si es
necesario
Bajo
=
Seria bueno tener algn da
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
Escribiendo Requerimientos Eficaces - 1
Evale desde la perspectiva del desarrollador

Documente en una forma jerrquica y estructurada
Incluya comportamientos esperados y condiciones de excepcin
No restrinja las opciones de diseo
Mantenga cortas las frases y prrafos
Utilice gramtica, ortografa y puntuacin apropiada
Utilice los trminos consistentemente
Defina los trminos en un glosario
Evite requerimientos redundantes
Evite requerimientos contradictorios
22
Escribiendo Requerimientos Eficaces - 2

Escriba los requerimientos a un alto grado de detalle.
Evite los prrafos largos
Tenga cuidado con el uso de "y" y "o", que sugieren que hay requerimientos
mltiples combinados
Evite listas en vietas (Bullets)
Identifique cada requerimiento
Organice en tablas los requerimientos similares
Sea preciso y especfico.
Use debera o debe, no use podra, pudo, pueda
Evite palabras ambiguas: minimizar, maximizar,
optimizar, rpido, de uso amigable, fcil, simple,
intuitivo, robusto, avanzado, mejorado,
eficiente, flexible, opcionalmente, suficiente, razonable
ESCRIBA LOS REQUERIMIENTOS NO SOLO PARA USTED.
23
Elementos Complementarios a un Requerimiento

Adems de la Definicin de un Buen Requerimiento, existen otros elementos a
considerar que lo afectan o lo complementan, y son importantes para el
entendimiento del requerimiento.
Estos elementos son:
Reglas de Negocio
Validaciones
Una Regla de Negocio describe o define el comportamiento de una Organizacin
Estn alineadas a las polticas de la Organizacin

Pueden aplicar a un solo requerimiento o son generales a un proceso, aplicando
a varios requerimientos.
Las Reglas de Negocio son Dinmicas, ya que dan movimiento a la
Organizacin
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.
Forma en que se calcula una comisin.
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
Mejores prcticas para Obtener Requerimientos
Identifique a los dueos del producto como representantes claves del

cliente
Debe representar a usuarios reales, no sustitutos
Sirve como la voz del cliente para una clase especifica de usuarios
Provee requerimientos, resuelve conflictos, define atributos
Debe estar autorizado apropiadamente
Desarrolle historias del usuario para obtener requerimientos

Define requerimientos de usuarios
Se enfoca en las tareas del usuario
Deriva requerimientos funcionales de la descripcin de las tareas
Deriva casos de prueba temprano en el proyecto
28
Mejores prcticas para Obtener Requerimientos cont..
Empiece por definir la visin del producto y el alcance del proyecto

Define los requerimientos del negocio
Proporciona el origen de los requerimientos de usuario y del sistema
propuestos
Controla el incremento no controlado del alcance
Fija prioridades del proyecto
Documente los atributos de calidad en el DRN
Visible para los usuarios e importante para los desarrolladores
Rena informacin de los dueos del producto
Escriba para ser cuantitativo y comprobable
29
Mejores prcticas para Anlisis de Requerimientos
Modelos de anlisis ofrecen mejor panorama de los requerimientos

ningn panorama dice todo lo que necesitas saber
diagrama de contexto, diagrama de flujo de datos, diagramas de estadotransicin (antes-despus), mapas de dialogo, modelos de anlisis de
objeto
utilice casos de prueba para verificar los modelos
Priorice los requerimientos en trminos de valor y riesgo
valor = beneficio al cliente + consecuencia si falta
contra = costo relativo + riesgo relativo
prioridad =
Valor %
costo % + riesgo %
30
Mejores prcticas para Anlisis de Requerimientos cont

Crear prototipos
Parcial o posible implementacin para clarificar los requerimientos
Crear una maqueta para la interfase del usuario, prueba de concepto para
arquitectura
Puede ser un prototipo desechable o evolutivo
Utilice programas utilitarios estructurados para evaluacin de prototipos
Crear un diccionario de datos
Los elementos y las estructuras de datos del cliente
Elementos y estructuras de interfaces de datos
Descripcin, tipos de datos, longitud, valores mnimos y mximos, valores
permitidos, valores automticos
Utilice un glosario para definir los trminos del cliente
31
Mejores prcticas para Documentos de Requerimientos
Utilice plantillas estndar de requerimientos

Requerimientos de Negocios:
Documento de Visin y Alcance
Requerimientos de Usuarios:
Documento de Casos de Uso
Requerimientos Funcionales:
Especificaciones de Requerimientos de
Software (SRS)
Identifique distintivamente cada requerimiento
Los hace fcil de seguir y modificables
Es mejor no utilizar numeracin jerrquica
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
Requerimientos de Negocios BR + nmero nico

Requerimientos de Usuarios
UR + nmero nico
Requerimientos de Sistema
SR + nmero nico
Diseo de Arquitectura
AD + nmero nico
Diseo Detallado
DD + nmero nico
Componente de Aplicacin
AC + nmero nico
Caso de Prueba:
Prueba de Aceptacin de Usuario
UAT + nmero nico
Prueba de Aceptacin Operacional
OAT + nmero nico
Prueba de Desempeo
PT + nmero nico
Prueba de Sistema
ST + nmero nico
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
Mejores prcticas para Verificacin de Requerimientos
Inspeccin formal de documentos de requerimientos

Mucho mas barato encontrar y corregir defectos en la etapa de
requerimientos
Incluir a los clientes, diseadores, probadores
Utilice listas de comprobacin 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 visin de comportamiento esperado
Revise los casos de prueba contra los requerimientos y modelos
35
Mejores prcticas para Manejo de Requerimientos

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 requisicin de cambios y un modelo estadotransicin (antes-despus)
Establezca un Consejo de Control de Cambios para tomar decisiones y
que haga cumplir el proceso de control de cambios
Anlisis de impacto de cambios de requerimientos
Involucre al usuario, diseador, probador
Identifique los componentes del sistema afectados por el cambio
Identifique las tareas que se tendran que efectuar
Estime el esfuerzo, costo, otros impactos
36
Mejores prcticas para Manejo de Requerimientos cont

Matriz de seguimiento de requerimientos
Ligar requerimientos a su origen
Ligar requerimientos a diseo, cdigo, casos de prueba
Ayuda a evitar pasar por alto requerimientos durante la construccin
Facilita el mantenimiento y anlisis de impacto
Seguimiento de estatus de requerimientos

Propuestos, aprobados, implementados, verificados, suprimidos
Permite un mas 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
37
Ejemplo de Requirements Traceability Matrix
38
Ha experimentado cualesquiera de las siguientes

situaciones?
La visin y el alcance del proyecto nunca son claramente definidos.

Los clientes estn demasiado ocupados para trabajar con los analistas o
los desarrolladores en los requerimientos.
Los sustitutos del usuario (por ejemplo: gerentes o mercadotecnia)
afirman hablar por los usuarios, pero realmente no lo hacen.
Los usuarios afirman que todos los requerimientos son crticos, as que no
les dan prioridad.
Los desarrolladores encuentran ambigedades e informacin faltante al
codificar, as que suponen muchas cosas.
stos son sntomas que resultan al caer en los Riesgos de los
requerimientos que usted puede y debe evitar.
39
Riesgo #1: Confusin Sobre Requerimientos
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
Riesgo #1: Confusin Sobre Requerimientos

Soluciones
Adopte plantillas para los tres tipos de requerimientos
Requerimientos de Negocios (Documento de Visin y Alcance)
Requerimientos de Usuario (Documento de Requerimiento de Usuario y
Documento de Casos de Uso)
Requerimientos de Software (Especificacin de Requerimientos de
Software)
Clasifique los requerimientos funcionales de los requerimientos nofuncionales, atributos de calidad, restricciones, requerimientos de
interfases externas, reglas del negocio
Clasifique la informacin proporcionada por el usuario en las diferentes
categoras
Identifique las ideas de solucin de los requerimientos
41
Riesgo #2: Involucramiento Inadecuado Del Usuario
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
Riesgo #2: Involucramiento Inadecuado Del Usuario
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
Riesgo #3: Requerimientos Vagos y Ambiguos
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
Riesgo #3: Requerimientos Vagos y Ambiguos

Soluciones
Revise formalmente los documentos de requerimientos para ambigedad
antes de revisar el contenido
Escriba casos de prueba conceptuales contra los requerimientos (es decir,
entradas, salidas)
Modele los requerimientos para encontrar diferencias de conocimiento
Utilice prototipos para hacer los requerimientos mas tangibles
Defina los trminos en un glosario
Evite palabras ambiguas: minimizar, maximizar, optimizar, rpido, de uso
fcil, simple, intuitivo, robusto, avanzado, mejorada, eficiente, varios, y/o,
etc., incluya, apoye, adecuado
45
Riesgo #4: Requerimientos Sin Priorizar

Sntomas
Todos los requerimientos se clasifican como crticos
Los diferentes interesados (stakeholders) interpretan alta prioridad de
diferente manera
Despus de priorizar, 95% de los requerimientos todava son altos
Los desarrolladores no quieren admitir que no pueden hacerlo todo
No est claro cuales requerimientos diferir si reduccin de alcance" llega
a ser necesaria
46
Riesgo #4: Requerimientos Sin Priorizar
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
Riesgo #5: Creando Funcionalidad Que Nadie Usa
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
48
Riesgo #5: Creando Funcionalidad Que Nadie Usa
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
Riesgo #6: Parlisis de Anlisis
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
50
Riesgo #6: Parlisis de Anlisis

Soluciones
Recuerde: el producto es software, no un documento de requerimientos

Seleccione un ciclo de vida de desarrollo apropiado
liberaciones progresivas que sean iterativas e incrementales
crear prototipos evolutivos
poner limite de tiempo
Decida cuando los requerimientos son bastante aceptables
riesgo aceptable para proceder con el desarrollo
Revisado por los interesados (stakeholders) del proyecto, incluyendo
analistas, desarrolladores, probadores y usuarios
Modele solo las partes complejas o inciertas del sistema
No incluya diseos finales de interfase de usuarios en la definicin de
requerimientos
51
Riesgo #7: Incremento no Controlado del Alcance

Sntomas
Se agregan nuevos requerimientos continuamente
El programa no cambia
No se provee recursos adicionales
El alcance del producto nunca se define claramente
Los requerimientos propuestos, vienen, y van, y regresan
Los cambios a los requerimientos se hacen furtivamente, entran por la
puerta de atrs
Los problemas del alcance se discuten durante las revisiones del
documento de definicin de requerimientos
La firma final es solo un ejercicio intelectual
52
Riesgo #7: Incremento no Controlado del Alcance

Soluciones
Determine las causas raz del incremento no controlado del alcance

Documente la visin y alcance del producto
Defina los lmites del sistema y las interfaces
Siga el proceso del control del cambio para todos los cambios
Mejore los mtodos de obtencin de requerimientos
Siga un proceso significativo de formalizacin de requerimientos
Renegocie los compromisos cuando los requerimientos cambian
53
Riesgo #8: Proceso Inadecuado de Control de Cambios

Sntomas
No se ha definido ningn proceso de control de cambios

Algunas personas pasan por alto el proceso de control de cambios y les
permiten hacerlo
Negocian tratos con amigos
Trabajan en cambios propuestos antes de que sean aprobados
Implementan cambios rechazados
No implementan cambios aprobados
Se descubre nueva funcionalidad durante la ejecucin de las pruebas
Estatus confusos sobre la requisicin de cambios
No se comunican los cambios a todos los afectados
No est claro quin hace las decisiones sobre los cambios
54
Riesgo #8: Proceso Inadecuado de Control de Cambios
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
Riesgo #9: Insuficiente Anlisis de Impacto Para los

Cambios Propuestos
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
Riesgo #9: Insuficiente Anlisis de Impacto Para los

Cambios Propuestos
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
Riesgo #10: Control de Versin Inadecuada
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
Riesgo #10: Control de Versin Inadecuada
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
Que es un Requerimiento que se Puede Poner a Prueba?

Un requerimiento que se puede poner a prueba tiene las siguientes
caractersticas:
1.Predecible
9.Escrito en un estilo consistente
2.Inequvoco
10.Utiliza reglas de proceso que reflejan

estndares consistentes
3.Correcto
11.Explicito
4.Completo
12.De lgica consistente
5.No-redundante
13.Se presta a ser re-usado
6.Se presta para control de cambios
14.Conciso y preciso
7.Se puede ligar

8.Se puede leer por todos los interesados
(stakeholders)
15.Priorizado
16.Viable
61
Definicin de Habilidad de ser Probado
Los resultados se pueden medir/predecibles

Dado un estado inicial del sistema y una serie de condiciones, es
posible predecir exactamente cuales sern los resultados
Probar = comparar un resultado esperado con un resultado observado
62
Proceso RBT:
Que es Pruebas Basadas en Requerimientos?
Desarrollado por Richard Bender

Un enfoque sistemtico para:
Verificar requerimientos como entradas a diseo, codificacin y pruebas
Establecer seguimiento a los requerimientos
Proveer una cobertura mxima de pruebas con el mnimo numero de casos de
prueba
Validad la conformidad del sistema con los 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
Planeacin de Pruebas e Inicio

Desarrollo de Casos de Prueba
Desarrollar
Escenarios de
Prueba
Anlisis del
Diseo
Funcional
Ambiente
Controlado
Casos de Prueba/Datos
Preparar la
Estrategia
de Pruebas
Pruebas de
Desempeo y
Aprobacion
Constru el Sistema Correcto?
64
Proporciones Tpicas de Descubrir Defectos
Prueba Unitaria 50%

85%
Prueba de Integracin 18%
Sin RBT
Prueba de Sistema 12%
UAT
5%
Entregado
al Cliente
15%
(Bender & Associates)
65
Proporciones Tpicas de Descubrir Defectos
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
7. Verificar los casos de pruebas

con los autores de los
requerimientos
8. Verificar los casos de prueba
con los usuarios/expertos en la
materia
9. Verificar los casos de prueba
con los desarrolladores
10.Utilice los casos de prueba en la
revisin del diseo
11.Utilice los casos de prueba en la
revisin del cdigo
12.Valide el cdigo con los casos
de prueba derivados de los
requerimientos y casos de uso
67
Proceso RBT:
Principales Tcnicas Especficas Para Pruebas
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:
Beneficio de las Tcnicas RBT

Aplica a los requerimientos funcionales y a los no-funcionales

Puede ser utilizado con requerimientos y especificaciones
documentados
Proporciona requerimientos y especificaciones que son claras, precisas,
predecibles, correctamente lgicas, consistentes y que se pueden
probar
Involucra y beneficia a todos los interesados (stakeholders) (es decir,
diseadotes/arquitectos/DBAs, programadores, probadores)
Establece la plataforma para la revisin de productos de trabajo
posteriores y seguimiento de los requerimientos
69
Revisin de Ambigedad:
Un Ejemplo Simple
La mitad de dos y dos = ??
Tiene la respuesta correcta?
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.
Identifique las Ambigedades -- tiene 10 minutos.
71
Resumen
Claves para Requerimientos Excelentes
Educar a los usuarios, desarrolladores, gerentes y probadores

Una asociacin de colaboracin entre usuarios-consultores-desarrolladoresprobadores
Reconocer que hay diversas clases de requerimientos
Desarrollo iterativo, incremental de los requerimientos
Plantillas estndares de documentos de requerimientos
Revisiones formales e informales de requerimientos
Escribir casos de prueba contra los requerimientos
Priorizar los requerimientos analticamente
Control de cambios practico y eficaz
72
La meta fundamental es
NO
SORPRESAS!
73
GRACIAS

Análisis de Requerimientos

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Análisis de Requerimientos

Încărcat de

Drepturi de autor:

Formate disponibile

ANLISIS DE REQUERIMIENTOS

Taxonoma de pruebas de software

Copyright 2013 HITSS

Contexto Del Negocio

Copyright 2013 HITSS

Copyright 2013 HITSS

Contexto del Negocio:

Razones Claves de los Fracasos de Proyectos

Indefinicin de la visin y alcance del proyecto

Copyright 2013 HITSS

Contexto del Negocio:

Distribucin Tpica de Defectos

Copyright 2013 HITSS

Contexto del Negocio:

Esfuerzo Tpico para Encontrar y Corregir Defectos

Copyright 2013 HITSS

Que es un Requerimiento? - Perspectiva del Cliente

Something wanted or needed

Algo deseado o necesario

IEEE STD. 610.12-1990, GLOSSARY OF SOFTWARE ENGINEERING

Copyright 2013 HITSS

Los Requerimientos son las especificaciones de lo que debe ser

Deben Describir QU es lo que har

Copyright 2013 HITSS

Tres Niveles de Requerimientos

Documento de Casos de Uso

Especificacin de Requerimientos de Software (SRS)

Componentes de Ingeniera de Requerimientos

Copyright 2013 HITSS

Revisin de la ingeniera de Requerimientos:

Copyright 2013 HITSS

Revisin de la ingeniera de Requerimientos:

Copyright 2013 HITSS

Revisin de la ingeniera de Requerimientos:

Copyright 2013 HITSS

Desarrollo y Manejo de Requerimientos

Recabe las necesidades de los

Establezca y mantenga un acuerdo con

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces cont..

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces cont..

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces cont..

Copyright 2013 HITSS

Caractersticas de Requerimientos Eficaces cont..

Copyright 2013 HITSS

Escribiendo Requerimientos Eficaces - 1

Evale desde la perspectiva del desarrollador

Copyright 2013 HITSS

Escribiendo Requerimientos Eficaces - 2

ESCRIBA LOS REQUERIMIENTOS NO SOLO PARA USTED.

Copyright 2013 HITSS

Elementos Complementarios a un Requerimiento

Una Regla de Negocio describe o define el comportamiento de una Organizacin

Estn alineadas a las polticas de la Organizacin

Copyright 2013 HITSS

Forma en que se calcula una comisin.

Copyright 2013 HITSS

Copyright 2013 HITSS