Tema 4.

Captura de
Requisitos
Objetivos.
Diferencia entre sistema actual y sistema
requerido
Cuando y cmo aplicar las tcnicas de
bsqueda de informacin
La necesidad de documentar requisitos
Cmo dibujar diagramas de caso de uso para
documentar requisitos
Cmo escribir descripciones de caso de uso

4.1. INTRODUCCIN
Averiguar que desean los usuarios->Requisitos
Los requisitos se pueden clasificar de varias formas
Los analistas usan varias tcnicas para identificar y
documentar requisitos
Stakeholders: todos aquellos interesados o influidos por
el desarrollo del sistema de informacin
UML proporciona tcnica de realizacin de diagramas
que podemos usar para documentar los requisitos de los
stakeholders->Diagrama de Casos de Uso

4.2. REQUISISTOS DE
USUARIO
Comprender tanto objetivos globales de la
empresa como necesidades de usuarios
individuales.
Documentar perfectamente lo que el personal
hace->requisitos del sistema actual.
Documentar perfectamente lo que los usuarios
desean del nuevo sistema->nuevos requisitos.
Los requisitos deberan identificar las ventajas
de adquirir o crear el nuevo sistema->Anlisis
coste-beneficios.

4.2. REQUISISTOS DE
USUARIO

4.2.1 Sistema actual

Podemos encontrarnos con los denominados SISTEMAS
HEREDADOS: millones de lneas de cdigo depuradas a lo largo
de los aos.
Estrategias:
crear nuevos front-ends grficos con OO y empaquetar los sistemas
heredados detrs de ellos.
Sino es posible dejarlos como estn debido a que la tecnologa que utilizaban
est obsoleta y sin soporte, habr que cambiarlos y esto supone conocerlos
internamente en profundidad. No nos fijamos entonces en como trabaja la
gente, sino que nos centramos en como lo hace el sistema.

Autores como Yourdon sealan que tampoco debemos perder el

norte destripando y modelando hasta lo ms mnimo el sistema
actual y dejando de lado el nuevo.
Otros defienden la posicin contraria.
Lo mejor es llegar a un equilibrio: investigar el sistema existente y
modelarlo para ver como mejorarlo con el nuevo.

4.2. REQUISISTOS DE
USUARIO
4.2.2 Clasificacin de los
requisitos
Funcionales
No Funcionales
De Facilidad de Uso
5

4.2. REQUISISTOS DE
USUARIO
4.2.2 Clasificacin de los requisitos
Requisitos funcionales
Lo que hace un sistema o se espera que haga
Usaremos casos de uso
Los requisitos funcionales incluyen:
Descripciones de los procesos que el sistema deber
realizar
Detalles de las entradas al sistema obtenidos de
formularios en papel y documentos, e interacciones entre
personal, tales como llamadas telefnicas y de otros
sistemas.
Detalles de las salidas esperadas del sistema en forma de
documentos e informes impresos, de pantallas y de
transferencia a otros sistemas.
Detalles de los datos que tienen que mantenerse en el
sistema.

4.2. REQUISISTOS DE
USUARIO
4.2.2 Clasificacin de los requisitos
Requisitos no funcionales
Relacionados con lo bien que el sistema cumple los
requisitos funcionales.
Incluyen:
Criterios de rendimiento, tales como los tiempos de
respuesta deseados para la actualizacin de datos en el
sistema o para la obtencin de datos del sistema.
Previsin del volumen de datos, bien en trminos de
circulacin de datos o en trminos de los que deben
almacenarse.
Consideraciones de seguridad

4.2. REQUISISTOS DE
USUARIO
4.2.2 Clasificacin de los requisitos
Requisitos de facilidad de uso
Son los que permitirn asegurar que existe un buen
acoplamiento del sistema con los usuarios que accedan a l
con las tareas que deben realizar cuando lo utilizan.
Conviene para conseguir una buena facilidad de uso reunir
la siguiente informacin:
Caractersticas de los usuarios que utilizan el sistema
Tareas que realizarn los usuarios y los objetivos que tratan de
conseguir
Factores situacionales, que describen las situaciones que pueden
surgir durante la utilizacin del sistema. (Ejemplo: una persona
zurda debe usar el sistema)
Criterios con los que el usuario valorar el sistema entregado.
(Ejemplo: me gustara que cada ventana del sistema no mostrar
demasiados botones)

4.2. REQUISISTOS DE
USUARIO

4.2.2 Clasificacin de los requisitos

EJERCICIO I: lea la siguiente descripcin relacionada con la
empresa FoodCo, y decida qu partes son requisitos funcionales y
cules son no funcionales:
La asignacin de personal a lneas de produccin debera ser
fundamentalmente automatizada. Un determinado proceso se
ejecutar una vez a la semana, para realizar la asignacin, basndose
en las habilidades y experiencia de los operarios. Deberan tambin
tenerse en cuenta los detalles de fiestas y faltas por enfermedad. Un
borrador de una primera lista de asignacin para la semana siguiente
se imprimir a las 12:00 del medioda del viernes. Solamente el
personal de Planificacin de produccin podr corregir la asignacin
automtica para ajustar la lista. Una vez realizadas las correcciones, la
lista de asignacin final tiene que imprimirse a las 5:00 PM. En la
actualidad, el sistema tiene que poder manejar la asignacin de 100
operativos y debera tener posibilidades de expansin para manejar el
doble de ese nmero.

4.3. TCNICAS DE BSQUEDA DE

HECHOS
Los analistas usan, principalmente,
cinco tcnicas para investigar
requisitos:

Lecturas preparatorias
Entrevistas
Observacin
Muestreo de documentos
Cuestionarios

10

4.3. TCNICAS DE BSQUEDA DE

HECHOS
4.3.1 Lecturas preparatorias
Si el analista no trabaja internamente en la empresa,
es un consultor externo, necesitar conocer la
organizacin. Fuentes de informacin que puede usar
son:
Informes de la empresa
Grficos de la organizacin
Manuales de normativas
Descripciones de trabajos
Otros Informes
Documentacin de los sistemas existentes

11

4.3. TCNICAS DE BSQUEDA DE

HECHOS
4.3.1 Lecturas preparatorias
Ventajas:
Ayudar al analista a adquirir buen conocimiento de la
organizacin antes de reuniones con trabajadores
Obtener de lo ledo requisitos ya definidos para el sistema
actual

Desventajas:
Muy a menudo, los documentos escritos no se adaptan
completamente a la realidad; a veces son antiguos o
reflejan una poltica oficial que en la prctica se trata de
forma distinta.

Situaciones apropiadas:
Usar lecturas preparatorias cuando se desconoce la
organizacin. tiles en etapas iniciales de investigacin.

12

4.3. TCNICAS DE BSQUEDA DE

HECHOS
4.3.2 Entrevistas
Ampliamente utilizadas.
Reunin estructurada entre analista y entrevistados.
La estructura puede ser ms o menos cerrada:
Preguntas fijas
Preguntas sobre temas que permitan al investigador tratar
otros asuntos segn surjan.

Aprovechar para reunir documentos que usa el entrevistado

Si dos o ms usuarios del sistema realizan lo mismo puede
ser conveniente entrevistarlos en grupo
CONSEJOS

13

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.2 Entrevistas
Ventajas:
El contacto personal permite al analista adaptarse a lo que
dice el usuario->esto proporciona informacin de gran
calidad.
Si el entrevistado no tiene nada que decir la entrevista
puede darse por finalizada.
Desventajas:
Requieren mucho tiempo
Entrevistados pueden verse sometidos a presiones si el
entrevistador tiene una visin muy rgida
Si varios entrevistados proporcionan algn tipo de
informacin conflictiva, es posible, que posteriormente, sea
difcil de clarificar.
Situaciones apropiadas:
Apropiadas en la mayor parte de proyectos.

14

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.3 Observacin

Buena para detectar esas situaciones excepcionales que

se producen en el trabajo y que no se contemplan
cuando se responde a una entrevista.
Ver la informacin que utilizan las personas para realizar
su trabajo.
Determinar los tiempos que se utilizan para la
realizacin de las tareas.
Ver la trazabilidad de los documentos o de la
informacin: pedidos se realizan a travs de telfono, se
pasan a almacn para seleccionar, empaquetar y enviar
el producto al comprador.
Ver errores en el uso del sistema actual.
Etc..

15

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.3 Observacin:

Ventajas:
Datos recogidos en tiempo real
Verificar informacin obtenida por otras fuentes
Conseguir datos bsicos sobre rendimiento del sistema y de los usuarios

Desventajas
A la mayora de la gente no le gusta que la observen->trabajarn de forma
distinta->se distorsionan los resultados->afecta a la validez
Problemas logsticos: los observados trabajan a turnos o se desplazan largas
distancias.
Problemas ticos: persona observada trabaja con datos personales o
privados sensibles o trabaja con pblico (Ejemplo: clnica mdica)

Situaciones apropiadas:
til en situaciones en las que distintos entrevistados han dado
informaciones contradictorias.
Seguir elementos a travs de algn tipo de proceso desde el principio al fin.

16

4.3. TCNICAS DE BSQUEDA DE

HECHOS
4.3.4 Muestreo de documentos

Primer muestreo:
En las entrevistas y observaciones:
recoger documentos cumplimentados
y sin cumplimentar.
Recoger tambin pantallazos del
sistema actual

EJEMPLO

17

4.3. TCNICAS DE BSQUEDA DE

HECHOS
4.3.4 Muestreo de documentos

Segundo muestreo
El analista realizar anlisis estadstico
de documentos para localizar
patrones de datos: cantidad de datos
a manejar, nmero de lneas mximas
que tienen los documentos, datos que
se repiten, etc.

18

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.4 Muestreo de documentos

Ventajas:
Obtener datos cuantitativos: nmero medio de lneas de
factura, rango de valores,
Calcular porcentajes de error en documentos en papel.

Desventajas:
Si el sistema va a cambiar drsticamente puede que los documentos
actuales no reflejen como sern en el futuro

Situaciones apropiadas:
Primer muestreo es casi siempre adecuado.
Segundo muestreo (estadstico) cuando se procesen grandes
cantidades de datos, cuando porcentajes altos de error y se trata
de reducir los mismos con el nuevo desarrollo.

19

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.5 Cuestionarios

Consisten en una serie de preguntas escritas

que suelen limitar la respuesta: si, no, no sabe.
Aunque tambin pueden ser de respuesta
abierta.
Disearlos con sumo cuidado.
EJEMPLO
DIRECTRICES 1
DIRECTRICES 2

20

4.3. TCNICAS DE BSQUEDA DE

HECHOS

4.3.5 Cuestionarios

Ventajas:

Desventajas:

Manera econmica de reunir datos a partir de un nmero elevado de

personas.
Un buen cuestionario es posiblemente analizable mediante PC.
Buenos cuestionarios no fciles de crear.
Los cuestionarios enviados por correo convencional adolecen de
repuesta lenta.

Situaciones apropiadas

Ideal cuando es necesario obtener informacin de muchas personas o

estas estn alejadas geogrficamente (empresas con muchas
sucursales)
Para sistemas de informacin que van a ser utilizados por pblico en
general-> el analista se hace una idea de los tipos de usuario que
usarn el sistema y como lo usaran (puntos de informacin
electrnica en un ayuntamiento)

21

4.3. TCNICAS DE BSQUEDA DE

HECHOS
EJERCICIO II: Imagine que est
entrevistado a una de las tres
personas en Planificacin de
produccin de FoodCo. Elabore una
lista con no menos de cinco
preguntas que desee hacerle.

22

4.4 IMPLICACIN DEL

USUARIO

En grandes proyectos es probable que un comit director est

encargado de gestionar el proyecto desde el lado de los
usuarios. Estaran:
Altos directivos con total responsabilidad para dirigir la
organizacin
Directores financieros con control presupuestario sobre el proyecto
Directores del departamento/s de usuarios
Representantes del departamento de TI que entrega el proyecto
Representantes de los usuarios

Los usuarios estarn involucrados en la realizacin del

proyecto de varias maneras, tales como:

Sujetos de entrevistas para establecer requisitos

Representantes en comits de proyecto
Implicados en la evaluacin de prototipos
Implicados en las pruebas
Sujetos de cursos de entrenamiento
Usuarios final del sistema
23

4.4 IMPLICACIN DEL

USUARIO
Una de las primeras tareas en la bsqueda
de hechos es elaborar un plan que defina:
la informacin que se est buscando, las
tcnicas que se utilizarn, quien est
implicado en la bsqueda de hachos y
cuanto tiempo durar.
EJEMPLO

24

4.5 REQUISITOS DE
DOCUMENTACIN

Analistas y diseadores modelan el nuevo sistema con

ayuda de una mezcla de diagramas y texto.
Dentro de un proyecto debera considerarse siempre algn
conjunto de estndares (Nosotros estamos utilizando UML)
A parte de los diagramas y especificaciones textuales que
se obtengan en el modelado tambin hay otros tipos de
documentos:
Grabaciones de entrevistas y observaciones
Detalles de problemas
Copias de documentos existentes y dnde se utilizan
Detalles de los requisitos
Detalles de los usuarios
Actas de las reuniones
.

25

4.5 REQUISITOS DE
DOCUMENTACIN

Se deber dispones de un sistema de archivos y un

conjunto de convenciones sobre cmo se deber archivar
todo este material y mantener un registro de quien retira
elementos del sistema de archivos.

En muchos proyectos en los que los documentos se

almacenan digitalmente es interesante un sistema de
gestin de documentos con control de versiones.

26

4.6 CASOS DE USO

4.6.1 Objetivo
Los casos de uso pueden utilizarse para modelar
requisitos funcionales. No son adecuados para modelar
requisitos no funcionales.
Un requisito puede cumplirse mediante ms de un caso
de uso y un caso de uso puede cumplimentar ms de un
requisito.
Diagrama de actividad que muestra las actividades
involucradas en la captura de requisitos y los
documentos que se generan.

27

4.6 CASOS DE USO

Los diagramas de caso de uso se utilizan
para mostrar la funcionalidad que el
sistema ofrecer y qu usuarios se
comunicarn con el sistema para utilizar
esa funcionalidad.
EJEMPLO

28

4.6 CASOS DE USO

Los casos de uso estn soportados por
especificaciones de comportamiento que pueden
modelarse con diagramas de comunicacin o
diagramas de secuencia o en forma de texto con
descripciones de caso de uso.
Las descripciones de caso de uso en texto ofrecen
una descripcin de la interaccin entre los
usuarios del sistema (ACTORES) y las funciones
del mismo.

29

4.6 CASOS DE USO

4.6.2 Notacin

30

4.6 CASOS DE USO

4.6.2 Notacin
Ejemplo:

31

4.6 CASOS DE USO

4.6.2 Notacin
Acciones alternativas:
Las descripcin del caso de uso refleja la forma usual de
ejecutar una determinada funcin. Los escenarios representan
rutas especficas (alternativas) a travs del caso de uso.
Tambin hay que incluir posibles respuestas a errores.

Debera incluirse tambin la finalidad del caso de uso.

EJEMPLO:
El director de campaa desea registrar qu personal est
trabajando en una determinada campaa.
Esta informacin se utiliza para validar hojas de tiempos y
para calcular las gratificaciones de la plantilla a final de ao
PLANTILLA

32

4.6 CASOS DE USO

4.6.2 Notacin
Relacin extender:
<<extender>>
Se utiliza cuando se quiere mostrar que un caso
de uso ofrece una funcionalidad adicional que
puede necesitarse en otro caso de uso.

33

4.6 CASOS DE USO

34

4.6 CASOS DE USO

4.6.2 Notacin
Relacin incluir
<<incluir>>
Se aplica cuando hay una secuencia de
comportamiento que se utiliza frecuentemente en
un determinado nmero de casos de uso y no se
quiere copiar la misma descripcin en cada caso
de uso en la que se utiliza.

35

4.6 CASOS DE USO

36

4.6 CASOS DE USO

37

4.6 CASOS DE USO

4.6.2 Notacin
Tambin es conveniente describir quienes son
los actores en trminos de ttulos de puestos
de trabajo o forma en que interactan con el
sistema.
Los actores pueden ser no humanos: otros
sistemas o mquinas

38

4.6 CASOS DE USO

4.6.2 Notacin
Generalizacin y Especializacin de Casos de Uso y
Actores
EJEMPLO:
Supongamos que el Director de Campaa puede hacer
todo lo que hace el Contacto de Personal. En vez de
asociar al Director de Campaa con todos los casos de
uso a los que est asociado el Contacto de Personal,
mostramos al Director de Campaa como una
especializacin del Contacto de Personal. (Ver diagrama
en diapo. Siguiente)

39

4.6 CASOS DE USO

Esto es un caso
de uso abstracto
que nos ayuda a
definir la
funcionalidad de
los otros dos
casos de uso

40

4.6 CASOS DE USO

4.6.2 Notacin
EJERCICIO III: Lea el extracto de la trascripcin
de una entrevista con uno de los que planifican
la produccin en FoodCo. Dibuje un diagrama
de caso de uso y cree descripciones de caso de
uso para todos los que pueda encontrar en
esta informacin. Identifique y describa a los
actores si es posible. Realice el diagrama con
una herramienta de dibujo.

41

4.6 CASOS DE USO

4.6.3 Soporte de casos de uso con prototipado
Puede ser til construir prototipos segn se van
concretando los requisitos.
Los prototipos se pueden utilizar para ayudar a
determinar los requisitos.
EJEMPLO: el caso de uso Buscar campaa en la diapo37 se
usa mucho, con lo que puede ser til crear un prototipo
y mostrrselo al usuario para asegurarnos que cumple
con lo que el usuario espera.
(Ver diapo siguiente)

42

4.6 CASOS DE USO

Este primer prototipo es enseado al cliente que sugiere

otra solucin: mejor presentar los clientes, elegir el cliente
y que de ese cliente muestre sus campaas, luego elegir la
campaa.

43

4.6 CASOS DE USO

Se ha obtenido un nuevo requisito del cliente relativo a la

facilidad de uso y a la velocidad con la que se encuentra una
campaa, la cual mejora con este segundo prototipo. Es ms
fcil y ms rpido encontrar una campaa as que de la otra
manera.

44

4.6 CASOS DE USO

4.6.3 Soporte de casos de uso con
prototipado
Los prototipos no tienen por que desarrollarse
como programas, tambin pueden presentarse
en papel como distribuciones de pantallas que
van mostrando los pasos que el usuario
debera ejecutar para interactuar con un
determinado caso de uso. (Ver diapo siguiente)

45

4.6 CASOS DE USO

46

4.6 CASOS DE USO

4.6.3 Soporte de casos de uso con
prototipado
EJERCICIO IV: Realice prototipos de pantallas de
algunos de los casos de uso que obtuvo en el
ejercicio III.

47

DIAGRAMA DE ACTIVIDAD PARA

CAPTURA Y MODELADO DE
REQUISITOS

48

MATRIZ DE TRAZABILIDAD DE
REQUISITOS
Permite ver si todos los requisitos se
satisfacen con los casos de uso.
Se ve qu casos de uso satisfacen qu
requisitos.

Requisito 1
Requisito 2

Caso de
Uso 1
X

Caso de
Uso 2

Caso de
Uso 3
X

49

ESTUDIO DE CASOS
1.

2.
3.

Analiza con tu grupo la entrevista entre Dave Harris, un

analista de distemas, y Peter Bywater, un director de
finanzas de Agate. Realice el diagrama de casos de uso
y describa cada uno de ellos.
Piensa con tu grupo en los posibles usos que podras
hacer de un sistema de biblioteca y dibuja un diagrama
de caso de uso para representar estos casos de uso.
Haz con tu grupo una lista de requisitos no funcionales
del sistema de biblioteca del caso anterior.

50