02 desarrollo de requisitos

1
Ingeniería de Requisitos
Tema 2: Desarrollo de Requisitos
(Dr. Ricardo Quintero)

2
Temas
 La Visión del Producto y el Alcance del
Proyecto
 Clasificación de los Usuarios
 Levantamiento de Requisitos
 Entendiendo los Requisitos de Usuario
 Las Reglas del Negocio
 Documentando los Requisitos
 Modelos y Diagramas para diversos Requisitos
 Requisitos No Funcionales
 Validación de Requisitos

La Visión del Producto y el
Alcance del Proyecto
 Historia verdadera:
“Cuando mi colega Karen introdujo en su compañía la
inspección del documento de requisitos, observó
que muchos de los aspectos que los inspectores
detectaron pertenecía al alcance del proyecto. Los
inspectores frecuentemente tenían un
entendimiento diferente sobre el alcance y objetivos
del proyecto. En consecuencia, tuvieron dificultad
para determinar que RF pertenecían al DERS”
3

Introducción
 Los RN representan el nivel de
abstracción más alto en la cadena
de requisitos.
 Definen la Visión y el Alcance
para el sistema software.
 Los RU y los RF deben alinearse
al contexto y objetivos que los RN
establecen.
4

Introducción
 Proyectos que no tienen bien
definida y comunicada la
dirección invitan al desastre: los
stakeholders nunca se ponen de
acuerdo en los requisitos si carecen
de un entendimiento común de
los RN para el producto.
5

Introducción
 Un síntoma común de que los RN no
están suficientemente definidos se refleja
en la inclusión, borrado y agregado
continuo de características.
 La Visión y el Alcance se deben resolver
antes que se detallen los RF.
 Esta Visión y Alcance ofrece el marco de
referencia adecuado para la toma de
decisiones sobre cambios y extensiones
en requisitos.
6

La Visión del Producto
 Def.- Describe lo que es el
producto actual y lo que
eventualmente llegará a ser.
 La VP alinea a todos los
stakeholders en una dirección
común.
7

El Alcance del Proyecto
 Def.- Identifica que porción de la
visión a largo plazo del producto
manejará el proyecto actual.
 El AP pone límites a lo que estará
dentro o fuera. Define los límites
del proyecto.
 Los detalles del AP se representan
mediante la línea base de
requisitos que el equipo define para
el proyecto.
8

Visión del Producto y Alcance del
Proyecto
 La Visión aplica al Producto como un
todo. Cambiará lentamente ante la
evolución de los objetivos del negocio.
 El Alcance pertenece a un proyecto
específico o iteración que implementará
el siguiente incremento de la funcionalidad
del producto. Más dinámico que la visión, el
líder de proyecto la ajusta en función de
tiempo, presupuesto, recursos, calidad.
9

Visión del Producto y Alcance del
Proyecto-Gráficamente
10

El documento de Visión y Alcance
 El documento de Visión y Alcance
recolecta los RN en un solo documento
que pone la base para el trabajo
subsecuente.
 El propietario de este documento es el
patrocinador ejecutivo del proyecto (o
alguien similar).
 El analista puede trabajar con el
propietario para escribir el documento.
11

El documento de Visión y Alcance
 La entrada a los RN debe provenir de los
individuos que tienen un claro sentido
del porqué del proyecto.
12

Plantilla básica para el documento
de visión
Puede basarse en esta plantilla
13

Ejemplos…
 Oportunidad de Negocio: “Explotar el
registro pobre de seguridad de un producto de
la competencia”.
 Objetivo de Negocio: “Capturar el 80% del
mercado por ser reconocido como el producto
más seguro en el mercado a través de
revisiones de revistas y encuestas de
consumidores”.
 Necesidad del cliente: “Un producto más
seguro”.
 Característica: “Un motor de seguridad
nuevo, robusto”.
14

El Diagrama de Contexto
 La descripción del Alcance establece
los límites y conexiones entre el
sistema y el resto del universo.
 El Diagrama de Contexto ilustra
gráficamente estos límites.
 Incluye:
 Terminadores: que interactúan con el
sistema.
 Datos y control.
 Flujo
15

El Diagrama de Contexto
 Se puede incluir en el documento de
Visión y Alcance o como un apéndice
del DERS.
16

Ejemplo de Diagrama de Contexto
17

18
Temas
 La Visión del Producto y el Alcance del Proyecto

Clasificación de los Usuarios
 La participación del cliente es un factor
crítico para el éxito de los proyectos.
 El éxito en los requisitos software, y
por tanto en el desarrollo de software,
depende en obtener la voz del
cliente cerca del oído del
desarrollador.
 Es importante identificar
representantes de clientes al
proyecto.
19

Pasos para buscar la voz del
cliente
1. Identificar las diferentes clases de
usuarios para el producto.
2. Identificar las fuentes de RU.
3. Seleccionar y trabajar con individuos
que representen cada clase de usuario y
otros grupos de stakeholders.
4. Acordar quienes serán los tomadores
de decisiones de requisitos de tus
proyectos.
20

Fuentes de Requisitos
 Los orígenes de los Requisitos
Software dependerán de la
naturaleza del producto y tu
ambiente de desarrollo.
21

Típicas Fuentes de Requisitos
 Entrevistas y discusiones con usuarios
potenciales.
 Documentos que describen el producto
actual o de la competencia.
 Problemas reportados y solicitudes de
extensión al sistema actual.
 Encuestas de mercado y cuestionarios de
usuarios.
 Observando usuarios en su trabajo.
 Análisis de escenarios (CU).
 Eventos y respuestas (sistemas de tiempo
real).
22

Clases de Usuarios
 Los usuarios difieren en los
siguientes aspectos:
 Su experiencia en el dominio y su
expertise en computación.
 Las características que ellos usan.
 Las tareas que realizan en soporte a
sus procesos de negocio.
 Sus privilegios de acceso o niveles de
seguridad.
23

Clases de Usuarios
 Basados en los aspectos anteriores se
pueden agrupar los usuarios en diferentes
clases de usuarios.
24

Clases de Usuarios
 Usuarios favorecidos: reciben
trato preferencial cuando se
toman decisiones de prioridad o se
resuelven conflictos entre
requisitos.
 Usuarios desfavorecidos:
aquellos que se espera que no
usen el producto (por razones
legales, seguridad)
25

Clases de Usuarios
 Usuarios ignorados y otras
clases de usuarios: otros usuarios
que no se consideran como parte de
la clasificación.
26

Importancia de la clasificación de
usuarios
 Cada clase de usuario tendrá sus propios
requisitos para las tareas que desempeñan
 Tendrán diferentes requisitos no
funcionales (usabilidad) que conducirá las
decisiones de diseño de la IU.
 Muy importante: cada tipo de usuario será la
fuente básica de levantamiento de requisitos.
 Considere, además, un catálogo de usuarios
para todos los sistemas. Podrá reutilizarlo
sistema a sistema.
27

Clases de Usuarios y el DERS
 Documenta las clases de usuarios y sus
características, responsabilidades y
localizaciones físicas en el DERS.
 Incluye toda la información pertinente
de cada clase de usuario, su tamaño
relativo o absoluto y cuales clases son
favorecidas, esto ayudará a priorizar las
peticiones de cambios y conducir la
evaluación de impacto posteriormente.
28

Ejemplo de Clases de Usuarios
Químicos
(Favorecidos)
Aproximadamente 1000 químicos
localizados en 6 edificios utilizarán el
sistema para solicitar químicos de
vendedores y del almacén. Cada
químico utilizará el sistema varias
veces al día, necesitan buscar en
catálogos de vendedores.
Compradores Conocen poco de química y necesitan
ayudas de consulta para los catálogos de
vendedores. Utilizarán el sistema unas 20
veces al día
29

Un usuario ejemplo
 Es posible crear 1 usuario
representativo de cada clase,
como sigue:
“Alfredo, de 41 años, ha sido químico en Contoso
Farmaceutica desde que se graduó hace 14 años. No
tiene mucha paciencia con las computadoras.
Trabaja en 2 proyectos a la vez …”
 Conforme exploras los requisitos del químico, piensa
en Alfredo como el Arquetipo de esta clase de
usuario y pregúntate: ¿Qué necesitará hacer
Alfredo?
30

Buscando Representativos de
Usuarios
 Todo tipo de proyecto necesita usuarios
representativos que provean la voz del
cliente.
 Estos usuarios representativos deberían
estar involucrados a través de todo el
ciclo de vida, no sólo en la fase aislada de
requisitos al inicio.
 Una estrategia útil también es crear
grupos enfocados de usuarios que
incluyan expertos y novatos.
31

Rutas de comunicación entre
Usuarios y Desarrolladores
32

El Campeón del Producto (Product
Champion)
 Cada Campeón de Producto es la
interfase principal entre miembros
de una clase de usuario y el analista
de proyectos.
 Los Campeones deben ser
usuarios actuales, no
representantes de patrocinadores,
gerentes o desarrolladores de
software que pretenden ser usuarios.
33

El Campeón del Producto (Product
Champion)
 Los mejores Campeones de Producto tienen una
clara visión del nuevo sistema y son
entusiastas acerca de él porque ven el próximo
beneficio para él y sus compañeros.
 Deben ser comunicadores efectivos, respetados
por sus colegas.
 Deben tener entendimiento pleno del dominio
del problema.
 Debe estar completamente empoderado para
tomar decisiones sobre sus representados.
34

Expectativas de los Campeones
de Productos
35
Categoría Actividades
Planeación
•Refinar el alcance y limitaciones del producto.
•Definir las interfases a otros sistemas.
•Evaluar el impacto de nuevos sistemas sobre
operaciones del negocio.
•Definir la ruta de transición a partir de las
aplicaciones actuales
Requisitos •Recolectar requisitos de otros usuarios
•Desarrollar los escenarios en los CU
•Resolver conflictos entre requisitos propuestos

Expectativas de los Campeones
de Productos
36
Categoría Actividades
Validación&
Verificación
•Inspeccionar los documentos de requisitos
•Definir el criterio de aceptación
•Desarrollar los casos de prueba a partir de los
escenarios de los CU
•Proveer los conjuntos de datos de pruebas
•Realizar las pruebas beta
Ayuda a
usuarios
•Escribir porciones de manuales de usuarios y
ayuda
•Preparar material para entrenamiento
•Presentar demostraciones de productos a
compañeros
Gestión de
Cambios
•Evalúa y prioriza las correcciones de defectos
•Evalúa y prioriza peticiones de extensión
•Evalúa el impacto de cambios propuestos de
requisitos en usuarios y procesos de negocio
•Participa en las decisiones de cambios

“Vendiendo” la idea del Campeón
de Producto
 Espera oposición a la propuesta
del Campeón del Producto: “Los
usuarios están muy ocupados”, “La
gerencia quiere tomar las
decisiones”, “Nos va a demorar”,
“Es muy caro”, “No se lo que voy a
hacer como Campeón de Producto”.
 Recuerda la importancia del
involucramiento del usuario.
37

38
Temas

Introducción
 Lea la siguiente Historia.
 ¿Le ha sucedido algo similar al
levantar requisitos? Comente.
39

Introducción
 El corazón de la IR es la Elicitación
de Requisitos (o levantamiento de
requisitos).
 La ER es el proceso de identificar
las necesidades y restricciones
de los diferentes stakeholders del
sistema software.
40

Introducción
 La ER se centra en los RU: las
tareas que los usuarios deben
realizar con el sistema y las
expectativas de rendimiento,
usabilidad y otros atributos de
calidad del usuario.
 El analista debe cambiar la
pregunta : ¿Qué deseas? por
¿Qué necesitas hacer?
41

Introducción
 El resultado de la ER es un acuerdo general
de las necesidades.
 Una vez que se encuentran estas necesidades,
los desarrolladores pueden explorar
soluciones alternativas para atender las
necesidades.
 Los participantes de la ER deben resistir la
tentación de diseñar el sistema hasta que
entiendan el problema, de otra forma se
arriesgan a hacer considerable tarea de
rediseño posteriormente.
42

Introducción
 El énfasis principal es en las tareas en
lugar de la IU y en enfocarse en las
necesidades básicas más que en deseos.
Esto mantiene al equipo enfocado y evita el
desvío prematuro hacia detalles de diseño.
43

Planeación de la Elicitación de
Requisitos
 Empieza por planear las
actividades de la Elicitación de
Requisitos.
 Aún un plan simple de acciones
incrementa la posibilidad de éxito y
ofrece expectativas reales a los
stakeholders.
44

Elementos a incluir en la
planeación de la ER
 Objetivos (explorar CU, desarrollar los RF, etc.)
 Estrategias y procesos (encuestas, talleres,
visitas al cliente, entrevistas individuales o a
grupos)
 Productos (lista de CU, el DERS, análisis de
encuestas o especificaciones de atributos de calidad)
 Estimación de tiempos y recursos (identificando
clientes y analistas en las actividades, estimaciones
de esfuerzo y tiempo)
 Riesgos (factores que pueden impedir la ER,
severidad de cada riesgo y como mitigar o controlar
el riesgo)
45

Elicitación de Requisitos
 La ER tiene éxito cuando se establece una
relación colaborativa entre clientes y los
desarrolladores de requisitos.
 La comunicación se facilita cuando se usa
el vocabulario del dominio y se evita la
“jerga” computacional. Use glosarios.
 Cuando la discusión se empieza a tornar
hacia el “espacio de la solución” la pregunta
¿Porqué? puede devolverla al “espacio del
problema”
46

Elicitación de Requisitos
 En lugar de sólo transcribir lo que los usuarios
dicen, un analista creativo sugiere ideas y
alternativas a los usuarios durante la
elicitación.
 Cuando los usuarios no pueden expresar lo
que ellos necesitan, quizá puedas observar
su trabajo (o incluso hacerlo) y sugerir formas
de automatizar el mismo.
 Después de cada entrevista, documenta los
aspectos discutidos y pide a los entrevistados
que revisen la lista y hagan correcciones.
47

Talleres de Elicitación
 Los talleres de requisitos son una
técnica altamente efectiva para
vincular usuarios y
desarrolladores (de requisitos).
 El facilitador debe planear el
taller, seleccionar los participantes y
guiar a los participantes a un
resultado exitoso.
48

Tips para conducir sesiones
exitosas en talleres de requisitos
 Establecer reglas claras:
 Iniciar y finalizar a tiempo.
 Regresar rápido de los “breaks”.
 Sólo uno comenta a la vez.
 Todos deben contribuir.
 Enfocar comentarios en aspectos, no en
individuos.
49

 Mantenerse en el alcance:
 Usar el documento de visión y alcance
para confirmar si los RU propuestos
caen dentro del alcance del proyecto.
 Enfocarse en las tareas del usuario y no
en detalles de diseño de IU (que
vendrá después).
50

 Usar “parking lots” para
registrar elementos para
posterior consideración:
 Múltiple información surgirá en el taller
(atributos de calidad, reglas de
negocio, ideas de IU, restricciones,
etc.). Usar hojas de rotafolio como
“Parking lots” para no perderlas,
mostrar respeto a quien las brinda y
usarlas después.
51

 Discusiones “Timebox”:
 Asignar una periodo fijo de tiempo para
discutir cada tópico (ej. 30 min. Por
cada CU). Evitar invertir más tiempo
que el necesario para evitar enfrentar
otros tópicos.
52

 Mantener el equipo pequeño e incluir
los participantes correctos.
 Grupos mayores a 5 o 6 participantes avanzarán
más lento.
 Incluya al Campeón del Producto y otros
representantes de usuarios, un analista de
requisitos y un desarrollador. Considere
“experiencia”, “conocimiento” y “autoridad para
tomar decisiones” como calificadores para
participar en el taller.
 Mantenga a todos participando en el
taller.
53

Clasificando la entrada de los
clientes
 El analista debe clasificar la
entrada de los clientes:
54

Requisitos del Negocio
 Cualquiera que describa los beneficios
económicos, de mercado o del negocio
que los clientes o la organización desea
ganar a partir del producto.
 “Incremento del mercado en un X%”
 “Ahorro de $Y por año en electricidad gastado
ahora por unidades ineficientes”
 “Ahorro de $Z en costos de mantenimiento
consumidos por el sistema legado W”
55

Casos de Uso o Escenarios
 Oraciones sobre objetivos de
usuario o tareas del negocio que
el usuario necesita realizar.
 “Necesito imprimir una etiqueta para
cada paquete”
 “Necesito gestionar una cola de muestras
químicas esperando ser analizadas”
 “Necesito calibrar el controlador de la
bomba”
56

Reglas de Negocio (RN)
 Cuando el cliente dice que sólo ciertas
clases de usuarios pueden realizar una
actividad bajo condiciones específicas.
 Se pueden derivar RF para forzar las
reglas.
 Las RN no son RF.
 “Debemos cumplir con cierta ley o política corporativa”
 “Se debe conformar algún a un cierto estándar”
 “Si alguna condición es verdad, entonces algo sucede”
 “Debe ser calculado de acuerdo a cierta fórmula”
57

Requisitos Funcionales (RF)
 Describen comportamientos observables
que el sistema exhibirá bajo ciertas
condiciones y las acciones que permitirá
a los usuarios tomar.
 Se derivan de los RU, RN y el DERS.
 “Si la presión excede 40 psi, la luz de precaución
se encederá”
 “El usuario será capaz de ordenar la lista del
proyecto en orden alfabético ascendente y
descendente”
 “El Sistema enviará un e-mail al Coordinador de
Ideas cuando alguien genere una nueva idea”
58

Atributos de Calidad
 Oraciones que indican que tan bien
el sistema desempeñará algún
comportamiento o permitirá a
los usuarios tomar alguna
acción.
 Rápido, fácil, intuitivo, amigable con el
usuario, robusto, confiable, seguro,
eficiente. (Todos éstos se deben definir
de forma precisa con el usuario).
59

Requisitos de Interfases Externas
 Describen conexiones entre tu sistema
y el resto del universo.
 El DERS debe incluir secciones para
interfases con usuarios, hardware y otros
sistemas software.
 “Debe leer señales de un dispositivo”
 “Debe enviar mensajes a otro sistema”
 “Debe ser capaz de leer (o escribir) archivos en
algún formato”
 “Debe controlar una pieza de hardware”
 “Los elementos de la IU deben conformarse a un
estilo estándar de IU”
60

Restricciones
 Restricciones de diseño e implementación
que acotan legítimamente las opciones
disponibles al desarrollador.
 “Los archivos enviados electrónicamente no
deben exceder 10 MB de tamaño”
 “Debe ser escrito en Java”
 “No debe requerir más de 1 Gb de RAM”
 “Debe operar idénticamente a otro sistema”
 “Debe usar un control de IU específico”
61

Definiciones de Datos
 Cuando el usuario describe el formato, tipo de
dato, valores permitidos o valores por
default para un elemento de datos o la
composición de una estructura de datos
compleja.
 “El código postal consiste de cinco dígitos,
seguido por un guión opcional, el valor por
default es 0000”
 Recolecte estos en un diccionario de datos,
una referencia maestra que el equipo puede
utilizar a lo largo de todo el desarrollo del
producto y su mantenimiento.
62

Ideas solución
 Mucho de lo que los usuarios presentan
como requisitos caen en la categoría de
ideas solución.
 Alguien que describe una forma específica
de interactuar con el sistema para realizar
cierta acción está presentando una solución
sugerida.
 El analista debe “sumergirse” debajo
de la Idea Solución para obtener el
verdadero requisito.
 La clave: preguntar ¿Porqué?
63

¿Cómo saber cuando terminar?
 Si el usuario no puede pensar en
más CU, quizá terminaste.
 Si el usuario propone nuevos CU,
cuyos RF ya fueron derivados,
quizá terminaste.
 Si los usuarios repiten aspectos
cubiertos en previas discusiones,
quizá terminaste.
64

¿Cómo saber cuando terminar?
 Si sugiere nuevas características,
RU o RF fuera de alcance.
 Si los requisitos propuestos son de
baja prioridad.
 Si los usuarios están proponiendo
capacidades que serán incluidas
“algún día en la vida del producto”
en lugar de “ahora”.
65

66
Temas

Introducción
 ¿Cómo conduce usted los talleres de
requisitos para obtener los CU?
67

Introducción
 Las personas utilizan los sistemas
software para alcanzar objetivos
y la industria del software busca
crear software útil.
 Un prerrequisito necesario para
diseñar software útil es conocer lo
que los usuarios intentarán
hacer con él.
68

Introducción
 Por muchos años, los analistas han
utilizado escenarios para obtener los
requisitos de usuarios.
 Un escenario es una descripción de
una sola instancia de uso del sistema.
 Ivar Jacobson, Larry Constantine y Lucy
Locwood, así como Alistair Cockburn
han formalizado esto en los Casos de
Uso.
69

El enfoque de Casos de Uso
 Un Caso de Uso describe una secuencia de
interacciones entre el sistema y un actor
externo.
 Aunque nacen en el mundo OO, pueden
utilizarse para cualquier paradigma de
desarrollo.
 Los CU cambian la perspectiva de desarrollo de
requisitos para discutir lo que los usuarios
necesitan lograr en contraste al enfoque
tradicional de preguntar a los usuarios lo que
desean que el sistema haga.
70

Diagramas de CU
 Proveen una representación visual de
alto nivel de los RU.
71

Casos de Uso y Escenarios
 Un CU es una actividad única que
un actor realiza para lograr algo de
valor.
 Un CU es una colección de
escenarios relacionados.
 Los escenarios pueden ser
normales o alternativos.
72

Elementos esenciales de la
descripción de un CU
 Un identificador único
 Un nombre que de forma breve establezca la
tarea del usuario “verbo+objeto”
 Una descripción textual escrita en lenguaje
natural
 Una lista de precondiciones
 Una lista de poscondiciones
 Una lista numerada de pasos que muestren los
pasos de la secuencia de diálogo entre actor y
sistema
73

Cursos Normal y Alternativos en
un CU
74

CU que comparten un conjunto
común de pasos-<<include>>
75

Identificando Casos de Uso
 Se pueden identificar en varias
formas:
 Identifica los actores primero y
después los procesos de negocio en
los cuales participan.
 Identifica los eventos externos a los
cuales el sistema debe responder y
después relaciona estos eventos a
actores participantes y CU especificos.
77

Identificando Casos de Uso
 Se pueden identificar en varias
formas:
 Expresar procesos de negocio en
términos de escenarios específicos,
generalizar los escenarios a CU e
identificar los actores involucrados en
cada CU.
 Derivar los CU a partir de RF. Si
algunos requisitos no trazan a CU
alguno, considere si realmente se
necesitan.
78

Documentando los CU
 En esta etapa de exploración, los
participantes deben pensar en CU
esenciales: simplificados,
generalizados, abstractos, libres de
tecnología e independientes de
implementación.
 El foco debe ser el objetivo que el
usuario trata de alcanzar y las
responsabilidades del sistema.
79

Documentando los CU
 Los CU esenciales están a un nivel
de abstracción más alto que los CU
concretos.
 Estilo concreto: capturar el número
ID del químico.
 Estilo esencial: especificar el químico
deseado.
80

Ejemplo de CU
 Este es un ejemplo de CU
81

CU y Casos de Prueba
 Así como los CU esenciales también
se pueden crear
Casos de Prueba conceptuales
(independientes de teconología).
 Estos Casos de Prueba ayudan al
equipo a tener un claro
entendimiento de cómo el sistema
se comportará en escenarios
específicos.
82

CU y RF
 Los desarrolladores software no
implementan RN o CU, ellos
implementan RF: “bits” específicos de
comportamiento de sistema que
permiten a los usuarios ejecutar los CU
y lograr sus objetivos.
 Es necesario que el analista traduzca
la visión de requisitos del usuario
(expresada en el CU) a la visión del
desarrollador.
83

Formas de documentar los RF
obtenidos a partir de los CU
 Sólo CU: incluir los RF directo en la
descripción del CU.
 CU y DERS: escribir descripciones
simples directas del CU y
documentar los RF derivados en el
DERS. Se debe establecer la
trazabilidad entre ambos.
84

Formas de documentar los RF
obtenidos a partir de los CU
 Sólo DERS: organizar el DERS por
CU o por característica e incluir
ambos, CU y RF, en el DERS.
85

Errores a evitar
 Muchos CU: quizá porque no se
estén escribiendo al nivel de
abstracción adecuado. Típicamente
se deben tener más CU que RN y
características, pero menos que los
RF.
86

Errores a evitar
 Incluir diseño de IU en los CU:
los CU se deberían enfocar en lo
que los usuarios necesitan lograr
con la ayuda del sistema, no en
como se deberían ver las pantallas.
Enfatiza las interacciones
conceptuales entre actores y
sistema y difiere la IU específica
a la etapa de diseño.
87

Errores a evitar
 Incluir definiciones de datos en los CU.
Manejarlo en un diccionario de datos
separado.
 CU que los usuarios no entienden. Si los
usuarios no pueden relacionar la
descripción del CU a sus procesos de
negocio o tareas, hay problemas con el CU.
 Uso excesivo de relaciones include y
extends.
88

89
Temas

Introducción
 Toda organización opera de acuerdo
a un conjunto extenso de políticas
corporativas, leyes y estándares
industriales.
 Tales principios controladores se les
conoce colectivamente como
Reglas de Negocio.
90

Introducción
 Las Aplicaciones Software frecuentemente
forzan las RN, en otros casos son controladas
humanamente mediante políticas y procedimientos.
 Muchas RN se originan fuera del contexto de
toda aplicación software, aunque suelen ser la
fuente mayor de RF porque dictan capacidades
que el sistema debe poseer para conformar con las
reglas.
 Aún Requisitos del Negocio de alto nivel
podrían conducirse a partir de RN (cumplir con
alguna regulación gubernamental).
91

Introducción
 Las RN se deben tratar como un Activo
Importante.
 Si no se documentan o manejan apropiadamente
existirán sólo en la “mente” de los individuos: se
entenderán de forma distinta, se manejarán
inconsistentemente.
 Si se conoce donde y como cada aplicación
implementa sus RN, será mucho más fácil cambiar
las aplicaciones cuando la regla cambie.
 Tener un Repositorio Maestro de RN facilitará a
todas las aplicaciones afectadas su implementación
consistente.
92

Taxonomía de las RN
 Se han propuesta diferentes
taxonomías (clasificaciones) para
organizar las RN.
 Veremos una taxonomía simple que
incluye cinco tipos de RN que
trabajan para muchas situaciones.
93

Taxonomía de las RN
94
Una sexta categoría podría incluir
términos, palabras definidas, frases y
abreviaciones que son importantes
para el negocio.
(Un Glosario es un lugar conveniente
para definir términos)

Hechos (Facts)
 Los Hechos son estatutos simples que
son verdad a lo largo de todo el negocio.
Son llamados invariantes (verdades
inmutables de entidades y atributos).
 Describen asociaciones o relaciones
entre términos importantes del negocio.
 Otras RN podrían referenciar ciertos
Hechos, pero los Hechos en sí mismos
generalmente no se traducen en RF
software.
95

Ejemplos de Hechos (Facts)
 “Cada contenedor químico tiene un identificador
único en código de barras”
 “Cada orden deberán tener un cargo de
embarque”
 “Cada línea de producto en una orden
representa una combinación específica de
químico, grado, tamaño de contenedor y
número de contenedores”
 “Boletos no reembolsables generan un cargo
cuando el comprador cambia el itinerario”
 “El impuesto de ventas no se calcula sobre
cargos de embarque”
96

Restricciones (Constraints)
 Los Constraints acotan las
acciones que el Sistema o sus
usuarios pueden realizar.
 Algunas palabras y frases que
sugieren una RN “Restricción”:
debe, no debe, podría, solamente.
97

Ejemplos de Restricciones
(Constraints)
 “Un solicitante menor de 18 años debe tener
un padre o tutor como aval del préstamo.”
 “Un usuario puede solicitar un químico en nivel
1 solamente si tiene entrenamiento en
químicos de uso rudo en los pasados 12
meses.”
 “La correspondencia podría no desplegar más
de 4 dígitos del número del IMSS.”
 “La tripulación de una línea aerea debe recibir
al menos 8 Hrs. De descanso continuo en cada
periodo de 24 Hrs.”
98

Hay muchas restricciones
 Pueden existir restricciones a nivel de
proyecto o diseño o implementación.
 Muchas RN imponen restricciones
sobre la forma en la que el negocio
opera: donde se reflejen en los RF
software, la restricción es la
justificación del RF.
 En el acceso al sistema también hay
restricciones (manejo de Passwords).
99

Habilitadores de Acción (Action
Enablers)
 Una regla que dispara alguna
actividad bajo condiciones
específicas es un Habilitador de
Acción.
 La condición podría ser una
combinación compleja de valores
falso y verdaderos para múltiples
condiciones individuales.
100

Enablers)
 Forma general:
“Si <alguna condición es verdadera
o sucede algún evento> entonces
<algo sucede>”
 Se pueden documentar como
Tablas de decisión (se verán
después).
101

Enablers) Ejemplos
 “Si el almacén de químicos tiene
contenedores de un cierto químico,
entonces ofrece contenedores al solicitante”
 “El último día del cuatrimestre, genera el
reporte EP sobre manejo de químicos”
 “Si el cliente ordenó un libro para autor que
ha escrito múltiples libros, entonces ofrece
los otros libros del autor antes de aceptar la
orden”
102

Inferencias (Inferences)
 Es una regla que establece nuevo
conocimiento basado en la
veracidad de ciertas condiciones.
 También se le conoce como
conocimiento inferido.
 La inferencia crea un nuevo hecho
a partir de otros hechos o a partir
de computaciones.
103

Inferencias (Inferences)
 También utilizan la forma
“Si/Entonces”, pero la clausula
“Entonces” implica un Hecho o
Pieza de Información, no una
acción a realizar.
104

Inferencias (Inferences) Ejemplos
 “Si un pago no se recibe dentro de 30 días
de calendario o la fecha está vencida,
entonces la cuenta es reportada”
 “Si el vendedor no puede embarcar un
producto de la orden dentro de cinco días a
partir de la recepción de la orden, entonces
el producto es devuelto”
 “Químicos con toxicidad LD50 menor a 5
mg/Kg son consideradores peligrosos”
105

Computaciones (Computations)
 Cálculos realizados usando
fórmulas matemáticas
específicas o algoritmos.
 Muchas computaciones siguen
reglas que son externas a la
compañía (como el cálculo de
impuestos).
106

Computaciones (Computations)
 “El precio unitario se reduce un 10% para
ordenes de 6 a 10 unidades, 20% para órdenes
de 11 a 20 unidades y 35% para órdenes
mayores a 20 unidades”
 “El cargo por envío terrestre para una orden
que pesa más de 2 Kg. Es $4.75 más $0.12 por
fracción”
 “El precio total de una orden se calcula como la
suma del precio de los productos, menos los
descuentos, más lo impuestos, más el cargo de
embarque y seguro”
107

Documentando las RN
 Dado que las RN pueden influir múltiples
aplicaciones, la organización debería
manejarlas como un activo a nivel
empresarial (no a nivel de proyecto).
 En principio un catálogo simple es
suficiente, en casos mayores se podría
manejar una base de datos (con todo,
busque siempre la simplicidad).
 Trate de definir una plantilla para la
documentación.
108

Ejemplo de plantilla para
documentar las RN
109
ID Definición de la
Regla
Tipo de
Regla
Estática/
Dinámica
Fuente
ORDER-15
Un usuario puede
solicitar un
químico a nivel 1
solamente si tiene
entrenamiento en
los 12 meses
anteriores
Restricción Estática Política
corporativa
DISC-13 El descuento a la
orden se calcula
basado en el
tamaño de la
orden actual
Computación
Dinámica Política
corporativa

Reglas del Negocio y Requisitos
 Simplemente preguntar al usuario:
“¿Cuáles son tus RN?” Suele no
ayudar para su descubrimiento.
 Dependiendo de la aplicación,
algunas veces tendrás que
inventar la RN conforme
avances en el análisis y otras las
descubrirás durante las
discusiones de requisitos.
110

Reglas del Negocio y Requisitos
 Durante el taller de Elicitación de
Requisitos el analista tendrá que
hacer preguntas sobre las
razones de ciertos requisitos y
restricciones que los usuarios
presenten.
 Estos discusiones provocan el
surgimiento de RN como
justificaciones.
111

Fuentes de RN y preguntas
posibles que las obtienen
112

RN descubiertas y su
implementación
 Después de identificar y
documentar la RN, determine
cuales se deben implementar en
el software.
 Algunas RN conducirán a CU (y por
tanto a Requisitos Funcionales que
forzarán la regla).
113

implementación-Ejemplo
 Regla #1 (Habilitador de Acción) “Si la
fecha de expiración para el contenedor
químico se ha alcanzado, entonces notifique
a la persona que posee actualmente el
contenedor”
 Regla #2 (Inferencia) “Un contenedor de
un químico que puede formar un producto
explosivo se considera expirado 1 año
después de su fecha de manufactura”
 Regla #3 (Hecho) “El Éter puede formar
espontáneamente peróxidos explosivos”
114

implementación-Ejemplo
 Estas reglas dieron origen al CU
“Notificar el propietario químico de
expiración”
 Un RF para este CU es “El sistema
enviará una notificación por e-mail
al propietario del contenedor
químico en la fecha en la que el
contenedor expire”
115

Trazabilidad entre RF y sus
Reglas de Negocio padre
 Use un atributo en el requisito
llamado “Origen” e indique la regla
que originó el RF
 Defina enlaces de trazabilidad
entre el RF y la(s) RN(s) pertinentes
en la Matriz de Trazabilidad.
116

Recomendación Final
 Para prevenir redundancia, no
dupliques reglas del catálogo de
RN en el DERS.
 En su lugar, el DERS debería
referenciar hacia reglas específicas
como fuente, digamos, de
algoritmos.
117

Siguientes pasos…
 Lista todas las RN que pienses
pertenecen al proyecto en el que
estás trabajando. Empieza poblando
un catálogo de RN. Clasifícalas de
acuerdo a la taxonomía propuesta y
discute el origen de cada regla.
 Identifica la justificación detrás de
tus requisitos funcionales para
descubrir otras RN.
118

Siguientes pasos…
 Construye una matriz de
trazabilidad para indicar cuales RF o
elementos de la base de datos
implementan cada RN que has
identificado.
119

120
Temas

Introducción
 El resultado del Desarrollo de Requisitos es
un acuerdo entre clientes y
desarrolladores sobre el producto a
construir.
 El documento de Visión y Alcance
contiene los RN.
 Los Requisitos de Usuario se capturan en
los CU.
 Los RF y RNF detallados residen en el
Documento de la Especificación de
Requisitos Software (DERS).
121

Introducción
 A menos que todos los requisitos
se escriban en un formato
legible y los stakeholders clave los
revisen, la gente no tendrá
seguridad de lo que se está
acordando.
122

Introducción
 Los requisitos software se pueden representar
de diversas formas:
 Documentos que usan lenguaje natural
estructurado y bien escrito.
 Modelos gráficos ilustrando procesos,
estados del sistema y sus cambios,
relaciones de datos, etc.
 Especificaciones formales matemáticas.
 La forma más práctica: documentos
textuales+modelos gráficos.
123

La Especificación de Requisitos
Software
 La ERS establece de forma precisa
las Funciones y Capacidades que
el sistema software debe proveer y
las Restricciones que debe
respetar.
 Es la base para la posterior
planeación, diseño y codificación
(las cuales no deberían incluirse
ahí).
124

ERS: completa y correcta
 La ERS es el repositorio último
para los requisitos del producto, por
lo que se espera que sea completa.
 Ni desarrolladores, ni clientes
deberían hacer supuestos: si una
cierta capacidad o calidad no
aparece ahí, no se debe esperar
que aparezca en el producto.
125

ERS: evolutiva e iterativa
 No se debería esperar escribir el DERS
completo desde el inicio.
 Pero si se necesita capturar en él los
requisitos de cada incremento, antes de
construir tal incremento.
 Antes de iniciar cada iteración se deberían
fijar (obtener su línea base).
 La línea base es el resultado de la
revisión y aprobación de la ERS.
126

Organizando la ERS: Etiqueta los
Requisitos
 Para satisfacer el criterio de
trazabilidad y modificabilidad cada
RF se debe etiquetar.
 Numéralos secuencialmente: RF-
39, RNF-40.
 En caso de duda en algún requisito,
señálalo de alguna manera: TBD
(To be determined).
127

ERS e Interfases de Usuario
 Imágenes de pantallas o arquitecturas de
IU describen soluciones (diseños), no
requisitos.
 El diseño de pantallas podría retardar el
establecimiento de la línea base de los
requisitos.
 Incluir diseño de IU en requisitos puede
resultar en un diseño visual conduciendo
los requisitos, lo cual puede llevar a
vacíos funcionales.
128

ERS e Interfases de Usuario
 Un balance adecuado podría ser incluir
imágenes conceptuales (esquemas) de
pantallas seleccionadas en la ERS sin
demandar la implementación precisa
siguiendo esos modelos.
 Esto podría mejorar la comunicación sin
motivar a los desarrolladores con
restricciones innecesarias.
 Debería ilustrar la intención subyacente,
nada más.
129

Plantilla para la ERS (basada en el
estándar IEEE 830)
 No hay necesidad de inventar un
nuevo documento de ERS.
 Puede utilizar esta plantilla, basada
en el estándar IEEE 830.
 Un Ejemplo.
130

131
Temas
 Modelos y Diagramas para diversos
Requisitos

Introducción
 Lea esta Historia
 Con relación a su experiencia,
¿Cuáles son los Diagramas que
utiliza para la especificación de
requisitos?.
132

Introducción
 De acuerdo a Alan Davis (1995) no
existe una sola vista de los
requisitos que provea un
entendimiento completo.
 Se necesita una combinación de
representaciones textuales y
visuales para dibujar la imagen
completa del sistema.
133

Introducción
 Las vistas incluyen:
 Listas y tablas de RF.
 Modelos gráficos de análisis
 Prototipos de IU
 Casos de uso
 Casos de prueba
 Árboles de decisión
 Tablas de decisión, etc.
134

Introducción
 Los analistas podrían escribir los
RF y dibujar algunos modelos.
 Los diseñadores de IU construyen
prototipos.
 Los “testers” conducen la escritura
de los casos de prueba.
135

Introducción
 Comparando las diversas
representaciones creadas a través
de diversas personas, con diversos
procesos de pensamiento revelará
inconsistencias, ambigüedades,
supuestos y omisiones difíciles de
detectar a partir de una única vista.
136

De la Voz del Cliente a Modelos
de Análisis
 Escuchando cuidadosamente
como presentan los clientes sus
requisitos, el analista puede
seleccionar palabras que se
correspondan con elementos de
modelado.
137

De la Voz del Cliente a Modelos
de Análisis-Ejemplo
138
Tipo de Palabra Ejemplos Componentes de
Modelos de
Análisis
Sustantivo Personas,
organizaciones,
sistemas software,
datos u objetos que
existan
Terminadores o
datos (DFD)
Actores (CU)
Entidades o sus
atributos (DER)
Clases o sus
atributos (DC)
Verbo Acciones, cosas que
el usuario puede
hacer, eventos que
pueden suceder
Procesos (DFD)
CU
Relaciones (DER)
Transiciones (DTE)
Actividades (DA)

Diagrama de Flujo de Datos (DFD)
 Identifica los procesos
transformacionales del sistema, las
colecciones (almacenes) de datos o
materiales que el sistema manipula y los
flujos de datos o materiales entre
procesos, almacenes y el mundo exterior.
 Se puede elaborar el Diagrama de
Contexto en el nivel 0 del DFD
dividiendo el sistema en sus procesos
mayores.
139

Diagrama de Flujo de Datos
(DFD)-Ejemplo
140

Diagrama Entidad-Relación
 Muestra las relaciones entre los
datos del sistema.
 Si el Diagrama ER se utiliza desde la
perspectiva del analista entonces
mostrará grupos lógicos de
información del dominio del
problema.
141

Diagrama Entidad-Relación-
Ejemplo
142

Máquinas de Estado que modelan
IU: el Mapa de Diálogo
 El comportamiento de una IU se puede modelar
mediante una Máquina de Estado.
 En un momento en el tiempo un solo elemento
de diálogo (menú, workspace, caja de diálogo,
prompt, etc.) está disponible para entrada del
usuario.
 El usuario navega a un cierto elemento de
diálogo basado en acciones que realiza desde
el mismo.
 Esta Máquina de estados se le llama Mapa de
Diálogo (Wasserman y Wiegers)
143

 El Mapa de Diálogo representa la IU a un nivel de
abstracción alto.
 Muestra los elementos de diálogo en el sistema y los
enlaces de navegación entre los mismos, sin
mostrar detalles de diseño de pantallas.
 El Mapa de Diálogo permite que puedas explorar
conceptos de la IU basado en el entendimiento
que se tiene de los requisitos (puede complementar
los CU).
 Usuarios y desarrolladores pueden estudiar el Mapa
de Diálogo para consensar una visión común de
cómo el usuario interactuaría con el sistema
para realizar una cierta tarea.
144

 Los usuarios pueden recorrer el
Mapa de Diálogo para buscar
transiciones innecesarias,
incorrectas, perdidas y por tanto
requisitos perdidos, incorrectos o
innecesarios.
 Importante: el Mapa de Diálogo
conceptual que se formula como
parte del análisis sirve como guía
durante el diseñado detallado de
la IU. 145

Del Mapa de Diálogo a la Máquina
de Estados
 Cada Elemento de Diálogo se
corresponde con un estado de una
Máquina de Estados.
 Cada opción de Navegación se
corresponde con una transición
(flecha) entre estados.
 El evento que dispara una
navegación de IU se muestra sobre la
flecha de transición.
146

Del Mapa de Diálogo a la Máquina
de Estados
 Eventos:
 Acción de usuario: presionar una tecla
de función, clic sobre un hyperlink o
presionar un botón.
 Valor de datos: entrada de usuario
inválida que dispara un mensaje de
error.
 Condición de sistema: detectar que
una impresora no tiene papel.
 Alguna combinación de las
anteriores: teclear una opción de menú
y presionar la tecla Enter. 147

Ejemplo de Mapa de Diálogo
148
Elemento de diálogo
Acción
stm Solicitud de químico-IU DTE
Lista de Solicitudes
Actuales
Captura químico de
solicitud
Despliega Mensaje de
Error
Lista de Vendedores
para el químico
Lista de contenedores
almacén
Confirmar que la
solicitud se acepta
Histórico del
Contenedor
Pide colocar una solicitud Cancela la solicitud
borrar químico de la lista
solicitar otro químico
cancelar la
adición de
nuevo químico
quimico invalido
OK
solicitar químico desde almacen
solicitar un químico diferente
solicitar un químico de un vendedor
solicitar un químico diferente
cancelar la adicion de un nuevo químico
seleccionar vendedor y agregarlo a la lista
introducir solicitud para un número > 0 de químicos
solicitar químico de un vendedor
solicitar ver el Histórico del Contenedor Return
OK; salir de función de solicitud
seleccionar contenedor y agregarlo a la lista
cancelar la adición de nuevos químicos

Diagramas de Clases
 Un Diagrama de Clases en el cual
las clases se corresponden a
entidades del dominio o negocio y
donde además se muestran las
relaciones entre las clases.
149

Diagrama de Clases-Ejemplo
150

Tablas de Decisión y Árboles de
Decisión
 Son 2 técnicas alternativas para
representar lo que el sistema debe hacer
cuando entran en juego decisiones de
lógica compleja.
 La Tabla de Decisión lista los diferentes
valores para todos los factores que
influyen un cierto comportamiento e indica
la acción esperada del sistema en respuesta
a una combinación de factores.
151

Tabla de decisión-Ejemplo
152
Número de Requisito
Condición 1 2 3 4 5
Usuario
autorizado
F V V V V
Químico
disponible
- F V V V
Químico
peligroso
- - F V V
Solicitante
entrenado
- - - F V
Aceptar
solicitud
X X
Rechazar
solicitud
X X X

Árbol de decisión
 Es una forma alternativa de
representar gráficamente lógica
compleja y acciones del sistema.
 Selecciona sólo 1
representación: tabla de decisión
o árbol de decisión
153

Árbol de decisión-Ejemplo
154

Recomendaciones finales …
 Cada técnica de modelado vista tiene sus
ventajas y limitaciones.
 Algunas se sobreponen a otras (D. E-R, D.
de clases, por ej.) por lo que no trates de
crear todos los modelos para tu proyecto.
 Toma en cuenta que los modelos de análisis se
crean para ofrecer entendimiento y
comunicación que vaya más allá de la
especificación textual o de una única vista que
un requisito pueda proveer.
 Usa lo que realmente necesitas para
explicar mejor tus requisitos.
155

156
Temas

Introducción
 Discuta la relación que existe
entre el éxito de un proyecto
software y sus Requisitos No
Funcionales.
157

Introducción
 El éxito de un sistema software dependen
no sólo de que ofrezca la funcionalidad
esperada.
 Depende, también, de que logre las
expectativas de que tan bien trabajará.
 Es decir:
 ¿Qué tan fácil de utilizar será?
 ¿Qué tan rápido correrá?
 ¿Qué tan frecuente fallará?
 ¿Cómo manejará situaciones inesperadas?
158

Introducción
 Los Atributos de Calidad
distinguen a un producto que
solamente hace lo que se supone
debe hacer de otro que “deleita” a
sus clientes.
 Un producto software excelente
refleja un óptimo balance de las
características de calidad
competentes.
159

Introducción
 Si no exploras las expectativas de
calidad durante el levantamiento de
requisitos, serás afortunado si el producto
los satisface.
 Desde el punto de vista técnico, los
Atributos de Calidad conducen las
decisiones arquitectónicas y de diseño
(dividir las funciones del sistema en varias
computadoras para alcanzar objetivos de
desempeño o integridad)
160

Introducción
 Generalmente los clientes no presentan
sus expectativas de calidad
explícitamente, sólo a través de su
información podemos encontrar pistas
al respecto.
 La calidad, en sus muchas dimensiones,
debe definirse tanto por clientes como
por aquellos que construirán, probarán
y mantendrán el software.
161

Atributos de Calidad
 Existen varias clasificaciones para los
Atributos de Calidad.
 Si los desarrolladores conocen cuales
son más cruciales para el éxito de su
proyecto, podrán seleccionar el mejor
enfoque para la arquitectura, diseño y
programación que logre alcanzar los
objetivos de calidad.
 Se muestra una posible clasificación.
162

Clasificación-Atributos de Calidad
163
Importantes para los
Usuarios
Importantes para los
Desarrolladores
Disponibilidad Capacidad de Mantenimiento
(Maintainability)
Eficiencia Portabilidad
Flexibilidad Reusabilidad
Integridad Capacidad de Pruebas
(Testability)
Interoperabilidad
Confiabilidad
Robustez
Usabilidad

El Mundo Ideal …
 En un Mundo Ideal todo sistema debería
exhibir el máximo valor posible para todos sus
atributos: estar disponible todo el tiempo, nunca
fallar, ofrecer resultados instantáneos y correctos y
ser intuitivo de utilizar.
 Como esto no siempre es posible, tu debes
aprender cuales atributos son los más
importantes para el éxito de tu proyecto.
 Después definir los objetivos del usuario y
desarrollador en términos de los atributos
esenciales de tal forma que los diseñadores tomen
las decisiones apropiadas.
164

Definiendo los Atributos de
Calidad
 Se deben definir preguntas apropiadas
para obtener del usuario los Atributos de
Calidad del Sistema.
 El analista debe trabajar con los usuarios
para crear requisitos específicos,
medibles y verificables.
 Considera, además, preguntar a los
usuarios lo que sería un desempeño,
usabilidad, integridad o confiabilidad
inaceptable (requisitos inversos).
165

Atributos importantes para los
usuarios-Disponibilidad
 La medida planeada de tiempo en la
que el sistema estará disponible para
su uso completamente operacional.
 Disponibilidad= Tiempo Medio entre Fallas del
Sistema/Tiempo promedio de reparación entre fallas
 Pregunta al usuario que porcentaje real de
tiempo requieren disponibilidad y si hay
momento para los cuales es imperativo para lograr
objetivos del negocio o seguridad.
166

usuarios-Disponibilidad
 Ejemplo:
 DI-1 El sistema debería estar
disponible al menos 99.5% en
miércoles entre 6:00 am y media
noche, y al menos 99.95% en
miércoles entre 4:00 pm y 6:00 pm
hora local.
 Ten cuidado con especificar 100% en
los atributos de calidad porqué será
imposible y costoso de alcanzar.
167

usuarios-Eficiencia
 La medida de que tan bien el sistema
utiliza la capacidad del CPU, espacio en
disco, memoria o ancho de banda.
 La Eficiencia está relacionada con el
desempeño: si el sistema consume
muchos de los recursos disponibles, los
usuarios encontrarán baja en el
desempeño.
 Considera configuraciones mínimas de
hardware cuando defines objetivos de
eficiencia, capacidad y desempeño.
168

usuarios-Eficiencia
 Ejemplo:
 EF-1: Al menos 25% de la capacidad
del CPU y RAM disponible a la
aplicación deberían estar sin usar en
las condiciones planeadas de carga
pico.
169

usuarios-Flexibilidad
 Mide que tan fácil es el sistema
para agregarle capacidades.
 Se le conoce también como:
extensibilidad, aumentabilidad,
expandibilidad.
 Si los desarrolladores anticipan
muchas extensiones, deberían
seleccionar enfoques de diseño
que maximicen la flexibilidad del
software.
170

usuarios-Flexibilidad
 Ejemplo:
 FL-1: Un programador con al menos 6
meses de experiencia soportando este
producto debería ser capaz integrarle
una nueva capacidad de impresión al
producto, incluyendo modificaciones al
código y pruebas, en no más de 1 hr. de
trabajo.
171

usuarios-Integridad
 El cual abarca seguridad, tiene que
ver con el bloqueo de acceso no
autorizado a las funciones del
sistema, prevenir pérdida de
información, asegurar que el
software está protegido contra
virus y proteger la privacidad y
seguridad de los datos
introducidos al sistema.
172

usuarios-Integridad
 Establece los requisitos de integridad
en término no ambiguos:
verificación de identidad de usuario,
niveles de privilegio de usuarios,
restricciones de acceso o datos
precisos que se deben proteger.
173

usuarios-Integridad
 Ejemplo:
 IN-1: Sólo los usuarios que tengan
privilegios de Auditor estarán autorizados
para ver el histórico de movimientos del
cliente.
 Muchos de los requisitos de
Integridad son también Reglas de
Negocio. Esto sugiere establecer
trazabilidad entre los mismos.
174

usuarios-Interoperabilidad
 Qué tan fácil puede intercambiar
datos o servicios el sistema con
otros sistemas.
 Para evaluar interoperabilidad, necesitas
conocer con cuales otras
aplicaciones se integrarán los datos
y servicios de la aplicación actual.
 Está relacionada con los requisitos de
interfases externas.
175

usuarios-Interoperabilidad
 Ejemplo:
 IO-1. El Sistema deberá ser capaz de
importar cualquier estructura química
del sistema ChemiDraw (versión 2.3 o
anterior) y Chem-Struct (versión 5 o
anterior).
176

usuarios-Confiabilidad
 La probabilidad de que el
software se ejecute sin fallas por
un periodo específico de tiempo.
 La Robustez es también considerado
un aspecto de confiabilidad.
 Medida: porcentaje de las
operaciones que se completan
correctamente y tiempo promedio en
el que el sistema corre antes de
fallar.
177

usuarios-Confiabilidad
 Ejemplo:
 CO-1. No más de 5 experimentos de
1000 se deberían perder por fallas en
el software.
178

usuarios-Robustez
 O Tolerancia a Fallas: grado al cual un
sistema continua funcionando
apropiadamente cuando se enfrenta a
entradas inválidas, defectos en
componentes software y hardware o
condiciones no esperadas de operación.
 Pregunte al usuario sobre condiciones de
error que el sistema podría encontrar y
la forma en la que debería reaccionar.
179

usuarios-Robustez
 Ejemplo:
 RO-1. Si el editor falla antes de que el
usuario guarde el archivo, el editor
debería ser capaz de recuperar todos los
cambios hechos en el archivo que está
siendo editado, hasta antes de 1 minuto
antes de la falla. Esto estará disponible
la próxima vez que el usuario inicie el
programa.
180

usuarios-Usabilidad
 Incluye los factores que hace que los
usuarios perciban al sistema amigable con
el usuario.
 También se le conoce como facilidad de
uso, ingeniería humano-computadora.
 Discusiones sobre usabilidad pueden incluir
preguntas tipo: ¿Qué tan importante es que
seas capaz de solicitar químicos de forma
rápida y simple?¿Que tanto tiempo debería
tomar completar una solicitud de un
químico?
181

usuarios-Usabilidad
 Ejemplos:
 US-1. Un usuario entrenado debería ser capaz de
introducir una solicitud completa en un promedio
de cuatro a máximo seis minutos.
 US-2. Todas las funciones del menú Archivo
deberán contar con teclas “shortcut” (Ctrl-X). Los
comandos del Menú deberán ser semejantes a
Microsoft Word.
 US-3. Un usuario que nunca hubiera utilizado el
sistema deberá ser capaz de hacer una solicitud
con no más de 30 minutos de orientación.
182

Desarrolladores-Mantenibilidad
 Indica que tan fácil es corregir un
defecto o modificar el software.
 Depende de que tan fácil es de
entender, cambiar y probar el
software. Está relacionado con la
flexibilidad y capacidad de prueba.
 Se mide en términos del tiempo
promedio para arreglar un problema y
el porcentaje de reparaciones
correctas.
183

Desarrolladores-Mantenibilidad
 Ejemplo:
 MA-1. Un programador de
mantenimiento deberá ser capaz de
modificar los reportes existentes con 20
horas de trabajo o menos de esfuerzo de
desarrollo.
 MA-2. Las llamadas a funciones no
deberán anidarse en más de 2 niveles de
profundidad.
184

Desarrolladores-Portabilidad
 El esfuerzo requerido para migrar una
pieza de software de un ambiente operativo
a otro.
 Algunos incluyen también la habilidad de
internacionalizar y localizar un
producto.
 Los desarrolladores seleccionar
aproximaciones de diseño y codificación
que facilitarán la portabilidad del producto
apropiadamente.
185

Desarrolladores- Reusabilidad
 El esfuerzo relativo para convertir un
componente software y utilizarlo en otra
aplicación.
 Desarrollar un componente reutilizable tiene un
costo mayor que uno que sólo se utilizará en 1 sola
aplicación.
 Un software reutilizable debe ser:
 Modular
 Bien documentado
 Independiente de aplicación específica y ambiente
operativo
 Genérico en capacidad.
186

Desarrolladores- Reusabilidad
 Ejemplo:
 RU-1: Las funciones de entrada se
diseñarán para ser reutilizables a nivel
de código objeto en otras aplicaciones
que utilizan representaciones
internacionales de estructuras
químicas.
187

Desarrolladores- “Testability”
 Conocida también como verificabilidad.
Se refiere a la facilidad con la cual los
componentes software o el producto
integrado se pueden probar para la
búsqueda de defectos.
 El diseño para verificabilidad es crítico si:
 El producto tiene algoritmos y lógica compleja.
 Contiene interrelaciones complejas de
funcionalidad.
 Será modificado frecuentemente (y tendrán que
requerirse múltiples pruebas de regresión).
188

Desarrolladores- “Testability”
 Ejemplo:
 TE-1: La complejidad ciclomática
(McCabe 1982) máxima de un módulo
no deberá exceder a 20.
 Complejidad ciclomática: medida del número
de ramificaciones lógicas en el código fuente:
entre más ramificaciones y ciclos tenga tenderá
a ser más difícil de probar, entender y mantener.
189

Desarrolladores- Desempeño
 Que tan bien o que tan rápido debe
desempeñar funciones específicas el
sistema.
 Incluye: velocidad, througput
(transacciones por segundo), capacidad
(carga concurrente) y tiempo (alta
demanda en tiempo real).
 Los requisitos de desempeño restringen
seriamente las estrategias de diseño,
por lo que es importante establecer
claramente sus objetivos.
190

Desarrolladores- Desempeño
 Ejemplo:
 DE-1. El intérprete debe realizar el
análisis sintáctico a velocidad de 500
estatutos por minuto.
 DE-2. Cada página Web se descargará
en 15 segs O menos sobre una
conexión por modem de 50 Kbps
 DE-3. La autorización de un retiro en el
cajero automático no deberá tomar
más de 10 seg.
191

Definiendo RNF usando
Planguage
 Algunos de los RNF se han definido
de forma incompleta o no precisa.
 No se puede evaluar un
producto si no se definen los
RNF de forma precisa.
 Para abordar el problema de la
ambigüedad e incompletitud de RNF
Tom Gilb ha desarrollado
Planguage.
192

Planguage
 Ejemplo - Definir el RNF en Planguage:
“95% de las consultas a la base de datos del
catálogo deben completarse dentro de 3
segs. con un usuario que utiliza una PC
Intel Pentium 4 de 1.1 Ghz corriendo
Windows XP con al menos 60% de los
recursos del sistema libres”
193

Planguage
 TAG Desempeño.
ConsultaTiempoDeRespuesta (Etiqueta)
 AMBITION Tiempo de respuesta rápido
para consultas de base de datos sobre la
plataforma del usuario (propósito del RNF)
 ESCALA Segundos de tiempo entre
presionar la tecla Enter (o clic Ok) para
introducir la consulta y empezar el
despliegue de resultados (unidad de
medida)
194

Planguage
 MÉTRICA Pruebas Stopwatch realizadas
sobre 250 consultas de prueba que
representan un perfil de uso operacional
(forma precisa de hacer las mediciones)
 DEBE No más de 10 segs. Para el 98% de
las consultas (nivel mínimo aceptable)
 PLAN No más de 3 segs. por cada
categoría de consulta, 8 seg. Para todas las
consultas (objetivo nominal)
195

Planguage
 DESEO No más de 2 segundos para todas
las consultas. (resultado ideal)
 DEFINICIÓN de plataforma base
Procesador Intel Pentium 1.1 Ghz, 128 Mb
RAM, Windows XP, corriendo QueryGen 3.3
con al menos 60% de recursos libres.
Ninguna otra aplicación corriendo.
 Más detalles: http://www.gilb.com
196

Compensación de atributos
(Trade-off)
 Ciertas combinaciones de atributos
presentan compensaciones
mutuas.
 Usuarios y desarrolladores deben
decidir cuales atributos son más
importantes que otros y respetar
estas decisiones consistentemente
al tomar decisiones.
197

Tabla de Compensación de
atributos (Trade-off)
 La siguiente tabla muestra las
compensación entre atributos. Utiliza
los siguientes convencionalismos para su
interpretación:
 Un sigo “+/-” en el renglón indica que
incrementar el atributo del renglón
tiene un efecto positivo/negativo en el
atributo de la columna.
 Una celda en blanco indica
poco/ningún efecto en el atributo de la
columna.
198

Tabla de Compensación de
atributos (Trade-off)
199

Implementando los RNF
 Aunque los Atributos de Calidad
son RNF, ellos pueden conducir a
RF, líneas guía de diseño u otra
información técnica que
producirán los atributos de calidad
deseados.
200

De los Atributos de Calidad (RNF)
a Especificaciones Técnicas
201
Tipo de Atributo de Calidad Probable Categoría de
Información Técnica
Integridad, Interoperabilidad,
Robustez, Usabilidad, Seguridad
Requisitos Funcionales
Disponibilidad, Flexibilidad,
Eficiencia, Desempeño,
Confiabilidad
Arquitectura del Sistema
Interoperabilidad, Usabilidad Restricciones de Diseño
Flexibilidad, mantenibilidad,
portabilidad, confiabilidad,
reusabilidad, verificabilidad,
usabilidad
Línea guía de diseño
Portabilidad Restricción de Implementación

202
Temas

Introducción
 ¿Ha tenido alguna experiencia de
“ambigüedad” en la especificación
de sus requisitos? Comente
203

Introducción
 Si un desarrollador software tiene que
implementar un requisito ambiguo o
incompleto tendrá que hacer sus
propias interpretaciones, las cuales no
siempre son correctas.
 Se requiere un esfuerzo substancial
para arreglar errores de requisitos
después de que se ha completado el trabajo
basado en estos requisitos.
204

Introducción
 Estudios han demostrado que puede costar
aproximadamente 100 veces más
corregir un defecto en un requisito que
corregir un error encontrado durante el
desarrollo de requisitos.
 Cualquier medida que se pueda tomar para
detectar errores en las
especificaciones de requisitos ahorrará
tiempo y dinero substancial.
205

Las Pruebas y el Desarrollo de
Requisitos
 Si se inicia la planeación de las
pruebas y el desarrollo de Casos
de Prueba pronto, detectarás
muchos errores antes de que se
introduzcan.
 Esto previene daños futuros y
reduce los tiempos de
mantenimiento y costos.
206

Modelo V de Desarrollo de Software
con diseño/planeación de Pruebas
207

Modelo V de Desarrollo de Software
con diseño/planeación de Pruebas
 Planea las actividades de pruebas e
inicia el desarrollo de Casos de Prueba
preliminar durante la fase
correspondiente de desarrollo.
 Aunque aún no se ejecuten las pruebas (no
hay código todavía) los Casos de Prueba
conceptuales revelarán errores,
ambigüedades y omisiones en la ERS y
en los modelos de análisis antes de que el
equipo escriba el software.
208

Validación de Requisitos
 La VR es el cuarto componente
(junto con elicitación, análisis y
especificación del desarrollo de
requisitos).
209

 La VR intenta asegurar que:
 La ERS describe correctamente las
capacidades y características del
sistema que satisfacerán las
necesidades de los stakeholders.
 Los requisitos software se derivaron
correctamente de los requisitos del
sistema, reglas del negocio u otras
fuentes.
 Los requisitos son completos y de
alta calidad.
210

 La VR intenta asegurar que:
 Todas las representaciones de requisitos son
consistentes unas con otras.
 Los requisitos proveen una base adecuada para
proceder con el diseño y construcción.
 Sólo se pueden validar requisitos que
han sido documentados no los que están
en la mente de alguien.
 La VR debe ser un proceso iterativo, no
un paso final antes de fijar los requisitos en
la línea base.
211

Validación & Verificación
 Algunos llaman a esta etapa
Verificación. La Verificación
determina si un producto satisface
los requisitos establecidos por el (do
the thing right).
 Validación evalúa si el producto
satisface las necesidades del cliente
(do the right thing).
212

Revisión Formal de Requisitos
 Una Revisión por Parejas es aquella en la
que alguien externo al autor del producto
examina problemas en el mismo.
 Ésta es una técnica importante para
identificar requisitos ambiguos o no
verificables, que no fueron definidos
claramente para diseño y otros problemas.
 La RxP es un proceso formal, bien
definido (en contraste con “Revisiones
Informales”).
213

Revisión Formal de Requisitos
 El mejor tipo de Revisión Formal es llamada
Inspección.
 La Inspección de documentos de
Requisitos es la técnica de mayor calidad
software.
 Si se desea maximizar la calidad del
software, el equipo inspeccionará cada
documento de requisitos que crea.
 Inicia la inspección cuando tengas un 10% de la
ERS: es la mejor técnica para prevenir –no
sólo encontrar- defectos.
214

El proceso de Inspección
 Michael Fagan desarrolló el
proceso de inspección en IBM a la
mitad de los 70s y otros lo han
extendido o modificado con sus
métodos.
 Cualquier artefacto puede ser
inspeccionado (requisitos, diseño,
código fuente, pruebas, planes de
proyectos, etc.)
215

El proceso de Inspección
 La Inspección es un proceso
multietapas bien definido.
 Involucra un pequeño equipo de
participantes entrenados que
cuidadosamente inspeccionan un
producto de trabajo buscando
defectos y oportunidades de
mejora.
216

Participantes en un proceso de
Inspección
 Deben representar 4 perspectivas:
1. El autor del producto de trabajo y
quizá compañeros del autor. El
analista provee esta perspectiva.
2. El autor de cualquier producto de
trabajo o especificación
predecesora para el producto
inspeccionado. Un arquitecto de
sistemas (o cliente) que asegure que
la ERS detalla apropiadamente la
especificación del sistema.
217

Inspección
 Deben representar 4 perspectivas:
3. Gente que hará el trabajo basado
en el producto siendo
inspeccionado. Desarrollador, tester,
líder de proyecto y escritor de la
documentación del usuario.
4. Gente responsable del trabajo del
producto que interactuará con el
producto inspeccionado. Buscarán
problemas con los requisitos de
interfases externas.
218

Inspección
 Limita el equipo a 6 o menos
inspectores.
 Esto significa que algunas
perspectivas no serán
representadas en cada inspección.
219

Roles de la inspección-Autor
 Autor: es el analista que obtuvo los
requisitos de usuario y escribió la
especificación. Toma un papel pasivo en
la inspección. No puede asumir ningún otro
papel. Escucha los comentarios de otros
inspectores, responde (no debate) a sus
preguntas y piensa. Puede detectar errores
que los otros inspectores no ven.
220

Roles de la inspección-Moderador
 Moderador: o líder de inspección; planea
la inspección con el autor, coordina
actividades y facilita las reuniones de
inspección. Distribuye los materiales a ser
inspeccionados por los participantes, varios
días antes de la reunión de inspección.
Inicia la reunión a tiempo, motiva la
participación y mantiene enfocada la
reunión a encontrar defectos más que
resolver problemas. Da seguimiento, junto
con el autor, a la correcta corrección de
defectos.
221

Roles de la inspección-Lector
 Lector: parafrasea la ERS un requisito
a la vez. Los otros participantes señalan
defectos potenciales. Estableciendo los
requisitos en sus propias palabras, el lector
provee una interpretación que puede diferir
de la de otros inspectores. Esto es una
buena forma de revelar una ambigüedad,
un posible defecto o un supuesto.
222

Roles de la inspección-Escritor
 Escritor: usa formatos estándar para
documentar lo que surja y los defectos
encontrados durante la reunión de
inspección. Debe enunciar en voz alta lo
que escribió para confirmar exactitud. Los
otros inspectores deben ayudar al escritor a
capturar la esencia de lo que surge en una
forma que claramente comunica al autor la
localización y naturaleza de lo surgido.
223

Criterios de Inicio de la Inspección
 Los prerrequisitos que se deben satisfacer antes
de inspeccionar el documento de requisitos son:
 El documento está conforme la plantilla estándar.
 Se ha revisado la ortografía del documento.
 El autor ha revisado visualmente el documento por
errores de diseño.
 Están disponibles los documentos de referencia que
los inspectores requerirán para examinar el
documento.
 Los temas abiertos están señalados como TBD.
 El moderador no encontró más de 3 defectos en una
examen de 10 minutos de una muestra
representativa del documento.
224

Etapas de la Inspección-
Planeación (Planning)
 El Autor y el Moderador planean
juntos la inspección.
 Determinan:
 Quien participará
 Que materiales recibirán los
inspectores antes de iniciar.
 Cuantas reuniones de inspección se
necesitarán para cubrir el material.
 La Tasa de Inspección (número de
páginas por hora).
226

Etapas de la Inspección-Planeación
(Planning)-La Tasa de Inspección y el No. de
Defectos encontrados
227

Introducción (Overview meeting)
 Durante la Introducción, el Autor
describe los antecedentes del
material que el equipo está
inspeccionando, sus supuestos y los
objetivos específicos de la
inspección.
 Si todos son familiares con el
documento, se puede omitir esta
etapa.
228

Preparación (Preparation)
 Cada inspector examina el producto
para identificar posibles defectos,
usando checklist de típicos defectos.
Hasta 75% de los defectos encontrados se
descubren en esta etapa. No omitas este
paso.
 Considera pedir a cada desarrollador que
revisará la ERS calificar cada requisito
en términos de que tan bien lo entienden
(1=no se entiende; 5=claro, completo y no
ambiguo)
229

Etapas de la Inspección-Reunión
de Inspección (Inspection Meeting)
 El Lector lee a los otros inspectores a
través del DERS, describiendo 1 requisito
a la vez en sus propias palabras.
 Conforme los inspectores encuentran
posibles defectos (u otros aspectos), el
Escritor los captura en una forma que viene
a ser la lista de acciones para el autor de
los requisitos.
 Las reuniones de inspección no
deberían tomar más de 2 hrs. Si se
necesita más tiempo, reprograma otra
reunión.
230

Etapas de la Inspección-Reunión
de Inspección (Inspection Meeting)
 Al final de la reunión el equipo decide
aceptar el DERS tal como está, aceptar
con revisiones menores o indicar si se
requiere mayor revisión (esto indica
problemas con el proceso de desarrollo de
requisitos).
 Considera una retrospectiva para explorar
como se pueden mejorar los procesos antes
de la siguiente actividad de especificación.
231

Etapas de la Inspección- Retrabajo
(Rework)
 El Autor debe planear invertir algo de
tiempo re-trabajando los requisitos que
siguen a la reunión de inspección.
 Es el momento de resolver
ambigüedades, eliminar puntos no
claros y establecer la base para el
desarrollo exitoso del proyecto.
232

Seguimiento (Follow-up)
 Paso final de la inspección. El
Moderador o un individuo designado
trabaja con el Autor para asegurarse
que todos los aspectos abiertos
fueron resueltos y que los errores
fueron corregidos apropiadamente.
 Esta etapa brinda el cierre de la
inspección y habilita al moderador
para determinar si el criterio de
terminación se ha satisfecho.
233

Criterios de Cierre de la
Inspección
 Las Postcondiciones que se deben satisfacer antes
de que el moderador declare la inspección completa
son:
 Todos los aspectos encontrados han sido
atendidos.
 Cualquier cambio hecho al documento y
productos de trabajo relacionados fueron hechos
correctamente.
 Se ha revisado la ortografía del documento.
 Todos los TBD se han resuelto.
 El documento se ha incluido en el Sistema de
Configuración del Sistema.
234

Checklists de defectos
 Para ayudar a los inspectores a
localizar típicos errores en los
productos que inspeccionan es
bueno desarrollar un checklist
para cada tipo de documento de
requisitos crea la organización.
235

Ejemplo Checklist de defectos-CU
 ¿El CU es un Proceso elemental de negocio?
 ¿Es claro el objetivo del CU?
 ¿Está escrito el CU a nivel esencial, libre de
detalles de diseño e implementación?
 ¿Están documentados todos los cursos
alternativos?
 ¿Hay secuencias de acción comunes que se
pueden factorizar en CU separados?
 ¿Las precondiciones y postcondiciones
enmarcan apropiadamente el CU?
236

Checklist para DERS
 También se puede hacer un
checklist para inspeccionar el DERS.
237

Probando los Requisitos-Casos de
Prueba conceptuales
 Se puede iniciar derivando los Casos de
Prueba conceptuales muy temprano en el
proceso de desarrollo.
 Se pueden utilizar los Casos de Prueba para
evaluar requisitos textuales, modelos
de análisis y prototipos.
 Los Casos de Prueba son independientes
de implementación.
238

Probando los Requisitos-Casos de
Prueba conceptuales
239

Definiendo el Criterio de
Aceptación
 No es suficiente la correcta
implementación de los requisitos, se
requiere también que la acepte el
usuario final.
 Los cliente deben definir el Criterio
de Aceptación que determina si el
sistema realmente satisface sus
necesidades.
240

Aceptación
 La pregunta clave a responder por
el usuario es: ¿Cómo juzgaría si
el sistema satisface sus
necesidades?
 Si el cliente no puede expresar
como evaluaría la satisfacción del
sistema de un requisito particular,
tal requisito no se ha establecido
de forma suficientemente clara.
241

Aceptación
 No es suficiente escribir los
requisitos. Se necesita asegurar
que son los correctos y que son
suficientemente buenos para
servir de base al diseño,
construcción, pruebas y gestión del
proyecto.
242

02 desarrollo de requisitos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (15)

Similar a 02 desarrollo de requisitos

Similar a 02 desarrollo de requisitos (20)

Más de Ricardo Quintero

Más de Ricardo Quintero (20)

02 desarrollo de requisitos