25/9/2015

Anlisis de requerimientos del software

Anlisisderequisitosdelsoftware
[PRESSMAN,2002]
Laingenieraderequisitosdelsoftwareesunprocesodedescubrimiento,refinamiento,modelado
yespecificacin.Serefinanendetallelosrequisitosdelsistemayelpapelasignadoalsoftware.

Tantoeldesarrolladorcomoelclientetienenunpapelactivoenlaingenieraderequisitosun
conjuntodeactividadesquesondenominadasanlisisElclienteintentareplantearunsistemaconfuso,a
niveldedescripcindedatos,funcionesycomportamiento,endetallesconcretos.Eldesarrolladoracta
comointerrogador,comoconsultor,comopersonaqueresuelveproblemasycomonegociador.

Elanlisisylaespecificacinderequisitospuedenparecerunatarearelativamentesencilla,pero
lasaparienciasengaan.Elcontenidodecomunicacinesmuydenso.Abundanlasocasionesparamalas
interpretaciones o falta de informacin. Es muy probable que haya ambigedad. El dilema al que se
enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente
annimo:Squecreequeentendiloquepiensaquedije,peronoestoysegurodequesedcuentade
queloqueescuchnoesloqueyoquisedecir.

El anlisis de requisitos es una tarea de ingeniera del software que cubre el hueco entre la
definicindelsoftwareanivelsistemayeldiseodesoftware.Elanlisisderequerimientospermiteal
ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y
rendimientos),indicalainterfazdelsoftwareconotroselementosdelsistemayestablecelasrestricciones
quedebecumplirelsoftware.

Tareasdeanlisis

Elanlisisderequisitosdelsoftwaresepuedesubdividirencincoreasdeesfuerzo:
1.Reconocimientodelproblema
2.Evaluacinysntesis
3.Modelado
4.Especificacin
5.Revisin

Todoslosmtodosdeanlisisserelacionanporunconjuntodeprincipiosoperativos:

1.Deberepresentarseyentenderseeldominiodelainformacindeunproblema.
2.Debendefinirselasfuncionesquedeberealizarelsoftware.
3. Debe representarse el comportamiento del software (como consecuencia de
acontecimientosexternos),
4. Debendividirselosmodelosquerepresentaninformacin,funcinycomportamientode
maneraquesedescubranlosdetallesporcapas(ojerrquicamente).
5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la
implementacin.

Ademsdelosprincipiosoperativosmencionadosanteriormente,sesugiereunconjuntode
principiosdirectricesparalaingenieraderequerimientos:

1.Entenderelproblemaantesdeempezaracrearelmodelodeanlisis.
2.Desarrollarprototiposquepermitanalusuarioentendercomoserlainteraccinhombre
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

1/6

25/9/2015

Anlisis de requerimientos del software

mquina.
3.Registrarelordenylarazndecadarequerimiento,
4.Usarmltiplesplanteamientosderequerimientos.
5.Priorizarlosrequerimientos.
6.Trabajarparaeliminarlaambigedad.

Uningenierodesoftwarequeseapegueaestosprincipiosesmuyprobablequedesarrolleuna
especificacindesoftwarequerepresenteunexcelentefundamentoparaeldiseo.

Funcionesyhabilidadesdelanalista
La funcin principal de un analista del software (o ingeniero de requisitos es llevar a cabo las
actividadesnecesariasparacumplirconlascincoreasdeesfuerzodescritasenlaseccinanterior.
Paralocualhaceusodelassiguientestcnicas:
1.Entrevistas
2.Talleres
3.Observacin
4.Encuestas
5.Revisindocumental
6. Usodeespecificacionesformalespararequerimientos(formatosestndardedocumentos,
UML,etc.)

Elingenieroderequisitosdebeposeerhabilidadesparticularesparafacilitarlacomunicacincon
el cliente y ganar su confianza. (Consultar el artculo: So You Want to be a Requirements Analyst?,
SoftwareDevelopment,Julio2003)

IngenieradeRequisitos
Conceptos[SOMMERVILLE,2002]
RequisitosdelSoftware
Es la descripcin de los servicios y restricciones de un sistema de software, es decir, lo que el
softwaredebehacerybajoqucircunstanciasdebehacerlo.

IngenieradeRequisitosdelSoftware
Eselprocesodedescubrir,analizar,documentaryverificarlosrequisitosdelsoftware.

Stakeholders
Estetrminoseutilizaparareferirseacualquierpersonaquetieneinfluenciadirectaoindirecta
sobrelosrequisitosdelsistema.Entrelosstakeholdersseencuentranlosusuariosfinalesqueinteractan
con el sistema y todos aquellos en la organizacin se que vern afectados por dicho sistema. Los
stakeholders tambin son los ingenieros que desarrollan o dan mantenimiento a otros sistemas
relacionados,losadministradoresdelnegocio,losexpertoseneldominiodelsistema,losrepresentantes
delostrabajadores,etc.

Elprocesodelaingenieraderequisitos
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

2/6

25/9/2015

Anlisis de requerimientos del software

Fuente:[URJC]

Lasactividadesdelprocesoson:
1.Comprensindeldominio
2.Recoleccinderequisitos
3.Clasificacin
4.Resolucindeconflictos
5.Priorizacin
6.Verificacinderequisitos
7.Anlisis

ActividadesdelaIngenieradeRequisitos.[SOMMERVILLE,2002]

Laingenieraderequisitosincluyedosactividadesprincipales:laobtencinderequisitos,queda
como resultado una especificacin del sistema que el cliente comprende, y el anlisis, que da como
resultadounmodelodeanlisisquelosdesarrolladorespuedeninterpretarsinambigedad.[BRUEGGE,
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

3/6

25/9/2015

Anlisis de requerimientos del software

2002]

La obtencin de requisitos se enfoca en la descripcin del propsito del sistema y es la que

implicaelretomayor.Elcliente,losdesarrolladoresylosusuariosidentificanunreaproblemaydefinen
un sistema que resuelve el problema. A tal definicin se le llama especificacin de los requisitos del
software (SRS) y sirve como contrato entre el cliente y los desarrolladores. La SRS se estructura y
formaliza durante el anlisis para producir un modelo de anlisis. Tanto la SRS como el modelo de
anlisisrepresentanlamismainformacin.Difierensloenellenguajeynotacinqueusan.LaSRSest
escritaenlenguajenatural,mientrasqueelmodelodeanlisisseexpresa,porlogeneral,enunanotacin
formalosemiformal.Laespecificacindelsistemaeslabasedelacomunicacinconlosstakeholders.
Elmodelodeanlisiseslabasedelacomunicacinentrelosdesarrolladores.
La obtencin de requisitos y el anlisis se enfocan slo en la visin del sistema que tiene el
usuario.

Tiposderequisitos
Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma
independienteasuimplementacin.Elambienteincluyealusuarioycualquierotrosistemaexternocon
elcualinteracteelsistema.
Requisitosnofuncionales:Describenatributosslodelsistemaodelambientedelsistemaqueno
estn relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen
restricciones cuantitativas, como el tiempo de respuesta o precisin, tipo de plataforma (lenguajes de
programaciny/osistemasoperativos,etc.)

CaractersticasdeunabuenaSRS
[IEEEStd8301998]
1.Correcta
2.Noambigua
3.Completa
4.Consistente
5.Calificadadeacuerdoalaimportanciay/oestabilidad
6.Verificable
7.Modificable
8.Rastreable
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

4/6

25/9/2015

Anlisis de requerimientos del software

1.Correcta
UnaSRSescorrecta,sysolos,cadarequisitoespecificadoesunrequisitoqueelsoftwaredebe
cumplir.
2. Noambigua
UnaSRSnoesambiguasysoloscadarequisitoespecificadotieneslounainterpretacin.
3. Completa
UnaSRSescompleta,sysolos,incluyelossiguienteselementos:
a)Todoslosrequisitossignificativos,yaseaqueserelacionenafuncionalidad,desempeo,
restricciones de diseo, atributos o interfaces externas. En particular cualquier requisito
externoimpuestoporunaespecificacindelsistemadebeserreconocidoytratado.

b)Definicindelasrespuestasdelsoftwareatodoslostiposposiblesdeclasesdedatosde
entrada en todos los tipos posibles de clases de situaciones. Notar que es importante
especificarlasrespuestastantoparavaloresdeentradavlidoscomoinvlidos.
c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS as
comoladefinicindetodoslostrminosyunidadesdemedida.
4. Consistente
UnaSRSesconsistente,sysolos,nosecontradiceasmisma,esdecir,siningnsubconjunto
derequisitosahdescritossecontradicenoentranenconflicto.
5. Jerarquizadadeacuerdoalaimportanciay/oestabilidad
Una SRS est calificada de acuerdo a la importancia y/o estabilidad si cada requisito tienen un
identificadorqueindiquelaimportanciaoestabilidaddelrequisito.
6. Verificable
Una SRS es verificable, s y solo s, cada requisito especificado es verificable. Un requisito es
verificablesysolosexisteunprocesofinitodecostoefectivoconelcualunapersonaounamquina
puedeverificarqueelproductodesoftwarecumpleelrequisito.Engeneralcualquierrequisitoambiguo
noesverificable.
7. Modificable
UnaSRSesmodificable,sysolos,suestructurayestilosontalesque,cualquiercambioalos
requisitos pueden ser hechos fcil, completa y consistentemente sin perder la estructura y el estilo. La
modificabilidadgeneralmenterequierequeunaSRS:
a)Tengaunaorganizacincoherenteyfcildeusarconunatabladecontenido,un
ndiceyreferenciascruzadasexplcitas.
b) Nosearedundante(estoes,elmismorequisitonodebeaparecerenmsdeuna
parteenlaSRS).
c)Expresacadarequisitodemaneraseparada,envezdehacerlomezcladoconotros
requisitos.
8. Rastreable
UnaSRSesrastreablesielorigendecadaunodesusrequisitosesclaraysifacilitalareferencia
decadarequisitoeneldesarrollofuturoomejoradeladocumentacin.
Serecomiendanlossiguientesdostiposderastreabilidad:
a) Rastreabilidadhaciaatrs(estoes,aestadospreviosdeldesarrollo).El
requisitotienereferenciasexplcitasasusfuentesendocumentosanteriores.
b)Rastreabilidadhaciaenfrente(estoes,atodoslosdocumentosderivadosdel
SRS). Depende de que cada requisito en la SRS tenga un nombre nico o
nmero de referencia. Es particularmente importante cuando el software entra
en operacin y mantenimiento. Cuando el cdigo y los documentos de diseo
sonmodificados,esescencialcontarconlacapacidadparaconocerelconjunto
completoderequisitosquepuedenserafectadosporesasmodificaciones.
http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

5/6

25/9/2015

Anlisis de requerimientos del software

Bibliografa
[BRUEGGE,2002]

[IEEEStd8301998]

IngenieradeSoftwareOrientadoaObjetos
Bruegge,BerndyDutoit,Allen
PrenticeHall,2002
ISBN:9702600103

IEEERecommendedPracticeforSoftwareRequirements
Specifications
SoftwareEngineeringStandardsCommitteeoftheIEEE
ComputerSociety
ISBN0738103322

IngenieradelSoftware.Unenfoqueprctico.5ta.Edicin
Pressman,Roger
McGrawHill,2002
ISBN8448132149

IngenieradeSoftware.6ta.Edicin
Sommerville,Ian
PrenticeHall,2002
ISBN9702602068

CursodeIngenieradelSoftwareI
UniversidadReyJuanCarlos
http://kybele.escet.urjc.es/asignatura.asp?Nombre1=ISI

[PRESSMAN,2002]

[SOMMERVILLE,2002]

[ISURJC]

http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm

6/6