Ingeniera de requerimientos

Ingeniera de Sistemas e Informtica

Propsito y contenido de la sesin

Propsito de la sesin
Describe como se realiza el
proceso de refinamiento
del sistema.

Contenido de la sesin
Refinamiento del sistema.

Recapitulando

Requerimientos de software

REFINANDO LA DEFINICIN DEL SISTEMA

Puntos claves
Un sistema completo de requisitos puede ser determinado
definiendo las entradas, las salidas, las funciones, los atributos
y los atributos del entorno del sistema
Los requisitos deben excluir la informacin relacionada con el
proyecto, tal como horario, planes del proyecto, presupuestos
y test de pruebas, as como la informacin del diseo
Los requisitos y el proceso del diseo son iterativos; los
requisitos conducen a la seleccin de ciertas opciones del
diseo, que alternadamente pueden iniciar nuevos requisitos.
Las restricciones del diseo son restricciones en el diseo del
sistema o del proceso

Definicin de requerimientos de software

Una Capacidad del software necesaria para el usuario para
resolver el problema y alcanzar un objetivo
Una capacidad del software que se debe satisfacer o poseer un
sistema o un componente del sistema para satisfacer el
contrato, el estndar, la especificacin, o la otra
documentacin formalmente impuesta.

Elementos del sistema

Entradas al Sistema
Salidas del Sistema
Funciones del Sistema
Caractersticas del Sistema
Atributos del entorno del Sistema

Relacin entre las caractersticas y los

requerimientos del software
Las caractersticas son simples descripciones de un deseo y
comportamiento beneficioso
El documento de visin cita las caractersticas en el lenguaje del usuario
Los requerimientos de software expresan las caractersticas con ms
detalles, usando uno o mas especificaciones de requerimientos de
software que deben ser cumplidos por los desarrolladores para
suministrar las caractersticas al usuario
Las caractersticas ayudan a comprender y comunicar a un alto nivel de
abstraccin, pero no podemos describir el sistema y escribir cdigo de esas
descripciones
Los requisitos de software son especficos.
Podemos codificar de ellos y deben ser lo suficientemente especfico para ser
"Sometidos a pruebas"; es decir, podemos validar el sistema (se implementa un
requisito real)

Relacin entre las caractersticas y los

requerimientos del software
Documento Visin

Requerimientos del sw

Caracterstica 63: El sistema de

seguimientos
de
defectos
proporcionar la informacin
para ayudar al usuario a
determinar estado del proyecto.

SR63.1 La informacin ser proporcionada

en un histograma que demuestra tiempo
en el eje x y el nmero de los defectos
encontrados en el eje y.
SR63.2 El usuario puede ingresar el
perodo en das, semanas, o meses.
SR63.3 Un informe ejemplo se demuestra
en la ilustracin 1.

El dilema de los requerimientos: que versus

como

Excluir la Informacin del proyecto

Calendarios, plan de la administracin de la
configuracin, planes de verificacin y
validacin, presupuestos,

Excluir la Informacin del diseo

Diseo del sistema, arquitectura

Ms sobre requisitos versus diseo

Iteracin de requerimientos y de diseo.

Otras caractersticas de los requisitos

Requerimientos de Software (1)

Requerimientos Funcionales
Requerimientos no Funcionales
Usabilidad
Confiabilidad
Disponibilidad
Promedio entre fallas
Promedio de reparacin
Exactitud
Mximo nmero de defectos o ratio de defectos
Defectos por tipo
Funcionamiento
Tiempo de respuesta
Rendimiento, transacciones por segundo
Capacidad, nmero de clientes o transacciones
Modos de degradacin
Adaptabilidad

Requerimientos de Software (2)

Restricciones del diseo
Son limitaciones en el diseo del sistema o proceso

Use Oracle BDMS

Programar en Visual Basic
Use la librera de clases XYZ
Compatibilidad con los sistemas existentes
Estndares

Las Restricciones de Diseo son requisitos verdaderos?

No, porque no representan a ninguno de los 5 elementos
del sistema
Si, cuando es elevada a nivel de negocio, poltica o asunto
tcnico.

Requerimientos de Software (3)

Restricciones del diseo
Son limitaciones en el diseo del sistema o proceso

Use Oracle BDMS

Programar en Visual Basic
Use la librera de clases XYZ
Compatibilidad con los sistemas existentes
Estndares

Las Restricciones de Diseo son requisitos verdaderos?

No, porque no representan a ninguno de los 5 elementos
del sistema
Si, cuando es elevada a nivel de negocio, poltica o asunto
tcnico.

Usando requisitos padre-hijo para incrementar

la especificidad (1)

Usando requisitos padre-hijo para incrementar

la especificidad (2)

Refinando la definicin del sistema

REFINANDO LOS CASOS DE USO

Puntos claves
Para soportar las actividades del diseo y la codificacin,
los casos de uso desarrollados en las actividades de
recopilacin de requerimientos deben estar completos
Los casos de uso son apropiados cuando el sistema es rico
en funcionalidad y debe soportar diferentes tipos de
usuarios
Los casos de uso no son tan efectivos cuando aplicamos a
sistemas sin usuarios o con pocos usuarios y pocas
interfaces, aquellos con principalmente requisitos no
funcionales y restricciones de diseo

Redundancia del problema

Los casos de uso esta dirigido a la redundancia significativa,
aumentando el tamao de la documentacin de los requisitos
Muchos casos de uso son muy similares, sin embargo no son
lo suficientemente distintos para descomponerlo
El mantenimiento puede ser un desafo cuando el
comportamiento comn es expresado en muchos casos de
uso
Requiere el uso adicional relaciones de caso, como la
generalizacin, include, extend; que aaden complejidad.

Refinando las especificaciones de caso de uso

tem

Nombre caso de uso

Breve descripcin

Flujo de eventos

Valor

Control de luz
Este caso de uso describe la forma como las luces son
encendidas o apagadas o su intensidad es disminuida cuando
los usuarios presionan los interruptores de luz de varias
maneras.
El flujo bsico del caso de uso comienza cuando el Residente
presiona el botn del Control de Interruptores(CI). Si el
Residente deja de presionar el CI dentro del periodo de
tiempo, el sistema conmuta el estado de la luz. Esto significa:
Si la luz estaba encendida, la luz se apaga, no hay
iluminacin.
Si la luz estaba apagada, la luz se enciende con el ultimo
nivel de iluminacin conocido.

Refinando las especificaciones de caso de uso

tem

Valor

Flujo
Si el Residente mantiene pulsado el CI por mas de un segundo, el
alternativo de sistema inicia la disminucin de la iluminacin para el nivel indicado de
eventos
luz. La siguiente accin ocurre mientras el residente continua
presionando el botn CI:
1. La iluminacin se incrementa lentamente hasta el valor mximo a un
ratio de 10% en un segundo.
2. Cuando el nivel mximo de iluminacin es alcanzado, la iluminacin
disminuye lentamente hasta el valor mnimo a un ratio de 10% en un
segundo
3. Cuando el valor mnimo es alcanzado, la secuencia del caso de uso
regresa al paso 1.
Cuando el residente libera la presin del botn CI.
4. El sistema cesa el cambio de iluminacin.

Refinando las especificaciones de caso de uso

tem
Pre condiciones

Valor
El botn seleccionado CI debe estar Graduacin
de iluminacin activada
El botn seleccionado CI debera estar pre
programado para el control de banco de luces.
Post condiciones Al salir de este caso de uso, la intensidad de la luz
es recordado por el sistema.
Requerimientos El nivel mnimo de luz no puede ser 0. Debe ser un
especiales
valor mnimo aceptable tal que las luces sean
adecuadas para la noche.

Refinando la definicin del sistema

UNA MODERNA ESPECIFICACIN DE SOFTWARE

Puntos Claves
Un paquete moderno de ERS (ERS, Software
Requirements Specification) es una coleccin de
artefactos que describen el comportamiento externo del
sistema (modelo conceptual).
El documento de Visin es la entrada del moderno ERS. Es
una declaracin ampliada de las necesidades del usuario,
metas y objetivos, mercados objetivos y caractersticas
del sistema; lo ltimo se enfoca en los detalles a
implementar.
El correcto balance de la tcnica esta en el mix del
modelo de casos de uso y la especificacin tradicional de
requerimientos.

El moderno paquete ERS

Histricamente, la tcnica de documentacin de
requerimientos fue usar el lenguaje natural
El mejoramiento de la tcnica derivo en el varios
estndares, tal como IEEE (Institute of Electrical and
Electronics Engineers) 830: Standard for Software
Requirements Specification (1994).
Con las herramientas y tcnicas hoy, el ERS es una
estructura lgica en vez de un documento fsico.

Elementos de un paquete moderno ERS

El moderno paquete ERS

Es un paquete activo y viviente.
Tiene varios papeles cuando se comienza con el desarrollo.
Es la base para la comunicacin entre desarrolladores y los grupos
externos, usuarios y stakeholders.
Formalmente e informalmente representa una acuerdo entre las
partes. Se desarrolla lo que esta en ello.
El administrador del proyecto lo usa como estndar en las
discusiones con el equipo de proyecto
Sirve de entrada al diseo e implementacin
Sirve de entrada al testeo y aseguramiento de la calidad
Controla la evolucin del sistema durante toda la fase de
desarrollo

Quin es el propietario del paquete ERS?

Quin es responsable de crear y mantener los componentes
del ERS?
Usualmente, los miembros del equipo
El anlisis del sistema refinara el documento de visin
Recuerde, es un artefacto vivo y necesita ser actualizado

Organizando un paquete moderno ERS (1)

Organizando un paquete moderno ERS (2)

Organizando un paquete moderno ERS

Organizando un paquete moderno ERS

Balanceando los requerimientos

Sobre la ambigedad y especificidad

El requerimiento sweet spot es punto de balance
de la gran cantidad de comprensibilidad y la mnima
cantidad de ambigedad
Encontrar el sweet spot depender de las
habilidades de los miembros del equipo, el contexto
de la aplicacin y el nivel de seguridad
Si el riesgo de malinterpretar es inaceptable, ms
tcnicas de requerimientos formales es necesario ser
aplicado.

Encontrando el sweet spot

El principal reto
es detallar
suficientemente
los
requerimientos

Realmente, tenemos que especificar

Pantone 287 como el fondo de
nuestras GUI? No? Le gusto el color
la ultima vez?
A que nivel de detalle de especificar
los requisitos para evitar cualquier
cambio?
Eso depende.

Caja de luz
Caractersticas
Controlado por un
microprocesador
Almacena el estado del botn
Count si ha sido pulsado un
numero par o impar de veces
El detector de bombilla quemada
destella la bombilla restante

Objetivo del ejercicio

Escribir de manera clara y simple los requerimientos
Usando el lenguaje natural o los casos de uso
Para el ejercicio, el usuario esta disponible para entrevistarlo, as se
puede refinar los requerimientos

Especificacin de requerimientos (Davis,1993)

Despus de pulsar on (antes pulso off) el sistema esta
encendido.
Despus de pulsar off (antes pulso on) el sistema esta
apagado.
Si esta en ON, si Count ha sido presionado un numero
impar de veces, brilla Odd.
Si esta en ON, si Count ha sido presionado un numero
par de veces, brilla Even.
Si uno de las luces esta quemada el otro debe parpadear
a intervalos de 1 segundo

Es suficiente?
La especificacin es suficiente para la mayora de casos.
Refleja la forma como el dispositivo debe trabajar
Para el programador, quien debe escribir el cdigo, descubre
por lo menos la siguiente ambigedad:
Qu significa parpadear a intervalos de 1 segundo?
Todava parece obvio?

Posible ciclo de servicio de la lmpara

Ciclo A o B?
Cul escoge? Ciclo de servicio A o B?
Aunque la mayora escoge B, esta claro que el requerimiento es
ambiguo.
El programador preguntara al cliente Qu ciclo debe ser usado?
Si el programador no es perspicaz o no reconoce la ambigedad o
piensa S que significa porque se como debe trabajar
El proyecto podra estar en riesgo
Para la mayora de aplicaciones, no es importante si se enciende
durante un segundo o 0.25 segundos.
Si el equipo es electro quirrgico si importa .

Cul es nivel de especificidad?

Depende del contexto de la aplicacin
Cun capaces para tomar las decisiones correctas son los
desarrolladores?
Mnimo nivel de seguridad para hacer preguntas donde hay
ambigedad
Para el equipo electro quirrgico se debera ahondar en la
especificacin
Tiempo de elevacin
Precisin del tiempo
Voltaje, etc.

Ambigedad VS especificidad

Mary tiene un pequeo cordero

Tiene 1: mantiene en posicin como propiedad .. 4: Adquiere o
toma posesin de: obtiene (como en lo mejor) 4c: ACEPTA; Tiene
matrimonio 5: Marcado o caracterizado por (tiene el cabello
rojo) 10: Mantener una posicin de ventaja 10b: TRAMPA,
ENGAO 12b: DAR A LUZ (tener un bebe) 13: Compartir (tener
una cena) 14: SOBORNO, (se puede tener a un precio)
Cordero 1: Una joven oveja de menos de un ao de edad o sin
dientes permanentes 1b: El joven de los animales (ej. Pequeos
antlopes) 2: Una persona caballerosa o dbil como un cordero
2b: MASCOTA 2c: Una persona fcil de engaar o engaada,
especialmente en falsificacin de pagares 3: Carne de cordero
usado como comida.

Mary tiene un cordero

Tcnicas de desambiguacin
Memorizacin heurstica
Preguntar al grupo de desarrollo, usuarios o stakeholder
Tcnica de la palabra clave
El codero de Mary
Tcnica nfasis
Lea el requisito en voz alta y enfatice las palabras individuales hasta tener
muchas interpretaciones como sea posible
Si slo una interpretacin es correcta, declare de nuevo el requerimiento
Si mltiples interpretaciones son correctas, generar requerimientos
adicionales
Otras tcnicas
Use figuras, grficos u otros mtodos formales

Qu hacer?
Para encontrar sweet spot
Use el lenguaje natural si fuera posible
Use figuras y diagramas
Cuando este en duda, pregunte
Argumente sus especificaciones con mas mtodos formales

Entrene a su equipo a reconocer problemas de ambigedad y

como solucionarlos

Refinando la definicin del sistema

MTODOS TCNICOS PARA ESPECIFICAR

REQUERIMIENTOS

Puntos claves
Los mtodos tcnicos son apropiados cuando la descripcin de
los requerimientos son demasiados complejos para decirlo en
lenguaje natural o si no puede permitirse malas
interpretaciones
Los mtodos tcnicos son seudocdigo, diagrama de estados
finitos, arboles de decisin, diagrama de actividades, modelo
entidad relacin, anlisis orientado a objetos y anlisis
estructurado

Seudocdigo

Diagrama de estado finitos

rbol de decisin

Diagrama de actividad

Diagrama entidad relacin

Modelo orientado a objetos

Diagrama de flujo de datos

Refinando la definicin del sistema

MEDIDA DE LA CALIDAD DE LOS

REQUERIMIENTOS DE SOFTWARE

Puntos clave
Tener un conjunto de requerimientos de calidad es objetivo
principal, estos requisitos deben cubrir nueve medidas de
calidad
Las lista de chequeo pueden ser usadas para asegurar la
calidad de los requerimientos, modelo de casos de uso,
especificacin de casos de uso y actores
Una alta calidad en ERS tiene un buen TOC, a buen ndice,
historial de revisiones y glosario

Nueve medidas de la calidad

Correcto
Inequvoco (no ambiguo)
Completo
Consistente
Clasificado por importancia y estabilidad
Verificable
Modificable
Trazable
Entendible

Universo necesidades y requerimientos

Requerimientos no ambiguos

Si y solo si tiene una

sola interpretacin
IEEE 830-1993, 4.3.2, 1994

Completitud del conjunto de requerimientos

Si y solo si describen todo los requisitos

significativos concernientes al usuario,
relacionados con al funcionalidad, el
rendimiento, las restricciones de diseo,
atributos o las interfaces externas
IEEE 830-1993, 4.3.3, 1994

Asegurando la completitud
Asegurarse que las figuras, etiquetas y diagramas
tienen las etiquetas y referencias apropiadas
Algunos aspectos pueden ser evaluados por un
desarrollador sin conocimiento especial de la
aplicacin
La raz cuadrada de un numero
Si es negativo?

Revisar las entradas de las clases realizables para

asegurarnos que el comportamiento de sistema este
descrito para entradas vlidas e invalidas

Completitud en los requerimientos no

funcionales
A menudo se descuida aspectos de rendimiento y restricciones
de diseo o suposiciones sobre las interfaces externas con
otros sistemas
Se debera crear una lista de chequeo siguiendo las guas en el
rea de usabilidad, confiabilidad, rendimiento y
suportabilidad. Asimismo, para la restricciones de diseo.

Completitud de los requerimientos funcionales

Omitir la funcionalidad es difcil
Los desarrolladores tcnicos no saben si se ha omitido alguna
funcionalidad
La funcionalidad es nueva

A veces, la funcionalidad es profundamente arraigada y obvia

para el usuario
En un sistema de nmina, el pago del da feriado

El uso de tcnicas de caso de uso ayudan

Completitud a travs del prototipo

Los storyborads, la revisin de requerimientos y los prototipos
nos acercaran mejor a los verdaderos requerimientos.
El equipo de desarrollo debe dar un paso adicional con
preguntas que pasa-si (what-if) para las condiciones limites
del sistemas, excepciones y eventos inusuales.

Consistencia en el conjunto de requerimientos

Si solo si ningn conjunto individual de requerimientos esta en conflicto con
otro
IEEE 830-1993, 4.3.4.1, 1994
Los conflictos toman varias formas y son visibles en varios niveles de detalle
Si esta formalizada y automatizada, se identifican mecnicamente
Sino es necesaria una evaluacin manual
Algunas veces, son obvios
Cuando ocurre X se da la accin P
Cuando ocurre X se da la accin Q
Los prototipos ayudan en la consistencia de los requerimientos
Los profesionales de testeo y aseguramiento de calidad lo hacen a travs de
una evaluacin manual

Ranqueo de requirimientos por importancia y

estabilidad
En un conjunto de alta calidad, los desarrolladores, clientes y otros
stakeholders tienen ranqueado los requerimientos por importancia para el
cliente y en trminos de estabilidad
IEEE 830-1993, 4.3.5, 1994
Importante en el alcance del proyecto
Los recursos son insuficientes para implementar todos los
requerimientos
Por eso, se planifica y presupuesta
Es til saber que requerimientos son voltiles y que requerimientos el
usuario considera crticos
Los requerimientos tienen atributos como: costo, riesgo, dificultad y otros.
(Documento visin)
Basados principalmente en la estrategia de implementacin
Los atributos importancia y estabilidad son asociados con la percepcin del
usuario del mundo

Ranqueo de requerimientos

Ranqueo de requerimientos
Dada esta informacin y otros factores, se debe determinar el
porcentaje para determinar la importancia y relativa
volatilidad.
El administrador del proyecto debera estar preparado para dedicar
una proporcionalidad alta de recursos en SR103 y SR172
Igualmente en SR071

Requerimientos verificables
Es verificable en conjunto si y solo si cada uno de los
componentes contenidos en los requerimientos es verificable
Los requerimientos pueden ser considerados verificables si y
solo si all existe un finito, costo efectivo del proceso con el
cual una persona o mquina puede determinar que el
desarrollo del sistema de software satisface verdaderamente
los requerimientos
IEEE 830-1993, 4.3.6, 1994

Pruebas para verificar los requerimientos

No es posible proveer una prueba cientfica rigurosa de verificacin
para cada requisito, pero eso no es generalmente necesario.
La responsabilidad del personal de pruebas (testing) y de
aseguramiento de la calidad (quality assurance) es crear los
apropiados casos de prueba y los procedimientos de prueba para
llevar la comprobacin en cuanto el software ha sido desarrollado.
Ellos necesitan requerimiento bien definidos y sin ambigedad
Es comn tener una reunin con los especialistas de las pruebas y
preguntarles
Esta Ud. Seguro que puede crear un test script para verificar que el
requerimiento ha sido satisfecho?

Tpicas reacciones de los desarrolladores y/o profesionales de las

pruebas en relacin a la verificacin
El sistema debe soportar 1000 usuarios simultneamente
Eso depende de que son capaces de a hacer cuando ellos estn conectados
(logged in).
Si el usuario tiene abierta las posibilidades podran entrar a una transaccin
que la aplicacin explore secuencialmente a travs de cada registro de la
base de datos
Podra ser difcil de verificar que el sistema tiene mil usuarios cargados
Hay una probabilidad mnima pero diferente de cero que los 1000
usuarios decidan realizar tal transaccin al mismo tiempo
Si los usuarios estn limitados a cierta clase de transacciones y si
podemos determinar una tpica, la transaccin costosa, podemos
verificar que el requerimiento ha sido satisfecho con un razonable grado
de certeza, aunque tendremos que usar una herramienta de carga para
simular 1000 terminales activos

Tpicas reacciones de los desarrolladores y/o profesionales de las

pruebas en relacin a la verificacin

El sistema responder a una consulta arbitraria en 500 milsimas de segundo

Eso depende de lo que signifique arbitrario. Si el rango de las posibles consultas es finita y si
podemos identificar la consulta ms compleja, nosotros podemos verificar el comportamiento
del sistema.
El tiempo de visualizacin ser de forma placentera
No se preocupe por eso. La belleza esta en el ojo del espectador
El sistema ser amigable con el usuario
Esto es igual de incorrecto que forma placentera
Pero sin definir cuidadosamente los trminos y detalles, amigable al usuario es una invitacin a
la discusin
El sistema exporta vista de datos en el formato separado por comas
Me gustara aclarar los detalles; por ejemplo, Qu sucede si la vista de datos es nula?
Pero en principio, si, podemos verificar que el sistema produce el comportamiento deseado en
esta rea.
La verificacin y validacin son aspectos importantes para desarrollar software de alta calidad.

Conjunto de requerimientos modificables

Si slo si su estructura y estilo son tal que cualquier cambio de
los requerimientos pueden ser hechos fcilmente,
completamente y consistentemente, mientras se conserva la
estructura y estilo existente.
IEEE 830-1993, 4.3.7, 1994
Estos requerimientos tienen mnima redundancia y estn
bien organizados, con una tabla de contenido, ndice y
referencia cruzada.
Podra o no mantenerse el paquete de requerimientos con
una herramienta automatizada. Aunque es una necesidad
en sistemas grandes, que pueden tener miles de requisitos.

Trazabilidad de requerimientos
Si slo si cada uno de los requerimientos esta claro y existe un mecanismo que hace
factible referirlo en el futuro desarrollo
IEEE 830-1993, 4.3.8, 1994
Los requerimientos tienen identificadores como etiquetas o nmeros
Algunos componentes necesitaran trazar a otros componentes del mismo proyecto
y posiblemente del mismo paquete.
El cambio de un requerimiento podra afectar a otro requerimiento
Algunos requerimientos pueden ser descritos como sub o hijo, por lo que la
trazabilidad es obvia.
La trazabilidad permite contestar Que pasa-si
Qu pasa si cambiamos este requisito?
Interacta con el desarrollo de software y, si es as, con qu elementos?
Fuerza a revisar el plan de pruebas, si es as, cuales?
Para el mismo proyecto se puede usar la matriz de trazabilidad

Matriz de trazabilidad

Requerimientos entendidos
Un conjunto de requerimientos es entendible si el usuario y el
desarrollador comprenden los requerimientos individuales y la
funcionalidad completa.

Preguntas

Qu hemos aprendido?

Reflexionemos