Mdulo 2

Captura y
Modelado de
Requerimientos.

3.1- Captura de
requisitos, objetivo de
la captura de requisitos
Conceptos Bsicos:
Requerimiento:
Unrequerimientoesunacaractersticadelsistemaounadescripcinde
algo que el sistema es capaz de hacer con el objeto de satisfacer el
propsitodelmismo.
Analizarrequerimientosesmuchomsquedejarescritomeramenteloque
quieren los clientes. Es difcil saber exactamente lo que el sistema debe
hacer.
Los requerimientos son caractersticas que deben incluirse en un nuevo
sistemaconsiderando:

descripcionesdeserviciosodeaquelloqueelsistemaescapazde
hacer,

restricciones que el sistema deba considerar, contemplando las

necesidadesocondicionesestablecidasporelusuario,

los problemas observados y las mejoras posibles en relacin al

sistemaactual.

PropsitosdelosRequerimientos:
1.Permitenquelosdesarrolladoresexpliquencmohanentendido
loqueelclientepretendedelsistema.
2.Indicanalosdiseadoresqufuncionalidadycaractersticasvaa
tenerelsistemaresultante.

3. Indican al equipo de pruebas qu demostraciones llevar a cabo

paraconvenceralclientequeelsistemaqueseleentregaesloque
habaordenado.

CaractersticasdelosRequerimientos:
Como plantea Shari Pleeger en su libro Ingeniera de Software (ver
bibliografa), para asegurar que los desarrolladores y los clientes
comprendan y utilicen correctamente los requerimientos es importante
queestosltimosseandealtacalidad.
Con este objetivo debe comprobarse que los requerimientos posean las
siguientescaractersticas:
Correcto: Tanto los clientes como los desarrolladores deben revisar los
requerimientosdefinidosparaasegurarsequenocontenganerrores.
Consistente:Unrequerimientoesconsistentesinoescontradictoriocon
otrorequerimiento.PorejemplosiunrequerimientodicequeHabrun
mximo de 10 puestos de trabajo simultneos y otro requerimiento
expresaqueParaprocesarlospagosenfechadevencimientosepodr
trabajar con 12 puestos simultneos, estos requerimientos son
inconsistentes.
Completo: Un requerimiento est completo si no necesita ampliar
detalles en su redaccin para su comprensin. Un conjunto de
requerimientos es completo si todos los estados posibles, cambios de
estado,entradas,productosyrestriccionesestndescriptosenalgunode
losrequerimientos.
Realista:Debecomprobarsequeelsistemapuedahacerloqueelcliente
estpidiendo.Aveces,cuandoeltiempodedesarrolloeslargo,elcliente
intenta anticiparse a las mejoras en tecnologas disponibles e impone
requerimientos sobre el estado del arte. Todos los requerimientos deben
serrevisadosparaasegurarquesonposibles.
Necesario: Un requerimiento es necesario si su omisin provoca una
deficiencia en el sistema a construir. En ocasiones, un requerimiento
restringe innecesariamente a los desarrolladores o incluye funciones que
noestndirectamenterelacionadasconelproblemaqueseesttratando.
Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de distintos mtodos de
verificacin.Debemospoderprepararpruebasquedemuestrenquesehan
cumplimentadolosrequerimientos.

 Rastreable: Debe ser posible rastrear cada funcin del sistema hasta el
conjuntoderequerimientosquelaestablece.

Tipos de Requerimientos:
Unaclasificacintpicadelosrequerimientosdeunsistemadesoftwarees
lasiguiente:
1.RequerimientosFuncionales
2.RequerimientosNoFuncionales

1.RequerimientosFuncionales
Definen las funciones que el sistema ser capaz de realizar y describen
cmodebecomportarseelsistemaantedeterminadoestmulo.
Describen la funcionalidad o los servicios que se espera que el sistema
provea, detallando las transformaciones que el sistema realiza sobre las
entradasparaproducirsalidas.
Ejemplos:
a)ParaunSistemadeProcesamientodeTransacciones
Elsistemadeber:
Registrarlospedidosdelosclientes.
Administrardatosdelosclientes.
Generarfacturasdeventa.
EmitirReportesdeVentasenunrangodefechadado.
Administrardatosdelosproductosquesecomercializany
sustockactual.
Registrarmovimientosdestockdecadaproducto.

b) Para un Sistema de un Videojuego: (Basado en el ejemplo

desarrollado en libro Ingeniera de Software, una perspectiva
orientadaaObjetosdeEricBraude,2003).
Elsistemadeber:
Generar dos tipos de personajes: los que estn bajo el
control del jugador y personajes extraos bajo el control
delaaplicacin.
Permitiraljugadordefinirunpersonajeprincipal.
Mantener cualidades para cada personaje: fuerza,
velocidad,paciencia.
Mantenerunvalorparacadacualidaddecadapersonaje.
Permitir que los personajes puedan interactuar cuando
estnenlamismarea.

2.RequerimientosNoFuncionales:
Sonrestriccionesdelosserviciosofuncionessobreelsistemaquelimitala
eleccindealternativasenlaetapadediseoyconstruccindelsistema.
Los requerimientos no funcionales son caractersticas que de una u otra
forma pueden limitar el sistema, como por ejemplo, el rendimiento (en
tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad,
estndares,entreotras.
Ejemplos:
a)ParaunSistemadeProcesamientodeTransacciones
Elsistemadeber:
Operarenunentornodered.
Definir distintos niveles de usuario y asignar permisos de acceso
segnelniveldelosmismos.
AlmacenarlosdatosenunabasededatosRelacional.
b)ParaunSistemadeunVideojuego:1
Elsistemadeber:

OperarenunacomputadoraconsistemaoperativoWindows98o
superior.
Operarenunequipoconunmnimode512Kbdememoria.
EllenguajedeimplementacindeberserJAVA.

Clasificacin de Requerimientos No
Funcionales
La figura que se muestra a continuacin contiene una clasificacin de los
requerimientos no funcionales presentada por Ian Sommerville (2002) en
sulibroIngenieradeSoftware(verbibliografa).

Fuente:LibroIngenieradeSoftwareIanSommerville(2002),Pg.102

Comentamosacontinuacinlascaractersticasgeneralesdelosprincipales
tiposderequerimientosnofuncionales:

RequerimientosdelProducto:

Estos requerimientos especifican el comportamiento del producto, como

porejemplo:
Requerimientos de desempeo en la rapidez de ejecucin. Por
ejemplo: La consulta de disponibilidad de habitaciones deber
realizarseenuntiempomenorde20segundos
Requerimientos de tamao de memoria requerida, tamao en
disconecesario
Requerimientosdefiabilidadquefijanlatasadefallasparaqueel
sistemaseaconsideradoaceptable.
Requerimientos de portabilidad, como por ejemplo: La
aplicacin deber poder accederse desde navegadores Web
InternetExplorer6.0osuperiores,ynavegadoresMozillaFirefoxa
partirdelaversin4.0

Requerimientosorganizacionales:

Se derivan de las polticas y procedimientos existentes en la organizacin

delclienteyenladeldesarrollador.Algunosejemplosson:
Estndaresenlosprocesosquedebenutilizarse.
Requerimientos de implementacin como el lenguaje de
programacin o el mtodo de diseo a utilizar. Por ejemplo: El
motordebasededatosautilizardeberserSQLServer2008,que
eselutilizadoparalosotrosaplicativosdelaorganizacin
Requerimientosdeentregaqueespecificancundoseentregarel
productoysudocumentacin.

Requerimientosexternos:

Este apartado cubre todos los requerimientos que se derivan de los

factoresexternosalsistemaydesuprocesodedesarrollo.stosincluyen:
Requerimientos de interoperabilidad que definen la manera en
que el sistema interacta con otros sistemas. Por ejemplo: Se
debergenerarunarchivoconlainformacindelasacreditaciones
de sueldos respetando el formato establecido por el Banco
ProvinciadeCrdoba.

 Requerimientos legales que deben seguirse para asegurar que el

sistema opere dentro de la Ley. Por ejemplo: Las facturas
generadas e impresas deben cumplimentar todas las
reglamentaciones definas a tal efecto por la AFIP (Administracin
FederaldeIngresosPblicos)ylaLeydeFacturacinvigente.
Requerimientos ticos para asegurar que ser aceptado por el
usuarioyporelpblicoengeneral.

Categoras de los Requerimientos:

Engeneral,planteaShariPleeger,estilsepararlosrequerimientosentres
categoras:
1.Requerimientosquedebenserabsolutamentesatisfechos
2.Requerimientosquesonmuydeseables,peronoindispensables.
3.Requerimientosquesonposibles,peroquepodraneliminarse
Dependiendo del tiempo asignado al proyecto, los recursos, los costos,
envergadura del proyecto, entre otros aspectos, el sistema a desarrollar
debe considerar obligatoriamente los requerimientos de la categora 1.
Dependiendo de cunto debe ajustarse el proyecto a las limitaciones
puedenanalizarselosdecategora2parasupostergacinoeliminaciny
los requerimientos de categora 3 son los primeros a eliminarse del
proyectosegnlanecesidadrequerida.
En anlisis de requerimientos por categora es til para que todos los
participantescomprendanloquerealmentesenecesita.

Los problemas con los

Requerimientos:
Paul Bramble, uno de los autores del libro Patrones de Casos de Uso,
plantea que existen una serie de problemas cuando trabajamos en la
definicindelosrequerimientos:
Los requerimientos pueden ser tediosos (una extensa lista y/o
documentos)
Losrequerimientospuedenestardesorganizados

 Los requerimientos, como lo expresan los usuarios, pueden ser

imprecisos,ambiguosoerrneos
La captura de requisitos es un proceso continuo (mientras ms
estudiamoselsistema,msaprendemosdelymscambia).
Losclientesnosiempreconocensusverdaderasnecesidades,enmuchos
casoscreenestarsegurosdelasmismas.Esnuestrotrabajoencontrarlas.
Un Analista/Desarrollador puede afirmar Yo entiendo los
requerimientos,peroQuhacerealmenteelSistema?
Se necesita un proceso ordenado y sistemtico para trabajar con los
requerimientos, porque stos son la base de todo proyecto y en gran
medidalosresponsablesdesuxitoofracaso.

Ingeniera de Requerimientos
Concepto
Eselprocesodedescubrir,analizar,documentaryverificarlosserviciosy
restricciones que debe considerar el sistema a desarrollar. En otras
palabras, la ingeniera de requerimientos esun proceso que comprende
todaslasactividadesrequeridasparacrearymantenerundocumentode
requerimientosdelsistema.
Permiteunaespecificacindelosrequerimientoscompleta,consistentey
noambigua,lacualservircomobaseparaacuerdoscomunesentretodas
laspartesinvolucradasyendondesedescribenlasfuncionesquerealizar
elsistema.
La siguiente figura ilustra el esquema de procesos comprendidos por la
IngenieradeRequerimientos.

Fuente:PginaWebdelSIU(ConsorciodeUniversidades),artculodeRicardoWilliams
(CoordinadorgeneraldelSIU,LicenciadoenSistemas,EspecialistaenIngenierade
Software)http://www.siu.edu.ar/infosiu/&edicion=12&nota=75(fechavisitadelsitio:20
092013)

ELICITACIN
Concepto:Procesoendondeseadquiereelconocimientodeltrabajodel
cliente / usuario, se busca comprender sus necesidades y se detallan las
restriccionesmedioambientales.
Resultado: el conjunto de los requerimientos de todas las partes
involucradas.
Tcnicas: Entrevistas, cuestionarios, observacin, anlisis de
documentos,torbellinodeideas,JAD,entrelasprincipales.

ESPECIFICACIN
Concepto: Esta etapa es un proceso de descripcin del requerimiento
durante el cual se producir el documento de especificacin de
requerimientosdelsoftware(ERS).
Resultado:Unaformadecontratoentreusuariosydesarrolladoresque
define el comportamiento funcional deseado del software (y otras
propiedades como performance, confiabilidad, seguridad.) sin mostrar
cmoseralcanzadatalfuncionalidad.Existeunanormaestndarparala

escrituradeldocumentodeespecificacinderequerimientos(ERS)quees
la: IEEE Std. 830 (1998) ( IEEE = Institute of Electrical and Electronics
EngineersInstitutodeIngenierosenElectricidadyElectrnica)
Tcnicas:LatcnicamsutilizadaenelmomentoesladeCasosdeUso,
conotrasherramientasgrficascomplementarias.

VALIDACIN
Concepto:Eselprocesoquecertificaqueseatacaelproblemacorrecto.
Este proceso final se nutre de los anteriores y realiza la integracin y
validacinfinaldeloobtenidoencadaunadelasetapasanteriores.
Resultado:Modeloderequerimientosenlneaconlasexpectativasdelos
usuarios.
Tcnicas:Revisionesderequerimientos,prototipos,generacindecasos
deprueba,anlisisdeconsistenciaautomtico.

La captura de requisitos en el PUD

En el Proceso Unificado de Desarrollo, el propsito fundamental del flujo
de trabajo de requisitos es guiar el desarrollo hacia el sistema correcto.
Estoseconsiguemedianteunadescripcin,suficientementebuena,delos
requisitos del sistema como para que los desarrolladores lleguen a un
acuerdo con el cliente sobre qu debe hacer y qu no debe hacer el
sistema.
Ms all de cul sea el punto de partida para el descubrimiento de los
requisitos(modeladodelnegocio,deldominio,especificacinderequisitos
hechaporelcliente),hayunaseriedepasosqueestnsiemprepresentes:

Enumerarlosrequisitoscandidatos.

Comprenderelcontextodelsistema.

Encontrarrequisitosfuncionales

Encontrarrequisitosnofuncionales

10

Enumerarlosrequisitoscandidatos
Durante el desarrollo del sistema todos los involucrados en el proyecto
(clientes, usuarios, analistas, desarrolladores y otros) presentan buenas
ideasquepuedenconvertirseenrequisitosverdaderos.
Conviene entonces confeccionar una lista de caractersticas con estas
ideasalasqueconsideramosrequisitoscandidatos.Estalistaseaumenta
con la aparicin de nuevas ideas y disminuye cuando algunas
caractersticasseconviertenenverdaderosrequisitosypasanamodelarse
comocasosdeuso.
Elrestodelospasossetratarnconmsdetalleenlospuntosquesiguen.

3.2- Comprensin del

contexto del sistema
mediante un modelo de
negocio
Comprender el contexto del sistema
Paracapturarlosrequisitoscorrectos,quenosllevenaconstruirelsistema
correcto, se requiere un firme conocimiento del contexto en el que se
emplazaelsistema.
Hay, por lo menos, dos formas de expresar el contexto de un sistema en
una forma que sea de utilidad para los desarrolladores del sistema: el
modeladodeldominioyelmodeladodelnegocio.
Un modelo de dominio (tambin conocido como Modelo de Objetos del
Dominio del Problema) describe los conceptos importantes del contexto
como objetos del dominio y enlaza estos objetos entre s. Este tema se
desarrollaacontinuacinenestaunidad.

11

Elmodeladodelnegocioserealizaparadescribirlosprocesosdelnegocio,
con una visin orientada a objetos, con el objetivo de comprenderlos. El
modelado de negocio es parte de la Ingeniera de Negocios, que es una
tcnica que tiene por objetivo mejorar los procesos de negocio de la
organizacin.

Modelo de Negocio
Unmodelodecasosdeusodelnegociodescribeprocesosdeunnegocioy
susinteraccionesconelexterior.Supropsitoprincipalesdescribircmo
esusadoelnegocioporsususuarios,enestecasosusclientesysocios.
Para nosotros, la principal motivacin para confeccionar un modelo de
negocio ser la posibilidad de derivar, a partir de dicho modelo, los
requerimientosdelsistemadesoftwarequedarsoporteaesesistemade
negocio.
ElmodeladodenegocioestsoportadopordostiposdemodelosdeUML
(definidosenlaextensindeUMLrelativaalNegocio):

Modelo de Casos de Uso de Negocio: Presenta una vista externa

delnegociolacualdefineloqueesesencialqueelnegociorealice
para entregar el resultado deseado a sus clientes (actores del
negocio).

Modelo de Objetos del Negocio: Es una vista interna del negocio

quedescribecmocadacasodeusodenegocioesllevadoacabo
por parte de un conjunto de trabajadores de negocio que utilizan
unconjuntodeentidadesdenegocio.

Notacin y elementos bsicos del

Modelado de Negocio
Los elementos bsicos que estn presentes en el Modelado de Negocio
son:
ActordeNegocio(usuariosdelnegocio)
CasodeUsodeNegocio(procesosdelnegocio)
TrabajadordeNegocio(engeneral:rolesquejueganlaspersonas
enunaorganizacin)

12

 Entidad de Negocio (las cosas que un negocio administra,

producey/outiliza)

Actor De Negocio: Representa un rol en relacin al negocio,

desempeado por algo o alguien en el entorno del negocio. Un
actor normalmente corresponde a un ser humano pero hay
circunstanciasenqueunsistemadeinformacinjuegaelroldeun
actor.
Simbologa:

CasoDeUsoDeNegocio:Esunasecuenciadeaccionesquerealiza
unnegocioparaproducirunresultadoobservabledevalorparaun
actorindividualdelNegocio.Loscasosdeusodenegociocapturay
modelanlosprocesosdenegocio.

Simbologa:

TrabajadorDeNegocio:Representaunroloconjuntoderolesenel
negocio. Un trabajador de negocio interacta con otros
trabajadoresymanipulaentidadesdenegociomientrasparticipaen
lasrealizacionesdeloscasosdeusodenegocio.Puederepresentar:
Una abstraccin de un humano que acta dentro del
negocio.
Una abstraccin del sistema de software que modelamos
como trabajador automatizado cuando el Actor en vez de
comunicarse con un trabajador de negocio humano accede
directamentealsistema.

13

Simbologa:

Entidad De Negocio: Representa una abstraccin de algo que los

trabajadores de negocio toman, inspeccionan, producen o utilizan
cuandoejecutanuncasodeusodenegocio.Puederepresentar:
a)Undocumento
b)Unaparteesencialdeunproducto
c) Algo menos tangible como el conocimiento o
informacin acerca de un cliente, proveedor,
artculosyotrasabstraccionesclave.(*1)

Cuandoelobjetivoderealizarunmodelodenegocioesfundamentalmente
derivar el sistema de informacin de soporte nos concentraremos en
modelar entidades de negocio del tipo c) y dejaremos de lado las que
representan cosas ms bien fsicas. De esta manera las entidades de
negocioseutilizanpararepresentarlosmismostiposdeconceptosquelas
clasesdeldominio(quepodemosmodelarmedianteundiagramadeclases
comoyasevioenlaUnidad1)
Simbologa:

14

EjemplodeModelodeCasosdeUsodeNegocio

EjemplosdeModelodeObjetosdelNegocio

a)Diagramadecolaboracindenegocio:
Muestraunarealizacindecasodeusodelnegocio.

Ejemplo de diagrama de colaboracin de negocio para el caso de uso de

negocioAtenderCompradediscografa

15

b)Diagramadeentidadesdenegocio:
Esundiagramadeclasesquemodelalasentidadesdenegocio.

Enestediagramapuedenbosquejarselosatributosyresponsabilidadesde
lasentidadesdenegociocomoclasesdelDominiodeProblema.

c)Diagramadetrabajadoresdenegocio:
Es un diagrama de clases que modela los trabajadores de negocio,
indicandosusatributosyresponsabilidades.

16

Derivacin del sistema de informacin

a partir del sistema de negocio
Un buen entendimiento de los procesos de negocio es importante para
poder construir el sistema de soporte correcto. Es en la vista interna del
negocio,capturadaporelmodelodeobjetos,quesepuedeverlaconexin
msestrechaconrespectoacmodeberanverselosmodelosdelsistema
deinformacin.

Losmodelosdenegociopodranservircomoentradaalavistadecasosde
uso y a la vista lgica. (Recordar vistas de la arquitectura con UML que
tratamosenlaUnidad2).

Modelo de Negocio y Modelo de casos

de uso del sistema de informacin.
Lasreglasqueenunciamosacontinuacinnosservirnparapoderderivar
losactoresycasosdeusodelsistemadeinformacinapartirdelModelo
deNegociorealizado.
1.ParacadaTrabajadordelNegociosedeberdeterminarsivaautilizarel
sistemadeinformacin.Silarespuestaess,entonces:
a)Seidentificarunactordelsistemadeinformacinconelmismonombre
delactordenegocio.

17

b) Analizar sus responsabilidades: determinar cules implican el uso del

sistema de informacin e identificar un caso de uso del sistema por cada
unadeellas

2. Si en el modelo de negocio tenemos Trabajadores de Negocio

automatizados,entonces:
a)Elactordenegociopasaraseractordelsistemadeinformacin.

b)Lasresponsabilidadesdeltrabajadordenegocioautomatizadopasarna
sercasosdeusodelsistemadeinformacin.

18

Modelo de Negocio y clases del

Modelo de dominio y Modelo de
anlisis.
Las reglas que enunciamos a continuacin nos servirn para poder
encontrar clases del Modelo de Dominio y del Modelo de Anlisis del
sistemadeinformacinapartirdelasentidadesdenegocio.
1. Para cada Entidad de Negocio determinar si va a ser soportada por el
sistemadeinformacin.Enestecaso:
a)SeidentificarunaclasedelModelodeObjetosdelDominiode
ProblemaconelmismonombrequelaentidaddeNegocio
b)SeidentificarunaclasedeentidaddelModelodeAnlisis.
2. Las relaciones entre Entidad de Negocio que sern soportadas por el
sistemadeinformacinpasarnaserrelacionesentreclasesdelDominio
deProblemaydelModelodeAnlisis.

Modelo de Dominio
Otro de los elementos tiles a la hora de comprender el contexto del
sistema, adems del Modelo de Negocio, es contar con un modelo de
dominio.
El Modelo de Dominio (tambin llamado Modelo de Objetos del Dominio
de Problema y frecuentemente encontrado por las siglas MODP) captura

19

los tipos de objetos ms importantes en el contexto del sistema. Los

objetos del dominio representan las cosas que existen o los eventos
quesucedenenelentornoenelquesedesenvuelveelsistema.
Muchos de las clases del dominio del problema, pueden deducirse de la
especificacin de requisitos o mediante la entrevista con los expertos del
dominio,odelModelodeObjetosdelNegocio(entidadesdenegocio)sise
cuentacondichomodelo.Lasclasesdeldominioaparecencomo:

Entidadesdelnegocioquerepresentancosasquesemanipulanen
elnegociocomopedidos,cuentas,contratos.

Entidades del mundo real y conceptos de los que el sistema debe

hacerunseguimiento,comoartculos,vehculos.

Sucesosqueocurrirnohanocurrido,comolapartiday/ollegada
deunavin,unsiniestroenunacompaadeseguros.

El principal diagrama UML para describir el dominio es el Diagrama de

clases.

Utilidaddelmodelodedominio
El modelado del dominio debe contribuir a la comprensin del problema
quesesuponequeelsistemaresuelve.Paradesarrollarestemodelodebe
conformarse un equipo en el que estn presentes tanto los expertos del
dominio(usuarios)comogenteconexperienciaenmodelado,coordinado
porlosanalistasdeldominio.
El modelo de dominio ayuda a los usuarios, clientes, desarrolladores y
otros participantes del proyecto a utilizar un vocabulario comn. La
terminologa comn es necesaria para compartir el conocimiento con los
otros.
Lasclasesdeldominioqueaquseencuentrenseutilizarnaldescribirlos
casosdeusoydisearelprototipodeinterfazdeusuario(dentrodelflujo
de trabajo de Requisitos) y para sugerir clases internas al sistema en
desarrolloduranteelAnlisis.

20

Diagrama de Clases del dominio de

problema
Como ya vimos en la Unidad 1, un diagrama de clases (en UML) es un
diagrama que muestra un conjunto de clases, interfaces, sus
colaboracionesyrelaciones.
Seutilizanparamodelarlavistadediseoestticadeunsistema.ConUML
los diagramas de clases se emplean para visualizar el aspecto esttico de
los bloques de construccin bsicos del sistema y sus relaciones, y para
especificarlosdetallesparaconstruirlos.
Los componentes y simbologa del diagrama de clases se trataron en la
Unidad1.

Pautasparasuconstruccin
Seenumeranacontinuacinalgunaspautas,enformadeconsejosaseguir
cuandoseestconfeccionandoundiagramadeclases:

Debe comunicar un aspecto de la vista de diseo esttica de un

sistema.

Debecontenersloloselementosesencialesparacomprenderese
aspecto.

Debe proporcionar detalles en forma consistente con el nivel de

abstraccin, mostrando slo aquellos adornos que sean esenciales
endichonivel.

Sedebendistribuirsuselementosdemododeminimizarloscruces
delneas.

Organizar los elementos de modo que los que sean

semnticamentecercanosloestntambinfsicamente.

Usar notas y colores sobre aspectos importantes que se quieran

destacar.

SemuestraacontinuacinelModelodeObjetosdelDominiodeProblema
de una empresa de venta de discografa, que se est utilizando para
diversosejemplos.

21

22

3.3- Captura de
requerimientos
Siguiendoconelprocesodecapturaderequerimientos,habiendorealizado
ya la enumeracin de requisitos candidatos y obtenido una comprensin
delcontextodelsistema(medianteunmodelodenegocioy/ounmodelo
dedominio),continuamosconlaidentificacinderequisitosfuncionalesy
nofuncionales,principalmentemediantelatcnicadecasosdeuso.

Encontrar requisitos funcionales

Latcnicaespecficaparaidentificarlosrequisitosfuncionalesdelsistema
sebasaenloscasosdeuso.Loscasosdeusocapturantantolosrequisitos
funcionalescomolosnofuncionales,especficosdecadacasodeuso.
Cadausuarioquierequeelsistemahagaalgoparal,esdecirquetendr
distintosmodosdeutilizarelsistema.Cadaunadeestasformasdeutilizar
el sistema es un caso de uso. Entonces si se pueden describir todos los
casosdeusoquenecesitaelusuario,sepodrsaberloquedebehacerel
sistema.

Encontrar requisitos no funcionales

Los requisitos no funcionales especifican propiedades del sistema como
restricciones del entorno o de la implementacin, dependencias de la
plataforma, consideraciones de rendimiento, seguridad, flexibilidad,
facilidaddemantenimiento,entreotras.
Algunosrequisitosnofuncionalessernaplicablesatodosloscasosdeuso
engeneralyalgunospuedenserespecficosparauncasodeusoosloun
nmerodeterminadodeellos.
Porejemplo,elrequisitonofuncional:Lasfacturasgeneradaseimpresas
debencumplimentartodaslasreglamentacionesdefinasatalefectoporla
AFIPylaLeydeFacturacinvigente,afectarnicamentealcasodeuso
Generar facturacin, en cambio el siguiente requisito no funcional: El
sistemadeberfuncionalenunentornoderedcontemplandounmximo

23

de40puestosdetrabajosimultneos,esunrequerimientoqueafectaen
generalatodosloscasosdeusoyaningunoenparticular.

3.4- El modelo de caso

de uso.
Los casos de uso proporcionan un medio intuitivo y sistemtico para
capturar los requisitos funcionales poniendo nfasis en el valor agregado
paracadausuarioindividualoparacadasistemaexterno.Lautilizacinde
los casos de uso hace que los analistas deben pensar en trminos de
quinessonlosusuariosyqunecesitaduobjetivosdelaempresapueden
cumplir.
Elprincipalesfuerzodelaetapaderequisitosesdesarrollarunmodelodel
sistema que se va a construir y la utilizacin de los casos de uso es una
forma adecuada para ello, debido a que los requisitos funcionales se
estructuran naturalmente mediante los casos de uso y los requisitos no
funcionalessuelenserespecficosdeuncasodeusoypuedentratarseen
esecontexto.

Flujo de trabajo del modelado de

casos de uso
Dentro del PUD (Proceso Unificado de Desarrollo), el primer flujo de
trabajoeselderequisitos.Parapresentaresteflujodetrabajo,aligualque
se ir haciendo con los restantes en las siguientes unidades,
mencionaremos los artefactos que se crean en este flujo de trabajo, los
trabajadoresparticipantesylasactividadesarealizar:

Artefactos: Los artefactos fundamentales que se utilizan en la

capturaderequisitosson:
9 ModelodeCasosdeUso,queincluyeloscasosdeusoylos
actores.
9 Descripcindelaarquitectura

24

9 Glosario
9 Prototipodelainterfazdelusuario

Trabajadores:Lostrabajadoresresponsablesporlosartefactosque
seproducenenelmodeladodecasosdeusoson:
9 AnalistadeSistemas.
9 Especificadordecasosdeuso.
9 Diseadordeinterfazdeusuario.
9 Arquitecto.

Actividades: Las actividades a realizar por los trabajadores para

producirlosdistintosartefactosson:
9 Encontraractoresycasosdeuso.
9 Priorizarcasosdeuso.
9 Detallarloscasosdeuso.
9 Prototiparlainterfazdelusuario.
9 Estructurarelmodelodecasosdeuso.

Elsiguientegrficomuestralosartefactosdelmodeladodecasosdeusoy
lostrabajadoresresponsablesdecadauno:

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftware,IvarJacobsonyotros,
(2000),Pg.127

25

Lasiguientefiguramuestraungrficoqueindicaelflujodetrabajoparala
actividadderequisitosenelPUD,incluyendolostrabajadoresparticipantes
ysusactividades:

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftwareIvarJacobsonyotros,
(2000)Pg.136

Acontinuacinserealizarunadescripcindecadaunodelosartefactos,
poniendo nfasis en los principales y luego se describirn las actividades
comprendidasenesteFlujodeTrabajodeRequisitos.

Artefactos del Flujo de Trabajo de

Requisitos
ModelodeCasosdeUso
El modelo de casos de uso permite que los desarrolladores y los clientes
lleguen a un acuerdo sobre los requisitos, es decir, sobre lo que debe

26

cumplir el sistema y constituye la entrada principal para el anlisis, el

diseoylaspruebas.
El modelo de casos de uso es un modelo que contiene actores, casos de
usoylasrelacionesentrestos.Sielmodelodecasosdeusoesgrande,es
decir, si el nmero de ellos es elevado es til introducir paquetes en el
modeloparatratarsutamao.Unpaquetereunirciertonmerodecasos
de uso agrupados por algn criterio de homogeneidad (los que
correspondenaunmismoactor,losqueserefierenaunmismoproceso,
sonlosprincipalescriterios).

Actor
Unactoreselrolquejuegaunusuarioenuncasodeuso.Normalmente,
un actor representa un rol que es representado por una persona, un
dispositivo de hardware o incluso otro sistema al interactuar con nuestro
sistema.
Elmodelodecasosdeusodescribeloquehaceelsistemaparacadatipo
deusuario.Cadausuariopuederepresentarseporunoomsactores.Dela
misma forma cada sistema externo que interacta con el sistema en
desarrollopuederepresentarseporunoomsactores.
Cadarol(actor)defineloquehaceuntrabajadordelnegocioenunproceso
concreto.Cadavezqueunusuarioenconcreto(unhumanouotrosistema)
interacta con el sistema, la instancia correspondiente del actor est
desarrollando ese papel. Una instancia de un actor es, por lo tanto, un
usuarioconcretoqueinteractaconelsistema.
Podemosdistinguirlasiguienteclasificacindeactoressegnelobjetivoa
cumplirenrelacinaloscasosdeuso:

Actor Primario: Tiene un objetivo claro que debe ser tenido en

cuentayconcretadoconlaayudadelsistemadeinformacin.

Actor Secundario: Es de quin el sistema necesita ayuda para

cumplirconelobjetivodelactorprimario.

Simbologa:

27

Glosario
Se puede utilizar un glosario para definir trminos comunes importantes
quelosanalistasyotrosdesarrolladoresutilizanaldescribirelsistema.Un
glosario es muy til para lograr consenso en la definicin de distintos
conceptosyparareducirelriesgodeconfusiones.

Descripcindelaarquitectura
Ladescripcindelaarquitecturacontieneunavistadelmodelodecasosde
uso,querepresentaloscasosdeusosignificativos.
La vista de la arquitectura del modelo de casos de uso debera incluir los
casos de uso que describan alguna funcionalidad importante y crtica, o
que impliquen algn requisito importante que deba desarrollarse pronto,
dentrodelciclodevidadelsoftware.
Estavistadelaarquitecturaseutilizacomoentradacuandosepriorizanlos
casosdeusoparasudesarrollodentrodecadaiteracin.

Fuente:LibroElProcesoUnificadodeDesarrollodeSoftwareIvarJacobsonyotros,
2000,Pg.133

28

CasodeUso
Uncasousorepresentacadaformaenquelosactoresusanelsistema.Los
casosdeusosonfragmentosdefuncionalidadqueelsistemaofrecepara
aportarunresultadodevalorparasusactores.Uncasodeusoespecifica
una secuencia de acciones que el sistema puede llevar a cabo
interactuandoconsusactores.
Por lo expresado, un caso de uso es una especificacin. Especifica el
comportamiento de elementos dinmicos, en este caso instancias de
casosdeuso.Unainstanciadeuncasodeusoeslarealizacin(oejecucin)
deuncasodeuso.
Podemosestablecerlacategoradeloscasosdeusocomo:

Esenciales:Describenlafuncionalidadprincipaloesencialquetiene
que cumplir el sistema. Comprenden los principales procesos que
debeejecutarelsistemadeinformacin.

De Soporte: Comprenden la funcionalidad que surge a partir de

analizar aquello que se necesita para que puedan funcionar los
casos de uso esenciales. Tambin aqu se consideran los casos de
uso del usuario, que comprenden la funcionalidad requerida para
administrar los datos de los usuarios del sistema y los permisos
asignadosalosmismos.

Otraformadeclasificarloscasosdeusoeslasiguiente:

Concreto:Selellamaasalcasodeusoqueesiniciadoporunactor
yqueconstituyeunflujodeeventoscompleto.

Abstracto:Eselcasodeusoquenoesiniciadonuncaporunactor,
sinoquenicamenteesinstanciado(iniciado)porotrocasodeuso.
Surgen a partir de relaciones de extensin, inclusin o
generalizacin.

Ladescripcindeuncasodeusopuedeincluir:

Diagramasdeestados:Especificanelciclodevidadelasinstancias
decasosdeuso.

29

Diagramas de actividad: Describe el ciclo de vida con ms detalle

indicando la secuencia temporal de acciones que tienen lugar
dentrodecadatransicin.

Diagramas de colaboraciones y de secuencia: Describen las

interaccionesentreunainstanciatpicadeunactoryunainstancia
tpicadeuncasodeuso.

EldiagramaUMLquemodelaloscasosdeusoeseldiagramadecasosde
uso.

Prototipodeinterfazdelusuario
Los prototipos de interfaz del usuario nos ayudan a comprender y
especificarlasinteraccionesentreactoreshumanosyelsistemadurantela
capturaderequisitos.Noslonosayudaadesarrollarunainterfazgrfica
mejor,sinoacomprendermejorloscasosdeuso.
Paraespecificarlainterfazdeusuariopuedenutilizarsemodelosdeinterfaz
grficayesquemasdepantallas.
El tema de los prototipos de interfaz se ampla en el punto 3.5 de esta
unidad.

Diagrama de Casos de Uso

Los diagramas de casos de uso son importantes para modelar el
comportamientodeunsistemaounsubsistema.Estosdiagramasfacilitan
que los sistemas y subsistemas sean abordables y comprensibles, al
presentarunavistaexternadecmopuedenutilizarseestoselementosen
uncontextodado.
Losdiagramasdecasosdeusocontienen:casosdeuso,actores,relaciones
dedependencia,generalizacinyasociacin.
Los actores se conectan a los casos de uso a travs de asociaciones. Una
asociacinentreunactoryuncasodeusoindicaqueelactoryelcasode
usosecomunicanentresycadaunopuedeenviaryrecibirmensajes.La
relacin de asociacin entre un actor y un caso de uso se grafica para el
caso en que el actor sea el responsable de instanciar (iniciar) el caso de
uso.

30

SimbologadelDiagramadeCasosdeUso
Enlasiguientefigurasemuestranlosdistintoselementosquepuedenestar
presentesenundiagramadecasosdeuso.

Nombredecasodeuso
Cada caso de uso debe tener un nombre que lo distinga de los dems.
Puedeserunnombresimple(unasimplecadenadetexto)ounnombrede
camino(path)enelcasodequeestprecedidoporelnombredelpaquete
enqueestincluidoelcasodeuso.
Losnombresdecasosdeusosonexpresionesverbalesquedescribenalgn
comportamiento del vocabulario del sistema que se est modelando. Se
aconseja que el nombre del caso se uso comience con un verbo en
infinitivo.

Nombredeactor
El nombre del actor debe reflejar el rol que cumple un usuario al
interactuarconelcasodeusoalqueestconectadoynodebereflejaraun
usuarioenparticular.

RelacindeGeneralizacinentreactores
Puedendefinirsecategorasgeneralesdeactoresyespecializarlosatravs
derelacionesdegeneralizacin.Losactoresespecializados(hijos)heredan
elcomportamientodelactorpadre.

31

Siuncasodeusoesinstanciadoporelactorpadrepuedeserinstanciado
porcualquieradesushijos.Ahorabienpodrahabercasosdeusoqueson
instanciadosporunodelosactoreshijoenparticular.

Relacionesentrecasosdeuso
Los casos de uso pueden organizarse especificando relaciones de
generalizacin,inclusinyextensinentreellos.Estasrelacionesseutilizan
para:
Factorizar el comportamiento comn (extrayendo ese
comportamientodeloscasosdeusoenlosqueseincluye)
Factorizarvariantes(poniendoesecomportamientoenotroscasos
deusoqueloextienden).
Simplificar un caso de uso extrayendo una parte compleja y
ubicndolaenotrocasodeuso.

Relacindegeneralizacinentrecasosdeuso
La generalizacin entre casos de uso es como la generalizacin entre
clases. En este contexto significa que el caso de uso hijo hereda el
comportamientodelcasodeusopadre.Elhijopuedemodificary/oagregar
comportamientoalheredado.
La generalizacin se emplea para simplificar la forma de trabajo y la
comprensin del modelo de casos de uso y para reutilizar casos de uso

32

semifabricados. Un caso de uso semifabricado existe solamente para

queotrosloreutilicen.
Grficamenteseindica,aligualquelaherenciaentreclases,conunalnea
continua con punta de flecha vaca dirigida del caso de uso hijo hacia el
padre.
Ejemplos:

Relacindeinclusinentrecasosdeuso
Unarelacindeinclusinentrecasosdeusosignificaqueuncasodeuso
baseincorporaexplcitamenteelcomportamientodeotrocasodeusoen
el lugar especificado en el caso base. El caso de uso incluido nunca es
instanciado por un actor, sino que es instanciado por el/los casos de uso
queloincluyen.Porello,uncasodeusodeinclusinessiempreuncasode
usoabstracto.
Lasecuenciadecomportamientoylosatributosdelcasodeusoincluidose
encapsulan y no pueden modificarse o accederse, solamente puede
utilizarseelresultado (o funcin) del caso de uso incluido. El caso de uso
base llama al caso de uso incluido el cual se ejecuta y luego el control
vuelvealcasodeusobase.

33

Una caracterstica de la relacin de inclusin es que el caso de uso base

siempre deber invocar la ejecucin del caso de uso incluido para
completarconsuobjetivo;esdecir,elcasodeusobasenoestcompleta
sinoseejecutalafuncionalidaddelcasodeusodeinclusin.
La relacin de inclusin se usa para abstraer el comportamiento comn
entrecasosdeuso,evitandodescribirelmismoflujodeeventosrepetidas
veces.Tambinseutilizaparaapartardelcasodeusobaseunaporcinde
funcionalidadcomplejaoquecomplicalacompresindeste.
La inclusin se representa como una dependencia estereotipada con la
palabra include o en forma abreviada inc, dirigida desde el caso de uso
basehaciaelcasodeusoincluido.

Relacindeextensinentrecasosdeuso
Unarelacindeextensinentrecasosdeusosignificaqueuncasodeuso
baseincorporaimplcitamenteelcomportamientodeotrocasodeuso.El
caso de uso base puede ejecutarse aisladamente, pero bajo ciertas
condiciones su funcionalidad ser extendida por la del caso de uso de
extensin.
Laextensinpuedeversecomoqueelcasodeusodeextensinincorpora
su comportamiento enel caso de uso base. Una relacin de extensin se
utiliza paramodelar laparte de un caso de uso que el usuario puede ver
como comportamiento opcional del sistema. De esta forma se separa el
comportamiento opcional del obligatorio. Tambin puede utilizarse para

34

modelar un subflujo separado que slo se ejecuta bajo ciertas

circunstancias.
El hecho de que la llamada al caso de uso de extensin sea opcional se
debeaqueelcasodeusobaseescompletoensmismo,esdecirpuede
cumplir con su objetivo sin necesidad de llamar al caso de uso de
extensin; slo que a veces extender o ampliar su funcionalidad
llamandoalaejecucindelotrocasodeuso.
El caso de uso de extensin puede en algunos casos ser instanciado
directamente por un actor (en este caso se considera un caso de uso
concreto),ademsdeinstanciarseparaextenderelcomportamientodeun
caso de uso base. Si el caso de uso de extensin nunca es instanciado
directamenteporunactor,entoncesesuncasodeusoabstracto.
La extensin se representa como una dependencia estereotipada con la
palabraextendoenformaabreviadaext,dirigidadesdeelcasodeusode
extensinhaciaelcasodeusobase.

ActividadesdelFlujodeTrabajodeRequisitos
Cuando los trabajadores ejecutan las actividades, crean y modifican
artefactos. Describimos un flujo de trabajo como una secuencia de
actividadesqueestnordenadas,demodoqueunaactividadproduceuna
salidaquesirvedeentradaalasiguiente.Apesardeello,enelmundoreal

35

nosiempretrabajamosestrictamenteensecuencia.Sepuedetrabajarpor
mltiplesvasqueproducenunresultadofinalequivalente.
Una actividad puede ser retomada muchas veces (recordemos que
estamosenunprocesodedesarrolloiterativo)ycadaunadestaspuede
acarrear la ejecucin de un solo fragmento de la actividad. Por ejemplo
cuando retomamos la actividad Encontrar actores y casos de uso, el
nuevo resultado puede ser solamente una identificacin adicional de un
casodeuso.
Las distintas actividades en el modelado de casos de uso adoptan
diferentesformasendiferentesfasesdelproyecto.Porejemplo,cuandoun
analistadesistemasejecutalaactividaddeEncontraractoresycasosde
usodurantelafasedeinicio,identificarmuchosactoresycasosdeuso
nuevos.Perocuandolaactividadserealicedurantelafasedeconstruccin,
el analista har principalmente cambios secundarios en el conjunto de
actoresycasosdeuso.
Se describen a continuacin las actividades que se realizan en el flujo de
trabajoderequisitos.

ENCONTRARACTORESYCASOSDEUSO
Laidentificacindeactoresycasosdeusoeslaactividadmsdecisivapara
obteneradecuadamentelosrequisitosyesresponsabilidaddelanalistade
sistemas.
Para realizar esta actividad, si se dispone de un modelo de negocio, se
puedeobtenerunborradordelmodelodecasosdeusoenformabastante
directa.Otrasvecessepuedepartirdelmodelodedominioosimplemente
deunaespecificacindelascaractersticasqueserequierendelsistema.
Estaactividadpuededescomponerseencuatropasos:
1.Encontrarlosactores
2.Encontrarloscasosdeuso
3.Describirbrevementeloscasosdeuso
4.Describirelmodelodecasosdeusocompleto

1.Encontrarlosactores:
Haydoscriteriostilesalahoradeelegirloscandidatosaactores:

36

 Primero debe ser posible identificar al menos un usuario que

puedarepresentaralactorcandidato.
Segundo,debeexistirunacoincidenciamnimaentrelosrolesque
desempean las instancias de los diferentes actores. No debemos
tener dos o ms actores que cumplan los mismos roles. O son el
mismo actor o se realiza una generalizacin abstrayendo el
comportamientocomn.
Para encontrar actores, resulta til preguntarse por ejemplo quin va a
utilizarciertainformacin,quinvaausarunadeterminadafuncionalidad,
quin actualizar algn dato en el sistema, con qu otros sistemas va a
interactuarelsistemaqueestamosmodelando.
Elanalistadesistemasdanombrealosactoresydescribebrevementelos
papeles de cada actor. La descripcin de cada actor debe esbozar sus
necesidadesyresponsabilidades.
2.Encontrarloscasosdeuso:
Elanalistadesistemasidentificarloscasosdeusoatravsdelostalleres
con los clientes y los usuarios. El analista de sistemas va repasando los
actores de a uno y piensa en qu forma pueden utilizar el sistema o qu
necesitandelsistema,proponiendoascasosdeuso,queseconsideranen
primerainstanciacandidatos.Algunosdeloscandidatosnollegarnaser
casosdeusoporsmismos,sinoquesernpartesdeotro.
Comoyamencionamosalhablardelascategorasdecasosdeuso(pgina
21 de esta material), habr casos de uso a los que llamamos esenciales
porque involucran actividades que constituyen el ncleo del negocio y
suelenserlosprimerosenserdescubiertos;yotroscasosdeusoalosque
llamamos secundarios o de soporte, que permiten realizar tareas tales
como: actualizar todas las clases que aparecieron en el dominio del
problema y las que irn apareciendo, ms adelante (en las ltimas
iteraciones) pueden aparecer casos de uso para administrar usuarios,
sesindeusuario,entreotros.
Seeligeunnombreporcadacasodeuso,querepresentelasecuenciade
accionesconcretaqueaadevaloraunactor(producealgodevalorpara
el actor). El nombre del caso de uso comienza con un verbo
(preferentementeeninfinitivo)ydebereflejarelobjetivodelainteraccin
entreelactoryelsistema.
3.Describirbrevementecadacasodeuso:
Amedidaquesevandescubriendoloscasosdeusosesueleirregistrando
algunas palabras explicndolos. Luego se procede a describir ms

37

formalmenteelcasodeuso,enprimerainstanciaconunaspocasfrasesy
msadelanteseharunadescripcindetallada.
4.Describirelmodelodecasosdeusocompleto:
Estatareaconsisteenelaborardiagramasydescripcionesparaexplicarel
modelodecasosdeusoentotalidad.
Nohayunareglaestrictaqueindiquequsedebeincluirenundiagrama
(considerandounsistemamedianamentecomplejoenelquenosepueden
incluirtodosloscasosdeusoensolodiagrama).Podemostenerdiagramas
por cada proceso de negocio, o reunir todos los casos de uso en los que
intervieneunmismoactor.
Elmodelodecasosdeusopuedeorganizarseenconjuntosdecasosdeuso
conformandopaquetesdecasosdeuso.

PRIORIZARCASOSDEUSO
El propsito de esta actividad es determinar cules casos de uso son
necesarios para el desarrollo en las primeras iteraciones y cules pueden
dejarseparamsadelante.
Los resultados de esta actividad conforman la vista de la arquitectura del
modelodecasosdeuso,queesrevisadaporeljefedeproyectoyseutiliza
comobaseparalaplanificacindeunaiteracin.

DETALLARCASOSDEUSO
El objetivo de esta actividad es detallar el flujo de sucesos en detalle,
incluyendocmocomienza,terminaeinteractanconlosactores.
Conelmodelodecasosdeusocomopuntodepartidaelespecificadorde
uncasodeusoindividualpuedecomenzaradescribircadacasodeusoen
detalle,especificandolasecuenciaprecisadeacciones.
Hay varias formas y herramientas con las que se puede realizar la
descripcin de un caso de uso. Independientemente de la forma elegida
para describir el caso de uso, debe verificarse que la descripcin siempre
incluyalosiguiente:
9 Elestadoinicial,comoprecondicin.
9 Cmoycundocomienzaelcasodeuso(esdecir,laprimeraaccin
aejecutar).
9 El orden requerido en el que las acciones de deben ejecutar
(determinadoenformadesecuencianumerada).

38

9
9
9
9

Cmoycundoterminanloscasosdeuso.
Losposiblesestadosfinales,comopostcondiciones.
Loscaminosdeejecucinquenoestnpermitidos.
Lasdescripcionesdecaminosalternativosqueestnincluidosjunto
conladescripcindelcaminobsico.
9 Lasdescripcionesdecaminosalternativosquehansidoextradosde
ladescripcindelcaminobsico.
9 Lainteraccindelsistemaconlosactoresyqucambiosproducen.
9 Lautilizacindeobjetos,valoresyrecursosdelsistema.
9 La descripcin explcita de lo que hace el sistema, separando las
responsabilidadesdelsistemadelasaccionesdelosactores.

Acontinuacindemuestraunaplantillaquecubreestosaspectosyresulta
muy til para realizar una descripcin detallada de un caso de uso,
incluyendolasreferenciasaloscasosdeusoconlosquetienerelaciones
deextensin,inclusin,generalizacin.
Hay diferentes formatos que se pueden utilizar para una plantilla
descriptiva de caso de uso, el siguiente es simplemente una propuesta;
mientras se respeten los tems esenciales que deben incluirse en la
descripcin, tal como se enunciaron en el prrafo anterior, se pueden
agregaroquitarseccionessegnlasnecesidadesopreferenciasdelequipo
deespecificacin.
PlantillaparaladescripcindeCasosdeUso

39

40

Otras herramientas que pueden ayudar a mejorar la comprensin de los

casosdeusoson:

Diagramasdeestado:Paradescribirlosestadosdeloscasosdeuso
ylastransicionesentreesosestados.

Diagramas de actividad: Para describir las transiciones entre

estadosconmsdetallecomosecuenciasdeacciones.

Diagramas de interaccin: Para describir cmo interacta una

instanciadecasodeusoconlainstanciadeunactor.Enestecasoel
diagrama de interaccin muestra slo el caso de uso y el actor o
actoresparticipantes.

PROTOTIPARLAINTERFAZDELUSUARIO
Hasta aqu, se ha desarrollado el modelo de casos de uso que especifica
qu usuarios hay y para qu necesitan usar el sistema. Ahora, hay que
disearlainterfazdeusuarioquelepermitallevaracaboloscasosdeuso
demaneraeficiente.
Secomienzaconloscasosdeuso,intentandodeterminarqusenecesita
delasinterfacesdeusuarioparahabilitarloscasosdeuso.Estoeshacerun
diseo lgico de la interfaz. Luego se realiza un diseo fsico y se
desarrollanprototipos.
Como ya mencionamos anteriormente, el tema de los prototipos de
interfazseamplaenelpunto3.5deestaunidad.

ESTRUCTURARELMODELODECASOSDEUSO
Elmodelodecasosdeusoseestructurapara:

41

Extraer descripciones de funcionalidades generales y compartidas

quepuedenserutilizadaspordescripcionesmsespecficas(casos
deusodeinclusin).

Extraerdescripcionesdefuncionalidadadicionalesuopcionalesque
pueden extender descripciones ms especficas (casos de uso de
extensin).

En esta actividad el analista de sistemas puede reestructurar el conjunto

completo de casos de uso para hacer que el modelo sea ms fcil de
entenderydetrabajarconl.
Elanalistadebebuscarcomportamientoscompartidosyextensiones.Esto
sereflejaenladeterminacinderelacionesdegeneralizacin,inclusiny
extensinentrecasosdeuso.
CuandosetrateltemadeRelacionesentrecasosdeusosepresentaron
variosejemplosdecadauna.Semuestraenlasiguientefiguraunejemplo
deuncasodeusocuyafuncionalidadfueextradadeloscasosdeusobase
yesllamandoporextensinoporinclusinsegnseaelcasodeusobase
llamador.

Ejemplo de diagrama de casos de uso de un Sistema de Comercializacin

deDiscografa,delquesehanidodandoalgunosejemplossueltos.

42

43

3.5- Prototipos de
Interfaz
Concepto y propsito de los prototipos
Unprototipoesunaversininicialdeunsistemadesoftwarequeseutiliza
para demostrar los conceptos, probar opciones de diseo y, en general,
conocermsacercadelproblemayopcionesdesolucin.
TalcomoloplanteaIanSommerville(2002),unprototipodesirvedeapoyo
adosactividadesdentrodelprocesodeingenieraderequerimientos:
1. Obtencin de requerimientos: Los prototipos permiten a los
usuarios experimentar para ver cmo el sistema ayudar a su
trabajo.Lespermiteadquirirnuevasideasparalosrequerimientosy
proponernuevosrequerimientos.
2.Validacinderequerimientos:Unprototipopuederevelarerrores
yomisionesenlosrequerimientospropuestosyespecificados.Con
el uso de prototipos los usuarios a menudo encuentran que su
visininicialfueincorrectaoincompleta,entonceslaespecificacin
del sistema puede modificarse para reflejar el cambio en la
comprensindelosrequerimientos.
Adems de permitir a los usuarios mejorar la especificacin de
requerimientos, el desarrollo de un prototipo del sistema tiene otras
ventajas:

Al demostrar las funciones del sistema se identifican las

discrepanciasentrelosdesarrolladoresylosusuarios.

Durante el desarrollo del prototipo, el personal de

desarrollo puede darse cuenta de que los requerimientos
soninconsistentesy/oestnincompletos.

Aunquelimitado,sedisponerpidamentedeunsistemaque
funciona y demuestra la factibilidad y usabilidad de la
aplicacinaadministrar.

El prototipo de utiliza como base para escribir la

especificacinparalaproduccindeunsistemadecalidad.

44

Por lo general el desarrollo del prototipo conduce a mejorar la

especificacin del sistema, pero una vez que el prototipo est disponible
tambinseutilizaparaotrospropsitos:
1.Capacitaralusuario:Elprototiposepuedeutilizarparcapacitara
losusuariosantesqueelsistemafinalestterminado.
2.Probarelsistema:Losmismoscasosdepruebaseintroducenal
prototipoyalsistemaenprueba.Siambossistemasdanlosmismos
resultados el caso de prueba no detecta una falla. Pero si los
resultadosdifierensignificaqueelsistemafallayhayqueinvestigar
lasrazonesdelasdiferencias.

Construccin de prototipos de interfaz

de usuario
En la actualidad, las interfaces grficas de usuario (GUI por sus siglas en
ingls) se han convertido en las normas para los sistemas interactivos. El
esfuerzocomprendidoenlaespecificacin,eldiseoylaimplementacin
deunainterfazdeusuariorepresentaunapartesignificativadeloscostos
dedesarrollodeunsistema.
Ian Sommerville (2002) nos plantea que los diseadores no deben dar su
opininalosusuariosdeloquedeberaserunainterfazdeusuarioyqueel
usuariodebetenerunaparticipacinactivaeneldiseodelamisma.
Desde el punto de vista de la Ingeniera de software, la construccin de
prototipos es una parte esencial del proceso de diseo de la interfaz de
usuario. La construccin de prototipos evolutivos con la participacin del
usuariofinaleslanicamanerasensibleparadesarrollarinterfacesgrficas
deusuarioparalossistemasdesoftware.
La siguiente figura nos muestra el proceso de diseo de una interfaz de
usuario, tal como lo presenta Ian Sommerville en su libro Ingeniera de
Software(verbibliografa).

45

Fuente:LibroIngenieradeSoftwareIanSommerville,2002,Pg.329.

Ventajas del uso de Interfaz Grfica de

Usuario (GUI)
Aunque las interfaces basadas en texto an se utilizan, especialmente en
los sistemas heredados, los usuarios actuales de sistemas informticos
esperan que las aplicaciones tengan algn tipo de interfaz grfica de
usuario.
Este tipo de interfaces se caracterizan por el uso de los siguientes
elementos:

Ventanas: Las ventanas mltiples permiten que se

despliegue simultneamente informacin diversa en la
pantalladelusuario.

conos: Los conos representan diferentes tipos de

informacin. En algunos sistemas los conos representan
archivosyenotrosrepresentanprocesos.

Mens: Los comandos se seleccionan de un men en lugar

deteclearseenunlenguajederdenes.

Apuntador: Para seleccionar las opciones de un men,

indicar elementos de inters en una ventana o dirigirse a
alguna parte de la ventana se utiliza un dispositivo
apuntadorcomoelmouse(ratn).

46

Grficos: Los elementos grficos se pueden mezclar con

textoenelmismodespliegue.

Entre las ventajas del uso de interfaces grficas de usuario podemos

mencionar:

Sonfcilesdeaprenderyutilizar.

Para interactuar con el sistema los usuarios cuentan con pantalla

mltiples (ventanas) por lo tanto es posible ir de una tarea a otra
sinperderdevistalainformacingeneradadurantelaprimertarea.

Es posible interactuar rpidamente y tener acceso inmediato a

cualquierpuntodelapantalla.

Elementos de una interfaz grfica de

usuario
Los diseadores de interfaces de usuario deben tener en cuenta las
capacidades fsicas y mentales de la gente que utilizar el software. Las
personas olvidan fcilmente y cometen varios errores cuando tienen que
manejar demasiada informacin o estn bajo presin, pero poseen un
ampliorangodecapacidadesfsicas.
Lashabilidadeshumanassonlabaseparalosprincipiosdediseoque se
enuncian a continuacin y que consisten en una serie de principios
generales que se pueden aplicar a todos los diseos de interfaces de
usuario.

Familiaridad del usuario: La interfaz debe utilizar trminos y

conceptos que se toman de la experiencia de las personas que ms
utilizan el sistema. Por ejemplo, si en la organizacin utilizan el
trmino afiliado para referirse a los clientes mantener esta
denominacinenlasinterfaces.

Consistencia:Lainterfazdebeserconsistenteenelsentidodequelas
operaciones comparables se activan de la misma forma. Por ejemplo
todas las ventanas de registro de datos son similares (ventana para
registrarnuevodisco,nuevosello,nuevognero)

Mnima sorpresa: El comportamiento del sistema no debe provocar

sorpresa a los usuarios. Utilizar recursos como mostrar una barra de
avanceparaindicaralusuarioqueelsistemaestprocesandoalgo,por
ejemplo,paraquenopiensequesehaclavadoelsistema.

47

Recuperabilidad: La interfaz debe incluir mecanismos para permitir a

los usuarios recuperarse de los errores, como confirmacin de
acciones destructivas (siempre solicitar confirmacin ante una accin
eliminar), proveer un recurso para deshacer (incluir la opcin
cancelarentodaslasventanas)

Guaalusuario:Cuandoloserroresocurren,lainterfazdebeproveer
retroalimentacin significativa y caractersticas de ayuda sensible al
contexto.Mostrarmensajedeerrorsignificativoparaelusuarioquele
den indicacin sobre cul es el error y cmo subsanarlo o cmo
continuarcorrectamenteconlaaplicacin.

Diversidad de usuarios: La interfaz debe proveer caractersticas de

interaccinapropiadaparalosdiferentestiposdeusuariosdelsistema.
Hay usuarios que tienen buena memoria y son giles con el teclado
numrico de modo que prefieren ingresar por este medio los datos
(como por ejemplo legajos de personal o cdigo de artculos) en vez
que tener que trasladar la mano al mouse para hacer la seleccin
desdeuncomboolista,locualsetraduceenmstiempoempleadoen
la operacin si hay que hacer muchos cambios de movimiento de la
mano (del teclado al mouse y de ste al teclado sucesivamente). De
modoquelainterfazdeberapermitirambostiposdeacciones:ingreso
dedatososeleccindelosmismos.

Interaccin del usuario

Los diseadores de interfaces de usuario deben decidir cmo se va a
introducir la informacin del usuario a la computadora y cmo se
presentaralusuariolainformacindelsistema.
La interaccin del usuario implica emitir comandos y datos asociados al
sistema de software. En las primeras computadoras la nica forma de
hacerestoeraatravsdeunainternadelneadecomandosenlaquese
utilizaba un lenguaje de propsito especfico. Sin embargo este enfoque
slo lo utilizaban los expertos por lo que fueron surgiendo otras
posibilidadesquelesfacilitabanlastareas.
IanSommerville(2002)enellibroquehemosestadomencionando,citaa
Shneiderman,quienclasificlasdiversasformasdeinteraccindelusuario
con la computadora (es decir con la interfaz de usuario) en estos cinco
estilosprimarios:

Manipulacin directa: Cmo arrastrar para mover o eliminar un

archivo. Es una interaccin rpida e intuitiva adems de fcil de

48

aprender pero puede ser difcil de implementar si no hay una

representacinvisualclaraparalastareasyobjetos.

Seleccin de mens: Seleccionar el archivo y luego seleccionar la

accinmoveroeliminardesdeunmen.Evitaerroresdelusuario
y requiere teclear poco, pero puede parecer lenta a usuarios
experimentados.

Llenado de formularios: El usuario llena campos de un formulario

(ventana de carga de datos), puede tener mens asociados, botones,
conos, entre otros elementos grficos. Implica una forma de
introduccin de datos sencilla y fcil de aprender pero ocupa mucho
espacioenpantalla.

Lenguaje de comandos: El usuario indica un comando especial y

parmetros necesarios (DEL nota.txt). Es una forma de interaccin
poderosayflexibleperopuederesultardifcildeaprender.

Lenguaje natural: Emitir un comando en lenguaje natural (borrar el

archivo nota.txt). Resulta accesible a usuarios casuales pero se
requiereteclearmsademsquesedeberadisponerdesistemasde
comprensin de lenguaje natural los cuales no siempre resultan
fiables.

Respectodelaformadepresentacindelainformacinalosusuariosenla
interfaz,podemosmencionarbrevemente.

Presentacin como texto: Utilizada generalmente cuando se

requiere informacin numrica precisa y la informacin cambia
relativamentelento.

Presentacin como grfico: Utilizada generalmente cuando los

datos cambian rpidamente o si las relaciones entre los datos son
significantes(usodegrficosdebarra,curva,torta,porejemplo).

Uso del color en el diseo de la interfaz

de usuario
En general, los sistemas interactivos permiten despliegues a color y los
diseadoresdeinterfacesdeusuarioutilizanelcolordediferentesformas.
Elusodelcolorenlasinterfacespuederesultardeutilidadayudandoalos
usuariosacomprenderymanejarlacomplejidad.Sinembargo,sielcolor

49

es utilizado de manera errnea puede conducir a interfaces poco

atractivas,fatigosasparalavistaypropensasaerrores.
A continuacin se listan algunas recomendaciones respecto del uso del
colorenlasinterfaces:
9 Limitar el nmero de colores utilizados, ser conservador al
momentodeutilizarlos.
9 Utilizaruncambiodecolorparamostraruncambioenelestadodel
sistema (por ejemplo en un listado de pedidos identificarcon azul
loscancelados).
9 Utilizar el cdigo de colores para apoyar la tarea que los usuarios
estn tratando de llevar a cabo (identificar instancias anmalas o
similitudes).
9 Utilizar el cdigo de colores en forma consciente y consistente: Si
enunapartesemuestranmensajesdeerrorencolorrojo,hacerlo
asentodaslasinterfaces.
9 Sercuidadosoalutilizarparesdecolores:Porlafisiologadelojolas
personas no pueden enfocar el rojo y el azul simultneamente. La
vista cansada es consecuencia del despliegue de rojo sobre azul.
Otrascombinacionestambinsonperturbadorasodifcilesdeleer
(comoamarillosobrenegroporejemplo).
9

Soporte al usuario
Lasinterfacesdeusuariosiempredebenproveeralgunaformadesistema
deayudaenlnea,comomencionamosalenunciarlosprincipiosdediseo
deinterfacesdeusuario.
Los sistemas de ayuda en lnea con una faceta de una parte general del
diseodeinterfacesdeusuario.Elsoportealusuariocubretresreas:

Losmensajesproducidosporelsistemaenrespuestaalasacciones
delusuario

Ayudaenlnea

Ladocumentacinsuministradaconelsistema

50

Mensajes de error
Los mensajes de error del sistema son la primera marca que reciben los
usuarios de un sistema de software. Al hacer su trabajo los usuarios
inexpertospuedencometererroresydemanerainmediatadeberapoder
comprenderelmensajedeerrorresultante.
Los mensajes de error deben tomar en cuenta el conocimiento y la
experienciadelosusuarios.Podemostener:

Mensaje orientado al sistema: Como por ejemplo: Error # 32 en

lnea410Esunmensajenegativo,noseajustaalashabilidadesy
niveldeexperienciadelusuario,tampocosugierecmorectificarla
situacin.

Mensaje orientado al usuario: Como por ejemplo Cliente no

registradoutilicelaopcin:RegistrarNuevoCliente.Estetipode
mensajes son los que se deben utilizar. Deben ser amables,
concisos,consistentesyconstructivos.

Diseo del sistema de ayuda

Enelcasoqueelmensajedeerrornoseasuficienteparaelusuario,stese
dirigirinmediatamentealsistemadeayudaenbuscademsinformacin
parasolucionarelinconvenienteodudaqueselepresenta.
Hayalgunosaspectosinteresantesaconsideraralmomentodedisearla
ayudaenlnea:

Niveles de entrada: Los sistema de ayuda proveen varios puntos

diferentesdeentradaalosusuarios.

Navegacin de la ayuda: Los usuarios pueden ingresar al sistema de

ayudaenelpuntodelajerarquacorrespondientealmensajeyluego
navegar por la estructura de red del sistema de ayuda. Puede pasar
que el usuario comience a navegar por la ayuda y al poco tiempo se
encuentreperdido;desplegarlainformacindeayudaenmltiples
ventanaspuedealiviarestasituacin.

Contenido:Eltextodeunsistemadeayudasepreparaconlaayudade
especialistas en la aplicacin. La ayuda en lnea no debe ser
simplemente una reproduccin del manual del usuario ya que las
personas leen en papel y en pantalla en forma diferente. El texto, su

51

exposicinyestilotienenquedisearsecuidadosamenteparapermitir
sudesplieguelegibleenunaventanageneralmentepequea.

Herramientas: Respecto de las herramientas que se pueden utilizar

paraconfeccionarunsistemadeayudaenlneatenemos,
9 Conjunto de pginas vinculadas a Worl Wide Web que sern
accedidasmedianteunnavegador:Sonfcilesdeimplementaryno
necesitan ningn software especial pero pueden ser difciles de
vincularconlasaplicaciones.
9 Sistema de hipertexto integrado con las aplicaciones, utilizando
herramientas como por ejemplo WinHelp que produce ayudas
similares a las que estn ampliamente difundidas en los sistemas
operativosyaplicativoscomerciales.

Documentacin del usuario

La documentacin del usuario no es estrictamente parte del diseo de la
interfaz de usuario, pero es recomendable disear el apoyo de ayuda en
lneajuntoconladocumentacinenpapel.
Losmanualesdelsistemaproveeninformacinmsdetalladadelaayuda
enlneaysediseadetalformaquepuedanserutilizadospordiferentes
tiposdeusuariosdelsistema.
Ian Sommerville (2002) nos recomienda al menos cinco documentos, o
captulosdeunnicodocumento,paraentregarjuntoconelproductode
software:

Descripcin funcional: Describe brevemente los servicios que

proveeelsistema.

Documentodeinstalacin:Proveelosdetallesdecmoinstalarel
sistema,losdiscosqueseentreganconelsistema,losarchivosde
estosdiscosylaconfiguracindehardwaremnimarequeridapara
quefuncionecorrectamenteelsistema.

ManualIntroductorio:Presentaunaintroduccinuntantoinformal
del sistema, describiendo su utilizacin normal. Describe como
iniciar, cerrar sesin de usuarios y cmo utilizar los recursos
comunesdelsistema.

52

Manual de referencia: Describe todos los recursos del sistema;

proveeuna listadelos mensajesdeerror,posiblescausasycmo
recuperarsedelosmismos.

Guadeladministrador:Describelosmensajesquesegeneranpor
lainteraccindelsistemaconotrossistemasycmoreaccionaren
estas situaciones; tambin cuando el problema puede estar
relacionado con algn elemento de hardware, indicando cmo
reconocer y reparar el problema, de ser posible para el usuario.
Estetipodedocumentacinsloestpresenteenalgunostiposde
sistemas, los que incluyen saturaciones como las que se
describieron.

Evaluacin de la interfaz
La evaluacin de la interfaz es el proceso de valorar la forma en que es
utilizadaunainterfazyverificarquecumplesusrequerimientos.
Idealmente, una evaluacin se compara con la especificacin de la
usabilidadquesebasaenlossiguientesatributos:

Aprendizaje: Se evala cunto tiempo tarda un usuario nuevo en

serproductivoconelsistema.

Velocidad de operacin: Se considera qu tan bien responde el

sistemaalasoperacionesdetrabajodelusuario.

Robustez:Seevalaqutantoleranteeselsistemaaloserroresdel
usuario.

Recuperacin:Seobservaqutanbienserecuperaelusuariodelos
erroresdelusuario.

Adaptacin: Se evala qu tan atado est el sistema a un solo

modelodetrabajo.

Para realizar la evaluacin de la interfaz de usuario se pueden aplicar

lassiguientestcnicas:

Cuestionarios,querecolectanlaopinindelosusuariosacercadela
interfaz.

Observacindelosusuariosalmomentodetrabajarconelsistema.

Videosdesesionesdeusuario.

53

Cdigo incluido en el software que recolecte informacin sobre

erroresmscomunesyrecursosmsutilizados.

Elementos de una interfaz grfica de

usuario
Se muestran a continuacin algunos elementos que estn presentes en
todainterfazgrficadeusuario.

54

55

Bibliografa

Booch Grady, Rumbaugh James, Jacobson Ivar, El lenguaje de Modelado

Unificado,Espaa,EditorialAddisonWesleyIberoamericana,(1999).
Captulos:16y17

Bramble Paul, artculo Introduction to Patterns for Writing Effective Use

Cases.

Braude Eric, (2003), Ingeniera de Sofware, una perspectiva orientada a

objetos,AlfaomegaGrupoEditorSA.
Captulo3

Davis Alan, artculo del autor extrado de Software Requeriments: Anlisis

andSpecification,PrenticeHall,(1990).

English, Arthur V., Senior Learning and Development Consultant, Unisys

Corporation. Business modeling with UML: Understanding the similarities
and differences between business use cases and system use cases. The
RationalEdge,artculodeAbril2007.

Jacobson Ivar, Booch Grady, Rumbaugh James, El Proceso Unificado de

DesarrollodeSoftware,Espaa,EditorialAddisonWesley,(2000).
Captulos:6y7

Jacobson Ivar, The Object Advantage. Business Process Reengineering with

ObjectTechnology,EditorialAddisonWesley,(1995).

PleegerShari,IngenieradeSoftware.TeorayPrctica,PrenticeHall
Captulo4

PressmanRoger,IngenieradeSoftware.Unenfoqueprctico6ta.edicin,
Ed.McGrawHill,(2006).
Captulos8y15

Sommerville Ian, Ingeniera de Sofware (2002), Ed. Pearson Educacin,

Mxico,(2002).
Captulos:5,6,8y15

www.uesiglo21.edu.ar

56