Creando requerimientos eficaces

Análisis de Ambigüedad

Creando Requerimientos Eficaces/
Análisis de Ambigüedad...

Creando

Requerimientos

E1icaces

Presentación de Entrenamiento.
1

Creando Requerimientos Eficaces
– Contexto Del Negocio
– ¿Que es un Requerimiento?
– Definiciones
– Tres Niveles de Requerimientos
– Componentes de Ingeniería de Requerimientos
– Características de Requerimientos Eficaces
– Escribiendo Requerimientos Eficaces
– Mejores Prácticas Para Documentar Requerimientos
Análisis de Ambigüedades
– Proceso de Pruebas Basadas en Requerimientos (RBT)
– Revisión de Ambigüedad


Agenda

2

Contexto del Negocio
– 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


Razones Claves de los Fracasos de Proyectos

3

Contexto del Negocio

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


Esfuerzo Típico para Encontrar y Corregir
Defectos

4

¿Que es un
Requerimiento?
Perspectiva del Cliente

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”


WEBSTER’S DICTIONARY:
“Something wanted or needed”
“Algo deseado o necesario ”

5

Definiciones
“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.”


Qué es un Requerimiento Efectivo?

6

Tres Niveles de Requerimientos
= Entrada

Requerimientos
de Negocio

= Documento Formal

Requerimientos
de Usuario

Atributos de
Calidad

Documento de Visión y Alcance
Requerimientos
del Sistema

Reglas de
Negocio

Requerimientos
Funcionales

Interfaces
Externas
Restricciones


Documento de Visión y Alcance

7

Especificación de Requerimientos de Software (SRS)


•  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 Negocio

8


•  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 de Usuario

9


• 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.


Requerimiento Funcional

10

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

Verificación


re-evaluar
corregir y cerrar
diferencias

11

Componentes de Ingeniería 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
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 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


Desarrollo de Requerimientos

12

1. Correcto
2. Viable
3. Necesario
4. Priorizado
5. Inequívoco
6. Verificable
7. Completo
8. Consistente
9. Modificable
10.Fácil de Seguir


Características de Requerimientos Eficaces

13

• 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 -1

14

• 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


Escribiendo Requerimientos Eficaces -2

15

• Utilice plantillas estándar de requerimientos
– Requerimientos de Negocios: Documento de Visión y Alcance
– Requerimientos de Usuarios: Documento de Casos de Uso
– Requerimientos Funcionales: Especificaciones de Requerimientos
de Software (SRS)
• Identifique distintivamente cada requerimiento
– Los hace fácil de seguir y modificables
– Es mejor no utilizar numeración jerárquica


Mejores Prácticas para Documentar
Requerimientos

16

Mejores Prácticas para Documentar Requerimientos

• 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 ejem., 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


Lineamientos de Identificadores

17

• Inspección formal de documentos de requerimientos
– Mucho mas 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


Mejores Prácticas para Documentar
Requerimientos

18

Mejores Prácticas para Documentar 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 impactosejores


• Maneje las Versiones de los documentos de requerimientos

19

Mejores Prácticas para Manejo de
Requerimientos

• 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


• 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

20


ANÁLISIS DE AMBIGÜEDADES

21

Proceso de Pruebas Basadas en Requerimientos (RBT)
Definición de Habilidad de ser Probado

• Dado un estado inicial del sistema y una serie de
condiciones, es posible predecir exactamente cuales
serán los resultados
• Probar = comparar un resultado esperado con un
resultado observado


• Los resultados se pueden medir/predecibles

22


Definir Requerimiento

23



24



25


1. Validar requerimientos
comparado con los objetivos
2. Aplicar casos de uso en base a
los requerimientos
3. Realizar un análisis inicial de
ambigüedad
4. Realizar una revisión de
contenido por especialistas en la
materia
5. Graficación de causa-efecto
6. Realizar revisiones de
consistencia lógica y diseño 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
revisión del diseño
11. Utilice los casos de prueba en la
revisión del código
12. Valide el código con los casos de
prueba derivados de los requerimientos
y casos de uso


Proceso RBT: Pasos Básicos

26


Revisión de Ambigüedad
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 lógicas, consistentes y que se
pueden probar
• Involucra y beneficia a todos los interesados (stakeholders) (es decir
diseñadotes/arquitectos/DBAs, programadores, probadores)
• Establece la plataforma para la revisión de productos de trabajo
posteriores y seguimiento de los requerimientos


Beneficio de las Técnicas RBT

27

Revisión de
Ambigüedad

¿Tiene la respuesta correcta?
Revisión


La mitad de dos y dos = ??

28

• Imagine un coche que ha sido diseñado para que “se maneje a si mismo”.
• Lo que sigue representa uno de los requerimientos para este coche – ¿o
no?
• Anote todas las ambigüedades que usted pueda pensar - tiene 10 minutos.
“Si la luz es roja, entonces pare.”


Ejercicio de Practica #1

29

Revisión de
Ambigüedad

El Cajero Automático (ATM) enviará una alarma al epartamento de
tecnología de la información (IT) cuando el ATM se ha tratado de
forzar. En caso que el ATM seabra sin la llave y el código de
seguridad, el ATM alertará al departamento inmediatamente para
que pueda tomar la acción apropiada.


Requerimiento de Negocio Antes de la Revisión de Ambigüedad

Identifique las Ambigüedades -- tiene 10 minutos.
30


El Cajero Automático (ATM) enviará una alarma al
departamento de tecnología de la información (IT)
cuando el ATM se ha tratado de forzar. En caso que el
ATM se abra sin la llave y el código de seguridad, el ATM
alertará al departamento inmediatamente para que pueda
tomar la acción apropiada.


Ambigüedades Descubiertas Durante la Revisión de Ambigüedades

31


• Un Cajero Automático (ATM) enviará una alarma electrónica al Oficial de Seguridad enguardia
al departamento de IT cuando el ATM se ha tratado de forzar, es decir, abierto sin el
uso de una llave física, seguido por el código de seguridad válido.
– Caso 1: (1) Si un operador autorizado de servicio inserta la llave física en la ranura de
el ATM, entonces mostrara el siguiente mensaje en la consola del ATM: "introduzca por
favor el código válido de seguridad." (2) Si el operador del servicio introduce el código
válido de seguridad, entonces la puerta del ATM se abre.
– Caso 2: Después de insertar la llave en el ATM, si el operador del servicio introduce un
código de seguridad incorrecto, entonces (1) se muestra el siguiente mensaje en la
consola del ATM: “Código de Seguridad inválido. Intente de nuevo por favor." (2) el
operador del servicio ahora tiene tres intentos para introducir el código válido de
seguridad. Si un código válido de seguridad se introduce en menos que o igual a tres
intentos, entonces la puerta del ATM se abre. Después de cada uno de los primeros
tres intentos con un código de seguridad inválido, el siguiente mensaje se mostrará en
la consola del ATM: “Código de Seguridad Inválido. Intente de nuevo por favor."
– Caso 3: Si un código válido de seguridad no ha sido introducido al tercer intento,
entonces (1) el siguiente mensaje se mostrará en la consola del ATM: “Código de
seguridad inválido. La oficina de seguridad será notificada." (2) El ATM envía una
alarma a la Oficina de Seguridad inmediatamente.
– Caso 4: En caso que el ATM se abra sin la llave y el código de seguridad válido,
entonces el ATM envía una alarma al departamento de Seguridad inmediatamente que
el ATM has sido forzado.


Requerimiento de Negocio Corregido después de la Revisión de Ambigüedades

32


• Un “de otro modo” pendiente
• Ambigüedad de referencia
• Alcance de la acción
• Omisiones
– Causas sin efectos
– Efectos faltantes
– Efectos sin causas
– Omisiones completas
– Causas faltantes
• Operadores lógicos ambiguos
– O, Y, Ni, Y No
– Conectores implícitos
– Operadores compuestos
• Negación
– Alcance de la negación
– Negación innecesaria
– Doble negación

• Declaraciones ambiguas
– Verbos, adverbios, adjetivos
– Variables, Seudónimos
innecesarios
– Abreviaciones y acrónimos
• Organización aleatoria
– Causas y efectos mixtos
– Secuencia de casos al azar
• Supuestos integrados
– Conocimiento funcional/de
ambiente
• Relación de precedencia ambigua
• Casos implícitos
• Etcétera.
• Es Decir (i.e.) vs. Por Ejemplo (E.G.)
• Ambigüedad temporal
• Limite de la ambigüedad
• Palabras y frases ambiguas


Lista de Comprobación De la Revisión De Ambigüedad

33

Revisión de
Ambigüedad
Ejemplo con ambigüedad:
“El código debe ser cualesquiera A, B, o C.”
¿Entonces? ¿Una condición de error?
Ejemplo sin ambigüedad:
Si el CLIENTE es un CLIENTE-CORPORATIVO
Entonces
FUNCION_1
De Otro Modo (CLIENTE es un CLIENTE-MINORISTA)
NO_ACCION
fin.
Revisión


“De Otro Modo” pendientes

34

Revisión de
Ambigüedad
• “Para la transacción 1, actualizar el registro del cliente, imprimir el
estado de cuenta del cliente, etcétera.”
• “La cantidad total debe de ser pagada para miembros plenos,
miembros asociados, etcétera.”
Revisión


Etcétera

35

Revisión de
Ambigüedad
Sumar el INTERES-GANADO al BALANCE-DE-CUENTA.
Si es mas de $1,000 entonces pasar
el CLIENTE a LISTA-CUENTAS-CLAVES.
VERSUS
Sumar el INTERES-GANADO al BALANCE-DE-CUENTA.
Si el INTERES-GANADO es mas de $1,000 entonces pasar
el CLIENTE a LISTA-CUENTAS-CLAVES.
Revisión


Nombres Explícitos de Variables

36


De un libreto de seguridad de una línea aérea
(encontrado en el bolsillo del asiento):
“Si usted está sentado en una fila de salida y usted no puede leer
esta tarjeta ni puede ver lo suficientemente bien para seguir estas
instrucciones, dígale por favor a un miembro de la tripulación."


Descuidos

37


• Todas las ambigüedades eliminadas
• Procesos descritos a un nivel predecible/que se pueda probar
• Todas las reglas son explícitas
• Todas las reglas son lógicamente consistentes
• Se aplican consistentemente los estándares de proceso
• Escritos en un estilo que es:
– consistente
– que todas las audiencias pueden leer
• Optimizado la probabilidad de re-uso
• Da apoyo al seguimiento


Características a Buscar

38

• Educar a los usuarios, desarrolladores, gerentes y probadores
• Una asociación de colaboración entre usuarios-consultoresdesarrolladoresprobadores
• Reconocer que hay diversas clases de requerimientos
• Desarrollo iterativo, incremental de los requerimientos
• Plantillas estándares de documentos de requerimientos
• Revisiones formales e informales de requerimientos
• Escribir casos de prueba contra los requerimientos
• Priorizar los requerimientos analíticamente
• Control de cambios practico y eficaz


Cllaves para Requeriimiientos Excellentes

39

Creando requerimientos eficaces

Más contenido relacionado

La actualidad más candente

Similar a Creando requerimientos eficaces

Más de Professional Testing

Creando requerimientos eficaces