PNL en LA TOMA DE REQUERIMIENTOS como TECNICA

para los FRAMEWORK CMMI

e ISO/IEC IS !!"#
Lautaro Guerra Genskowsky
lautaro.guerra@usm.cl
Departamento de Informtica
UTFS! "#ile
$le%andro &edini G
spin@latinspin.org
ale%andro.'edini@usm.cl
S(I) Latinoam*rica! "#ile
&$ UTFS! "#ile
RESUMEN
La comple%idad en la toma de re+uerimientos radica en dos factores los ni,eles de a'stracci-n por
el mane%o de un intangi'le y los canales de comunicaci-n. Frameworks apuntan lo +ue se de'e
reali.ar con referente a los re+uerimientos pero no indica c-mo #acerlo. /l presente art0culo es una
propuesta de utili.ar la t*cnica de ()L para la toma de re+uerimientos para ser ms eficiente la
comunicaci-n entre los actores y poder capturar las necesidades o deseos del futuro producto. $ su
,e. de poder ser utili.ada en los frameworks como "I
1
e IS23I/" IS 45567.
KE$WORDS% ()L! 8/9! "I! IS23I/" IS 45567.
& INTRODUCCION
La toma de re+uerimiento puede ser el comien.o del *:ito o el caos de un proyecto ya +ue
podemos construir el producto incorrecto o 'ien por+ue el proceso de transformar los deseos!
solicitudes e imgenes mentales del futuro sistema del cliente puede ser un proceso engorroso
donde la comunicaci-n es cla,e y no muc#as ,eces fluidas entre cliente y analista.
(or tal moti,o es de ,ital importancia encontrar un mecanismo o #erramienta +ue permita +ue la
comunicaci-n para la toma de re+uerimientos sea efecti,a y transformar lo a'stracto emitido por el
cliente3usuario en l-gico mane%a'le. /sa #erramienta es ()L
Los analistas conscientes de este pro'lema! intuiti,amente #an creado dos tipos de soluciones a
esta situaci-n! la primera orientada a lengua%es mas o menos formales de especificaci-n donde se
encuentran UL y orientaci-n a o'%etos y la segunda alternati,a es recurrir a modelos! diagramas!
prototipos +ue 'uscan resol,er las incongruencias y las ine:actitudes del mapeo mental de +uienes
poseen el conocimiento operacional y t*cnico del pro'lema y el conocimiento sist*mico y formal
de los clientes.
Se postula +ue es posi'le! utili.ando t*cnicas asociadas a la ()L! para disminuir el riesgo de
cometer errores de interpretaci-n en la ad+uisici-n de re+uerimientos de software.

(or otro lado modelos como IS23I/" IS 45567 y "I
1
entre otros definen la necesidad de
gestionar y detallar la toma de re+uerimientos esta'leciendo +u* se de'er0a #acer pero no el c-mo.
(or tal moti,o esta propuesta esta alineada a las necesidades planteadas en estos frameworks y a las
necesidades de esta'lecer un mecanismo optimo en las etapas de ad+uisici-n o elicitation de
re+uerimientos.

'& (QUE ES REQUERIMIENTO)
La especificaci-n de re+uerimientos es una descripci-n detallada y precisa de la funcionalidad del
sistema teniendo en cuenta las restricciones del mismo.
Generalmente! la especificaci-n de re+uerimientos sir,e como 'ase para el contrato entre los
desarrolladores y el cliente.
4
La especificaci-n es el resultado del proceso de planificaci-n y puede ser ,ista como un proceso de
representaci-n de una determinada situaci-n. La e%ecuci-n del plan concluye la instanciaci-n de un
producto o proceso en particular. La especificaci-n del producto descri'e la ,isi-n e:terna del
producto. La especificaci-n del proceso descri'e c-mo reali.ar un determinado proceso.
Los re+uerimientos son cruciales dentro de un proyecto de software por+ue nos permite sa'er +u*
de'emos construir y dimensionar el alcance en tiempo y recursos del proyecto. ;L. Guerra! $.
&edini 65<
alas prcticas de re+uerimientos son causa principal de fracaso de proyectos =T#e "#aos 8eport
4>>7?4>>@A! en una encuesta de 4>>B! arro%a lo siguienteC
Dificultad para mane%ar cam'ios @BD
Los re+s. son dif0ciles de documentar @6D
Los re+uerimientos crecen desordenadamente B@D
2tros factores causantes de fracaso en proyectos de software sonC
Falta de entendimiento de la tecnolog0a y de la naturale.a sist*mica de la organi.aci-n por parte de
la gerencia. /l #ec#o +ue un cam'io tecnol-gico implica cam'ios organi.aciacionales y culturales
es dif0cil de apreciar de'ido aC
La presi-n del tiempo! especialmente en organi.aciones del sector pE'lico! donde el
dinero de'e ser gastado antes de terminar el aFo fiscal! puede lle,ar a poca atenci-n a la
definici-n y control del proyecto.
)o iniciar el proceso de definici-n del sistema con la participaci-n acti,a de todos los
in,olucrados enC
o identificar necesidades
o Identificar sistemas e:istentes y sus pro'lemas
o (reparar a todo el personal para el cam'io
o )o in,ertir en planificar el proyecto dentro de la organi.aci-n y comprar una
soluci-n. ;Flowers>B<
'& Clas*+*can,o re-.er*m*en/os
Los re+uerimientos pueden ser t*cnicos y )o t*cnicos. Ga en general! los re+uerimientos pueden
clasificarse enC
Funcionales o de sistema
$sociados a caracter0sticas de comportamiento
)o funcionales u operacionales
;I/// 46@7.4>>@<

/n esta clasificaci-n se aprecia +ue la mayor0a de los re+uerimientos se o'tienen de dos fuentesC
procesos administrati,os u operacionales y conocimiento prctico de +uienes operan! e%ecutan y
administran estos procesos. Los primeros usualmente se modelan con #erramientas +ue facilitan su
H
descripci-n! anlisis y almacenamientoI los segundos re+uieren de frecuentes entre,istas semi?
estructuradas entre los analistas y las personas responsa'les de los procesos.
J
'&' (Q.0 ,*ce CMMI

1 ISO/IEC !!"# 2SPICE3 con respec/o a re-.er*m*en/os)
/n el modelo de capacidad de madure. integrado del S/I! fuertemente aparece los re+uerimientos
en dos reas de procesos la primera en el ni,el H =desde el punto de ,ista del modelo escalonadoA
para Gesti-n de re+uerimientos Requirements Managements y para el ni,el J el rea de
proceso desarrollo de re+uerimientos Requirements development.
"I
1
para su ni,el H de madure. crea la 'ase de gestionar los re+uerimientos! usando sus
prcticas especificas. (ara el prop-sito de Gesti-n de 8e+uerimientos es administrar los
re+uerimientos de los productos y componentes de producto del proyecto e identificar
inconsistencias entre estos re+uerimientos! los planes del proyecto y los productos de tra'a%o.
Mana4e Re-.*remen/s / Gesti-n de re+uerimientos.
Los re+uerimientos de'en ser administrados! para definir el m'ito de acci-n del sistema! planificar
su construcci-n y puesta en marc#a! determinar pla.os y recursos necesarios para su
presupuestaci-n.

Pr5c/*cas espec6+*cas
S( 4.4 2'tener un entendimiento de los re+uerimientos.
S( 4.H 2'tener compromiso con los re+uerimientos.
S( 4.J $dministrar los cam'ios de los re+uerimientos.
S( 4.7 $dministrar tra.a'ilidad 'i?direccional de los re+uerimientos.
S( 4.5 Identificar inconsistencias entre el tra'a%o del proyecto y los re+uerimientos
(ara el ni,el J de "I
1
el rea de proceso es
Re-.*remen/s De7elopmen/ / Desarrollo de 8e+uisitos3re+uerimientos
/l prop-sito del Desarrollo de 8e+uisitos es la creaci-n y anlisis de los re+uisitos de cliente! de
producto y de los componentes del producto. Los re+uisitos forman la 'ase para el diseFo.
/l Desarrollo de 8e+uisitos incluye las siguientes acti,idadesC
- Identificaci-n! documentaci-n! anlisis! ,alidaci-n y comunicaci-n de las necesidades!
e:pectati,as y restricciones del cliente para poder o'tener los re+uisitos del cliente y constituir
una 'ase +ue satisfaga a todos los in,olucrados.
- 8ecogida y coordinaci-n de las necesidades de todos los in,olucrados.
- Desarrollo de los re+uisitos del ciclo de ,ida del producto a desarrollar.
- /sta'lecimiento de los re+uisitos del cliente.
- /sta'lecimiento de los re+uisitos iniciales del producto y de sus componentes de forma +ue
sean consistentes con los re+uisitos del cliente.
/sta rea de proceso trata todos los re+uisitos de usuario! no solo los re+uisitos a ni,el de producto!
ya +ue el usuario puede especificar re+uisitos espec0ficos de diseFo
Pr5c/*cas espec6+*cas
S( 4 .4?4 8ecoger las necesidades de los in,olucrados
S( 4.4?H Identificar necesidades adicionales
S( 4.H?4 Desarrollar los re+uisitos del cliente
SG H Desarrollar re+uisitos de producto
S( H.4?4 /sta'lecer re+uisitos de producto y de componentes
S( H.H?4 $signar los re+uisitos de producto?componente
S( H.J?4 Identificar re+uisitos de interfaces
SG J $nali.ar y ,alidar los re+uisitos
S( J.4?4 /sta'lecer conceptos operacionales y escenarios
S( J.H?4 /sta'lecer la definici-n de la funcionalidad necesaria
7
S( J.J?4 $nali.ar los re+uisitos
S( J.7?J $nali.ar los re+uisitos para alcan.ar un e+uili'rio
S( J.5?4 Kalidar los re+uisitos
S( J.5?H Kalidar los re+uisitos mediante m*todos intensi,os
)uestro o'%eti,o esta relacionado con las prcticas especificas 4.4 y 4.H
(ara IS23I/" IS 45567! Los referentes a la toma de re+uerimientos y a su gesti-n y ,ienen dados
por la categor0a de proceso "ustomer?Supplier process category ="USA! /ngineering process
category =/)GA $).H (ro%ect management. La propuesta de ()L se incorporar0a en el proceso
"US.J 8e+uirements elicitation process.
J. L9UM /S ()LN
La ()L =(rogramaci-n )eurolingO0sticaA constituye un modelo! formal y dinmico de c-mo
funciona la mente y la percepci-n #umana! c-mo procesa la informaci-n y la e:periencia y las
di,ersas implicaciones +ue esto tiene para el *:ito personal. "on 'ase en este conocimiento es
posi'le identificar las estrategias internas +ue utili.an las personas de *:ito! aprenderlas y
enseFarlas a otros =modelarAI para facilitar un cam'io e,oluti,o y positi,o. La (rogramaci-n
)eurolingO0stica! por analog0a con el computador! utili.a los patrones uni,ersales de comunicaci-n
y percepci-n +ue tenemos para reconocer e inter,enir en procesos di,ersos =aprendi.a%e! terapia!
afrontamiento del estr*s! negociaci-n! gesti-n de conflictos! superaci-n de fo'ias! etc.A. /l campo
de tra'a%o es tan amplio como lo es el de las relaciones interpersonales.
Tu,o su origen en las in,estigaciones de 8ic#ard &andler y Po#n Grinder! padres de la ()L! +ue
trata'an de a,eriguar por +u* determinados tratamientos de tres terapeutas en /stados Unidos
=Satir! /rickson y (earlsA consegu0an mayor *:ito +ue el resto de sus colegas.
()L es el estudio de lo +ue perci'imos a tra,*s de nuestros sentidos =,ista! o0do! olfato! gusto y
tactoA! c-mo organi.amos el mundo tal como lo perci'imos y c-mo re,isamos y filtramos el mundo
e:terior mediante nuestros sentidos. In,estiga los procesos +ue #acen +ue transmitamos nuestra
representaci-n del mundo a tra,*s del lengua%e. /s por tanto una aplicaci-n prctica +ue permite!
mediante t*cnicas y #erramientas precisas! reconocer y desarrollar #a'ilidades para el crecimiento
personal y la me%ora de las relaciones interpersonales. (ero so're todo! permite conocer de manera
o'%eti,a la percepci-n de los dems y la de nosotros mismos.
(PARA QU8 PNL)
La ()L se puede utili.ar para desarrollar de manera rpida y efica. un proceso de aprendi.a%e y as0
superar una situaci-n de estr*s! de conflicto! negociar con mayor ,enta%a frente a los ad,ersarios.
(ermite conocer la percepci-n de otras personas +ue est*n frente a uno o a uno mismo. /s un
complemento en el desarrollo de la Inteligencia emocional. /ntre otras cosas! ()L
$umenta de manera nota'le y rpida el auto confian.a.
e%ora las relaciones interpersonales.
Desarrolla el crecimiento personal y profesional #acia el *:ito.
(ermite con,ertirse en +uien deseemos y +ueramos ser.
Sir,e para reducir el estr*s.
Logra una 'uena capacidad para negociar y solucionar conflictos de manera positi,a.
;8efC #ttpC33www.capitalemocional.com3()L3pnl.#tm! accesado 45 agosto H665<.
5
J.4 8/9 Q()L
La siguiente figura muestra la ingenier0a de re+uerimientos siendo oportuna utili.ar ()L en la
etapa de elicitaci-n de re+uerimientos.
Figura 4 Ingenier0a de 8e+uerimientos
La o'tenci-n de re+uerimientos en cuanto a lo +ue se refiere a la entre,ista con el usuario!
o'tenci-n del material necesario para reali.ar los casos de uso =ULA =por e%emploA! modelado del
proceso! pasa necesariamente por una negociaci-n de compromisos =tiempo! credi'ilidad! eficacia!
eficienciaA! y posterior ,alidaci-n de la informaci-n o'tenida! mediante entre,ista a pares y3o
superiores al entre,istado. Si no se produce una rpida aceptaci-n del analista como un legitimo
otro! el proceso de o'tenci-n de informaci-n es lento! engorroso y propenso a errores. ()L es una
#erramienta adecuada para lograr pronta empat0a y acercamiento a las personas y as0 facilitar el
proceso de o'tenci-n de re+uerimientos.
#& PROCEDIMIENTO PARA LA TOMA DE REQUERIMIENTOS USANDO PNL
/l usar ()L como una #erramienta de tra'a%o en los analistas y %efes de proyecto pasa
necesariamente por una capacitaci-n de *stos en t*cnicas asociadas a el reconocer las
preocupaciones! temores! apre#ensiones! fortale.as! ,alores y principios de las personas +ue #acen
de contraparte a *stos! en los roles de clientes! usuarios del sistema y dueFo del sistema a construir.
/sta capacitaci-n pre,ia permite +ue los analistas utilicen sus #a'ilidades interpersonales! faciliten
la o'tenci-n de informaci-n y o'tengan con prontitud la atenci-n y disponi'ilidad de tiempo de sus
informadores! clientes y usuarios.
#& Al4.nas cons*,erac*ones pr5c/*cas en el .so ,e PNL
La consideraci-n ms rele,ante y frecuente en la toma de re+uerimientos es la restricci-n de
tiempo en su reali.aci-nI si a esto se agrega +ue el analista se ,e enfrentado a resol,er un pro'lema
lingO0stico =cultura de la organi.aci-n y del m'ito del pro'lemaA! un pro'lema de relaciones
=interacci-n entre analista y su contraparteA y un pro'lema t*cnico =especificaci-n de
re+uerimientos ,alidosA! es ra.ona'le suponer +ue o demora mas de lo presupuestado o su
inter,enci-n es incompleta. (ara enfrentar esta situaci-n desde la perspecti,a propuesta! el analista
de'er interactuar con su informante principal a tra,*s de los canales de comunicaci-n principal!
para ello de'er ser capa. de darse cuenta! en los primeros 45 minutos de la entre,ista de cuales
son *stos. $ partir de la sincroni.aci-n afecti,a y lingOista podr a,an.ar rpidamente a la
o'tenci-n de las seFales culturales cla,es =responsa'ilidad y roles! importancia de controles
B
()L
impl0citos! formali.aciones y cumplimiento de acuerdos! por e%emploA y los aspectos afecti,os
moti,adores de su entre,istado =intereses y moti,aci-n personal! conocimiento de la organi.aci-n
informal! capacidad de e:presar afecto! por e%emploA de modo +ue en este con,ersar =lengua%ear
segEn aturanaA la comunicaci-n t*cnica relacionada con el proceso se desen,uel,a fluidamente.
Tam'i*n es importante considerar +ue no solo se de'e mirar los canales de comunicaci-n del
entre,istado sino igualmente de la persona +ue captura los re+uisitos! es decir! de'o conocer mis
canales de comunicaci-n y los de la otra persona para poder estar sincroni.ados o en la misma
Rsinton0aS y +ue as0 se logre transmitir la informaci-n de una manera ms efecti,a.
Una #erramienta efecti,a en la etapa de ad+uisici-n y en las primeras reuniones =se aconse%a no
ms de tres en esta etapaA es asociar a cada petici-n o re+uerimiento inicial con ciertos aspectos de
criticidades! y so're todo e:plicitar las e:pectati,as asociadas +ue puedan generarse y +ue el futuro
producto! de'er satisfacer. Un e%emplo aparece a continuaci-n.
(etici-n "riticidad /:pectati,as $spectos afecti,os
8egistro #ist-rico de deudores /DI$ $LT$ Demostr- alto inter*s y preocupaci-n
Informe de nue,as solicitudes &$P$ /DI$ (oco inter*s y moti,aci-n en e:plicar
9& CONCLUSIONES
/n todo proyecto el *:ito radica en entregar a+uello +ue el usuario3cliente +uiere y necesita. La
mayor0a de los frameworks tienen un punto muy fuerte con respecto a la toma de re+uerimientos y
su gesti-n como una ,aria'le fundamental +ue contri'uye al *:ito. (ara disminuir la distancia
intelectual entre lo +ue se desea o esta en los pensamientos de los usuarios y clientes se presenta
como una opci-n la t*cnica ()L para esta'lecer mecanismos de comunicaci-n efecti,os +ue en
definiti,as son los ms ,enta%osos y contri'uyen a reali.ar una propuesta de prototipo! si as0 se
considera! ms af0n al producto. $dems! esta propuesta puede ser usada en cual+uier framework
cumpliendo las prcticas espec0ficas o re+uisitos +ue se solicitan.
:& REFERENCIAS
;L. Guerra! $. &edini 65<
Gesti-n de proyectos de Software! /d. U.T.F.S..! HT edici-n no,iem're H665
;. Penkins! 65<
"omparaci-n de las Iniciati,as Latinoamericanas para e%orar la (roducci-n de Software Dr.
arcelo Penkins GST Latinoam*rica H665
;flowers >B<
Flowers! S. Software failureC management failure. $ma.ing stories and cautionary tales.
"#ic#ester! )ew Gork! C Po#n Uiley! 4>>B. 4>@pp.
;Gartnert! 65 <
#ttpC33www.gartner.com37VdecisionVtools3measurement3measureVitVarticles3H66JV67H73'enVcmm.%
sp! accesado el 6B36B365
;I/// 46@7.4>>@<
I/// 46@7.4>>@ W Standard for de,eloping Software Life "ycle (rocesses!
IS23I/" 4HH6@ H666 draft? Information tec#nology X Software life cycle processes
@