Stakeholders, actores y modelado de casos de uso

Ttulo: Stakeholders y Actores Versin: 1.02 - 16/11/2004 0:2! ".#.
Asunto: $se %ase #odelin& %'tedra: (ntroduccin a la "r'ctica "ro)esional

Autores: "i**arulli - "orta - +i,ani
"'&ina 1 de 2!
%:-$sers-#aria .lena-/eskto,-,u0lica$"S1i0ra-Tra0a2o-)acultad-si-0i0lio&ra)ia 2012-Stakeholders3y3Actores.doc 1echa de i4,resin 24/10/2005
20:1! 610/,10
Resumen:
Use Case Modeling
Kart Bittner Ian Spence
ndice
............................................................................................................................................................................................... 1
RESUMEN: ................................................................................................................................................................................ 1
NDICE ...................................................................................................................................................................................... 2
QU SON LOS STAKEHOLDERS? .................................................................................................................................. 4
IDENTIFICANDO LOS TIPOS DE STAKEHOLDERS. ................................................................................................................................... 5
IDENTIFICANDO LOS REPRESENTANTES DE LOS STAKEHOLDERS Y LOS ROLES DE LOS STAKEHOLDERS. ............................................................ 6
EL ROL DE LOS STAKEHOLDERS Y LOS STAKEHOLDERS REPRESENTANTES. ............................................................................................... 6
USUARIOS: UNA CLASE MUY IMPORTANTE DE STAKEHOLDERS. ............................................................................................................... 8
STAKEHOLDERS Y EL MODELADO DE CASOS DE USO. ......................................................................................................................... 9
INVOLUCRE A LOS STAKEHOLDERS Y USUARIOS EN SU PROYECTO. ........................................................................................................ 10
"aso 1: (denti)icar a los Stakeholders y a los ti,os de usuarios: .......................................................................................................... 10
TIPO DE INFORMACIN DEL STAKEHOLDER. ..................................................................................................................................... 10
"aso 2: (denti)icar y reclutar a los stakeholders re,resentantes. .......................................................................................................... 11
INFORMACIN DEL ROL DEL STAKEHOLDER. ..................................................................................................................................... 11
"aso 5: (n7olucrar a los Stakeholders re,resentantes en el "royecto. ................................................................................................. 12
CREAR UNA VISIN COMPARTIDA. ............................................................................................................................... 12
ANALIAR EL PRO!LEMA. .............................................................................................................................................. 1"
ENTENDER EL STAKEHOLDER CLAVE Y LAS NECESIDADES DEL USUARIO. ................................................................................................ 14
DESCRI!IR LAS CARACTER#STICAS Y LOS OTROS REQUERIMIENTOS DE ALTO NIVEL DEL PRODUCTO. ............................................................... 15
MS SORE LAS CARACTERSTICAS. ............................................................................................................................................... 16
DOCUMENTAR LAS CARACTERSTICAS. ........................................................................................................................................... 1!
OTROS RE"UERIMIENTOS DEL PRODUCTO. ..................................................................................................................................... 1!
RESTRICCIONES ........................................................................................................................................................................ 18
RE"UERIMIENTOS OPERATIVOS .................................................................................................................................................... 19
PROVEER UNA VISTA DEL PRODUCTO. ............................................................................................................................................. 19
DECLARACIN DEL POSICIONAMIENTO DEL PRODUCTO. ...................................................................................................................... 19
COMPLETANDO LA VISTA $ENERAL DEL PRODUCTO. ........................................................................................................................ 2%
DOCUMENTO DE VISIN. ............................................................................................................................................................. 21
"'&ina 2 de 2!
20:1! 610/,10
ENCONTRAR LOS ACTORES. ......................................................................................................................................... 21
COMENAR POR IDENTIFICAR LOS ACTORES PRIMARIOS. .................................................................................................................... 22
TRA!A&AR DESDE LO ESPEC#FICO A LO $ENERAL .............................................................................................................................. 22
NO OLVIDAR A LOS ACTORES DE SOPORTE. ................................................................................................................................... 22
CONSIDERAR TODA LA INFORMACIN DE REQUERIMIENTOS E'ISTENTES ................................................................................................... 2"
RECORDAR( LOS ACTORES NO SIEMPRE SON PERSONAS. .................................................................................................................... 2"
ENFOCARSE EN EL L#MITE DEL SISTEMA. ......................................................................................................................................... 24
IDENTIFICAR LAS FUENTES DE INFORMACIN ..................................................................................................................................... 24
NO ANTICIPARSE AL DISE)O. ........................................................................................................................................................ 25
NO CONFUNDIR LOS ACTORES CON LOS DISPOSITIVOS QUE ELLOS USAN. ................................................................................................. 25
CUANDO NO PUEDA ENCONTRAR LOS ACTORES* COMIENE CON LOS CASOS DE USO .................................................................................. 25
ENFOCARSE PRIMERO EN LO FAMILIAR. ........................................................................................................................................... 26
EVOLUCIONAR EL CON&UNTO DE ACTORES A LO LAR$O DEL CON&UNTO DE CASOS DE USO .......................................................................... 26
DOCUMENTAR LOS ACTORES. ....................................................................................................................................................... 26
CMO DARLE UN NOMRE A LOS ACTORES. ..................................................................................................................................... 26
NO CONFUNDIR ACTORES CON ROLES OR#ANI$ACIONALES O CAR#OS LAORALES. ..................................................................................... 2!
NO SORE #ENERALI$AR. ............................................................................................................................................................ 2!
DAR A CADA ACTOR UNA DESCRIPCIN REVE. ................................................................................................................................. 28
CARACTERI$AR LOS ACTORES. ..................................................................................................................................................... 28
HACER UN SE#UIMIENTO DESDE LOS ACTORES A LOS TIPOS DE USUARIO% STAKEHOLDERS Y ROLES DE STAKEHOLDER. ....................................... 29
"'&ina 5 de 2!
20:1! 610/,10
Qu son los stakeolders!
Un stakeholder es:
Un individuo que es afectado materialmente por los resultados finales del sistema o el o los
proyectos que estn construyendo el sistema.
Usando esta definicin algunos stakeholders me llegan a la mente:
Los usuarios del sistema. Si estos no se ven afectados materialmente por el resultado final
del sistema, no lo usarn y el sistema en si mismo ser un fracaso.
El equipo de desarrollo. Si esta gente no se ve afectada materialmente por el resultado
final de su proyecto y el sistema que produce, hay proalemente algo fuera de lugar con
estructura de recompensas.
El con!unto completo de stakeholders ser en realidad ms grande que este.
La decisin de desarrollar un sistema a menudo afectar a una gran cantidad de gente. "or
e!emplo, la decisin de invertir en un sistema nuevo involucra a los inversores en s# mismos en el
$%ito del sistema& la decisin del equipo de desarrollo de usar un soft'are de terceros en su
solucin involucrar a los proveedores como stakeholders adicionales. (unque estas personas
podr#an no estar directamente afectadas por el prolema original, son afectadas por el resultado
final del proyecto. La figura siguiente, resume la relacin entre los stakeholders y el prolema y su
solucin.
"'&ina 4 de 2!
20:1! 610/,10
")*+LE,
(
")*+LE,
(
/o4inio del
"ro0le4a
/o4inio de la
Solucin
"roducto a %onstruir
Stakeholders
S+,-./
0.1
A,.23405
6 75-
Identificando los tipos de Stakeholders.
El primer paso para entender la comunidad de stakeholders es identificar los tipos de stakeholders
afectados por el sistema.
"ipo de Stakeolder: -lasificacin de un con!unto de stakeholders que comparten las mismas
caracter#sticas y relaciones con el sistema y.o el proyecto que produce al sistema.
Los Stakeholders generalmente caen dentro de las siguientes categor#as:
Usuarios: los ms ovios tipos de stakeholders son los usuarios actuales de un sistema.
Estos son las personas que estarn tomando los roles definidos por los actores en el
modelo de casos de uso. /ver 0. de -. 12
Sponsors: 3erentes de 0egocio, financistas, l#deres de departamentos, vendedores,
accionistas, y otras personas que invierten en la produccin del sistema. Estos
stakeholders son slo usuarios indirectos del sistema o ien estn afectados solamente por
las salidas de negocio que el sistema induce.
4esarrolladores: 3erentes de proyecto, 5esters, empleados de soporte, de mantenimiento
del sistema, dise6adores, codificadores, y cualquier otro tipo de desarrollador involucrado
en la produccin y soporte del sistema.
(utoridades: E%pertos en un aspecto en particular del dominio del prolema o la solucin.
"ueden ser autoridades legislativas, e%pertos en el dominio, e%pertos en tecnolog#a, etc.
-lientes: La gente y.o las organi7aciones quienes estarn en realidad adquiriendo el
sistema final. Estos pueden ser los compradores, evaluadores, contadores, y agentes
actuando a favor de las organi7aciones de compra.
La lista real de tipos de stakeholders para un proyecto ser ms concreta que esta, identificar
tipos de usuarios, agencias y unidades organi7acionales. La clave es asegurar que todos aquellos
que se ven afectados por la salida del sistema est$n considerados.
#ota de la C$tedra %: Esta frase es vlida a!o la visin estricta de )U" de actor como usuario del sistema.
0o ser#a del todo cierta para una visin de -ockurn donde un actor puede ser un ente e%terno due6o de
una meta.
"'&ina 8 de 2!
20:1! 610/,10
Identificando los Representantes de los Stakeholders y los roles de los
stakeholders.
El pr%imo paso es definir un con!unto de roles de stakeholders dentro del proyecto que permite
que las vistas de todos los tipos de stakeholders sean representados. El o!etivo es reclutar un
con!unto de stakeholders representantes para que est$n directamente involucrados en el proyecto.
Stakeolder representante: un miemro de la comunidad de stakeholders directamente
involucrado en la conduccin, formacin, y el alcance del proyecto. Un stakeholder
representante representa uno o ms tipos de stakeholders.
Rol del Stakeolder: -lasificacin de un con!unto de stakeholders representantes que
comparten los mismos roles y responsailidades con respecto al proyecto.
La definicin de roles del stakeholder permite a los stakeholders representantes entender el
compromiso que estn teniendo con el proyecto, las responsailidades que se estn tomando, el
nivel de involucramiento que estarn oligados a proveer, y a quienes ellos estn representando.
-uando se identifican los roles de los stakeholders, se est interesado en entender como ellos
interact8an con el proyecto tanto como con cual sucon!unto de tipos de stakeholders
representan. Es importante asegurarse que cada tipo de stakeholder sea representado y que su
representacin sea al nivel que refle!e tanto la importancia de los stakeholders para el proyecto
como las capacidades, y el eneficio, de los representantes.
En la mayor#a de los proyectos el t$rmino stakeholder se usa para indicar el con!unto de
stakeholders representantes directamente involucrados con el proyecto.
&l rol de los Stakeolders ' los Stakeolders representantes(
Los stakeholders y stakeholders representantes son los due6os del prolema y son afectados por
la solucin propuesta. Son tami$n la fuente principal de los requerimientos. La figura 9 ilustra
esta relacin. -omo el prolema en s# mismo es claramente intangile, son los stakeholders
representantes los que hacen de puente entre el prolema y la especificacin de la solucin
propuesta. La documentacin de los requerimientos en s# es una articulacin formal de las metas
de los stakeholders y act8a como sustituta durante el proyecto cuando los stakeholders
representantes no est$n disponiles. La figura : resume las relaciones entre los stakeholders, el
sistema y la documentacin de los requerimientos.
Los stakeholders representantes actuarn como fuente principal de la informacin de los
requerimientos, deen estar directamente involucrados en el proyecto y tener un claro
entendimiento del rol que se espera que interpreten.
"'&ina 6 de 2!
20:1! 610/,10
El rol del stakeholder representante incluye /pero no se limita2 a lo siguiente:
)epresentacin fiel de las visiones y necesidades de la seccin de la amplia comunidad de
stakeholders que represente.
5omar un rol activo en el proyecto.
"articipar en las revisiones de los requerimientos y otras revisiones del proyecto.
(sistir a 'orkshops y reuniones.
;acer investigaciones independientes.
4efender el proyecto para los stakeholders que representan.
Figura 2
Los stakeholders son la principal fuente de requerimientos.
Figura 3
Los requerimientos actan como la representacin de las metas de los stakeholders.
"'&ina de 2!
20:1! 610/,10
P-8/28741 ,+./3. 0.
S349.:510.-6
0
E
-
E
S
<
4
(
4
E
S

N.2.68040.6
C4-423.-;638246
R.<+.-8=8./356 0.
S5,3>4-.
9----------
9------------
9------------
9-----------
S349.:510.-6
S863.=4 4
C5/63-+8-
V.-8,82428?/ 0. 156
-.<+.-8=8./356
L4 =.34
S+6383+8- 14
=.34
R.<+.-8=8./356
5odos y cada uno de los proyectos requieren enfocarse en el involucramiento del stakeholder.
"ara todos los proyectos:
El involucramiento activo del stakeholder es imperativo.
Un acercamiento colaorador y cooperativo involucrando a todos los stakeholders es
esencial.
)ecordar: los stakeholders son los due6os del prolema y son la fuente de los requerimientos del
proyecto. Si el sistema no es un $%ito con los stakeholders, entonces no es un $%ito, punto.
Usuarios: Una clase mu' importante de Stakeolders(
(hora vamos a enfocarnos en un tipo importante de stakeholders: los usuarios del sistema. Los
usuarios interpretarn la mayor#a de los roles definidos por los actores del sistema, y sus
requerimientos ayudarn a dar forma al modelo de casos de uso. -ada usuario es un stakeholder,
porque estar afectado materialmente por el resultado final del sistema, pero no todos los
stakeholders son necesariamente usuarios.
Los actores definen roles, considerando que el mismo usuario podr#a interpretar varios roles.
"ipo de Usuario: -lasificacin de un con!unto de usuarios con con!untos similares de
hailidades y otras caracter#sticas, los cuales comparten los mismos roles y
responsailidades dentro del amiente del sistema.
5ipo de usuario es una definicin refinada de un tipo en particular de stakeholder. 5ener un perfil
completo de cada tipo de usuario es esencial para poder entender sus con!untos de hailidades,
actitudes, idioma, y otras caracter#sticas. -uando se trata con los conceptos ms astractos de
actores, es muy fcil olvidar que los usuarios reales podr#an tener variados niveles de hailidades
y capacidades.
-uando se definen los roles de los stakeholders, se deer#a tener en cuenta el grado de
involucramiento que deer#a tener el usuario para las necesidades del proyecto, la disponiilidad
de los usuarios para el proyecto, y el nivel de compromiso que los usuarios deer#an tener hacia el
proyecto.
En la mayor#a de los casos, ser imposile involucrar a todos los usuarios. Lo que es esencial es
que el con!unto de stakeholders representantes incluya a usuarios representativos y que para
cada tipo de usuario haya una representacin claramente definida. Los usuarios deen entender
como estn representados en el proyecto, y los usuarios representativos deen entender cuales
son sus responsailidades hacia los usuarios que representan.
"'&ina : de 2!
20:1! 610/,10
Stakeolders ' el Modelado de Casos de Uso(
Entender los stakeholders y sus necesidades particulares es esencial para el desarrollo de un
modelo efectivo de casos de uso. En muchos casos, el sistema tiene metas indirectas /o
secundarias2 que no estn relacionadas directamente a la satisfaccin de las necesidades de los
actores /y por implicancia, los usuarios2. *tros stakeholders, podr#an tener un inter$s investido en
la salida de un caso de uso en particular. ( menudo, este es el caso cuando el mane!o de reportes
dee ser generado o el mane!o de la informacin capturada pero ninguno de los gerentes est
involucrado directamente en el caso de uso. =>-ules son las metas del actor? >4nde est el
valor para el actor?@ preguntan los modeladores de casos de uso.
El con!unto de stakeholders que suministran los requerimientos para el caso de uso no est
restringido a aquellos quienes representan a los usuarios involucrados en el caso de uso /esto es,
interpretan el rol especificado por el actor2. Si se quiere conocer la cantidad de mane!o de
informacin que dee ser capturada, se deer#a halar con los gerentes que estarn usando la
informacin y no con los operadores quienes producirn los reportes. Entender estas relaciones
indirectas puede ser de gran ayuda cuando se mira el modelo de casos de usos, porque las metas
de la amplia comunidad de stakeholders a menudo pueden ser contrarias a aquellas del actor
involucrado.
La siguiente figura ilustra la relacin entre los stakeholders representantes, los actores y casos de
uso.

Si no se involucra a los stakeholders representantes correctos en la creacin y validacin del
modelo de casos de uso, entonces el modelo en si ser inservile. <dentificar e involucrar al
con!unto correcto de stakeholders representantes es la ase esencial de cualquier actividad de
modelado de casos de uso e%itosa.
"'&ina ! de 2!
20:1! 610/,10
A235-
C465 0. U65
S349.:510.-6
+e,resentan a los usuarios
;uienes inter,retan el rol de
Su4inistran los detalles y
los ,re,arati7os ,ara
In)olucre a los Stakeolders ' Usuarios en su pro'ecto(
Los siguientes pasos pueden aplicarse iterativamente para estalecer un nivel apropiado de
involucramiento de los stakeholders en sus actividades de modelado de casos de uso.
Paso 1: Identificar a los Stakeholders y a los tipos de usuarios:
-omo el n8mero actual de stakeholders puede ser enorme, se deer#a identificar primero los
distintos tipos de stakeholders que deen involucrarse en el proyecto.
Un uen comien7o es preguntarle a: tomadores de decisiones, usuarios potenciales, y otras partes
interesadas las siguientes preguntas:
>Aui$n se ver afectado por el $%ito o fracaso de la solucin nueva?
>Aui$nes son los usuarios del sistema?
>Aui$n es el comprador del sistema?
>Aui$n es el sponsor del desarrollo?
>Aui$nes se vern ms afectados por el resultado final que produce el sistema?
>Aui$n evaluar y firmar la aproacin del sistema cuando se entregue y se despliegue?
>;ay otros usuarios internos o e%ternos del sistema cuyas necesidades deen tomarse en cuenta?
>;ay cuerpos regulatorios o estndares organi7acionales los cuales el sistema deer oedecer?
>Aui$n desarrollar el sistema?
>Aui$n instalar y mantendr el nuevo sistema?
>Aui$n tendr actividades de soporte y suministrar entrenamiento para el nuevo sistema?
>Aui$n testear y certificar el nuevo sistema?
>Aui$n vender y pondr en el mercado al nuevo sistema?
>;ay alguien ms?
"ipo de In*ormaci+n del Stakeolder(
-uando se definen tipos de stakeholders, dee asegurarse de capturar la siguiente informacin:
#om,re: nomre del tipo de stakeholder.
-escripci+n ,re)e: descriir revemente lo que el tipo de stakeholder representa con
respecto al sistema o al proyecto. En general, los usuarios tienen el rol de uno o ms
actores del sistema.
Stakeolder representante: )esumir como los stakeholders sern representados dentro
del proyecto. En general se hace para referenciar el rol o roles aplicales a los
stakeholders representantes.
"or cada tipo de stakeholder que son tami$n tipos de usuarios, vale la pena capturar la siguiente
informacin:
"'&ina 10 de 2!
20:1! 610/,10
Caracter.sticas: Los tipos de usuarios pueden ser caracteri7ados en t$rminos de su
amiente f#sico, amiente social, n8meros, y otras caracter#sticas generales tales como
se%o, edad y medio cultural.
Competencias: 4escrie las hailidades que los usuarios necesitan para llevar a cao sus
traa!os, tanto como cualquier otra informacin relevante acerca del tipo de usuario que no
se mencione en otro lado. Esto puede incluir su nivel de conocimiento del dominio,
calificaciones en el negocio, nivel de e%periencia computacional, y otras aplicaciones que
ellos usan.
Paso 2: Identificar y reclutar a los stakeholders representantes.
4espu$s de que los stakeholders del proyecto hayan sido identificados, es hora de comen7ar a
reclutar a los stakeholders representantes que participarn activamente en el proyecto. 4e
particular inter$s son aquellos que estn involucrados directamente con las actividades de
modelado de casos de uso. "rimero har que definir e%actamente cuales sern sus roles y
responsailidades hacia el proyecto tanto como a que parte de la comunidad de stakeholders
representarn.
In*ormaci+n del rol del Stakeolder(
-uando se definan los roles del stakeholder dee asegurarse de capturar la siguiente informacin:
#om,re: nomre del rol del stakeholder.
-escripci+n ,re)e: -escri,ir revemente el rol del stakeholder y lo que representa con
respecto al desarrollo del proyecto. t#picamente, el rol es para representar uno o ms
stakeholder o tipos de usuarios, algunos aspectos del desarrollo de la organi7acin, o
ciertos tipos de clientes o algunas otras reas afectadas por el negocio.
Responsa,ilidades: resumir las responsailidades claves del rol con respecto al proyecto
y al sistema que se est desarrollando. -apturar el valor que el rol estar agregando al
equipo del proyecto. "or e!emplo, las responsailidades podr#an incluir aseguramiento que
el sistema ser mantenile, aseguramiento que har demanda de mercado para las
caracter#sticas del producto, monitorear el progreso del proyecto, y as# continua.
Compromiso: 4escriir revemente como ellos estarn involucrados. "or e!emplo, un
usuario permanente ema!ador deer comprometerse con el modelado de casos de uso y
otras actividades de requerimientos, atender a talleres de requerimientos durante la fase
de incepcin /inicio2, y servir como un miemro del comit$ de control de camios.
Las siguientes preguntas pueden ser de ayuda para definir los roles del stakeholder.
>Est cada tipo de stakeholder representado?
>Est cada unidad de negocio y departamento afectado representado?
>Aui$n evaluar y firmar la especificacin de requerimientos?
"'&ina 11 de 2!
20:1! 610/,10
>Aui$n atender el modelado de casos de uso y otros talleres de requerimientos?
>Aui$n proveer el conocimiento del dominio requerido para desarrollar una solucin e%itosa?
>Aui$n estar involucrado en alguna investigacin de mercado comprometi$ndose a !ustificar y
validar el producto?
>Au$ tipos de stakeholder son los ms importantes?
>-ul es el lanco /target2 de la audiencia para la presentacin del producto a!o desarrollo?
Paso 3: Involucrar a los Stakeholders representantes en el Proyecto.
Barias t$cnicas pueden usarse para involucrar a los stakeholders representantes en el proyecto.
Entre ellas estn las siguientes:
Entrevistas: estn entre las t$cnicas ms 8tiles para involucrar a los stakeholders en el
proyecto. Si se tiene un uen entendimiento del rol del stakeholder, se puede mantener a
la entrevista enfocada sore los puntos a mane!ar.
-uestionarios: son una t$cnica muy 8til, particularmente cuando un gran n8mero de
stakeholders representantes estn involucrados. Los cuestionarios tienen que ser
dise6ados, y la audiencia =seleccionada@, con un gran cuidado.
3rupos de foco: un grupo de foco le permite proar sore un con!unto de stakeholders
representantes para otener sus perspectivas de lo que el sistema tiene que hacer. Los
grupos de foco tienden a ser usados para recolectar la retroalimentacin espec#fica sore
tpicos espec#ficos.
-omit$s de consultar#as: un comit$ de consultor#a es una clase de grupo de foco
permanente. "rovee una forma de recolectar las perspectivas de los stakeholders sin los
gastos de estalecer un grupo de foco. La desventa!a comparado con un grupo de foco es
que la composicin del comit$ de consultor#a no puede ser camiado de acuerdo al tpico.
5alleres: los talleres pueden ser una muy 8til manera de capturar requerimientos, armar los
equipos de desarrollo, y desarrollar su entendimiento del sistema. 4eer#an ser ien
planeados con una agenda definida que se env#a a los participantes de antemano con
alg8n material de lectura de respaldo.
)evisiones: las revisiones son reuniones formales o informales organi7adas con la
intencin espec#fica de revisar algo, ya sea un documento o un prototipo.
Cuego de )oles: esta es una t$cnica de facilitacin que se usa t#picamente en con!unto con
los talleres para otener informacin espec#fica o retroalimentacin.
Crear una )isi+n compartida(
4espu$s de que el con!unto inicial de stakeholders ha sido reunido para traa!ar sore el proyecto,
lo primero que hay que hacer es crear una visin del sistema que todos ellos puedan compartir.
"'&ina 12 de 2!
20:1! 610/,10
"ara ser efectiva, esta visin dee proveer un entendimiento compartido del prolema a ser
resuelto y que unifique las distintas perspectivas de los stakeholders.
/nali0ar el 1ro,lema(
En muchos casos, camiar la percepcin de los clientes sore lo que ellos tienen ahora o camiar
su percepcin sore lo que ellos desean es suficiente para resolver el prolema. Si no e%iste
diferencia entre lo que se percie que tiene y lo que se quiere tener, entonces no se tiene un
prolema.
La me!or forma de capturar el prolema es construir una declaracin del prolema. Esto es una
s#ntesis de solucinDneutral del entendimiento compartido de los stakeholders del prolema a ser
resuelto. <ncluye una evaluacin del impacto del prolema y los eneficios que se otendrn por
su solucin. "uede capturarse usando una plantilla simple como se muestra en la tala 1.
La elle7a de la declaracin del prolema es su capacidad para representar la punta de la
pirmide de requerimientos mientras resume de forma simple y sucintamente el prolema a ser
resuelto, como se ilustra en la figura E.
Entender el prolema es el primer paso para entender los requerimientos. Los stakeholders a
menudo descrien el prolema en t$rminos de sus propias necesidades, pero cada necesidad
deer#a refle!ar un aspecto del mismo prolema fundamental.
"a,la %( "lantilla de declaracin del prolema.
El prolema de Fdescriir el prolemaG
(fecta Flos stakeholders afectados por el prolemaG
El impacto es F>-ul es el impacto del prolema?G
Una solucin e%itosa ser#a
Flistar algunos eneficios claves de una solucin
e%itosaG
"'&ina 15 de 2!
20:1! 610/,10

N.2.68040.6
C4-423.-;638246
/eclaracin
del ,ro0le4a
S8/3.38@4
"ro0le4a
"ro0le4a
/o4inio del
"ro0le4a
/o4inio de la
Solucin
"roducto a ser construido
1i&ura 8.
<a declaracin del
,ro0le4a re,resenta
la ,unta de la
,ir'4ide de
re;ueri4ientos.
La tala 9 muestra un e!emplo de una declaracin del prolema para un sistema de soporte de
clientes. 0otar que en la declaracin del prolema, el su!eto es el stakeholder, =yo necesito queH@
en los requerimientos correspondientes, el su!eto es el sistema, =El sistema proveeH@ La meta de
anali7ar este prolema es asegurarse que todas las partes involucradas est$n de acuerdo sore
cual es el prolema a ser resuelto.
"a,la2(
El prolema de )esolucin inoportuna e impropia de los
servicios de salida del cliente
(fecta 0uestros -lientes, )epresentantes de Soporte al
-liente, y al Servicio 5$cnico.
El impacto es <nsatisfaccin en los clientes, falta de calidad
perciida, empleados infelices, p$rdidas en las
rentas.
Una solucin e%itosa ser#a "roveerle a los )epresentantes de Soporte
acceso en tiempo real a la ase de datos de
prolemas y soluciones y facilitar el env#o del
Servicio 5$cnico, en tiempo y forma, slo para
aquellas uicaciones que genuinamente
necesitan su asistencia.
Entender el Stakeholder clave y las necesidades del usuario.
4efiniremos la necesidad de un stakeholder como:
Un refle!o del prolema /u oportunidad2 del negocio, personal u operacional que dee ser
encarado para !ustificar la consideracin, compra, o el uso de un nuevo sistema.
La figura I usa la pirmide de requerimientos para ilustrar la relacin entre las necesidades y la
declaracin del prolema. -apturar las necesidades de los stakeholders nos permite entender
cmo y hasta que punto los diferentes aspectos del prolema afectan a los diferentes tipos de
stakeholders.
"'&ina 14 de 2!
20:1! 610/,10
"ro0le4a
"ro0le4a
/o4inio del
"ro0le4a
/o4inio de la
Solucin
R.,1.A4/

N.2.68040.6
C4-423.-;638246
La descripcin de cada necesidad del stakeholder deer#a incluir las ra7ones detrs de la
necesidad e indicar claramente por qu$ es importante para los stakeholders afectados.
"ara cada necesidad del stakeholder tami$n es 8til entender:
La importancia relativa que los stakeholders y los usuarios le dan a la satisfaccin de cada
necesidad.
-ules stakeholders percien la necesidad.
-mo este aspecto del prolema es actualmente tratado. Estalecer la actual situacin del
negocio. Especificando el estado actual ser capa7 de entender me!or el impacto de los
casos de uso que escria.
-ules soluciones les gustar#a ver a los stakeholders. Especificar la situacin deseada del
negocio.
-mo ser medido el $%ito. 5odos los requerimientos deer#an tener un criterio de
medicin de $%ito. Si no se puede medir el $%ito entonces nunca ser capa7 de determinar
si se ha alcan7ado el estado deseado. -uando se camia algo tan grande como un
negocio, podr#a ser que el criterio de $%ito no pueda ser medile por alg8n tiempo.
"or e!emplo, el con!unto de necesidades para un sistema telefnico simple incluir#a:
Jcil de usar: el sistema deer ser fcil de usar para tanto los amantes de tecnolog#a como para los que le
tienen foia hailitando a todos los usuarios para usar de manera simple y efica7 tanto las caracter#sticas
Standard como avan7adas del sistema.
"roveer <nformacin de estado actuali7ado: el sistema deer proveer informacin en tiempo real a todos los
usuarios relacionada con la duracin y costo de las llamadas.
E%tensile: el sistema deer ser e%tensile, permitiendo la introduccin de nuevos servicios y facilidades sin
interrumpir el nivel de servicio suministrado al cliente.
Describir las caractersticas y los otros re!ueri"ientos de alto nivel del
producto.
"ara complementar el modelo de casos de uso y proveer una vista de alto nivel del sistema, es
muy 8til crear una vista de requerimientos de alto nivel del producto a ser construido. Esta vista es
provista por el con!unto de caracter#sticas del producto, y cuando se requiera, otras definiciones de
requerimientos de alto nivel.
"'&ina 18 de 2!
20:1! 610/,10
M$s so,re las caracter.sticas(
Las caracter#sticas son las capacidades de alto nivel /servicios o cualidades2 del sistema que son
necesarias para entregar eneficios a los usuarios y que ayudan a cumplir las necesidades de los
stakeholders y usuarios. El con!unto de caracter#sticas provee una s#ntesis de los eneficios
anunciados del producto que ser construido. La figura K muestra la relacin entre las
necesidades, las caracter#sticas y el sistema a construirse.
Las caracter#sticas pueden ser funcionales o no funcionales.
El prolema con la definicin de las caracter#sticas es que ellas a menudo estn desparramados
=por todo el mapa@& no tienen una definicin precisa y no pueden ser usadas para conducir
realmente el desarrollo o el test del sistema. (unque generalmente, no hay un nivel definido de
astraccin al cual una caracter#stica dee a!ustarse. Slo representan alg8n rea de
funcionalidad del sistema que, en ese momento, es importante para los usuarios del sistema.
"orque representan las cosas que son importantes para ese momento, siempre har que hacer
una lista de caracter#sticas para cada versin y estas listas de caracter#sticas sern diferentes
cada ve7.
Jigura K
4e esta forma se complementa el modelo de casos de uso, el cual, en t$rminos del con!unto de
casos de uso, presenta una vista de la funcionalidad completa del sistema y a menudo no muestra
los camios entre versiones.
La naturale7a inmediata e informal de las caracter#sticas las hace una herramienta muy poderosa
cuando se traa!a con stakeholders y clientes en la definicin de lo que quieren de una versin del
sistema.
Las caracter#sticas proveen la ase fundamental para la definicin del producto y el mane!o del
alcance. La cominacin de caracter#sticas y casos de uso proveen un mecanismo poderoso para
"'&ina 16 de 2!
20:1! 610/,10
"ro0le4a
"ro0le4a
/o4inio del
"ro0le4a
/o4inio de la
Solucin
S8/3.38@4

N.2.68040.6
C4-423.-;638246
L1.B4/
4 24C5
el mane!o del alcance del sistema, manteniendo a todos los stakeholders involucrados e
informados acerca del progreso del sistema y asegurando que se produce una especificacin de
requerimientos completa en una forma fcilmente accesile y mane!ale. <ndividualmente, ni las
caracter#sticas ni los casos de uso proveen tal solucin mane!ale o completa.
-ocumentar las Caracter.sticas(
-uando se documentan:
<ncluir una descripcin de funcionalidad y cualquier punto relevante de usailidad que dee
ser tenido en cuenta.
Evitar el dise6o. ,antener las descripciones de caracter#sticas en un nivel general.
Enfocarse en las capacidades requeridas y en el por qu$ /y no el cmo2 deer#an
implementarse.
(signar a cada caracter#stica un 8nico identificador para la referencia y el rastreo fcil.
(dems de la funcionalidad al sistema, tami$n considerar cualidades no funcionales requeridas
del sistema, tal como performance, usailidad, rouste7, tolerancia de errores, escalailidad,
instalacin, licencias y documentacin /manuales de usuario, ayuda online, etiquetas y paquetes2.
La siguiente tala nos muestra la priori7acin de algunas caracter#sticas para un sistema
telefnico simple.
identi*icador -escripci+n 1rioridad
JE(51
El sistema permitir a la persona que llama
reali7ar las llamadas locales.
0ecesario
JE(59
El sistema permitir a la persona que llama
reali7ar las llamadas larga distancia.
0ecesario
JE(5:
El sistema seleccionar la ruta ms arata
para todas las llamadas larga distancia
4eseale
JE(5L
El sistema proveer continuamente un
historial actuali7ado de llamadas de todas
las cuentas.
0ecesario
JE(5E
El sistema est continuamente disponile
las 9L horas en el d#a, todos los d#as.
4eseale
3tros Re4uerimientos del 1roducto(
Estos incluyen cualquier restriccin que afecta el desarrollo del producto y cualquier requerimiento
que el producto demande de su amiente operativo. Estos otros requerimientos del producto
deer#an ser documentados separadamente de las caracter#sticas e identificados claramente
como restricciones o requerimientos operacionales para evitar que miemros del equipo de se
confundan con los requerimientos reales del producto.
"'&ina 1 de 2!
20:1! 610/,10
Restricciones
0o importa cuan independiente de la tecnolog#a sean la recoleccin de requerimientos y los
procesos de desarrollo de soft'are, algunas restricciones inevitalemente afectarn la solucin
posile. ,uchas clases de restricciones pueden ser impuestas sore un proyecto. Entre estas se
incluyen:
-e #egocio ' &con+micas( -ostos y precios, disponiilidad, marketing, y n8meros de
licencias.
-e am,iente( Estndares e%ternos y regulaciones que son impuestas sore el proyecto a
desarrollar.
"cnicas( Las tecnolog#as que el proyecto est for7ado a adoptar o los procesos que el
proyecto tiene que seguir /tal como, se requiere que el sistema sea desarrollado en C9EE2.
-e Sistema( -ompatiilidad con sistemas e%istentes y amientes operativos.
-e calendario ' de recursos( Jechas en las que el proyecto fue comprometido o las
limitaciones de recursos que el proyecto dee usar.
Los stakeholders pueden imponer restricciones por una variedad de ra7ones:
"ol#ticas: restricciones que pueden ser impuestas al proyecto por las relaciones entre los
stakeholders en ve7 de fuer7as t$cnicas o de negocio formando el proyecto.
0ormas *rgani7acionales: las pol#ticas organi7acionales pueden ser impuestas en lugar de
restricciones sore la manera en la que el producto puede ser desarrollado. Una empresa
pude tener hecha una pol#tica de decisin para moverse hacia t$cnicas espec#ficas,
mitolog#as, estndares, o lengua!es.
4irectivas Estrat$gicas: las directivas estrat$gicas pueden estar en lugar de restricciones al
proyecto para usar tecnolog#as espec#ficas y proveedores.
-ultura *rgani7acional: la cultura de la organi7acin puede en s# misma restringir el
proyecto limitando la manera en la que el proyecto dee resolver el prolema. /;ay un
l#mite para la cantidad de camios que la gente puede hacer frente a la misma ve7, y esto
podr#a evitar que un proyecto adopte su tecnolog#a y m$todos preferidos2.
La mayor#a de las restricciones son restricciones de dise6o de a!o nivel que surgen de las
decisiones de los dise6adores sore la tecnolog#a y m$todo.
Las restricciones pueden limitar su hailidad de proveer una solucin e%itosa.
"'&ina 1: de 2!
20:1! 610/,10
Re4uerimientos 3perati)os
En algunos casos el producto a producir termina en requerimientos que son impuestos al amiente
operativo en el cual se desarrollar. Estos no son requerimientos para ser llevados a cao por la
solucin, sino requerimientos que deen cumplirse en el amiente operativo si la solucin se
desarrolla e%itosamente. Estos requerimientos podr#an incluir:
)equerimientos del Sistema. -ualquier requerimiento del sistema necesario para soportar
la aplicacin. Sistema operativo, plataforma de red, memoria, etc.
)equerimientos del (miente *perativos. "ara los sistemas asados en hard'are, entre
estos puntos pueden estar la temperatura, humedad, radiacin, etc. "ara las aplicaciones
soft'are, factores amientales que pueden ser, condiciones de uso, amiente del usuario,
mane!os de error y recuperacin, etc.
1ro)eer una )ista del producto(
Las caracter#sticas y los otros requerimientos del producto no son suficientes para proveer una
vista completa de alto nivel del sistema. 5ami$n se necesitar documentar los eneficios, las
dependencias, las suposiciones /incluyendo las interfaces de otras aplicaciones y las
configuraciones del sistema2, y las alternativas para el desarrollo del producto.
-eclaraci+n del 1osicionamiento del 1roducto(
La plantilla que se muestra a continuacin puede usarse para e%presar la declaracin del
posicionamiento del producto, un elemento clave de la visin. Este formato le recuerda a la gente
las cosas que deen ser consideradas cuando se estalece la visin para el com8n entendimiento
"'&ina 1! de 2!
20:1! 610/,10
I=75/./
9----------
9------------
9------------
9-----------
.l "royecto
+estricciones
Stakeholders
R.63-8/D./ 14 18C.-340
0.1
L8=834/ 146 7568C818040.6
74-4
de alto nivel de lo que hace el sistema. -ualquiera relacionado con el proyecto deer#a ser capa7
de descriir revemente lo que hace el sistema en t$rminos simples.
"lantilla de 4eclaracin del "osicionamiento del producto.
Para /cliente apuntado2
Quin /declaracin de la necesidad u oportunidad2
El /nomre del producto2 es un /categor#a del producto2
Que
/declaracin del eneficio clave, lo cual es, la ra7n
irresistile para la compra2
lternati!a /principal alternativa competitiva2
"uestro producto /declaracin del la principal diferenciacin2
E!emplo:
4eclaracin del "osicionamiento del producto para una ,quina de -a!ero (utomtico /(5,2
Para -lientes actuales de cuenta de ahorro.
Quin
)equieren acceso instantneo al detalle de sus cuentas
y a los fondos que ellas contienen.
El Super /"M es un ca!ero automtico.
Que
"rovee la hailidad de e!ecutar transacciones ancarias
simples /tales como deposito de fondos o,
transferencias de fondos entre cuentas, o retiro de
fondos2
lternati!a
(cceder a los fondos y a los detalles sore el
mostrador de la sucursal.
"uestro producto
Esta disponile las 9L horas y no requiere asistencia de
un ca!ero ancario.
#o"pletando la $ista %eneral del Producto.
"ara proveer una vista completa del producto, se puede necesitar sinteti7ar otros aspectos del
producto no capturados directamente por los requerimientos de alto nivel. 5#picamente vale la
pena que se documente:
S#ntesis de las capacidades, las que el sistema ofrece a sus usuarios. "resentando una
reve vista del modelo de casos de uso sinteti7ar la funcionalidad ofrecida por el sistema.
+eneficios para los clientes, sinteti7ar los eneficios que el producto ofrece a sus clientes y
cuales caracter#sticas proveen los eneficios. Esto podr#a representarse con una tala
relacionando las necesidades de los stakeholders con respecto a las caracter#sticas.
Suposiciones y dependencias, listar cualquier suposicin que ha sido hecha y si cami
como afectar a la visin estalecida para el sistema. Listar cualquier dependencia que el
producto tenga con otros productos.
(lternativas y -ompetencia, listar cualquier alternativa que los stakeholders consideren
como disponile, incluyendo una descripcin de sus puntos fuertes y d$iles, para permitir
comparar con la solucin que se est proponiendo.
"'&ina 20 de 2!
20:1! 610/,10
Docu"ento de $isi&n.
El propsito del documento de visin es capturar el foco, las necesidades del stakeholder, las
metas y o!etivos, los mercados a los que apunta, los amientes de los usuarios, las plataformas
apuntadas, y las caracter#sticas del producto a construirse. -omunica los =Au$s y "or qu$s@
fundamentales relacionados al proyecto.
"rovee:
Una ase de alto nivel /a veces contractual2 para los requerimientos t$cnicos ms
detallados.
<ngresa al proceso de aproacin del proyecto /y as# es relacionado inmediatamente con el
caso de negocio2
Un veh#culo para la e%traccin inicial de la retroalimentacin con el cliente.
Un punto para estalecer el alcance y prioridad de las caracter#sticas del producto.
-omo el documento de visin se usa y se revisa por una amplia variedad de personal involucrado,
el nivel de detalle deer ser astante general para todos para entenderlo. Sin emargo, suficiente
detalle dee estar disponile para proveer al equipo la informacin necesaria para crear un
modelo de casos de uso y especificaciones suplementarias.
El documento dee contener las siguientes secciones:
"osicionamiento.
o La oportunidad del negocio.
o La declaracin del prolema.
o ,ercados demogrficos.
o (miente de los usuarios.
Stakeholders y Usuarios.
Stakeholder clave y necesidades del usuario.
Bista 3eneral del producto.
-aracter#sticas.
*tros requerimientos del producto.
&ncontrar los /ctores(
Los actores ms fciles de encontrar son aquellos que representan personas, porque en las
etapas tempranas es casi imposile confundir una persona con un sistema. "ara encontrar los
actores para el sistema, comen7ar por mirar a la gente que usar el sistema y luego generalice
para identificar los roles que interpretan. Estos son los actores.
"'&ina 21 de 2!
20:1! 610/,10
#o"en'ar por identificar los (ctores Pri"arios.
-omience por pensar en los usuarios que realmente usarn el sistema M el sucon!unto de los
usuarios para quienes el sistema provee valor.
El primer paso es definir los roles que estos usuarios adoptarn con respecto al sistema M estos
roles relacionados al sistema se modelan como actores. "ara cada tipo de usuario identificado,
asegurarse que haya por lo menos un actor definido para contemplar sus necesidades del
sistema. Los actores que representan los roles adoptados por los usuarios claves son los actores
primarios.
)ecordar que los tipos de usuarios se definen por sus competencias y capacidades, mientras que
los actores se definen por sus metas y relaciones con el sistema.
)raba*ar desde lo especfico a lo +eneral
5raa!ar desde lo espec#fico a lo general es siempre ms fcil. -uando se identifica unas pocas
personas quienes interpretan el mismo rol de actor, el actor es casi siempre ovio& si se traa!a de
la otra forma sore esto es casi siempre ms dif#cil.
Una ve7 que ha identificado un actor, dee darle un nomre. Un uen punto de comien7o para
esto es identificar el rol que el usuario interpreta mientras interact8a con el sistema& encontrar un
nomre de traa!o aceptale y refinarlo ms tarde si es necesario.
,o olvidar a los (ctores de Soporte.
Los actores primarios son los actores para quien el sistema se construye& son los actores para
quien el sistema provee suficiente valor econmico garanti7ando su construccin. Es tanto
necesario como correcto que deamos concentrar nuestro esfuer7o principalmente en estos
actores y en los usuarios que tomarn estos roles. ;ay, sin emargo, en general, otros con!untos
de actores esenciales para la operacin e%itosa del sistema que a menudo son olvidados. Estos
son los actores que soportan a los casos de uso que provee el sistema y aquellos que soportan al
sistema en s# mismo.
-asi cada caso de uso requiere que se le provea informacin, o tomar decisiones, por otro actor
adems del que inici el caso de uso. ,ientras el alcance del caso de uso comien7a a aparecer,
otros actores de soporte a menudo sern requeridos por el sistema para llegar a alcan7ar su meta
y entregar valor al actor que lo inici.
-uando se est identificando actores, dee asegurarse de que los requerimientos relacionados a
actividades de soporte del sistema y sus casos de uso se representen de alguna forma por los
actores.
"'&ina 22 de 2!
20:1! 610/,10
#onsiderar toda la infor"aci&n de re!ueri"ientos e-istentes
-uando se encuentran los actores las siguientes relaciones deer#an ser consideradas:
"ipos de Usuario /ctores: >;ay actores definidos para curir todos los tipos
identificados de usuarios?
Stakeolders /ctores: >;ay suficientes actores para representar las interacciones
requeridas por todos los stakeholders?
Roles de Stakeolders /ctores: >sae cul stakeholder representante estar validando
las decisiones hechas acerca de cada definicin de actor?
5ami$n deer#a considerar el impacto de las caracter#sticas definidas y las restricciones
revisando nuevamente las caracter#sticas y considerando quien est interesado en ciertos
requerimientos o rea de funcionalidad. "reguntndose, =>Aui$n est interesado en esta
capacidad?@, podr#a encontrar actores adicionales o posiles stakeholders.
Recordar: los actores no sie"pre son personas.
(lguna gente asume que los casos de uso son una t$cnica para descriir interacciones humanoD
mquina, y al hacer eso se pierden uno de los grandes eneficios de usar casos de uso. 4e
hecho, podr#an estar perdi$ndose el propsito ms importante de los casos de uso.
Un actor representa cualquier cosa que est$ fuera del sistema que intercamia informacin con el
sistema. Esto ciertamente incluye gente, y para muchos sistemas, las personas son los usuarios
e%ternos ms importantes del sistema. "ero para muchos otros sistemas, los actores son
principalmente otros sistemas, dispositivos, o sensores.
"'&ina 25 de 2!
20:1! 610/,10
E!emplo:
-onsidere un simple sistema de deteccin de incendio que monitorea una serie de
sensores de deteccin de incendio uscando se6ales de fuego, y cuando se detecta
suena una alarma, enciende un con!unto de regaderas, y notifica al departamento
local de omeros. <dentificar el caso de uso principal, #etectar $ncendio, es astante
fcil, pero sin usuarios humanos los actores son dif#ciles de determinar. -on un poco
de anlisis se identifican los siguientes actores: el control de regaderas% el detector de
incendio, y el departamento de &om&eros.
Enfocarse en el l"ite del Siste"a.
-onsidere que hay actores de otros sistemas que estn for7ndolo a enfrentar el l#mite del sistema
que estas creando. >Au$ es lo que hace su sistema, y donde este termina? Si considera
solamente a los actores humanos, a menudo terminar#a con un sistema que incluya otros sistemas
DD y esto realmente hace que sea dif#cil de imaginar lo que su sistema se supone que haga.
)epresentar a los otros sistemas como actores nos ayuda a definir lo que el sistema har y lo que
no M el l#mite del sistema. Si se da cuenta que alg8n otro sistema hace algo, ese sistema es un
actor de su sistema& si otro sistema solicita informacin de su sistema, es tami$n un actor de su
sistema. 5ratar todo lo e%terior a su sistema como un actor simplifica su prolema M slo necesita
enfocarse en lo que su sistema dee hacer por sus actores.
Identificar las fuentes de infor"aci&n
-uando se considere el l#mite del sistema, hay que enfocarse donde el sistema otendr la
informacin y los recursos que requiere para alcan7ar sus metas. Entender el intercamio de
informacin entre los actores y el sistema es fundamental para determinar efectivamente el l#mite
del sistema. El sistema depende del comportamiento de los actores tanto como de los datos que
ellos pueden proveer.
Una forma fcil de determinar si el comportamiento esta dentro o fuera del sistema es considerar
la uicacin de la informacin solicitada para soportar el comportamiento. >5iene el sistema la
informacin que requiere para mane!ar algunos eventos que se genera por uno de sus actores? Si
la respuesta es no, generalmente alg8n actor dee proveerla /qui7s a8n no identificado2. Balorar
la informacin que se necesita del sistema a menudo puede hacer que se descuran actores que
ser#an de otra manera irreconociles.
"'&ina 24 de 2!
20:1! 610/,10
,o anticiparse al dise.o.
(lgunas veces es dif#cil decir si otro sistema es en realidad un actor o slo parte del desarrollo del
sistema. ( menudo, nos topamos con sistemas que podr#an ser tratados como actores o como
dispositivos. La eleccin de cmo representarlo depende de un par de factores. Si el sistema se
requiere para comunicarse con alg8n otro sistema, y la comunicacin es algo que afecta al flu!o de
eventos, entonces el sistema es un actor. Si la comunicacin con el otro sistema es simplemente
un medio por el cual el dise6ador provee la funcionalidad solicitada, y el dise6ador puede elegir
como, cuando, o si el otro sistema se usa, entonces el otro sistema no es un actor y deer#a ser
omitido del modelo de casos de uso.
Una forma de descurir este prolema es preguntndose: =>tengo el control sore el
comportamiento del otro sistema?@ si no es as#, es t#picamente porque el otro sistema se
desarroll y mane! por otro grupo y esta totalmente separado de nuestro sistema. Una regla de
pulgar para actores dice: =Si no puedes controlarlo, es un actorN@
-ualquiera sean las decisiones que se tomaron acerca del con!unto apropiado de actores para el
sistema, los modeladores de casos de uso nunca deen anticiparse a los dise6adores y tratar de
usar el modelo de casos de uso para dise6ar el sistema.
,o confundir los actores con los dispositivos !ue ellos usan.
Los dispositivos son t#picamente mecanismos que los actores usan para comunicarse con el
sistema, pero ellas no son de por si actores. Si estamos escriiendo en una computadora, el
teclado no es el usuario del procesador de te%to, nosotros lo somos.
#uando no pueda encontrar los actores/ co"ien'e con los casos de
uso
(lgunas veces los casos de uso para el sistema son ovios, pero los actores involucrados son
dif#ciles de identificar. Este prolema se encuentra a veces cuando el sistema reali7a los llamados
procesamientos =atch@ que se e!ecutan sin ser atendidos, generalmente en la noche. El alcance
inicial que la mayor#a de los equipos de desarrollo toman es identificar un actor llamado el 'elo(
del )istema para que comience la tarea. Esto desgraciadamente es muy parecido a un dispositivo,
y que algunas veces causa prolemas, por lo menos no se parece a los otros actores del sistema.
"ara salir de este dilema, considere que alguien determina cuando estas tareas deer#an ser
iniciadas o detenidas y que el sistema podr#a soportar otros casos de uso que permitan que esta
persona mane!e estas tareas. "or esta ra7n, un actor con un nomre como "rogramador de
5areas /Co Scheduler2 es una me!or eleccin.
"'&ina 28 de 2!
20:1! 610/,10
Enfocarse pri"ero en lo fa"iliar.
Los equipos de desarrollo a veces se distraen con lo esot$rico, enfocndose sore las
funcionalidades originales e inusuales antes que en las funcionalidades sicas del sistema.
La me!or estrategia es enfocarse primero en encontrar los actores humanos y luego uscar los
actores ms ovios del sistema. -onsidere lo esot$rico slo despu$s de que haya estalecido un
entendimiento firme de lo que el sistema dee hacer.

Evolucionar el con*unto de actores a lo lar+o del con*unto de casos de
uso
(unque muchos liros y directrices presenten la 8squeda de actores de forma separada de la
8squeda de casos de uso, en realidad las dos actividades van de la mano y son generalmente
llevadas a cao simultneamente e iterativamente.
Una ve7 que un con!unto de casos de uso inicial se haya identificado para soportar a los actores
primarios, muchos otros actores sern identificados, que son requeridos para darle soporte a los
casos de uso.
Estos actores adicionales son solicitados para dar soporte al caso de uso porque:
Suministran informacin solicitada por el sistema para completar el caso de uso
e%itosamente.
5oman decisiones ya que el sistema es incapa7 de hacerlo por si mismo.
)ecien actuali7aciones y notificaciones del progreso hecho por el sistema mientras se
lleva a cao con el caso de uso.
Es muy dif#cil encontrar estos actores en el comien7o del modelado de actividades antes de que
los casos de uso por si solos los hayan identificado y osque!ado. En su lugar, el modelo de casos
de uso evoluciona y llega a ser ms detallado tanto ms que los actores y los casos de uso que
requieren que sean osque!ados y e%plorados.
Docu"entar los actores.
Una ve7 que se encontraron los actores, es necesario darles un nomre y documentarlos.
C+mo darle un nom,re a los actores(
Lo primero que tiene que hacer cuando encuentre a los actores es darle un nomre. -uando
nomre a un actor, aseg8rese de que el nomre descria el rol que el actor interpreta con relacin
al sistema.
"'&ina 26 de 2!
20:1! 610/,10
Si tiene dificultad al alcan7ar un acuerdo sore el nomre, listar las propuestas alternativas y
valorarlas de acuerdo a las similaridades. 5ami$n listar las responsailidades del actor con
respecto al sistema. (lgunas veces un uen nomre surge naturalmente de las responsailidades
del actor.
Los uenos nomres de actores descrien sus responsailidades. 4escriiendo el rol que el actor
interpreta con relacin al sistema.
Una trampa a evitar es simplemente convertir el nomre del caso de uso en la forma de un
nomre de actor. E!emplo: si tenemos un caso de uso E*traccin de efecti!o parecer#a tonto tener
un actor E*tractor de Efecti!o /en lugar de -liente ancario2.
#o con*undir actores con roles organi0acionales o cargos la,orales(
;acer un esfuer7o especial para asegurar que el nomre del actor no se pare7ca a un cargo
laoral en la organi7acin& si hay una similaridad, camiar el nomre para hacerlo claro que el
actor es un rol adoptado con respecto al sistema y no a un t#tulo de traa!o. Los cargos laorales
son mucho ms proales de ser refle!ados en el con!unto de tipos de usuarios que en el con!unto
de actores. ( menudo, es dif#cil de encontrar un nomre de actor que no suene como cargo
laoral.
En el modelo de casos de uso, los actores realmente son roles que un persona /o sistema2
interpreta cuando usa el sistema. (s# la persona con el cargo Empleado de ,ercanc#as tami$n
interpreta el rol descrito por el actor Empleado de ,ercanc#as. Esto es confuso. Lo me!or que se
puede hacer, si es posile, es evitar este prolema por completo: usar un nomre diferente para el
actor.
#o so,re generali0ar(
Llevar la generali7acin a un e%tremo oscurece los roles que las personas interpretan cuando
usan el sistema. En el caso de un sistema con un 8nico actor =)epresentante@, los equipos de
desarrollo se pierden de vista de un punto cr#tico: diferentes personas usan el sistema para
diferentes propsitos. (un las mismas personas interpretaran diferentes roles en cuanto ellas usen
el sistema para reali7ar diferentes cosas.
-uando siente que un actor podr#a ser demasiado general, preg8ntese a s# mismo si el nomre del
actor descrie un rol distintivo que las personas interpretan cuando usan el sistema. -uando se
nomre al actor, aseg8rese de que el actor no es simplemente un refle!o del caso de uso. (unque
no hay nada malo sintcticamente con nomrar a los actores de esta manera, ciertamente
reducir las capacidades de comunicacin del modelo por s# mismo. 5ami$n puede llevar a
"'&ina 2 de 2!
20:1! 610/,10
#antener /iarios de
Sectores
(n&resar
"edidos de
%lientes
#ane2ar %onsultas
de %lientes
"rocesar =astos Ad4inistrador de
Ventas
perder oportunidades para simplificar el modelo de casos de uso que, en general, slo llega a
estar ms claro cuando se considere el con!unto completo de responsailidades asignadas por
cada actor.
-uando se definen actores, no hay que preocuparse de las relaciones entre actores /como la
generali7acin2& simplemente capturar las personas o cosas que usaran el sistema.
En la figura se representa
el uso de cargos laorales
en el modelo de casos
de uso
-ar a cada actor una descripci+n ,re)e(
(segurarse de escriir una descripcin reve para cada actor. La descripcin reve deer#a
consistir de no ms de unas pocas oraciones que descrian el rol que el actor interpreta con
respecto al sistema. La descripcin reve deer#a capturar las responsailidades que tiene el actor
con respecto al sistema, y deer#a estalecer las metas que el actor espera alcan7ar con el uso
del sistema.
E!emplo:
#escripcin &re!e del actor +liente ,ancario del sistema -..
El -liente +ancario dirige las transacciones en el (5,. Ol o ella puede retirar fondos,
revisar el saldo de la cuenta, depositar fondos, y transferir cantidades entre cuentas.
Un -liente +ancario se crea cuando una persona are una cuenta en una institucin
financiera afiliada.
Caracteri0ar los actores(
Las caracter#sticas de un actor podr#an influenciar como el sistema se desarrolla, y en particular
como una interfase de usuario ptimamente usale es visualmente dise6ada. Las caracter#sticas
de los actores incluyen:
El alcance de la responsailidad del actor.
El amiente f#sico en el cual el actor estar usando el sistema.
"'&ina 2: de 2!
20:1! 610/,10
El n8mero y tipo de usuarios representado por este actor.
La frecuencia con la cual el actor usar el sistema.
5acer un seguimiento desde los /ctores a los tipos de usuario6 stakeolders
' roles de stakeolder(
Es importante recordar la relacin entre los actores y los tipos de usuario, stakeholders, y roles de
stakeholders identificados en el documento de Bisin.
El seguimiento de actores hasta tipos de usuarios nos ayudar a capturar e identificar las
caracter#sticas del actor. El seguimiento de los actores hasta los stakeholders y roles de
stakeholders nos hailitar los miemros correctos de la comunidad de stakeholders para ser
consultados durante la produccin, evolucin y validacin del modelo de casos de uso.
Este seguimiento tami$n provee una medida de la completitud del modelo por s# mismo. Si hay
tipos de usuario que no estn rastreados a por lo menos un actor, entonces o no son usuarios del
sistema o hay ms actores por identificar. Si hay actores que no se rastrearon a por lo menos un
tipo de usuario, entonces o estos actores son superfluos o hay ms tipos de usuario por identificar.
"'&ina 2! de 2!
20:1! 610/,10

Stakeholders, actores y modelado de casos de uso

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Stakeholders, actores y modelado de casos de uso

Загружено:

Авторское право:

Доступные форматы

Ttulo: Stakeholders y Actores Versin: 1.02 - 16/11/2004 0:2! ".#.

Asunto: $se %ase #odelin& %'tedra: (ntroduccin a la "r'ctica "ro)esional

Вам также может понравиться