Ingeniera de Requisitos:

Desarrollo de Requisitos

wFactura

Febrero 2010

Objetivos
Conocer las distintas fuentes de requisitos.
Explicar algunas tcnicas de recoleccin de requisitos.
Entender como se pueden aplicar estas tcnicas para la obtencin
de requisitos tanto de alto nivel (requisitos de negocio, features)
como de bajo nivel (requisitos de usuario, requisitos funcionales,
etc).
Entender los casos de uso como tcnica para recolectar requisitos
de usuario.
Conocer la importancia de priorizar los requisitos antes de
desarrollarlos.
Aplicar tcnicas de Aseguramiento de la Calidad en los requisitos de
software.

Contenido

Introduccin
Fuentes de requisitos de software.
Planeacin y recomendaciones para la recoleccin de requisitos.
Tcnicas de recoleccin de requisitos.
Anlisis de Requisitos
Especificacin de Requisitos
Validacin y/o Verificacin de Requisitos

Fase de Requisitos
en Moprosoft

Ingeniera de Requisitos:
Fundamentos
Introduccin a la Ingeniera de
Requisitos

Definicin de Requisito de SW (1)

Una condicin que debe ser cumplida para que el cliente
encuentre ACEPTABLE el producto o servicio proporcionado.
Una condicin o capacidad necesitada por un usuario para
solucionar un problema o lograr un objetivo.
IEEE Standard Glossary of Software Engineering Terminology (1990)

Constituyen la definicin del sistema que se va a construir o

mejorar

Definicin de Requisito de SW (2)

La siguiente definicin reconoce la diversidad de tipos de
requisitos.
Los requisitos son una especificacin de lo que debe estar
implementado. Son descripciones de cmo el sistema debe
comportarse, o una propiedad o atributo del sistema. Puede ser una
restriccin en el proceso de desarrollo del sistema.

Karl Wiegers piensa que:

Un requisito es una propiedad que un producto debe tener para
proveer valor a un stakeholder.

Lo que los Requisitos NO SON! (1)

Las especificaciones de Requisitos no incluyen:
Detalles de diseo o implementacin
Informacin de planeacin de proyecto, o informacin de pruebas.
Una solicitud informal de alguien en una reunin, un pasillo o un
elevador o una llamada telefnica
Solicitudes de clientes por medio de encuestas, correos electrnicos o
buzones de sugerencias
Observaciones o comentarios durante reuniones de ventas o de
publicidad

Lo que los Requisitos NO SON! (2)

Para que sea un requisito:
Debe ser solicitado formalmente
Debe ser documentado
Debe ser analizado formalmente para verificar el impacto
en el proyecto
Debe ser aprobado

Problemas de Requisitos(1)
La mayor consecuencia de los problemas de
requisitos es el RETRABAJO rehacer algo que se
pensaba que estaba listo.
El retrabajo puede consumir de 30 a 50% del
costo de desarrollo total.
Boehm, B. and Papaccio, P. Understanding and Controlling
Software Costs, IEEE Transactions on Software
Engineering, 1998, vol. 14 no. 10, pp. 1462-1476.

Todo proyecto tiene requisitos !

Problemas de Requisitos(2)
Algunos de los riesgos de requisitos ms comunes:
Participacin insuficiente del usuario
Requisitos que crecen sutlmente
Requisitos ambiguos
Requisitos Gold plating
Especificacin mnima
Pasar por alto clases de usuarios
Planeacin incorrecta

Beneficios de un proceso
de IR de buena calidad
Las organizaciones que implementan un buen
proceso de IR pueden cosechar mltiples beneficios.
Los posibles beneficios que se podran disfrutar en
cuanto ahorro de tiempo y dinero:

Menos defectos en los requisitos

Reducir el retrabajo
Disminucin de propiedades innecesarias
Rpido desarrollo
Disminucin de la falta de comunicacin
Menos caos
Estimaciones ms aproximadas
Satisfaccin del cliente y del equipo

Caractersticas de
excelentes requisitos
La mejor manera de checar si la sentencia de un
requisito tiene estas caractersticas es poner a varios
stakeholders a revisar cuidadosamente el SRS
(documento de especificacin de requisitos).

Completo
Correcto
Factible
Necesario
Priorizado
No ambiguo
Verificable
Rastreable

Niveles de Requisitos

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.9

Proceso de Desarrollo de
Requerimientos de SW

Ingeniera de Requisitos
Ingeniera de Requisitos
Desarrollo de
Requisitos

Elicitacin

Anlisis

Administracin de
Requisitos

Especificacin

Validacin

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

Proceso de Desarrollo de Requisitos

Elicitacin

Anlisis

Especificacin

Validacin

Deberas utilizar un desarrollo

iterativo para los proyectos que
quieres que salgan bien.

Martin Fowler

Desarrollo de Requisitos
Descubrimiento y Recoleccin

Ingeniera de Requisitos
Ingeniera de Requisitos
Desarrollo de
Requisitos

Recoleccin

Anlisis

Administracin de
Requisitos

Especificacin

Validacin

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

Fuentes de Requisitos
Entrevistas y discusiones con usuarios potenciales
Documentos que describen los productos actuales
SRSs
Reportes de problemas y solicitudes de mejoras para un sistema
actual (mesa de servicio)
Encuestas de mercado y cuestionarios de usuarios
Anlisis de escenarios de tareas de usuarios
Modelo de negocio

10

Stakeholders
Los stakeholders son los individuos, grupos, u
organizaciones
quines
estn
activamente
involucrados en un proyecto, son afectados por su
resultado, o son capaces de influenciar en l.

Por qu son importantes

los requisitos?
Un proceso efectivo de IR se enfoca en la interseccin de
intereses de todos los stakeholders.

Analistas
Testers
Legal Staff

Clientes $$
Usuarios
Desarrolladores
Project Managers

11

Stakeholders (clases de usuarios)

De los stakeholders hay un subconjunto que representa a
los usuarios finales del sistema.
Es importante identificar todas las clases distintas de
usuarios. Pues esta es una fuente vital de requisitos, pues
cada clase tiene necesidades distintas para usarlo. Por
ejemplo:
La frecuencia con la que ellos usan el producto
Su experiencia en el dominio de la aplicacin y su expertise en sistemas
de cmputo
Las caractersticas que utilizan
Las tareas que ejecutan para soportar sus procesos de negocio
Sus privilegios de acceso o niveles de seguridad

Clases de usuarios
Una jerarqua
(stakeholders)

de

clientes

usuarios

Wiegers,, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003
Wiegers

12

Buscando a los usuarios

representativos
Todo tipo de proyecto necesita usuarios representativos apropiados
para proveer la voz del cliente.
Cada clase de usuario necesita ser representado.
Un Product Champion es un miembro clave de la comunidad de
usuarios a la cual sirve como la interfase principal entre miembros de
una clase de usuarios y el analista de requerimientos del proyecto.
El enfoque de Product Champion provee una forma efectiva de
estructurar la relacin cliente-desarrollador.

Ejemplo
Listar al menos cinco clases distintas de stakeholders para el
sistema de ATM.
Nombre

Representa

Rol

Champion

Director General

Ejecutivo de la compaa

Sponsor del proyecto

Juan Prez

Equipo de Desarrollo

Personas del rea de

Sistemas

Sern quienes
desarrollarn el software
de ATM

Luis Garca

Gerente de Sucursal

Persona a cargo de una

sucursal del banco

Facilitador para la
instalacin del ATM en su
sucursal

Pedro Torres

Administrador del ATM

Empleado de sucursal del

rea de soporte tcnico

Dar mantenimiento al
ATM

Hugo Ruiz

Cliente del Banco

Persona que tiene una

cuenta en el banco

Usuario del ATM. Podr

realizar operaciones
bancarias con l.

13

Ejercicio
Listar al menos cinco clases distintas de stakeholders para uno
de los sistemas que estn desarrollando. Al menos uno debe
ser un usuario final (deseable poner dos).
Nombre

Representa

Rol

Champion

Diagrama de Contexto
La descripcin del alcance establece el lmite y conexin entre
el sistema que se est desarrollando y todo lo dems en el
universo.
Identifica los terminadores fuera del sistema que interfacean
con l de alguna manera, tambin como datos, flujos de
control entre los terminadores y el sistema.

14

Ejemplo de Diagrama de Contexto (1)

Otras Aplicaciones

Usuarios
El Nuevo Sistema

Sistemas
Legados

Reportes

Soporte

Comunicaciones

Definicin de Elicitation
(Del Merrian Webster On Line Dictionary)

1 : Sacar a relucir (algo latente o potencial)

<hypnotism elicited his hidden fears>
2 : Provocar o prolongar (como informacin o
una respuesta) <her remarks elicited cheers>

15

Recoleccin
El corazn de la ingeniera de requisitos es la recoleccin,
el proceso de identificar las necesidades y restricciones de
los distintos stakeholders para un sistema de software.

La recoleccin se enfoca en descubrir los requisitos de

usuario.

Recomendaciones en la Recoleccin
Usar el vocabulario del dominio de la aplicacin en vez
de usar la jerga computacional.
Los clientes deberan entender que una discusin acerca
de cierta posible funcionalidad no es un compromiso
para incluirla en el producto.
Plantear y clarificar cualquier suposicin que el cliente
pueda tener.
Registar sabiamente toda la informacin obtenida.

16

Escoger entre muchas

tcnicas de recoleccin
Entrevistas
Cuestionarios
Talleres de Recoleccin de Requisitos
Lluvia de Ideas
Observar como trabajan los usuarios
Prototipos
Casos de uso (Escenarios)

Entrevistas - Preguntas libres

Son preguntas alto nivel, abstractas que pueden preguntarse al inicio
de un proyecto para obtener informacin sobre aspectos globales del
problema del usuario y soluciones potenciales
Preguntas libres:
Son siempre apropiadas
Ayudan a entender la perspectiva de los afectados
No estn influenciadas por el conocimiento de la solucin

17

Tipos de preguntas libres

Usuario
Quin es el cliente?
Quin es el usuario?
Son sus necesidades diferentes?
Cules son sus backgrounds,
capacidades, ambientes?

Cul es su funcin?

Qu necesita para realizar sus
actividades?

Proceso

Cul es la razn por la que se

quiere resolver este problema?
Cul es el valor de una solucin
exitosa?
Cmo usted resuelve el
problema ahora?
Cmo piensa que debera ser?

Producto

Qu problemas del negocio podra

resolver o crear este producto?
En qu ambiente se usar el
producto?
Cules son sus expectativas para el
fcil uso, lo confiable, y el rendimiento
del mismo?

MetaMeta-Preguntas

Estoy preguntando demasiado?

Son mis preguntas relevantes?
Es usted la persona correcta para
resolver estas preguntas?
Son sus respuestas requerimientos
(necesidades)?
Puedo hacerle ms preguntas
despus?
Hay algo ms que yo debera
preguntarle?

Tipos de preguntas comodn

Es importante que el analista ponga atencin a lo que un usuario responde en una

entrevista y para ahondar en las respuestas puede apoyarse de preguntas tales como:
Quin?
Cundo?
Dnde?
Por qu?
Cmo? (sta es vital)
La manera en que lo hace es la mejor manera?
Ejemplo: Si el usuario comenta yo ejecut la nmina, se podra indagar mucho ms
que slo eso con las preguntas:
Quin ms lo hace?
Cundo o con qu frecuencia lo hace?
Dnde lo hace?
Por qu lo hace?
Cmo lo hace?
Se podra mejorar?

18

Lluvia de Ideas
Reglas para la Lluvia de Ideas








Prepare el ambiente de trabajo

Diga el objetivo claramente
Genere tantas ideas como sea
posible
Deje volar la imaginacin
No critique ni discuta
Mezcle y combine ideas

Ejercicio
Realizar una lluvia de ideas (brainstorming) para recolectar las
necesidades para el sistema elegido que estn desarrollando
actualmente.
Features

Versin 1

Versin 2

19

Workshops de Recoleccin
Workshops de grupos colaborativos son una tcnica
altamente efectiva para reunir a usuarios y desarrolladores
Tips de recomendaciones para conducir sesiones de
recoleccin efectivas son:
Establecer reglas base (iniciar y terminar a tiempo, una
conversacin a la vez, enfocarse en issues no en personas)
No salirse del alcance (usar documento de visin y alcance)
Apuntar ideas o elementos para una consideracin posterior
(llevar una lista de issues que son importantes y se pueden
discutir despus)
Discusin Timebox (poner lmite de tiempo a cada punto)
Mantener un equipo pequeo e incluir a los participantes
correctos
Mantener involucrados a todos (fomentar la participacin de
todos los integrantes)

Reduccin de riesgos a travs de prototipos

IKIWISI Ill Know It When I See It

Propsitos:
Clarificar y completar los requerimientos
Explorar alternativas de diseo
Prototipo Horizontal
Forma Final, funciones y tecnologa
Bote lo menos que pueda
Prototipo Vertical (pruebas de concepto)
Validan la factibilidad tecnolgica; exponen los riesgos potenciales
Desechables
Eliminan riesgos de requisitos mal entendidos
Bote todo exceptuando el conocimiento ganado
Evolutivo
Este prototipo se llega a convertir en el producto final

20

Los prototipos son excelentes pero

Excelente! El Faran estar complacido de saber

que han completado la construccin bajo el
presupuesto y antes de tiempo

Puntos a considerar de los prototipos

No incluir validaciones de entrada de datos exhaustivas, manejo de
errores, o documentacin de cdigo en prototipos desechables.
No hacer prototipos para requerimientos que ya estn entendidos,
a menos que se quieran para explorar alternativas de diseo.
Es riesgoso usar datos dummy en los prototipos pues los usuarios
pueden distraerse al ver datos no reales dentro de los mismos.
Nunca esperar que un prototipo reemplace completamente a un
SRS !!!

21

Aplicacin de tcnicas de recoleccin

ALTO
EXPERIENCIA DEL
CLIENTE/ USUARIO

Alcanzarlos
Alcanzarlos

BAJO

Entrevistas
Investigacin
Bosquejos
Talleres de Requerimientos

Problema Enredado
Enredado

Lluvia de Ideas
Actuacin de Roles
Bosquejos
Entrevistas
Talleres de Requerimientos

Maduros
Maduros

Anlisis Orientado a Objetos

Especificacin de Requerimientos
Prototipos Horizontales
Casos de uso
Reingeniera de Procesos del Negocio
Talleres de Requerimientos

Vendiendo/
Vendiendo/Enseando
Enseando

Prototipo Evolutivo
Especificacin de Requerimientos
Bosquejos
Casos de uso
Reingeniera de Procesos del Negocio
Talleres de Requerimientos

BAJO
ALTO
EXPERIENCIA DEL DESARROLLADOR

Algunas precauciones
acerca de la recoleccin
Usar Product Champions para validar la entrada de
varios usuarios.
El documento de Visin y Alcance puede cambiar
despus del proceso de recoleccin.
No incluir informacin acerca de la solucin dentro
de los requisitos (no especificar nada que tenga que
ver con el diseo ni construccin de la solucin).

22

Dudas o comentarios ?

Entendiendo los requisitos

del Usuario:
Casos de Uso

23

Casos de Uso
Por qu usar un Modelo de Casos de Uso para entender las
necesidades de los afectados?

Para llegar a un acuerdo con el usuario de lo que el sistema debe hacer

Para identificar quien interactuar con el sistema
Para identificar las interfases que el sistema debe tener
Para ayudar a verificar que no faltan requerimientos
Para verificar que los desarrolladores entienden los requerimientos

Actores y Casos de Uso

Definen los Lmites y las Funciones
Un sistema telefnico simple

Persona que
Llama

Llamada Local

Llamada Internacional

Cliente

Facturar al cliente

Receptor de la
llamada

Administrador
De Facturacin

Un modelo de lo que el sistema hace y para quien lo hace

24

Como Encontrar Actores

Pregntese lo siguiente:
Qu grupos de usuarios ayudan al sistema a realizar sus
tareas?
Qu grupos de usuarios se necesitan para ejecutar las
opciones mas obvias del sistema?
Qu grupos de usuarios se requieren para desarrollar
las funciones secundarias tales como mantenimiento y
administracin?
Interactuar el sistema con otro sistema o hardware
externo?

Como encontrar casos de uso

Para cada actor pregntese lo siguiente:
Cules son las tareas primarias que el actor quiere que el
sistema desarrolle?
Crear, almacenar, cambiar, remover o leer datos en
el sistema?
Tendr el actor que informar al sistema de cambios
sbitos externos?
Tendr el actor que estar informado de ciertas
ocurrencias en el sistema?
Tendr el actor que desarrollar la inicializacin o
terminacin del sistema?
Ponga un nombre a los casos de uso que ha encontrado

25

Modelo del Diagrama de Casos de Uso

Una solucin simple para una Mquina de Reciclaje

Mquina de Reciclaje
Cliente

Reciclar Objetos

Imprimir Reporte Diario

Cambiar Valores de Fondos

Operador

Administrador

Agregar Nuevo Tipo de

Objeto

Un modelo de lo que el sistema se supone que debe hacer

(casos de uso) y los alrededores (actores)

Ejercicio
Identifique Actores para el ATM

26

Ejercicio
Identificar Casos de Uso para el ATM

Desarrollo de Requisitos
Anlisis

27

Ingeniera de Requisitos
Ingeniera de Requisitos
Desarrollo de
Requisitos

Recoleccin

Anlisis

Administracin de
Requisitos

Especificacin

Validacin

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

Anlisis de Requisitos
Esta etapa dentro del proceso de Desarrollo de
Requisitos se enfoca principalmente a analizarlos
para:
Detectar y resolver conflictos entre requisitos
Clasificar los requisitos de acuerdo al nivel
Separar los requisitos de manera modular (que llegarn a
formar parte de componentes de software)
Priorizar los requisitos
Crear el modelo conceptual

28

Anlisis de Requerimientos
Priorizacin de requisitos basada en Importancia y Urgencia

Importante

No Importante

Urgente

Prioridad Alta

No hacer estos !

No Urgente

Prioridad Media

Prioridad Baja

Dudas o comentarios ?

29

Desarrollo de Requisitos
Especificacin

Ingeniera de Requisitos
Ingeniera de Requisitos
Desarrollo de
Requisitos

Recoleccin

Anlisis

Administracin de
Requisitos

Especificacin

Validacin

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

30

Documento de Especificacin de
Requisitos de Software (SRS)
Para Moprosoft, este documento debe llevar:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

Introduccin
Funcionales
Interfaz con Usuario
Interfaces con otro Software o Hardware
Confiabilidad
Eficiencia
Mantenimiento
Portabilidad
Interoperatividad
Reusabilidad
Restricciones de Diseo y Construccin
Legales y Reglamentarios

Algunas guas para la especificacin de

requisitos funcionales
Usar siempre palabras como debe, deber, permitir, podr y NO
palabras como podra, debera, tal vez.
Asignar un identificador nico a cada requisito.
Para los Requisitos No Funcionales que son Atributos de Calidad,
especificar mtricas de cmo el requisito se debe cumplir y no dejar frases
tales como que lo haga rpido, que lo haga bien, entre otras. Mejor
cosas como que responda en menos de 30 segundos, que se inserten el
100% de los registros, etc.
JAMS SUPONER O ASUMIR ALGO!!! (Si no se est seguro de algo
preguntar al usuario llamndolo por telfono, o preguntndole en
persona).
Especificar todo lo ms claro posible pues hay que tomar en cuenta que los
que disearn el sistema son otras personas.
Cuidar el no incluir palabras ambiguas, un sntoma sera que dos personas
entendieran cosas distintas del requisito.

31

Ejercicio
Liste los problemas que encuentre en la especificacin del
siguiente requisito. Proponga una mejor redaccin de ser
posible (en caso que sea necesario puede descomponerlo
en varios requisitos).
El clculo de la nmina puede ejecutarse una vez al mes sin que nadie
tenga que activarla. Este proceso se debera ejecutar lo ms rpido posible
para que el da de la ejecucin antes de la hora de la comida todos los
empleados tengan su sueldo depositado. La cantidad a depositar para cada
empleado es simplemente la resta entre su sueldo asignado y las
deducciones. Adems, la informacin de los empleados incluyendo su sueldo,
no debera poder ser vista por el personal encargado de administrar la base
de datos que no tengan que ver con dicha informacin.

Posible Solucin
RF-1. El sistema deber ejecutar de manera automtica el clculo de la
nmina el ltimo da de cada mes natural. Es imprescindible que su
ejecucin quede lista antes de la 1 pm. Ver RN-1 para el clculo del sueldo.
Ver RNF-1 para polticas de seguridad.
RN-1. El sueldo mensual de un empleado se calcula por medio de la
siguiente frmula:
Sueldo Total = Sueldo_Asignado Total_Deducciones
donde Total_Deducciones se obtiene
RNF-1. nicamente el personal de recursos humanos podr ver y/o
actualizar la informacin personal de los empleados. Ni siquiera el personal
de bases de datos lo debe poder hacer.

32

Atributos de Calidad (1)

Los atributos de calidad son difciles de definir porque los usuarios se

enfocan ms en proporcionar sus requisitos funcionales (de
comportamiento).

Una manera de clasificar a los atributos de calidad es con aquellas

caractersticas que son evidentes en tiempo de ejecucin de las que no lo
son.

Atributos importantes para los usuarios

Atributos importantes para los

desarrolladores

Disponibilidad
Eficiencia
Integridad
Confiabilidad
Escalabilidad
Usabilidad

Fcil de mantener
Fcil de evolucionar
Portabilidad
Reusabilidad
Fcil de probar

Atributos de Calidad (2)

Un usuario no podr responder a preguntas tales
como:
Cules son tus requisitos de disponibilidad?
Qu tan confiable debe ser el software?

Buscar otro estilo de preguntas relacionndolas

con el dominio del problema. Por ejemplo.
Qu tan importante es asegurar que ciertos usuarios no puedan ver
cierta informacin? Podra cualquier persona tener acceso a la
informacin de los clientes?
Qu tan grave sera que el sistema no estuviera disponible (se cayera) en
horas de trabajo en un da entre semana? y qu tan grave sera que se
cayera un fin de semana en la madrugada?

33

Especificacin de Atributos de Calidad

(Requisitos No Funcionales)
Interfase con el Usuario
IU1. Un usuario entrenado deber ser capaz de registrar una peticin
completa de un producto de un vendedor en un promedio de 4 a 6
minutos.
IU2. Un usuario quien nunca ha utilizado el sistema antes, deber ser
capaz de registrar una solicitud de un pedido de manera correcta
en un tiempo no mayor a 10 minutos.

Interfases Externas
IE1. El sistema deber ser capaz de comunicarse con el mdulo de RH.
IE2. El sistema interactuar con el sistema de nmina ya existente en la
empresa.

Especificacin de Atributos de Calidad

(Requisitos No Funcionales)
Confiabilidad
Confiabilidad
CC1. No ms de 5 ejecuciones experimentales de 1000 pueden ser
perdidas debido a fallas en el software.
Disponibilidad
CD1. El sistema estar disponible el 99.5 % del tiempo en das de trabajo
entre las 6 am y las 12 am, y al menos el 99.95 % del tiempo en das de
trabajo entre 4 pm y 6 pm.
Robustez
CR1. Si el editor falla antes que el usuario guarde el archivo, el editor
deber ser capaz de recuperar todos los cambios hechos en el archivo
editado hasta un minuto antes de la falla, en la prxima vez que se inicie el
programa.
Integridad
CI1. Slo usuarios con privilegios de acceso de auditor sern capaces de
ver histricos de las transacciones de los clientes.

34

Especificacin de Atributos de Calidad

(Requisitos No Funcionales)
Eficiencia
E1. Toda pgina web deber ser cargada a lo ms en 15 segundos sobre
una conexin por modem de 50 KBps.
E2. La autorizacin de una peticin de retiro en un ATM no deber tomar
ms de 10 segundos.

Mantenimiento
M1. Un programador deber ser capaz de modificar los reportes existentes
con 20 horas o menos de esfuerzo en desarrollo.
M2. Las llamadas a funciones no debern pasar de 2 niveles de
anidamiento.

Portabilidad
P1. El mdulo de facturacin deber ser capaz de ejecutarse sobre
cualquier terminal PC con sistema operativo Linux o Windows.

Especificacin de Atributos de Calidad

(Requisitos No Funcionales)
Restricciones de Diseo y Construccin
RDC1. El sistema deber ser desarrollado sobre la plataforma J2EE la cual
es la infraestructura tecnolgica de la empresa.
RDC2. Todo el mdulo de inventarios deber ser construido utilizando las
libreras existentes en la empresa.

Legales y Reglamentarios
LR1. El sistema deber implementar las regulaciones del gobierno actual.
LR2. El costo unitario del producto ser de $50 en compras de 100 o ms
unidades, y en compras de menos unidades el costo unitario ser de
$70.
LR3. Por cada tres retardos que un empleado acumule a lo largo del mes
actual, se le descontar un da de sueldo.

35

Trade-Offs de Atributos de Calidad

Tarea
Hacer un documento de especificacin de requisitos para
el Sistema ATM. Este documento deber tener al menos
un caso de uso y al menos un requisito no funcional en
cada punto de la norma.
NOTA: Esto debe ser hecho por la persona o personas
que jugarn el rol de Analistas en el proyecto de
Moprosoft.

36

Desarrollo de Requisitos
Validacin

Ingeniera de Requisitos
Ingeniera de Requisitos
Desarrollo de
Requisitos

Recoleccin

Anlisis

Administracin de
Requisitos

Especificacin

Validacin

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

37

Validacin de Requisitos
La fase de validacin es la cuarta y ltima del rea de
Desarrollo de Requisitos.
Las actividades de la validacin de requisitos
intentan asegurar que:
El documento de especificacin de requisitos (SRS) describe las
capacidades y caractersticas del sistema que cumplirn las
necesidades de los stakeholders.
Los requisitos estn completos y son de alta calidad.
Todas las representaciones son consistentes con las dems.
Los requisitos proveen una base adecuada para proceder con el diseo
y la construccin.
Los requisitos son especificados de acuerdo a los estndares
establecidos.

Validaciones y Verificaciones en
Moprosoft
Verificacin o
Validacin

Producto

Rol

Descripcin

Verificacin

Especificacin de
Requisitos

RE

Verificar la claridad de redaccin de la Especificacin de

Requisitos y su consistencia con la descripcin del
producto y con el estndar de documentacin
requerido en el proceso.
Adicionalmente revisar que los requisitos sean
completos y no ambiguos o contradictorios. Los
defectos encontrados se documentan en un Reporte de
Verificacin.

Validacin

Especificacin de
Requisitos

CL,
US,
RPU

Validar que la especificacin de requisitos cumple con

las necesidades y expectativas acordadas. Los defectos
encontrados se documentan en un Reporte de
Validacin.

Verificacin

Plan de Pruebas de
Sistema

RE

Verificar consistencia del plan de pruebas del sistema

con la especificacin de requisitos y con el estndar de
documentacin requerido.

Verificacin

Manual de Usuario

RE

Verificar consistencia del manual de usuario con la

especificacin de requisitos y con el estndar de
documentacin requerido.

38

La calidad es gratis:
Inspecciones de Software
Las inspecciones de software son la mejor tcnica que
existe para remover defectos antes de llegar a la fase de
pruebas. (Inventadas por Michael Fagan a mediados de los
70s).
Para maximizar la calidad del producto se deben realizar
ms inspecciones.
Las inspecciones son costosas: consumen tiempo y
recursos.
Sin embargo
Por cada hora invertida en una inspeccin, se ahorra
alrededor de 10 horas de retrabajo en el testing.
Por cada dlar invertido en inspecciones, se ahorran de 3 a
10 dlares en la fase de pruebas.

Inspeccin de Software: Roles (1)

Autor
Creador del producto a inspeccionar.
Rol pasivo y no puede llevar otro rol de la inspeccin.
Debe dejar su ego afuera de la inspeccin y tambin ver defectos que
otros no ven.

Moderador
Lder de la inspeccin.
Planea y coordina las actividades de la inspeccin con el autor.
Distribuye el material a ser inspeccionado a los inspectores das antes de
la reunin.
Dirige el proceso de inspeccin y mantiene el enfoque en encontrar
defectos en vez de resolver problemas.
Se asegura que el autor realice las modificaciones despus de la
inspeccin.

39

Inspeccin de Software: Roles (2)

Lector
Debe parafrasear un requisito del SRS a la vez.
Los otros participantes detectan defectos potenciales.
Debe nombrar con sus propias palabras cada requisito, con esto se
pueden detectar ambigedades si los otros participantes lo haban
entendido de otra manera.

Escritor (apuntador)
Usa formatos para registrar los defectos encontrados durante la
reunin de inspeccin.

Inspeccin de Software: Roles (3)

Inspector
Es quien encuentra errores, omisiones e inconsistencias en los
productos inspeccionados.
Los inspectores pueden ser:
Autores de productos de trabajo antecesores del producto inspeccionado:
(usuarios, cliente, otros analistas).
Personas que trabajarn en base al producto de trabajo inspeccionado:
(diseadores, arquitectos, programadores, testers, etc).
Personas que son responsables por productos de trabajo que interfasean
al producto inspeccionado.

Tratar de limitar la inspeccin a 6 o menos inspectores.

40

Inspeccin de Software:
Criterios de Entrada

El documento cumple el estndar de la plantilla.

El documento no tiene faltas de ortografa.
El documento ya no tiene errores de formato.
Cualquier otro documento referenciado debe estar disponible
para los inspectores.
Issues incompletos deben ser marcados como TBD (To Be
Determined).
Puntos que no apliquen deben ser explcitamente
mencionados.

Inspeccin de Software:
Fases de la Inspeccin (1)
1. Planificacin. Cuando el autor termina su producto de trabajo se
forma un grupo de inspeccin y se designa un moderador. ste ltimo
asigna roles y planifica los tiempos y recursos necesarios.
2. Overview. Si los inspectores no estn familiarizados se da una vista
general del producto a inspeccionar. Es opcional.
3. Preparacin. Los inspectores se preparan individualmente para la
evaluacin en la reunin estudiando los productos de trabajo y el
material relacionado.
4. Junta de Inspeccin. Los inspectores se renen. El moderador lleva la
reunin. Es importante que no dure ms de 2 horas.
5. Retrabajo. El autor corrige todos los defectos encontrados por los
inspectores.
6. Seguimiento. El moderador checa las correcciones del autor. Si est
satisfecho la inspeccin est completa.

41

Inspeccin de Software:
Fases de la Inspeccin (2)

Inspeccin de Software:
Criterios de Salida
Todos los defectos encontrados han sido removidos.
Cualquier cambio hecho al producto inspeccionado
fue realizado correctamente.
El documento inspeccionado ha sido puesto bajo
gestin de la configuracin.
El documento ha sido corregido ortogrficamente.

42

Ejercicio
Lleva a cabo un proceso de inspeccin con el
SRS que les ser proporcionado y cumpliendo
los tiempos siguientes:

Planificacin (5 minutos)
Overview (5 minutos)
Preparacin Individual (10 minutos)
Reunin de Inspeccin (20 minutos)
Retrabajo (5 minutos)
Seguimiento (10 minutos)

Resumen

Introduccin
Fuentes de requisitos de software.
Planeacin y recomendaciones para la recoleccin de requisitos.
Tcnicas de recoleccin de requisitos.
Anlisis de Requisitos
Especificacin de Requisitos
Inspeccin de software para validacin de requisitos

43

Dudas o comentarios ?

44