Análisis de Requerimientos

ANÁLISIS DE REQUERIMIENTOS

© Copyright 2013 HITSS 2

Taxonomía de pruebas de software Reglas del Curso

Tiempo del curso

Asistencia

Break

Celulares y Laptops

Preguntas

Evaluación


Agenda

Creando Requerimientos Eficaces

Contexto Del Negocio

¿Que son Requerimientos?

Definiciones

Tres Niveles de Requerimientos

Componentes de Ingeniería de Requerimientos

Características de Requerimientos Eficaces

Escribiendo Requerimientos Eficaces

Mejores Prácticas Para Desarrollo de Requerimientos

Mejores Prácticas Para Manejo de Requerimientos

Riesgos en la Creación de los Requerimientos y Cómo Evitarlos

Análisis de Ambigüedades Proceso de Pruebas Basadas en Requerimientos (RBT)

Revisión de Ambigüedad

Ejercicio Práctico


Objetivo

Proporcionar a los participantes los conceptos del Proceso de

Administración de Requerimientos, tomando en cuenta Requirements &

Testing

Describir los detalles del proceso para desarrollar un conjunto de

requerimientos claros y entendibles

Proporcionar una aplicación práctica a través de ejemplos


Contexto del Negocio:

Razones Claves de los Fracasos de Proyectos

Indefinición de la visión 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 través de la vida del proyecto

Desorden en el seguimiento de los procesos



Distribución Típica de Defectos

Requirements56%

Design27%

Other10%Code

7%Source: James Martin

Diseño

Requerimientos

Codificación

Otros



Esfuerzo Típico para Encontrar y Corregir Defectos

Requirements82%

Design13%

Other4%Code

1%

Requerimientos

Diseño

Codificación

Otros

Source: James Martin


Que es un Requerimiento? - Perspectiva del Cliente

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

Deben Describir QUÉ es lo que hará

el sistema, NO el CÓMO lo hará.


Tres Niveles de Requerimientos

Requerimientos de Negocio

Documento de Visión y Alcance

Requerimientos de Usuario

Documento de Casos de Uso

Requerimientos Funcionales

Especificación de Requerimientos de Software (SRS)

Restricciones

Interfaces Externas

Requerimientos del Sistema

Reglas de Negocio

Atributos de Calidad

= Entrada

= Documento Formal

Matriz de Administración de Requerimientos


Componentes de Ingeniería de Requerimientos

Ingeniería de Requerimientos

Desarrollo de Requerimientos

Manejo de Requerimientos

Obtención Análisis (Entender)

Especificación Verificación

clarificar re-escribir

re-evaluar corregir y cerrar

diferencias


Revisión de la ingeniería de Requerimientos:

Los Tres niveles de Requerimientos

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.


Desarrollo y Manejo de Requerimientos

Desarrollo 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

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



1.Correcto

2.Viable

3.Necesario

4.Priorizado

5.Inequívoco

6.Verificable

7.Completo

8.Consistente

9.Modificable

10.Fácil de Seguir



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 límites y restricciones

Basados en acuerdo entre los desarrolladores y los analistas del

negocio

Provee un chequeo de realidad en viabilidad y costo


Características 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 estándar

Algo asignado o derivado de un requisito del sistema

Una regulación del gobierno

Priorizado

Alto = Debe ser incluido en la siguiente liberación

Mediano = Puede esperar a una liberación futura si es

necesario

Bajo = Seria bueno tener algún día



Inequívoco Cada lector obtiene solamente una interpretación del requerimiento

Múltiples lectores llegan la misma interpretación

Escrito en un lenguaje simple, claro y conciso del área de la aplicación

Verificable Se puede verificar la implementación correcta a través:

Pruebas

Inspección

Demostración

No se puede verificar si es ambiguo, inconsistente, incorrecto o no viable



Completo

¡No faltan requerimientos o información esencial!

Use TBD (A Ser Determinado) para señalar lo que esta incompleto

Documentar como los TBDs serán resueltos

¡Continúe con el diseño y el desarrollo a su propio riesgo!

Lo completo también 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



Modificable

Cada requerimiento tiene un identificador único

Los requerimientos son expresados individualmente/singularmente

Los requerimientos no contienen redundancias

Fácil de Seguir

Cada requerimiento tiene un identificador único

Todos los requerimientos son escritos con un alto grado de detalle

No contiene listas en viñetas (Bullets) ni párrafos largos


Escribiendo Requerimientos Eficaces - 1

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 contradictorios


Escribiendo Requerimientos Eficaces - 2

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

ESCRIBA LOS REQUERIMIENTOS NO SOLO PARA USTED.


Elementos Complementarios a un Requerimiento

Además de la Definición 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 Organización

• Están alineadas a las políticas de la Organización

• Pueden aplicar a un solo requerimiento o son generales a un proceso, aplicando

a varios requerimientos.

• Las Reglas de Negocio son Dinámicas, ya que dan movimiento a la

Organización


Reglas de Negocio

Ejemplos:

• Cuando un cliente desea cancelar una tarjeta de crédito 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 algún producto o servicio

asociado.

• Forma en que se calcula una comisión.


Validaciones

• A nivel de requerimientos, son las condiciones específicas que deben ser

consideradas para cumplir con él.

• La diferencia con una Regla de Negocio, radica en que la Regla describe la

forma de operación del negocio, mientras que las validaciones son

características específicas que deben cumplir un componente de software.

• Son aquellas preferencias que se tengan en la operación del requerimiento.

• Normalmente las validaciones ayudan a que se cumplan las reglas de negocio.


Validaciones

Ejemplos:

• Verificar que en una pantalla de captura de información, se haya introducido

primero el número del cliente antes de seleccionar un producto asociado.

• Verificar que el número de cliente contenga todos los dígitos necesarios ó sea

un número válido.

• Que algún archivo cumpla con cierto layout antes de cargarlo.

• Si se introduce el número de teléfono, que se inhabilite la captura del correo

electrónico.


Mejores prácticas para Obtener Requerimientos

Identifique a los dueños 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 descripción de las tareas

Deriva casos de prueba temprano en el proyecto


Mejores prácticas para Obtener Requerimientos cont..

Empiece por definir la visión 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

Reúna información de los dueños del producto

Escriba para ser cuantitativo y comprobable


Mejores prácticas para Análisis de Requerimientos

Modelos de análisis ofrecen mejor panorama de los requerimientos

ningún panorama dice todo lo que necesitas saber

diagrama de contexto, diagrama de flujo de datos, diagramas de estado-

transición (antes-después), mapas de dialogo, modelos de análisis de

objeto

utilice casos de prueba para verificar los modelos

Priorice los requerimientos en términos de valor y riesgo

valor = beneficio al cliente + consecuencia si falta

contra = costo relativo + riesgo relativo

prioridad = Valor %

costo % + riesgo %


Mejores prácticas para Análisis de Requerimientos cont…

Crear prototipos

Parcial o posible implementación 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 evaluación de prototipos

Crear un diccionario de datos

Los elementos y las estructuras de datos del cliente

Elementos y estructuras de interfaces de datos

Descripción, tipos de datos, longitud, valores mínimos y máximos, valores

permitidos, valores automáticos

Utilice un glosario para definir los términos del cliente


Mejores prácticas para Documentos de Requerimientos

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


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


Descomposición de Requerimientos

Proyecto:

CM/BE001

RU001 RU002 RU003

RF0001 RF0002 RF0003

•Cambios Organizacionales

•Equipo

•Infraestructura de Negocio

•Procesos y Procedimientos

•Pruebas

•Productos y Servicios

•Red

•Recursos Humanos

•Seguridad

•Sistemas


Mejores prácticas para Verificación de Requerimientos

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


Mejores prácticas para Manejo de Requerimientos cont…

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


Ejemplo de Requirements Traceability Matrix


¿Ha experimentado cualesquiera de las siguientes

situaciones?

La visión y el alcance del proyecto nunca son claramente definidos. Los clientes están 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 críticos, así que no les dan prioridad. Los desarrolladores encuentran ambigüedades e información faltante al codificar, así que suponen muchas cosas. Éstos son síntomas que resultan al caer en los Riesgos de los requerimientos que usted puede y debe evitar.


Riesgo #1: Confusión 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 todavía no saben qué construir. Los requerimientos se enfocan solo en funcionalidad, y descuidan otras categorías de requerimientos.

¿Puede sugerir algunas soluciones?


Riesgo #1: Confusión Sobre “Requerimientos”

Soluciones

Adopte plantillas para los tres tipos de requerimientos

Requerimientos de Negocios (Documento de Visión y Alcance)

Requerimientos de Usuario (Documento de Requerimiento de Usuario y

Documento de Casos de Uso)

Requerimientos de Software (Especificación de Requerimientos de

Software)

Clasifique los requerimientos funcionales de los requerimientos no-

funcionales, atributos de calidad, restricciones, requerimientos de

interfases externas, reglas del negocio

Clasifique la información proporcionada por el usuario en las diferentes

categorías

Identifique las ideas de solución de los requerimientos


Riesgo #2: Involucramiento Inadecuado Del Usuario

Síntomas

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 de

requerimientos

Los usuarios rechazan el producto cuando lo ven por primera vez



Riesgo #2: Involucramiento Inadecuado Del Usuario

Soluciones

Identifique y defina todas las clases de usuarios

Identifique a los dueños del producto como un representante de

usuarios

Convoque a grupos de enfoque

Identifique al personal autorizado para hacer decisiones e involúcrelos

Haga que los usuarios evalúen los prototipos

Haga que los representantes de usuarios revisen a fondo los

documentos de requerimientos


Riesgo #3: Requerimientos Vagos y Ambiguos

Síntomas

Los lectores interpretan un requerimiento de diversas maneras

Falta información en los requerimientos que los desarrolladores necesitan

Los requerimientos no son verificables (es decir., falta información que los

probadores necesitan)

Los desarrolladores/probadores tienen que hacer muchas preguntas

Los desarrolladores/probadores tienen que suponer muchas cosas



Riesgo #3: Requerimientos Vagos y Ambiguos

Soluciones

Revise formalmente los documentos de requerimientos para ambigüedad

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 términos en un glosario

Evite palabras ambiguas: minimizar, maximizar, optimizar, rápido, de uso

fácil, simple, intuitivo, robusto, avanzado, mejorada, eficiente, varios, y/o,

etc., incluya, apoye, adecuado


Riesgo #4: Requerimientos Sin Priorizar

Síntomas

Todos los requerimientos se clasifican como críticos

Los diferentes interesados (stakeholders) interpretan alta prioridad de

diferente manera

Después de priorizar, 95% de los requerimientos todavía son altos

Los desarrolladores no quieren admitir que no pueden hacerlo todo

No está claro cuales requerimientos diferir si “reducción de alcance" llega

a ser necesaria



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 categorías de prioridad sin ambigüedades

Asigne requerimientos o características a las liberaciones

Priorice analíticamente los requerimientos


Riesgo #5: Creando Funcionalidad Que Nadie Usa

Síntomas

Los usuarios exigen ciertas características, después nadie las usa

La funcionalidad propuesta no está relacionada con las tareas del negocio

Los desarrolladores agregan una función porque “a los usuarios les

gustará”

Los usuarios no distinguen lo “trivial" de lo “importante“



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 beneficiarán con cada

característica

Analíticamente priorice los requerimientos, casos de uso, o características

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”


Riesgo #6: Parálisis de Análisis

Síntomas

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 múltiples formas

Diseño y codificación no empiezan hasta que el documento de

requerimientos esta perfecto



Riesgo #6: Parálisis de Análisis

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 diseños finales de interfase de usuarios en la definición de requerimientos


Riesgo #7: Incremento no Controlado del Alcance

Síntomas

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 atrás

Los problemas del alcance se discuten durante las revisiones del

documento de definición de requerimientos

La firma final es solo un ejercicio intelectual



Riesgo #7: Incremento no Controlado del Alcance

Soluciones

Determine las causas raíz del incremento no controlado del alcance

Documente la visión y alcance del producto

Defina los límites del sistema y las interfaces

Siga el proceso del control del cambio para todos los cambios

Mejore los métodos de obtención de requerimientos

Siga un proceso significativo de formalización de requerimientos

Renegocie los compromisos cuando los requerimientos cambian


Riesgo #8: Proceso Inadecuado de Control de Cambios

Síntomas No se ha definido ningún 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 ejecución de las pruebas Estatus confusos sobre la requisición de cambios No se comunican los cambios a todos los afectados No está claro quién hace las decisiones sobre los cambios



Riesgo #8: Proceso Inadecuado de Control de Cambios

Soluciones

Defina un proceso práctico 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 políticas de control de cambios

Compare las prioridades contra los requerimientos restantes.


Riesgo #9: Insuficiente Análisis de Impacto Para los

Cambios Propuestos

Síntomas

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 técnicamente 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



Riesgo #9: Insuficiente Análisis de Impacto Para los

Cambios Propuestos

Soluciones

Analice sistemáticamente 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 información 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


Riesgo #10: Control de Versión Inadecuada

Síntomas

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 idénticos tienen diferentes identificadores

La gente trabaja de diferentes versiones de requerimientos

los desarrolladores implementan características canceladas

los probadores hacen pruebas en requerimientos equivocados

Se pierde la historia de cambios y versiones de documentos anteriores



Riesgo #10: Control de Versión 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


ANÁLISIS DE AMBIGÜEDADES


¿Que es un Requerimiento que se Puede Poner a Prueba?

1.Predecible

2.Inequívoco

3.Correcto

4.Completo

5.No-redundante

6.Se presta para control de cambios

7.Se puede ligar

8.Se puede leer por todos los interesados (stakeholders)

9.Escrito en un estilo consistente

10.Utiliza reglas de proceso que reflejan estándares consistentes

11.Explicito

12.De lógica consistente

13.Se presta a ser re-usado

14.Conciso y preciso

15.Priorizado

16.Viable

Un requerimiento que se puede poner a prueba tiene las siguientes características:


Definición 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 serán los resultados

Probar = comparar un resultado esperado con un resultado observado


Proceso RBT:

¿Que es Pruebas Basadas en Requerimientos?

Desarrollado por Richard Bender

Un enfoque sistemático para:

Verificar requerimientos como entradas a diseño, codificación y pruebas

Establecer seguimiento a los requerimientos

Proveer una cobertura máxima de pruebas con el mínimo numero de casos de

prueba

Validad la conformidad del sistema con los requerimientos


Proceso RBT

Crear

Procedimientos

de Prueba

Identificar

Casos de

Prueba

Desarrollar

Escenarios de

Prueba

Preparar la

Estrategia

de Pruebas

Documentos

de Diseño

Documentos

de Diseño

Especificaciones

Funcionales

Documento de

Requerimientos

Definir

Requerimientos

Análisis del

Diseño

Funcional

Diseño de

Arquitectura

Diseño Técnico

Detallado

Construcción

Pruebas de

Desempeño y

Aprobacion

Pruebas de

Sistema

Prueba de

Sanidad Pruebas de

Integración

Pruebas

Unitarias

Control de

Liberación

Pla

neació

n d

e P

ruebas e

Inic

io

D

esarro

llo d

e C

asos d

e P

rueba

Tiempo

Verificación (Pruebas Estáticas)

Validación (Pruebas Dinámicas) C

asos d

e P

rueba/D

ato

s

Desarr

ollo

y E

jecució

n

Ambiente

Controlado

¿Construí Correctamente el Sistema?

¿Construí el Sistema Correcto?



Proporciones Típicas de Descubrir Defectos

Prueba Unitaria 50%

Prueba de Integración 18%

Prueba de Sistema 12%

UAT 5%

Entregado al Cliente

15%

85%

(Bender & Associates)

Sin RBT



Proporciones Típicas de Descubrir Defectos

Inspección

RBT

65 - 90%

Pruebas

10 - ~35%

Entregado al Cliente .015%

Aprox.

10-35%

Con RBT


Proceso RBT:

Pasos Básicos

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:

Principales Técnicas Específicas Para Pruebas


Utilizado en la fase de la determinación 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 inspección formal (es decir, componente de

Revisión de Productos de Trabajo [WPR])

Es el enfoque de esta sesión de entrenamiento

Graficación de Causa-Efecto

Una técnica de diseño de casos de prueba, utilizada una vez que los

requerimientos han sido revisados por ambigüedad y contenido

Obtenga el mínimo de casos de prueba para cubrir el 100% de los

requerimientos funcionales

Apoyado por la herramienta BenderRBT™


Proceso RBT:

Beneficio de las Técnicas 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 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


Revisión de Ambigüedad:

Un Ejemplo Simple

La mitad de dos y dos = ??

¿Tiene la respuesta correcta?


Revisión de Ambigüedad:

Ejercicio de Practica #3

Requerimiento de Negocio Antes de la Revisión de

Ambigüedad

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.

Identifique las Ambigüedades -- tiene 10 minutos.


Resumen

Claves para Requerimientos Excelentes

• Educar a los usuarios, desarrolladores, gerentes y probadores

• Una asociación de colaboración entre usuarios-consultores-desarrolladores-

probadores

• 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


La meta fundamental es …

¡NO SORPRESAS!

GRACIAS

Análisis de Requerimientos

Documents

Transcript of Análisis de Requerimientos