1 Introducción A La Ingenieria de Requisitos

Introduccin a
la ingeniera de
requisitos
Jordi Pradel Miquel
Jose Raya Martos
PID_00191265
CC-BY-SA PID_00191265
Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia de
Reconocimiento-Compartir igual (BY-SA) v.3.0 Espaa de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla
o comunicarla pblicamente siempre que se cite el autor y la fuente (FUOC. Fundaci per a la Universitat Oberta de Catalunya), y
siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en:
http://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca
Introduccin a la ingeniera de requisitos
ndice
Introduccin...............................................................................................
Objetivos.......................................................................................................
1.
Introduccin a la ingeniera de requisitos.................................
1.1.
La ingeniera del software ...........................................................
1.2.
Requisitos y stakeholders...............................................................
1.3.
La ingeniera de requisitos ..........................................................
1.4.
Problemticas de la ingeniera de requisitos ...............................
2.
Presentacin del caso prctico.......................................................
11
3.
Tipos de requisitos.............................................................................
15
3.1.
Requisitos de producto ...............................................................
15
3.1.1.
Requisitos funcionales ...................................................
16
3.1.2.
Requisitos no funcionales ..............................................
17
Requisitos de proceso ..................................................................
19
El proceso de la ingeniera de requisitos.....................................
20
4.1.
Obtencin de requisitos ..............................................................
20
4.2.
Gestin de requisitos ..................................................................
21
4.3.
Documentacin de requisitos .....................................................
22
4.4.
Validacin de requisitos ..............................................................
23
4.5.
Verificacin de requisitos ............................................................
24
Requisitos del caso prctico............................................................
25
5.1.
Identificacin de stakeholders.......................................................
25
5.2.
Problemticas ..............................................................................
25
5.3.
Tipos de requisitos ......................................................................
26
5.3.1.
Requisitos de producto no funcionales .........................
26
5.3.2.
Requisitos de productos funcionales .............................
27
5.3.3.
3.2.
4.
5.
Requisitos de proceso ....................................................
28
El proceso de la ingeniera de requisitos ....................................
28
Resumen.......................................................................................................
30
Actividades..................................................................................................
31
Ejercicios de autoevaluacin..................................................................
34
Solucionario................................................................................................
35
5.4.
Glosario........................................................................................................
37
Bibliografa.................................................................................................
39
Introduccin
La ingeniera de requisitos es la disciplina que incluye todas aquellas actividades relacionadas con los requisitos del software. A pesar de estar muy relacionada con la ingeniera del software, se trata de disciplinas con objetivos
diferentes.
Mientras que la ingeniera del software tiene como objetivo desarrollar un
producto de manera correcta, la ingeniera de requisitos tiene como objetivo
desarrollar el producto correcto. Por este motivo requiere conocimientos y habilidades de otras disciplinas, como la psicologa, el marketing o la organizacin de empresas.
La ingeniera de requisitos tiene un gran impacto econmico en la industria
del software. Cuando un equipo de desarrollo dedica su esfuerzo a desarrollar
un software con los requisitos equivocados, no solo se est malgastando esta
capacidad (que podra haberse utilizado en desarrollar el producto correcto),
sino que, adems, habr que dedicar esfuerzos a corregir la situacin.
En este mdulo haremos un repaso de aquello que ya conocemos sobre la
ingeniera de requisitos, por lo que ya hemos estudiado en otras asignaturas.
Este repaso nos permitir, en los mdulos siguientes, estudiar con ms detalle
las problemticas y tcnicas especficas de la ingeniera de requisitos.
Empezaremos hablando de la ingeniera de requisitos y de su objeto de estudio
(los requisitos), as como de la relacin de estos con los diferentes stakeholders
del proyecto de desarrollo.
A continuacin, presentaremos el caso prctico que desarrollaremos en el resto
de los mdulos para presentar los diferentes conceptos y tcnicas. Como la
ingeniera de requisitos es muy dependiente del contexto (al fin y al cabo cada
proyecto de desarrollo tendr unos requisitos diferentes), nos ser muy til
estudiar el mismo caso en todos los mdulos.
Una vez presentado el caso prctico, hablaremos del proceso de la ingeniera
de requisitos y presentaremos las diferentes actividades que forman parte de
l, que estudiaremos de manera ms detallada en el resto de los mdulos.
Finalmente, veremos algunos ejemplos de requisitos basados en el caso prctico anteriormente mencionado.
Ved tambin
Podis encontrar ms informacin sobre la ingeniera de requisitos en la asignatura Ingeniera del software.
Objetivos
El principal objetivo de este mdulo es presentar al estudiante la ingeniera de

requisitos y situarla en el contexto de la ingeniera del software. En concreto,
el estudiante, al finalizar este mdulo, debe ser capaz de:
1. Situar la ingeniera de requisitos dentro del contexto de la ingeniera del

software.
2. Estar familiarizado con la terminologa bsica de la ingeniera de requisitos.
3. Conocer el proceso de la ingeniera de requisitos, as como las diferentes
tareas involucradas en ella.
4. Saber aplicar el proceso de la ingeniera de requisitos a un caso prctico.
1. Introduccin a la ingeniera de requisitos
La ingeniera de requisitos es la disciplina que nos ayuda a identificar,

gestionar y mantener el conjunto de requisitos del software que hemos
de desarrollar.
La ingeniera de requisitos, por tanto, tiene lugar dentro del mismo contexto
que la ingeniera del software (el desarrollo de software), motivo por el cual se
puede ver como parte de la ingeniera del software. Aun as, hay que tener en
cuenta que la ingeniera de requisitos requiere conocimientos y habilidades
propias de otras disciplinas, como por ejemplo la psicologa, el marketing o
el diseo.
1.1. La ingeniera del software
El IEEE define la ingeniera del software como la aplicacin de un enfoque
sistemtico, disciplinado y cuantificable al desarrollo, la operacin y el mantenimiento del software.
El desarrollo de software es una actividad temporal en el sentido de que tiene
un inicio claro y un final tambin bastante claro, ya sea con xito o fracaso.
Por este motivo, el desarrollo se organiza en proyectos.
Existen muchos mtodos de desarrollo de software, muchos de ellos basados
en otras disciplinas de la ingeniera. Cada mtodo define uno o ms procesos
consistentes en decir qu tareas y en qu orden se deben llevar a cabo, qu
roles tendrn las personas que participan en ellos, qu tareas se asignan a
cada rol, qu artefactos se tienen que usar como punto de partida y qu otros
artefactos son el resultado de cada tarea.
Cada mtodo tiene sus particularidades, pero todos ellos tienen una serie de
actividades (conjuntos de tareas relacionadas) comunes:
Gestin del proyecto.
Identificacin, gestin y documentacin de requisitos.
Modelizacin.
Construccin y pruebas, incluyendo la verificacin de requisitos.
Calidad.
Mantenimiento y reingeniera.
Referencia bibliogrfica
IEEE Std (1993). IEEE Software Engineering Standard: glossary of Software Engineering
Terminology. IEEE Computer
Society Press.
Cada mtodo puede dar ms o menos importancia a cada actividad, pero no

la puede obviar si lo queremos considerar un mtodo de desarrollo completo.
1.2. Requisitos y stakeholders
Para poder desarrollar un sistema informtico, obviamente, hay que entender
qu sistema hay que desarrollar y, por lo tanto, hay que entender bien los
requisitos de todo tipo que los diferentes stakeholders tienen sobre el sistema.
Varias de las actividades de la ingeniera del software hacen referencia a estos
requisitos y, de hecho, podemos considerar que estos son una pieza clave para
el xito o fracaso de todo proyecto de desarrollo de software.
Los requisitos son caractersticas observables de un sistema que expresan una necesidad o restriccin que un stakeholder tiene sobre l.
Los requisitos nos sirven, por lo tanto, para delimitar cules de las posibles
soluciones a un problema son adecuadas (las que cumplen los requisitos) y
cules no.
Los stakeholders son aquellas personas o entidades que tienen algn

impacto o inters en este sistema.
A pesar de que todos los usuarios de un sistema son stakeholders, puesto que
todos lo usan y, por lo tanto, tienen intereses en l, no todos los stakeholders
son usuarios, puesto que puede haber muchas personas o entidades que, a
pesar de que no utilicen el sistema, se ven afectadas por su implantacin y
que, por lo tanto, tambin tienen intereses en l.
1.3. La ingeniera de requisitos
Denominamos ingenieraderequisitos a aquel subconjunto de la ingeniera
del software que se encarga de las actividades siguientes:
Obtencinderequisitos: identificar las fuentes de informacin de los posibles requisitos del sistema y obtener cules son estos requisitos candidatos.
Gestinderequisitos: estimar el coste que implica tener en cuenta cada

requisito, priorizarlos segn la importancia que tengan para los stakeholders y as poder seleccionar los requisitos que finalmente se tendrn en
cuenta en la etapa actual de desarrollo del sistema.
Documentacinderequisitos: documentar los requisitos de manera que

quede constancia del resultado del proceso de gestin de requisitos y que,
al mismo tiempo, los stakeholders y los desarrolladores compartan la visin

de cul es el producto que se ha de desarrollar. Esta documentacin puede
formar parte o no de la documentacin final del sistema.
Validacinderequisitos: comprobar que los requisitos elegidos para el

producto que estamos desarrollando reflejan las expectativas de los stakeholders y, por lo tanto, que no ha habido errores en su obtencin, priorizacin, seleccin y documentacin.
Verificacinderequisitos: verificar si el sistema desarrollado (o parcialmente desarrollado en el caso de ciclos de vida iterativos) satisface o no
los requisitos y cules.
Las tareas y artefactos concretos de la ingeniera de requisitos que se usen dependern, en buena parte, del mtodo empleado. As, por ejemplo, los mtodos que sigan un ciclo de vida en cascada necesitarn una documentacin de
requisitos mucho ms exhaustiva que los mtodos giles.
1.4. Problemticas de la ingeniera de requisitos
Las principales problemticas de la ingeniera de requisitos radican en el hecho de que se trata de una actividad de comunicacin entre personas y, como
en cualquier actividad de este tipo, nos podemos encontrar con varias dificultades. Las ms tpicas son:
Diferenciasrespectoalainformacinconlaquetrabajanlasdiferentespartes. Los stakeholders tienen informacin sobre el dominio que los

desarrolladores no tienen, mientras que los desarrolladores tienen informacin sobre la capacidad de la tecnologa que los stakeholders, no. Esto
suele condicionar la visin del problema que tienen unos y otros, y puede
afectar negativamente a la comunicacin.
Limitacionesdelcanalutilizado. Cualquier canal de comunicacin tiene

limitaciones. As, por ejemplo, la comunicacin escrita pierde los matices
del lenguaje inmediato y no verbal, mientras que la comunicacin verbal
impide o, cuando menos, dificulta la revisin de lo que se dijo.
Limitaciones del lenguaje utilizado. Las personas que se comuniquen

lo tienen que hacer en un lenguaje que los dos conozcan. Los lenguajes
naturales (el cataln, el castellano, etc.) son los ms comunes, pero son
propensos a la ambigedad. Existen lenguajes ms formales, pero resultan
poco tiles si no son conocidos por todas las partes que se comunican.
Dificultaddedefinirelmejorsistemaposible. Muy a menudo es difcil

descubrir cul es el mejor sistema posible, en el sentido de que puede ser
difcil saber qu quieren realmente los stakeholders. Muchas veces ni ellos
Podis ver la referencia completa en el artculo de Cusumano y otros en el apartado
de bibliografa.
10
mismos lo sabrn decir con certeza, puesto que estarn condicionados por
su desconocimiento de la tecnologa, por soluciones que ya conocen, etc.
11
2. Presentacin del caso prctico
En este apartado presentaremos un caso prctico que servir de hilo conductor

a lo largo de los diferentes mdulos de este material en cuanto a los ejemplos
que se irn presentando. Se trata de un sistema de informacin para una agencia de viajes mayorista ficticia que denominaremos Viajes UOC.
A continuacin, se presentan unos fragmentos de las entrevistas hechas a ciertas personas clave de la organizacin, que son, evidentemente, stakeholders,
para ver qu esperan del nuevo sistema.
El caso prctico no se presenta completo en el sentido de que un caso realista
completo queda fuera del espacio disponible en este mdulo. Por esta razn,
estas entrevistas no se transcriben completas y no contienen todos los requisitos ni todo el nivel de detalle que se encontrara en un caso real. Aun as,
las entrevistas s que son cercanas a un caso real en cuanto que se reproducen
en lenguaje natural y contienen las ambigedades y contradicciones que son
comunes en casos reales.
Joan Salvat, empleado de una agencia de viajes franquiciada
Todava recuerdo cuando se puso en marcha el sistema actual. Estuvimos tres meses sin
casi vender nada porque no ramos capaces de usar el nuevo sistema, puesto que nadie
nos haba explicado cmo hacer las cosas. Lo que pedira a los informticos es que o bien
hagan un sistema que se pueda usar para vender viajes sin necesidad de formacin o bien
nos hagan una formacin sobre la herramienta. En cualquier caso, no querra estar ms
de dos semanas con esta sensacin de no encontrar nada. Sinceramente, no creo que sea
tan difcil de conseguir lo que pido, hay muchas webs como Facebook o Hotmail que te
permiten hacer cosas igual de complicadas sin necesitar ninguna formacin.
En cuanto a los aspectos ms relacionados con mi trabajo, me da miedo que, si abrimos
el nuevo sistema en Internet, la gente no vendr a la agencia y no podremos asesorarlos
adecuadamente. Lo que ms me gusta de mi trabajo es, precisamente, ayudar al cliente
a elegir el destino, presentarle las diferentes alternativas y ayudarlo a elegir. Por ejemplo,
yo tengo mis hoteles preferidos en los destinos habituales y s cules tendran que evitar.
Por lo tanto, si la relacin con el cliente debe ser a travs de Internet, el sistema me tiene
que permitir dar esta misma informacin a travs del nuevo canal y, evidentemente,
el cliente ha de saber que la informacin le ha venido de Joan Salvat de la agencia de
la calle Mallorca y que, si le gusta mi criterio, puede consultar otras recomendaciones
mas o, mejor todava, pedir una cita para hablar conmigo sobre su viaje. Sin esto, nos
convertiremos en burcratas que solo hacen que despachar documentos de viaje y ser
una situacin muy triste para m como profesional.
Otra cosa que nos han pedido algunos clientes es poder crear un documento con el plan
de viaje donde figure informacin sobre traslados (horario de un vuelo, aeropuerto, terminal y compaa), hoteles (nmero de noches, telfono del hotel, etc.) y otros servicios
contratados. Este documento les puede servir a ellos para tener un resumen del viaje o,
incluso, para compartirlo con amigos y familiares para que sepan, en todo momento,
dnde los pueden localizar.
Adems de la entrevista mantenida con l, de Joan obtenemos un plan de viaje

que ha elaborado a mano:
12
13
Maria Costa, propietaria de una agencia de viajes franquiciada

Lo que espero del nuevo sistema es que me aporte nuevos clientes (especialmente gente
joven, que est muy acostumbrada a organizarse los viajes a travs de Internet) y que,
al mismo tiempo, no haga que mis clientes habituales dejen de venir a la agencia ahora
que pueden organizarse los viajes desde casa.
Se me ocurre, por ejemplo, que podemos hacer que los viajes se tengan que pagar en la
agencia para asegurarnos de que ningn cliente contrata un viaje sin venir en persona
ni una vez a la agencia. As pues, el cliente puede organizar el viaje (elegir el destino, las
fechas, el hotel, el avin, si quiere coche de alquiler, etc.) por Internet pero, a la hora de
hacer el pago, ha de venir a la agencia.
Tengo que trasladar tambin la preocupacin de Mart, un empleado de la agencia, respecto a la posibilidad de convertirnos en personal de apoyo del nuevo sistema; es decir,
que la gente lo haga todo por Internet y solo nos llame cuando no saben usar el nuevo
sistema o cuando han tenido algn problema informtico. Como muy bien dice Mart,
el nuevo sistema debe hacer su trabajo ms fcil y no complicarlo. De todos modos, supongo que los informticos ya habrn pensado en un mecanismo para que los clientes
puedan solucionar sus problemas informticos sin tener que ir o hablar con alguien de
la agencia.
Tambin en esta lnea quiero remarcar que el sistema tendra que funcionar sin necesidad
de formacin adicional, puesto que la media de empleados por agencia de la cadena es
de 3 personas y, por lo tanto, puede ser complicado coordinar las formaciones.
Dolors Snchez, propietaria de una agencia de viajes franquiciada
Si tengo que pagar por un sistema nuevo, este me ha de permitir tener un espacio propio
para mi agencia, para que mis clientes sepan que estn trabajando conmigo y no con
cualquier otra agencia. Adems, como tenemos acuerdos con mayoristas al margen de la
cadena, el sistema me tendr que permitir dar de alta estos productos que solo vendo yo
y definir las campaas de publicidad que se mostrarn a mis clientes.
Por otro lado, el nuevo sistema debe permitir reducir el coste del mantenimiento de mi
infraestructura informtica y no complicarla, pero no me fo de las aplicaciones web.
Tengo que poder trabajar cuando no haya red pero no quiero tener que contratar una
persona para que me configure los servidores, me haga las copias de seguridad, etc.
Marc Garca, director financiero de Viajes UOC
Ahora mismo, lo que ms me preocupa es de dnde sacaremos el dinero para financiar
este proyecto, puesto que estamos bastante endeudados por el programa de expansin
que llevamos a cabo el ao pasado, del cual no se espera obtener nuevos rendimientos
hasta de aqu a un par de aos. Adems, tenemos una inversin muy fuerte comprometida de aqu a dos aos y, por lo tanto, no podemos llegar ms endeudados de lo que estamos actualmente: la inversin se debera recuperar en menos de dos aos o no hacerse.
En este sentido, hemos de tener en cuenta que la red de agencias est formada por 95
agencias (se espera que sean 200 una vez finalizado el plan de expansin).
Problemas de financiacin aparte, me gustara que el nuevo sistema me ofreciera informacin consolidada de las ventas en todas las agencias, puesto que, ahora mismo, cada
agencia usa un sistema de facturacin independiente y nos cuesta mucho hacer los informes de facturacin. Ya puestos, se tendra que integrar con nuestro sistema de facturacin para evitar que Maria (trabajadora de mi departamento) dedique tres das cada
mes a copiar manualmente la informacin de un lugar al otro.
14
Snia Cases, directora de marketing de Viajes UOC

Creo que el nuevo sistema es una gran oportunidad para consolidar el valor de la marca
en los mercados emergentes gracias a las nuevas tecnologas y la web social 2.0.
El sistema tiene que permitir unificar la presencia en Internet de todas las agencias bajo
la marca nica Viajes UOC y potenciar la idea de que da igual con qu agencia trabaje
el cliente puesto que siempre tendr el apoyo de Viajes UOC. Por ejemplo, el sistema
debe evitar que una agencia defina sus propias campaas de marketing o que ofrezca
productos que no sean de Viajes UOC, puesto que esto fomenta la competencia entre
agencias de la cadena y disminuye el valor de la marca.
Por otro lado, queremos que los clientes puedan recomendar en las redes sociales los
viajes que ofrecemos y que puedan escribir sus opiniones sobre los hoteles, las compaas,
etc. Tambin queremos una aplicacin para Facebook que permita publicar en el muro de
los clientes informacin sobre sus vacaciones (cosas del tipo Gerard Lpez est pensando
si ir a Costa Rica o a China este verano o Gerard Lpez acaba de volver de su viaje a
Brasil).
Por ltimo, un amigo mo abogado me ha dicho que para cumplir la ley de proteccin
de datos es necesario que el sistema guarde constancia de todos los accesos que se hacen
a informacin personal de los clientes y que, para evitar problemas en caso de robo de
datos, lo mejor sera guardar estos datos de manera encriptada en la base de datos. Esto
s, no me preguntis cules son estos datos personales ni cmo se tienen que encriptar
porque no lo s.
Albert Jorba, director comercial de Viajes UOC
El nuevo sistema nos tiene que ayudar a vender la franquicia a otras agencias, sobre todo
si ofrecemos algn tipo de versin demo o periodo de pruebas para que los propietarios
de las agencias puedan ver las ventajas del nuevo sistema.
Por otro lado, tambin nos debera servir para vender productos complementarios. Por
ejemplo, si llegamos a un convenio con una compaa aseguradora, el sistema nos tiene
que permitir ofrecer los seguros de la compaa cada vez que un cliente compra un viaje.
15
3. Tipos de requisitos
Como hemos visto, las principales problemticas que debemos resolver en la

ingeniera de requisitos son problemticas propias de la comunicacin entre
personas y, una de ellas, es la limitacin del lenguaje utilizado. Por esta razn,
es especialmente interesante establecer y definir correctamente un vocabulario
comn, de tal manera que todos los participantes en el proceso de la ingeniera
de requisitos entiendan lo mismo cuando se utiliza un determinado trmino.
En este apartado establecemos una taxonoma para tipificar los requisitos con
el fin de evitar la ambigedad a la hora de determinar el tipo de un requisito.
Cada obra e incluso cada organizacin usa su propia taxonoma, pero hay
ciertos puntos comunes en la mayora de ellas.
Hay que tener en cuenta, pues, que ninguna taxonoma puede clasificar cada
requisito en una nica categora indiscutible. Siempre habr casos en los que se
podr argumentar la pertenencia de un requisito a una u otra categora segn
el punto de vista que se tome.
3.1. Requisitos de producto
Los requisitos de producto definen aquellas necesidades o restricciones que los
stakeholders tienen sobre el producto que se desarrollar como tal. Es decir, nos
interesar que, una vez desarrollado, el producto satisfaga estos requisitos.
Algunos ejemplos de requisitos de producto del caso prctico son:
Como usuario quiero poder consultar las recomendaciones de los agentes sobre un
hotel.
El sistema debe conocer el nombre, los apellidos, la direccin de correo electrnico,

la direccin y el telfono de los clientes.
El sistema tiene que permitir a las agencias continuar trabajando aunque se pierda
la conexin en Internet.
Taxonoma
Una taxonoma es una coleccin de trminos de vocabulario controlados que se organiza en una estructura jerrquica.
16
Muchas veces, cuando se habla de requisitos a palo seco, por abuso del lenguaje, se quiere hacer referencia a requisitos de producto, por oposicin a los
requisitos de proceso.
Los requisitos de producto se pueden clasificar, a su vez en:
Requisitos funcionales.
Requisitos no funcionales.
3.1.1. Requisitos funcionales

Los requisitos funcionales hacen referencia a la funcionalidad que debe proporcionar el sistema y los datos que tiene que conocer y guardar. Nos indican
qu clculos hace el sistema, qu datos mantiene, cmo los manipula, etc.
Podemos distinguir, dentro de los requisitos funcionales, entre los requisitos
de funcionalidad y los de datos.
Los requisitosdefuncionalidad, en general, describen cul tiene que ser el

comportamiento del sistema explicando qu respuesta debe dar ante los estmulos que le llegan desde el exterior. Por respuesta nos referimos a qu respuesta observable desde fuera, considerando el sistema como una caja negra.
Algunos ejemplos de requisitos funcionales de funcionalidad del caso prctico son:
Como usuario quiero poder consultar las recomendaciones de los agentes sobre un
hotel.
Como directora de marketing, quiero que los clientes puedan recomendar en las redes
sociales los viajes que ofrecemos.
Los requisitosdedatos describen qu datos tiene que conocer el sistema. Estos

son, tpicamente, datos que el sistema guardar de modo persistente.
Analizando el plan de viaje proporcionado por Joan Salvat podemos descubrir muchos
requisitos de datos del caso prctico. Un par de ejemplos pueden ser:
El sistema tiene que conocer el cliente de un viaje; en particular, debe saber el nombre,
los apellidos, la direccin de correo electrnico, la direccin postal y el telfono.
El sistema tiene que conocer el hotel u hoteles de un viaje. De los hoteles tiene que
saber el nombre, la direccin y el telfono. En relacin con el viaje tiene que saber las
fechas de entrada y salida, las horas de check-in y check-out, el tipo de habitacin,
las observaciones del hotel y la opinin del agente que ha reservado el viaje.
17
3.1.2. Requisitos no funcionales

Los requisitos no funcionales son aquellos requisitos de producto que, como
su nombre indica, no son funcionales sino calidades esperadas del sistema,
como por ejemplo usabilidad, fiabilidad, rendimiento o mantenibilidad. Son,
por lo tanto, restricciones sobre el conjunto de soluciones tales que si una
Terminologa
Los requisitos no funcionales
se denominan, tambin, requisitos de calidad.
solucin no satisface aquella calidad, no se considera vlida.

Los requisitos no funcionales suelen afectar a gran parte del sistema.
Por ejemplo, si decimos que el sistema de Viajes UOC tiene que ser porttil a otras plataformas, esto no afecta solamente a la recomendacin de hoteles o a la publicacin de la
opinin en Facebook, sino que afecta a todo el sistema.
Muchos autores y organismos de estandarizacin han intentado elaborar una

taxonoma completa de requisitos no funcionales que se han de tener en cuenta. Veremos, a continuacin, la que propone la plantilla Volere:
Requisitosdepresentacin. Hacen referencia al aspecto visual del sistema y tienen en cuenta aspectos como la imagen corporativa de la organizacin.
Un posible requisito conforme que todas las pantallas de la aplicacin tienen que mostrar el logo de Viajes UOC, que no aparece en las entrevistas, sera un requisito de presentacin.
Requisitosdeusabilidadyhumanidad. Son los relacionados con el hecho de que el sistema sea ergonmico y usable. Estos factores dependern
de las capacidades de los usuarios y de la complejidad de la funcionalidad.
Hay que tener en cuenta requisitos de eficiencia de uso, facilidad de aprendizaje, tasa de errores, nivel de satisfaccin, etc.
La necesidad de poder usar el sistema con poca o nada formacin, mencionada tanto por
Joan Salvat como por Maria Costa, es un requisito de usabilidad y humanidad.
Requisitosdecumplimiento. Se trata de los requisitos sobre la manera de

cumplir las responsabilidades del sistema, incluyendo caractersticas como
la velocidad, la latencia, la fiabilidad, la robustez, etc.
El requisito de que el sistema ha de permitir a las agencias continuar trabajando aunque
se pierda la conexin a Internet, pedido por Dolors Snchez, es un ejemplo de requisito
de cumplimiento.
Requisitosoperacionalesydeentorno. Agrupan los requisitos relativos

a la manera o el entorno en el que se usar el software, como por ejemplo
el entorno fsico en el que se usar.
Un requisito de que el sistema sea usable tanto desde ordenadores de escritorio como
desde dispositivos mviles sera un requisito operacional y de entorno.
Podis ver la referencia completa a la plantilla Volere en
el apartado de bibliografa.
18
Requisitosdemantenimientoysoporte. Hacen referencia a los requisitos

relativos al mantenimiento (correctivo y evolutivo) del sistema y al soporte
a los usuarios de este.
La peticin de Dolors Snchez de que el sistema sea fcil de mantener es un ejemplo de
requisito de mantenimiento y soporte.
Requisitosdeseguridad. Son, como su nombre indica, los que se ocupan

de la seguridad del sistema, incluyendo aspectos como permisos de acceso,
integridad, privacidad, auditora, etc.
Las necesidades expresadas por Snia Cases de encriptar la informacin personal y grabar
el acceso a esta informacin de carcter personal son dos requisitos de seguridad. A su
vez, tambin son requisitos legales, como comentaremos ms adelante.
Requisitosculturalesypolticos. Son aquellos que tienen en cuenta aspectos culturales y polticos de los usuarios.
Un requisito cultural tpico es lo referente al idioma de los usuarios. As, quiz querremos
que Viajes UOC pueda usarse en cataln, castellano e ingls. Esto no solo implica mostrar
los mensajes en el idioma adecuado, sino tambin usar el formato que sea necesario para
las fechas, los nmeros, etc.
As, por ejemplo, una fecha como 1/3 puede querer decir el uno de marzo o el tres de enero
segn el mbito cultural del usuario. De manera parecida, la semana podra empezar el
lunes o el domingo.
Requisitoslegales. Son requisitos que hay que satisfacer en virtud de la ley

que se aplicar sobre la organizacin responsable del sistema, pero tambin
requisitos de aplicacin de estndares reconocidos.
Como ya se ha comentado, los requisitos de seguridad mencionados por Snia Cases son,
a la vez, requisitos legales, puesto que hay una ley, la LOPD, que exige el cumplimiento
de ciertas medidas de seguridad cuando se guardan datos de carcter personal.
LOPD
LOPD son las siglas de la Ley
Orgnica 15/1999 de Proteccin de Datos de Carcter Personal de Espaa, una ley orgnica espaola que tiene por
objetivo garantizar y proteger
los datos personales, las libertades pblicas y los derechos
fundamentales de las personas
fsicas, y especialmente su intimidad y privacidad personal y
familiar.
19
3.2. Requisitos de proceso

Los requisitos de proceso establecen restricciones en el propio proceso de desarrollo de software en lugar de hacerlo sobre el producto final desarrollado.
Cualquier necesidad o restriccin que no sea del producto una vez terminado
sino del proceso que se sigue para completarlo ser, por lo tanto, un requisito
de proceso.
Uno de los requisitos de proceso ms importante es el coste de desarrollo, tanto en tiempo como en dinero. A pesar de no tratarse de una caracterstica observable en el producto ya desarrollado, s que lo es en el proceso. Y, evidentemente, los stakeholders tendrn necesidades y restricciones que imponer.
20
4. El proceso de la ingeniera de requisitos
Tal y como hemos visto anteriormente, el proceso concreto que seguiremos

en un proyecto de software dado depender en gran medida del mtodo de
desarrollo que estemos siguiendo, la medida y cultura de la organizacin para
la cual lo estamos desarrollando, as como otros factores, como la proximidad
geogrfica entre stakeholders y desarrolladores. En realidad, como veremos, no
se puede desligar el proceso de la ingeniera de requisitos del proceso de la
ingeniera del software.
No obstante, sea cual sea la metodologa seguida, tal y como se ha dicho, hay
una serie de actividades que son comunes y fundamentales a todos los proyectos en cuanto a la ingeniera de requisitos.
4.1. Obtencin de requisitos
La obtencin de requisitos consiste en determinar cules son las necesidades
de los stakeholders. Para ello, habitualmente, hay que observar y escuchar a los
stakeholders, a pesar de que puede haber otras fuentes de informacin interesantes, como por ejemplo las posibles soluciones de la competencia, las capa-
Elicitacin
La obtencin de requisitos
tambin es denominada, por
algunos autores, elicitacin.
cidades de la tecnologa, los sistemas (informticos o no) usados hasta ahora

para satisfacer estas necesidades, etc.
Por lo tanto, durante esta actividad se recoger mucha informacin sobre necesidades y deseos de los stakeholders, a muchos varios niveles de detalle.
En nuestro ejemplo nos podemos encontrar con que un stakeholder quiere vender viajes
en todo el mundo y que quiere que el sistema calcule la conversin entre divisas. Las
dos necesidades pueden ser requisitos, a pesar de que estn a niveles de detalle muy
diferentes.
Los requisitos recogidos durante la obtencin, por lo tanto, enumeran todas

las necesidades y deseos de los stakeholders que hayamos descubierto. Pero,
generalmente, el sistema que vamos a desarrollar no podr satisfacer todas
estas necesidades y deseos por dos motivos:
Entre los distintos stakeholders habr necesidades en conflicto, de tal modo

que una misma solucin no podr satisfacer las necesidades de todos los
stakeholders.
Como dispondremos de una capacidad limitada (en personas, tiempo y

presupuesto) es muy probable que no podamos desarrollar un sistema que
satisfaga todas las necesidades que los stakeholders puedan tener.
Ved tambin
Veremos con ms detalle la
obtencin de requisitos en el
mdulo Obtencin de requisitos.
21
Por ello, decimos que la obtencin de requisitos tiene que dar, como resultado,
un conjunto de requisitos candidatos.
Un requisito candidato es una necesidad o deseo expresada por un

stakeholder que podra convertirse en un requisito del sistema pero que
quiz no se tiene en cuenta a la hora de desarrollar el software.
Tal y como hemos dicho anteriormente, un posible motivo para no incluir un

requisito candidato es que este entre en conflicto con algn otro requisito que
s que queremos incluir.
En nuestro caso, Dolors Snchez nos pide un espacio propio para su agencia mientras
que Snia Cases nos pide que el nuevo sistema ayude a consolidar la imagen de marca
de Viajes UOC y potenciar la idea de que da igual con qu agencia trabaje el cliente.
En este caso, es muy probable que seamos incapaces de satisfacer las dos necesidades a
la vez y que, por lo tanto, hayamos de descartar o bien el requisito de Dolors o bien el
de Sonia.
Otro caso habitual es que el requisito se considere insuficientemente importante o prioritario como para justificar la inversin necesaria para su desarrollo.
Por ejemplo, Marc Garca nos pide que el nuevo sistema de ventas se integre con el sistema
de facturacin para evitar que Maria pierda tres das al mes en copiar la informacin de
un lugar al otro. Todava no sabemos cul es el coste de desarrollar esta integracin y, por
lo tanto, todava no sabemos si ser rentable o no para Viajes UOC incluir este requisito
o si bien es preferible descartarlo o encontrar una solucin intermedia.
La obtencin de requisitos, como veremos ms adelante, no se puede limitar

a recopilar los requisitos conocidos del sistema, sino que incluye un proceso
creativo de descubrimiento de nuevos requisitos que inicialmente no sabamos que estaban. Por este motivo, a menudo se usan trminos como evocacin/extraccin de requisitos (requirements elicitation).
4.2. Gestin de requisitos
En la introduccin hemos visto que la ingeniera de requisitos tiene un gran
impacto econmico en la industria del desarrollo de software, puesto que si
elegimos los requisitos equivocados, el esfuerzo de desarrollo no tendr el retorno esperado.
Una mala gestin de requisitos puede hacer que un proyecto que se haya ejecutado de manera impecable desde el punto de vista de gestin de proyectos
sea un fracaso absoluto puesto que no cubre la necesidad para la cual se decidi llevar a cabo el proyecto.
Por este motivo, es necesario determinar cules de los requisitoscandidatos
formarn parte, finalmente, de los requisitos del producto que vamos a desarrollar. Para determinarlo, hay que decidir cules son los requisitos ms impor-
Ved tambin
gestin de requisitos en el mdulo Gestin de requisitos.
22
tantes, cul es el coste de implementacin de los diferentes requisitos (y cul

es la capacidad con la que contamos para implementarlos), as como resolver
los conflictos que pueda haber entre requisitos.
Dentro de la gestin de requisitos podemos discernir varias actividades:
1) El anlisisdelosrequisitos consiste en entender bien los requisitos candidatos e identificar dependencias, solapamientos y conflictos que puedan tener.
2) De cara a facilitar la posterior seleccin de requisitos, hay que priorizar los
requisitos asignando, a cada uno, un valor de la importancia que tiene aquel
requisito candidato para el conjunto de los stakeholders. Este valor tendr que
ser una nica medida que resuma las necesidades de todos los stakeholders y se
deber determinar a partir del valor que d cada stakeholder a aquel requisito,
la importancia que tenga aquel stakeholder en el conjunto, etc.
3) Por otro lado, adems de la importancia de cada requisito hay que estimar el
esfuerzo que supondra tenerlo en cuenta, puesto que un requisito candidato
con cierto valor puede ser descartado como requisito para tener un coste de
desarrollo demasiado elevado y puede ser sustituido, por ejemplo, por otro
requisito de menos valor pero con un coste de desarrollo muy bajo.
4) Una vez tenemos una lista de requisitos candidatos etiquetados con el valor
y coste, podemos proceder a hacer una seleccin para determinar el conjunto de requisitos que se tendr en cuenta (para el proyecto o iteracin actual)
atendiendo a la capacidad del equipo de desarrollo.
Hay que seleccionar un conjunto de requisitos que sea consistente (no puede haber, por ejemplo, requisitos seleccionados contradictorios o requisitos
seleccionados que dependan de requisitos no seleccionados), que maximice el
valor total y que se pueda hacer con los recursos limitados disponibles.
5) Las actividades de anlisis, priorizacin, estimacin y eleccin no se podrn hacer de manera secuencial solo al inicio, puesto que los requisitos son
cambiantes. Por lo tanto, habr que hacer, adems, una gestindelcambio
de los requisitos. Esta gestin debe mantener, en todo momento, una lista de
requisitos que refleje las necesidades que en aquel momento sabemos que el
sistema tiene que satisfacer.
4.3. Documentacin de requisitos
Los requisitos seleccionados durante la gestin de requisitos son aquellos que
se tendrn en cuenta para desarrollar el sistema. Para comunicar cules son
estos requisitos al equipo de desarrollo y a los stakeholders se necesita, pues,
documentarlos, puesto que, en la mayora de los proyectos, una comunica-
Ved tambin
documentacin de requisitos
en el mdulo Documentacin
de requisitos.
23
cin exclusivamente oral y confiar en la memoria de los implicados no ser

suficiente. El documento donde se recogen los requisitos se conoce como especificacin:
La especificacin de requisitos recoge el contrato entre los desarrolladores y los stakeholders y sirve como herramienta de comunicacin para
los dos grupos. Por ello, resulta un elemento central de cualquier mtodo de desarrollo, especialmente en cuanto a la gestin del proyecto.
Las historias de usuario, los casos de uso y el lenguaje UML son herramientas
habituales usadas en la documentacin de requisitos para grabarlos a varios
niveles de detalle y, a la vez, usar una forma de documentacin que todos los
implicados puedan entender.
La documentacin de requisitos puede ser tan simple como una frase que resuma cada requisito y contar, para el resto, que desarrolladores y stakeholders
conversen y recuerden lo que se ha dicho. De lo contrario, la documentacin
de requisitos puede ser tan exhaustiva como se quiera.
Una simplicidad excesiva implica riesgos respecto a la interpretacin de los
detalles de los requisitos, puesto que se podra perder informacin. Es necesario, pues, que la documentacin sea suficientemente detallada para minimizar
estos riesgos.
Por otro lado, una documentacin demasiado costosa de elaborar puede ser
difcil de mantener, especialmente si los requisitos van cambiando. Y no solo
no tendra ningn valor, sino que tendra una repercusin negativa si deviene
obsoleta por los cambios de requisitos y no es actualizada a medida que estos
cambian.
Por tanto, en cada proyecto, hay que disponer de la documentacin necesaria
(para grabar los requisitos y comunicarlos entre el equipo y los stakeholders)
que sea posible elaborar y mantener a lo largo del desarrollo con los recursos
disponibles.
4.4. Validacin de requisitos
Una vez obtenidos los requisitos candidatos, seleccionados y documentados,
ya disponemos de una documentacin que, en principio, refleja las necesidades de los stakeholders sobre el sistema que se desarrollar. Pero, muchas veces,
durante las actividades que nos han trado a este punto se cometen errores que
pueden provocar que los requisitos documentados no reflejen correctamente
lo que los stakeholders quieren.
Ved tambin
validacin de requisitos en el
mdulo Validacin y verificacin de requisitos.
24
La validacin derequisitos consiste en asegurarnos de que los requisitos

que hemos elegido para el producto que estamos desarrollando reflejan
las expectativas de los stakeholders.
Algunos errores comunes que se pueden producir y que hay que detectar y
corregir durante la validacin son errores de comprensin de la necesidad de
los stakeholders, errores de gestin de requisitos y, sobre todo, errores de documentacin.
4.5. Verificacin de requisitos
Si todo el propsito del desarrollo del sistema es conseguir un sistema que
satisfaga los requisitos de los stakeholders, es obvio que hay que verificar, antes
de dar el sistema por bueno, que satisfaga realmente estos requisitos.
La verificacinderequisitos consiste en hacer las pruebas necesarias

sobre el sistema desarrollado (o que se est desarrollando) para comprobar si satisface los requisitos que se esperaba.
Hay que tener en cuenta que se deben verificar todos los tipos de requisitos y
que cada tipo demandar una forma diferente de verificacin. As, hablaremos
de pruebas funcionales para referirnos a las pruebas que hacemos para verificar que el sistema satisface los requisitos funcionales. En cuanto a los requisitos no funcionales, hablaremos de pruebas de estrs, pruebas de rendimiento,
pruebas de usabilidad, etc. y toda una serie de tipos de pruebas diferentes para
verificar cada tipo de requisito no funcional.
Si, una vez que se ha verificado que un sistema satisface unos requisitos, el sistema o los requisitos cambian, hay que volver a comprobar si el sistema todava satisface los requisitos (nuevos y previamente existentes). Por este motivo,
en muchos casos es interesante automatizar el proceso de pruebas para poder
realizar la verificacin en el mnimo coste posible.
Ved tambin
Veremos con ms detalle la verificacin de requisitos en el
mdulo Validacin y verificacin de requisitos.
25
5. Requisitos del caso prctico
En este apartado estudiaremos el caso prctico desde el punto de vista de los

stakeholders, las problemticas propias de la comunicacin con ellos, los tipos
de requisitos y el proceso de la ingeniera de requisitos.
5.1. Identificacin de stakeholders
En el caso prctico, tal como se ha presentado, ya tenemos identificados ciertos
stakeholders, que son los que se han entrevistado:
JoanSalvat, empleado de una agencia de viajes franquiciada.
MariaCosta, propietaria de una agencia de viajes franquiciada.
DolorsSnchez, propietaria de una agencia de viajes franquiciada.
MarcGarca, director financiero de Viajes UOC.
SniaCases, directora de marketing de Viajes UOC.
AlbertJorba, director comercial de Viajes UOC.
Adems de los ya identificados, podemos identificar otros stakeholders. Una

lista no exhaustiva de otros stakeholders que podemos identificar incluye:
Losclientes de la agencia de viajes, por ejemplo, son tambin stakeholders,

puesto que usarn el sistema.
Marc Garca menciona a Maria, una persona de su departamento que se

podra ahorrar bastante trabajo con el nuevo sistema y que, por lo tanto,
tambin es una stakeholder.
Mara Costa menciona a alguien llamado Mart, un empleado de la agencia que no quiere convertirse en personal de apoyo y que, por lo tanto,
tambin es un stakeholder.
Todas las personasquetenganqueinteractuartcnicamenteconelsistema tambin sern stakeholders. Esto incluir a las personas que lo instalen, que lo administren y que le den soporte, por ejemplo.
5.2. Problemticas
A lo largo del desarrollo del proyecto hay que tener en cuenta las problemticas
de la ingeniera de requisitos ya mencionadas.
Otros stakeholders
Estos solo son algunos de los
stakeholders que no habamos identificado todava, pero
la lista puede ser muy larga y
depender, en cada caso, de
la organizacin y el proyecto
concretos.
Otros ejemplos de stakeholders que se deben tener en
cuenta son organismos reguladores, otras empresas con las
que hayamos de interactuar,
etc.
26
As, por ejemplo, en este caso se han usado entrevistas que se han transcrito
para comunicar los requisitos. Al hacer la transcripcin, se habrn perdido
detalles y matices de la comunicacin oral.
Por otro lado, como ejemplo adicional de una problemtica que nos podemos
encontrar en Viajes UOC, los conocimientos de la tecnologa seguramente estarn afectando a los stakeholders, que estarn expresando sus requisitos a partir de los que ya conocen. Es probable, pues, que haya requisitos que no hayan
sido identificados porque los propios stakeholders no sepan que los tienen, en
el sentido de que son caractersticas que quieren sin saberlo.
5.3. Tipos de requisitos
5.3.1. Requisitos de producto no funcionales

A continuacin se listan algunos de los requisitos no funcionales que se pueden detectar a partir de los fragmentos de entrevistas disponibles. Para cada
ejemplo se dar una frase corta que identifique el requisito, una descripcin,
su tipo (segn la plantilla Volere), los stakeholders que estn interesados y unos
posibles criterios de aceptacin.
Ved tambin
Podis ver los tipos de requisitos de la plantilla Volere en el
subapartado 3.1.2 de este mdulo.
Requisito
Tiene que poderse usar sin formacin previa.
Descripcin
El sistema se debe poder utilizar sin necesidad de recibir formacin previa.
Tipo
Usabilidad y humanidad
Criterios de aceptacin
Se har una prueba piloto con empleados de las agencias y estos tienen que ser capaces de dar informacin y vender un viaje sin haber recibido formacin previa.
Stakeholders
Joan Salvat (empleado de agencia de viajes)

Mara Costa (propietaria de agencia franquiciada)
Cuestiones pendientes
Alternativamente, se puede considerar dar una formacin mnima, pero, en un mximo de dos semanas,
el personal tiene que poder usar el nuevo sistema.
Requisito
Tiene que ser fcil de mantener.
Descripcin
El sistema debe ser fcil de mantener sin necesidad de contratar personal para hacer la configuracin de
los ordenadores.
Las copias de seguridad se harn de manera totalmente automatizada.
Tipo
Mantenimiento y soporte
Se har una prueba piloto con personal de las agencias de modo que, con un PC con el SO acabado de
instalar sean capaces de conectarse a los servidores en menos de 30 minutos.
Stakeholders
Dolors Snchez (propietaria de agencia franquiciada)
Requisito
Tiene que poder trabajar sin red.
27
Descripcin
El sistema debe permitir que una agencia pueda vender viajes cuando no haya red.
Tipo
Operacional
Se har una prueba piloto que consistir en desconectar de la red una oficina y verificar que puede acceder a la informacin necesaria para vender un viaje.
Stakeholders
Dolors Snchez (propietaria de agencia franquiciada)
Requisito
Tiene que soportar 200 agencias.
Descripcin
El sistema debe soportar 95 agencias en el momento de la puesta en produccin y tiene que poder crecer hasta 200 agencias a lo largo de dos aos.
Cada agencia tiene una media de 3 empleados, lo cual hace que el volumen estimado de usuarios sea
de 600 + el personal propio de Viajes UOC.
Tipo
Cumplimiento (escalabilidad)
Se har una prueba de carga con usuarios simulados.
Stakeholders
Marc Garca (director financiero)
Requisito
Tiene que guardar constancia de todos los accesos a informacin personal de los clientes.
Descripcin
En cumplimiento de la LOPD, el sistema debe guardar constancia de todos los accesos que se hacen a
informacin personal de los clientes.
Tipo
Legal/Seguridad
Se acceder a la informacin personal de un cliente aleatorio y se verificar que el acceso ha quedado

registrado.
Se har una auditora especfica para el cumplimiento con la LOPD.
Stakeholders
Snia Cases, directora de marketing

Departamento legal de Viajes UOC
Definir exactamente qu datos se consideran personales.
5.3.2. Requisitos de productos funcionales

Nos centraremos ahora en la entrevista de Joan Salvat, el empleado de la agencia franquiciada. Elaboraremos una lista de requisitos funcionales que aparecen en su entrevista usando el formato de historia de usuario: Como <rol> quiero <requisito>.
Como cliente quiero informarme de un destino.
Como cliente quiero ver la informacin de un viaje que he comprado.
Como agente quiero introducir una recomendacin.
Como cliente quiero consultar recomendaciones.
Como cliente quiero contratar un viaje por Internet.
Como cliente quiero pedir una cita con un agente.
Como agente quiero contratar un viaje para un cliente.
28
Como cliente quiero consultar el plan de viaje.
5.3.3. Requisitos de proceso

En Viajes UOC tambin podemos identificar algunos requisitos de proceso.
As, por ejemplo, Marc Garca, el director financiero, dice que la inversin se
tendra que recuperar en menos de dos aos o no hacerse. Este objetivo se traduce en un requisito segn el cual el coste de desarrollo debe estar por debajo
de una cierta cantidad; este es, claramente, un requisito de proceso, puesto
que no es observable en el producto ya acabado, sino que es un requisito sobre
el proceso de su desarrollo.
De manera parecida, si hubiera requisitos sobre la metodologa de desarrollo
que hay que emplear, los horarios que tiene que hacer el equipo de desarrollo,
el idioma en el que se celebrarn las reuniones durante el desarrollo, etc. se
tratara de requisitos de proceso.
5.4. El proceso de la ingeniera de requisitos
En cuanto al proceso de la ingeniera de requisitos, a continuacin se proporcionan ejemplos concretos de las distintas actividades que lo forman en el
contexto del caso prctico.
As, durante laobtencinderequisitos, se han hecho las entrevistas que se
han transcrito. En las entrevistas, como es normal, hay informacin a muchos
niveles de detalle y detectamos necesidades muy variadas por parte de los stakeholders.
Como parte de la gestinderequisitos, por lo tanto, hay que analizar los requisitos recogidos para asegurarse de que los hemos entendido bien y detectar
dependencias, solapamientos y conflictos.
En nuestro caso, entre los deseos de los stakeholders los hay que entran en conflicto.
Dolors Snchez (la propietaria de un agencia franquiciada), por ejemplo, quiere que el
sistema le permita dar de alta productos que solo ella vende y que son de otros mayoristas,
mientras que Snia Cases (directora de marketing) quiere que el sistema evite que una
agencia (...) ofrezca productos que no sean de Viajes UOC. No ser posible, por lo tanto,
satisfacer a todos los stakeholders.
Por otro lado, con una capacidad limitada en tiempo y recursos ser imposible
satisfacer todas las demandas de todos los stakeholders. Para poder seleccionar
cules de los requisitos candidatos que nos piden podemos llevar a cabo, hay
que estimar qu coste tiene incluir cada requisito en el sistema y priorizarlos
segn cules son ms o menos importantes.
As, en el ejemplo antes mencionado, una vez identificado el conflicto entre los dos requisitos, habr que estimarlos y decidir una prioridad. A partir de aqu, uno de los requisitos puede ser seleccionado para tenerse en cuenta. Quiz se decida, por ejemplo, que lo
que pide Snia Cases es ms prioritario y, a la vez, menos costoso y, por lo tanto, quiz
se selecciona como requisito, descartando el requisito candidato de Dolors.
29
La actividad de documentacinderequisitos consistir en documentar los

requisitos detectados.
As, para el requisito que Joan tiene de poder introducir una recomendacin, quiz se
documenta como una historia de usuario, si se sigue una metodologa gil con poca documentacin, o quiz se documenta en forma de caso de uso si se hace una documentacin ms exhaustiva.
La validacinderequisitos consistir en comprobar que los requisitos documentados expresan, realmente, las necesidades de los stakeholders y que no ha
habido errores en las actividades que nos han trado hasta la documentacin
que hemos hecho.
Finalmente, la actividad de verificacinderequisitos consistir en comprobar que el sistema satisface un requisito que se supone ya implementado.
As, por ejemplo, una vez desarrollada la parte del sistema usada por las agencias, se
podra comprobar si es cierto que satisface el requisito de soportar 200 agencias. Pero no
solo los requisitos no funcionales se han de verificar. Para verificar un requisito como
el de que los agentes puedan introducir recomendaciones, habr que comprobar que la
funcionalidad est implementada y funciona correctamente.
30
Resumen
En este mdulo hemos hecho un breve repaso a lo que ya sabamos sobre la

ingeniera de requisitos. Hemos visto que la ingeniera de requisitos es una
disciplina indispensable, puesto que tiene un impacto muy grande sobre el
resto del desarrollo del software. Hemos visto que la fuente principal de requisitos son los stakeholders pero que no siempre es fcil obtener los requisitos a
partir de nuestras conversaciones con ellos.
Hemos visto tambin algunos ejemplos de clasificacin de requisitos segn la
taxonoma propuesta por la plantilla Volere y hemos echado un primer vistazo
al proceso de la ingeniera de requisitos, que hemos dividido en cuatro etapas,
que estudiaremos en detalle en el resto de los mdulos:
Obtencin de requisitos candidatos.
Gestin de requisitos.
Documentacin de requisitos (especificacin).
Validacin de requisitos.
Verificacin de requisitos.
Por ltimo, hemos presentado el caso prctico que usaremos a lo largo de los
materiales para ilustrar los diferentes conceptos y tcnicas que iremos estudiando.
31
Actividades
Para las actividades de este mdulo plantearemos otro caso prctico, el de CrowdArt.
CrowdArt es una empresa de nueva creacin que quiere ofrecer una plataforma de crowdfunding de proyectos artsticos. El crowdfunding consiste en buscar financiacin directa basada
en micropagos que hacen personas de todas partes, a cambio de una pequea recompensa,
como puede ser una mencin en los ttulos de crditos de la obra o algn tipo de material
de promocin.
A continuacin presentamos algunas notas tomadas durante las entrevistas a diferentes personas implicadas en el proyecto:
1)ImmaNcher, emprendedora y propietaria de CrowdArt
Imma es la emprendedora que hay detrs del proyecto CrowdArt y nos ha explicado el origen
de esta idea.
CrowdArt nace con la vocacin de llenar un vaco en el pas en cuanto a la financiacin
de pequeas obras de teatro, cortometrajes y todo tipo de proyectos artsticos que no
pueden financiarse por los medios habituales.
La empresa ofrecer, bsicamente, una herramienta web mediante la cual los artistas
podrn proponer los proyectos que quieren financiar. Tendrn que proponer su proyecto
de manera atractiva y franca e indicar la financiacin mnima que necesitan para poderlo
llevar adelante. La idea es que si consiguen suficiente financiacin hagan el proyecto,
pero si no, no cobren dinero, puesto que no lo podrn llevar a cabo.
El negocio de CrowdArt consiste en cobrar a los artistas una comisin del 5% de la financiacin que recojan los proyectos exitosos. Adems, para evitar tener muchos artistas
usando la plataforma para darse visibilidad pero sin llegar a financiar sus proyectos, se
cobrarn 50 por cada proyecto que un artista d de alta en el sistema.
Para el pago por parte de los artistas, Imma quiere usar la pasarela de pago de La Faixa, puesto
que es el banco con el cual el director financiero de CrowdArt, a quien no hemos podido
entrevistar, quiere trabajar.
Pedimos a Imma que nos explique con ms detalle cmo quiere que funcione el crowdfunding
en CrowdArt.
De acuerdo. Lo primero es que los artistas propongan proyectos. Para hacerlo, el artista
tiene que indicar un ttulo, una descripcin y cualquier otro material audiovisual que
tenga para vender su proyecto a los posibles mecenas. Tambin tiene que decidir qu inversiones y recompensas quiere que se puedan hacer. As, por ejemplo, puede decidir que
por una aportacin de 10 har constar el nombre del usuario en los ttulos de crditos
de su obra, que por 30 , adems de los crditos, dar dos entradas para el espectculo,
etc. Finalmente, es necesario que indique la financiacin que necesita. Es importante que
hile cuidadosamente, puesto que los mecenas solo pagarn realmente las aportaciones
prometidas si el proyecto logra su objetivo.
Para evitar que el sistema se llene de spam y de proyectos poco interesantes, el alta de
proyectos en CrowdArt ser moderada: antes de que un proyecto sea publicado, un administrador de CrowdArt lo mirar y decidir si es apto, en cuyo caso se publicar automticamente, o no lo es. En el ltimo caso, se informara al artista del motivo y el proyecto
sera desestimado. El artista podra continuar haciendo propuestas de proyectos (ya sea
el mismo, con mejoras, o nuevos proyectos).
Una vez publicado, un proyecto tendr 40 das para reunir la financiacin necesaria. Durante este periodo, los posibles mecenas pueden financiarlo. Para ello, el sistema ofrecer
a los usuarios la posibilidad de buscar proyectos por varios criterios y consultar los detalles de un proyecto. Si el usuario est interesado, podr hacer una promesa de aportacin
por uno de los importes definidos por el artista que cre el proyecto.
Los usuarios tambin podrn consultar el perfil de otros usuarios, donde constarn los
proyectos iniciados y las aportaciones hechas a otros proyectos, adems de una fotografa
opcional, un texto descriptivo, etc.
Cuando finalice el plazo de un proyecto, si ha reunido la financiacin necesaria, el sistema cobrar a los mecenas las aportaciones que prometieron y marcar el proyecto como
exitoso. Si no ha reunido la financiacin necesaria, sencillamente se marcar el proyecto
32
como finalizado (sin xito). En ambos casos el proyecto continuar apareciendo en las
buscas, pero como finalizado y no se podrn hacer ms aportaciones.
Finalmente, si un artista tiene un proyecto finalizado con xito, lo podr cobrar. Para
ello, tendr que acceder a la web, indicar que quiere cobrar el proyecto y dar sus datos
bancarios. El sistema har una transferencia con el importe reunido (restando la comisin
de CrowdArt).
La web incluir, est claro, un pequeo apartado de comunicacin entre los posibles
mecenas de un proyecto y el artista que hace de promotor en el que, por un lado, los
mecenas puedan enviar mensajes a los promotores y, por otro, los promotores pueden
mantener un blog donde ir explicando a sus mecenas cmo evoluciona el proyecto.
2)SebastiReixach, un artista
Sebasti ha participado en varios proyectos financiados por crowdfunding y har de representante de los artistas que quieren financiar sus proyectos.
Esto del crowdfunding es un fenmeno curioso, porque algunos mecenas financian proyectos de manera desinteresada pero muchos quieren algn tipo de recompensa y prcticamente todos, un reconocimiento. Cuando he usado otras plataformas de crowdfunding
he echado de menos, sobre todo, la posibilidad de personalizar qu donaciones se pueden
hacer y qu ofrezco a cambio. Para cada proyecto, por lo tanto, quiero poder configurar
qu donaciones son posibles (por ejemplo, 5, 10, 40 o 150 ) y qu reconocimiento o
recompensa doy a cada una. Adems, como algunas recompensas son fsicas, hay que
poder indicar un nmero mximo de aportaciones por aquel valor. Recuerdo una vez
que ofrec una entrada para ver mi corto para quien aportara 10 y, por sorpresa ma,
tuve ms de 200 aportaciones de 10 ... No caba todo el mundo en la sala que haba
reservado y tuve que hacer dos proyecciones!
Otra experiencia problemtica que tuve, esta mucho peor, sucedi en una ocasin en la
que me fui enredando en sacar adelante una obra de teatro para la cual haba conseguido
la financiacin por crowdfunding pero uno de los inversores que se haba comprometido
en poner 1.000 result no existir o qu s yo. Solo s que al final tuve que pedir este
dinero a unos amigos. Si CrowdArt quiere conservar a sus artistas, es necesario que esto no
pueda suceder bajo ningn concepto y que sea CrowdArt quien se asegure, persiguiendo,
si es necesario, a quien no respete su compromiso y respondiendo por l.
Tambin es importante tener un espacio de discusin, tipo foro, donde poder resolver
dudas a los usuarios sobre tu proyecto. Algunos usuarios se lo piensan bastante antes de
hacer segn qu aportaciones y quieren tener informacin ms detallada.
Por otro lado, yo utilizo esta va de financiacin a menudo. Creo que esto es un mrito
que los posibles mecenas tienen en cuenta. Confan ms en m si ven que he llevado a
cabo otros proyectos con xito. Por ello, creo que es importante disponer de un espacio
donde presentarme, poner un poco de CV y donde salgan otros proyectos que ya he
financiado con xito en CrowdArt.
Para atraer a otros artistas para que propongan sus obras, habr que moverse en los mismos crculos que nosotros nos movemos. Muchos artistas no conocen todava el crowdfunding o solo han odo hablar del l. Por ello, sera interesante rebajar al mnimo las
barreras de entrada. As, por ejemplo, muchos preferirn no dar datos bancarios hasta
que algn proyecto suyo haya funcionado y tengan que cobrar dinero.
Es de vital importancia que la empresa, CrowdArt, solo se involucre en la financiacin
de la obra, por lo que nosotros conservamos todos los derechos de nuestras obras.
3)JliaMaim, directora tcnica de CrowdArt
El proyecto se desarrollar usando Ruby on Rails, puesto que es una plataforma que
conozco y que s que es adecuada y, a la vez, s que podr encontrar al personal tcnico
que necesito para trabajar.
En cuanto a la explotacin, usaremos la tecnologa de la nube, el famoso cloud. Esto implicar que el diseo tendr que estar preparado para este tipo de arquitectura hardware.
4)FinaMas, community manager de CrowdArt
Fina es la community manager de CrowdArt. Un community manager se encarga de la relacin
entre la compaa y los usuarios de Internet, la comunidad de usuarios. Su trabajo, por lo
33
tanto, tiene mucho que ver con cmo ven los usuarios CrowdArt, crear una buena imagen
del producto, mantener la compaa activa en las redes sociales, etc.
Los artistas son usuarios con inquietudes estticas por naturaleza; lo mismo podemos
decir de los mecenas de proyectos artsticos. Por lo tanto, el aspecto esttico de la pgina
web es de importancia vital para su buen funcionamiento.
Otro aspecto muy importante de la comunidad de usuarios de CrowdArt es que habr
tanto usuarios ocasionales como usuarios habituales. Muchos usuarios no conocern el
crowdfunding a priori y, por lo tanto, es importante que el sistema incluya una pgina de
informacin donde se explique muy claramente tanto el funcionamiento de la pgina
web como los conceptos de crowdfunding, mecenazgo, etc. Ms concretamente, habr
que dejar muy claro a los posibles mecenas que una vez se comprometen a hacer un
pago, si el proyecto logra su objetivo de financiacin, no se pueden echar atrs. Para
ello, es importante pedir los datos de pago en el momento en el que el mecenas hace
un compromiso de aportacin e, incluso, retenerle, mediante un cargo a una tarjeta de
crdito o lo que sea, la cantidad comprometida.
As como hay que tener en cuenta a los usuarios que no se comprometan en sus mecenazgos, hay que cuidar muy especialmente a los artistas. CrowdArt ser interesante en
la medida en que haya proyectos interesantes en su catlogo. Por esta razn, los artistas
tienen que poder proponer sus proyectos sin ningn coste. As tendremos un catlogo de
proyectos ms interesantes y la fuente de ingresos ser los proyectos exitosos. Los artistas
que hayan conseguido su objetivo de financiacin no tendrn ningn inconveniente en
pagar un porcentaje de esta financiacin.
En cuanto a dar visibilidad al proyecto, nos centraremos en PeixCuc, la red social de
ms xito hoy en da. Los usuarios tendrn que poder clicar el clsico Me gusta para
cualquier proyecto del catlogo, as como publicar en su muro cualquier pieza de informacin que les interese.
Una forma de conseguir facilitar la entrada a nuevos usuarios es permitirles acceder a la
web sin tenerse que registrar. Para ello, quiero que puedan entrar con sus credenciales de
PeixCuc, tal como he visto que hacen otras webs.
5)NicolauEstruch, un mecenas
Nicolau es una persona con intereses artsticos y ha hecho mecenazgo de varios proyectos
artsticos con anterioridad. Har, por lo tanto, de representante de los mecenas.
Yo empec a hacer pequeas aportaciones a obras artsticas a partir de un amigo que
hace teatro. Mucha gente empezar as y lo que hace falta para que empiecen es poderles
enviar por correo o por el PeixCuc un enlace o una ficha de un proyecto concreto que
financiar. A partir de aqu ellos ya entrarn en la web, se informarn, etc.
Lo que es muy importante, por tanto, es que la informacin sobre el proyecto y el artista
que hace de promotor sean muy claras y atractivas, puesto que, en el fondo, uno financia
aquello que le gusta.
Una vez iniciado, yo empec a visitar las webs de crowdfunding regularmente y a buscar
proyectos que me pudieran interesar. En este sentido, es necesario que se pueda buscar
por varios criterios (financiacin que les falta, das que faltan, tipos de proyecto, etc.).
A la hora de elegir la cantidad que financiar, es interesante que las recompensas sean
divertidas, atractivas e innovadoras. Recuerdo que una de las obras que financi era una
obra de teatro en la que la recompensa fueron camisetas, varias entradas para verla, etc. y,
lo ms divertido, poda asistir a los ensayos y una invitacin para 4 personas para la fiesta
de estreno que haca el equipo y reparto. Me gast mucho dinero, pero nos lo pasamos
muy, muy bien!
Por otro lado, lo digamos o no, muchos queremos, tambin, reconocimiento. Por ello,
quiero que en la web haya un tipo de ficha de usuario donde figuren los distintos proyectos que he financiado y poder publicar en el tabln de mi PeixCuc cuando financio
un proyecto.
6)CarlotaBalasch, la directora de un pequeo teatro
Carlota es una amiga de Imma, que estaba con ella el da de la entrevista de Imma, y result
que, como directora de teatro, tena su opinin sobre CrowdArt.
34
No conoca este tipo de financiacin hasta que Imma me habl de esto, hace unos
aos. Es fantstico! Yo puedo ser usuaria como posible mecenas, pero sobre todo me
interesa porque me permite ver qu se est haciendo de manera independiente por parte
de artistas que no han entrado todava en los circuitos comerciales. Y esto, para un teatro
innovador como el nuestro es muy importante!
En este sentido, encuentro muy interesante poder consultar no tanto proyectos como los
artistas que hay detrs. Me interesa mucho ver qu artistas estn triunfando, es decir, cules estn consiguiendo financiacin para sus proyectos, porque sern, seguramente, promesas de quien estar pendiente para programar si hacen algn espectculo interesante.
Por otro lado, tambin me interesa poder consultar los tipos de proyecto (teatro, cine,
msica, fotografa, etc.). Incluso sera interesante tenerlos clasificados por gnero o estilo,
puesto que, en mi caso, por ejemplo, resultara muy interesante ver si hay bastante inters
por el teatro experimental o hasta qu punto el teatro de vanguardia tiene seguidores.
Bien, una vez que hemos descrito el caso de la empresa CrowdArt, ya podemos hacer las
actividades.
1. Identificad tres requisitos no funcionales candidatos del sistema. Para cada requisito indicad: una frase para identificarlo, una o dos frases que lo describan, el tipo de requisito segn
los tipos presentados en el subapartado 2.2.3 y los stakeholders interesados. Proponed tambin, para cada requisito, unos criterios de aceptacin y cuestiones que aclarar.
2. Indicad cinco requisitos funcionales que identifiquis en la entrevista a Imma. Para documentarlos, utilizad el formato de las historias de usuario (sin conversacin y sin los criterios
de aceptacin): Como <rol de usuario> quiero <objetivo> [para <beneficio>].
3. Identificad un caso en el que dos requisitos estn en conflicto. Indicad cules son los
requisitos (mediante una frase que los identifique) y cules son los stakeholders interesados
en cada uno.
4. Identificad un caso de dependencia entre requisitos, ya sea porque uno implica el otro, uno
sea un subconjunto del otro o el coste de uno afecte al coste del otro. Indicad cules son los
requisitos (mediante una frase que los identifique) y cules son los stakeholders interesados
en cada uno.
Ejercicios de autoevaluacin
1. Qu son los requisitos del software?
2. Quines son los stakeholders de un proyecto de desarrollo de software?
3. En cul de las actividades del proceso de ingeniera de requisitos se decide que un requisito
deje de ser un requisito candidato y pase a ser aceptado o rechazado?
4. El requisito Como usuario, quiero poder consultar las recomendaciones de los agentes
sobre un hotel, es un requisito de producto o de proceso?
5. El requisito Como usuario, quiero poder consultar las recomendaciones de los agentes
sobre un hotel, es un requisito funcional o no funcional?
6. Qu es un requisito candidato?
7. Qu es la especificacin de requisitos del software?
8. En qu consiste la verificacin de requisitos?
35
Solucionario
Actividades
1.
Requisito
La empresa quiere ofrecer una herramienta web.
Descripcin
La herramienta se usar a travs de la web.
Tipo
Operacional y de entorno
Stakeholders
Imma Ncher, propietaria de CrowdArt.
Se harn pruebas para comprobar que el sistema se pueda usar mediante los navegadores ms populares.
Habra que aclarar cules son los navegadores que hay que soportar y qu versiones de estos navegadores.
Requisito
Usar la pasarela de pago de La Faixa.
Descripcin
Para los pagos por parte de los usuarios, habr que utilizar la pasarela de pago de La Faixa, puesto que
es el banco con el cual el director financiero de CrowdArt quiere trabajar.
Tipo
Operacional y de entorno
Stakeholders
Director financiero de CrowdArt
Se usar un entorno de pruebas de la pasarela de pago y se escribirn y ejecutarn pruebas automatizadas de pago mediante la pasarela.
Adems de todos los detalles tcnicos que hay que aclarar, desde el momento en el que se manipulan
pagos, seguramente habr requisitos legales y de seguridad relacionados que tener en cuenta.
Requisito
La esttica de la pgina web tiene que ser atractiva.
Descripcin
La esttica del aplicativo web debe ser atractiva tanto para artistas como para mecenas.
Tipo
Presentacin
Stakeholders
Fina Mas, community manager
Se elegir un grupo de usuarios a los que se dejar usar el sistema. Despus se les pasar una encuesta
para evaluar su opinin respecto a la esttica.
Habr que definir con qu criterio se selecciona el grupo de usuarios de prueba, puesto que es importante que sea significativo. Por otro lado, habr que decidir si nos esperamos a tener el sistema desarrollado, si se harn pruebas sobre una maqueta de la interfaz grfica, etc. Finalmente, habr que definir los
detalles de la encuesta y cul es el resultado mnimo que consideraremos vlido.
2.
Como artista quiero proponer un proyecto creativo para obtener financiacin para sacarlo adelante.
Como propietaria de CrowdArt quiero que se cobren 50 al artista por cada proyecto
que d de alta en el sistema para evitar que muchos artistas usen el sistema solo para
darse visibilidad.
Como administrador de CrowdArt quiero examinar un proyecto antes de que se publique
y decidir si se tiene que publicar o no para evitar que aparezcan proyectos falsos y spam.
36
Como posible mecenas quiero poder buscar proyectos por varios criterios para encontrar
proyectos que quiz me interese ayudar a financiar.
Como mecenas quiero poder hacer una promesa de aportacin para un proyecto para financiarlo en caso de que reciba suficientes promesas y recibir el premio o reconocimiento que ofrece.
3. Imma dice que se cobrarn 50 por cada proyecto que un artista d de alta. Sebasti,
en cambio, dice que hay que rebajar al mnimo las barreras de entrada a los artistas y pone
como ejemplo que no tengan que dar los datos bancarios. Estn en conflicto claramente,
puesto que pagar 50 no solo supone una barrera de entrada, sino que supone dar los datos
bancarios para hacer el pago.
4. Sebasti, el artista, dice que hay que evitar por completo que un mecenas haga una promesa
de financiacin y despus se eche atrs. Fina Mas, por su parte, seala que hay que pedir los
datos de pago en el momento de hacer un compromiso de aportacin e incluso retener la
cantidad prometida. El segundo requisito se puede considerar un subconjunto del primero
en el sentido de que es una forma concreta de conseguir el primero, que los mecenas no se
echen atrs.
Ejercicios de autoevaluacin
1. Los requisitos son caractersticas observables de un sistema que expresan una necesidad
o restriccin que un stakeholder tiene sobre el software que queremos desarrollar (podis ver
el subapartado 1.2).
2. Los stakeholders son aquellas personas o entidades que tienen algn impacto o inters en
el sistema a desarrollar (podis ver el subapartado 1.2).
3. Gestin de requisitos (podis ver el subapartado 1.3).
4. Es un requisito de producto (podis ver el subapartado 3.1).
5. Es un requisito funcional (podis ver el subapartado 3.1).
6. Un requisito candidato es una necesidad o deseo expresada por un stakeholder que podra
devenir un requisito del sistema pero que quiz no se tiene en cuenta a la hora de desarrollar
el software (podis ver el subapartado 4.1).
7. La especificacin de requisitos del software es el documento donde se recogen los requisitos
aceptados del software (podis ver el subapartado 4.3).
8. La verificacin de requisitos consiste en hacer las pruebas necesarias sobre el sistema desarrollado (o que se est desarrollando) para comprobar si satisface los requisitos que se esperaba.
37
Glosario
actividad f Conjunto de tareas que llevan a cabo las personas que tienen un determinado
rol.
artefacto m Objeto producido por el trabajo del ser humano. En el contexto de la ingeniera del software, cada uno de los documentos, modelos, programas, etc., que se generan
como resultado del trabajo del ingeniero.
disponibilidad f Capacidad de un sistema informtico de estar disponible para sus usuarios. Si un usuario no puede acceder al sistema por el motivo que sea, decimos que el sistema
no est disponible. Habitualmente se mide en porcentaje de tiempo que el sistema est
disponible (90%, 99%, etc.).
ingeniera f Aplicacin de un enfoque sistemtico, disciplinado y cuantificable a las estructuras, mquinas, productos, sistemas o procesos para obtener un resultado esperado.
ingeniera del software f Aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, la operacin y el mantenimiento del software; es decir, la aplicacin de
la ingeniera al software. Vase el subapartado 1.1.
ingeniera de requisitos f Disciplina que nos ayuda a identificar, gestionar y mantener
el conjunto de requisitos del software a desarrollar. Vase el subapartado 1.3.
fiabilidad f Capacidad de un sistema informtico de proporcionar informacin correcta de
manera robusta (es decir, tolerante a posibles errores por parte de los usuarios o del hardware).
mantenibilidad f Capacidad de un sistema informtico de ser fcil de mantener. Es decir,
que sea fcil tanto corregir los errores que se encuentren (mantenimiento correctivo) como
aadir nuevas funcionalidades (mantenimiento evolutivo).
mtodo m Definicin de las caractersticas del proceso o procedimiento disciplinado utilizado en la ingeniera de un producto o en la prestacin de un servicio.
metodologa f Ciencia que estudia los mtodos. Conjunto de los mtodos de una disciplina.
proceso m Conjunto de fases en una accin progresiva.
rendimiento m Medida de la relacin entre el volumen de trabajo hecho y el consumo
de recursos empleado.
requisito m Condicin exigida o necesaria para una cosa. En el campo de la ingeniera
del software, necesidad o restriccin que afecta a un producto de software definiendo qu
soluciones son adecuadas (lo cumplen) y cules no (no lo cumplen) desde el punto de vista
de esta necesidad o restriccin. Una solucin ser adecuada si satisface todos los requisitos
del sistema.
requisito candidato m Necesidades o restricciones obtenidas en una primera etapa de
obtencin de requisitos y que se convertirn en requisitos solo si son seleccionados como
tales a la hora de definir el alcance del proyecto para desarrollar. Vase el subapartado 4.2.
requisito de capacidad m Requisito funcional.
requisito de datos m Requisito funcional en lo referente a los datos que tiene que conocer
(y probablemente almacenar de manera persistente) el sistema analizado. Vase el subapartado 3.1.1.
requisito de funcionalidad m Requisito funcional sobre el comportamiento del sistema,
es decir, sobre la respuesta esperada por parte del sistema a ciertos estmulos que le llegan
desde el exterior. Vase el subapartado 3.1.1.
requisito de proceso m Requisito que expresa una necesidad o restriccin que no es
del producto una vez terminado, sino del proceso que se sigue para desarrollarlo. Vase el
subapartado 3.2.
requisito de producto m Requisito que define aquellas necesidades o restricciones que
los stakeholders tienen sobre el producto que se desarrollar como tal.
requisito de calidad m Requisito no funcional.
38
requisito funcional m Requisito que describe la funcionalidad esperada del sistema; es

decir, que describe el comportamiento del sistema ante los estmulos que le llegan del exterior. Vase el subapartado 3.1.1 y tambin requisito no funcional.
requisito no funcional m Requisito que restringe el conjunto de soluciones posible,
tpicamente en forma de restriccin, sin hablar de la funcionalidad. Vase el subapartado
3.1.2.
rol m En el contexto de la ingeniera del software, funcin que una persona cumple en el
seno de un equipo de desarrollo de software.
seguridad f Capacidad de un sistema informtico de proteger la informacin ante robos,
usos fraudulentos, corrupcin de los datos, etc.
stakeholder m y f Persona o entidad con un inters sobre el producto que estamos desarrollando.
tarea f Como parte de la ejecucin de un proceso, una tarea la tiene que llevar a cabo una
persona con un rol concreto para crear unos artefactos de salida a partir de unos artefactos
de entrada.
usabilidad f Capacidad de un sistema informtico de ser fcil de utilizar.
usuario m Persona que utiliza un sistema informtico.
39
Bibliografa
Bibliografa principal
Pradel, J.; Raya, J. Ingeniera del Software. Editorial UOC.
Los materiales de la asignatura de Ingeniera del software, especialmente el mdulo 3, tratan
los requisitos de manera introductoria.
Bibliografa complementaria
Davis, A. M. (2005). Just Enough Requirements Management. Dorset House.
En esta obra, Alan Davis propone un enfoque pragmtico para la obtencin y la gestin de
requisitos.
Autores varios (2004). SWEBOK. Software Engineering Body Of Knowledge Guide. IEEE Computer Society.
Esta obra recoge el cuerpo de conocimiento (es decir, aquellas ideas que son ampliamente aceptadas en la industria) de la ingeniera del software. Se puede consultar en la direccin http://www.computer.org/portal/web/swebok/htmlformat (Fecha de consulta: febrero
del 2012).
Referencias bibliogrficas
IEEE-SA Standards Board (1998). IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society.
Leffingwell, D.; Widrig, D. (2000). Managing Software Requirements - A Unified Approach.
Addison Wesley.
Robertson, J.; Robertson, S. Volere Requirements Specification Template. http://
www.volere.co.uk/template.htm (Fecha de consulta: febrero del 2012).
Cusumano, M.; MacCormack, A.; Kemerer, C. F.; Crandall, W. (2003). Software Development Worldwide: the State of the Practice. IEEE Software. http://www.compaid.com/caiinternet/casestudies/cusumano-internationalcomparisons.pdf (Fecha de consulta: febrero del
2012).
Requirements Solutions Group (2008). A Requirements Taxonomy. http://
requirementssolutions.com/WhitePapers/RequirementsTaxonomy.pdf (Fecha de consulta:
febrero del 2012).

1 Introducción A La Ingenieria de Requisitos

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

1 Introducción A La Ingenieria de Requisitos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1 Introducción A La Ingenieria de Requisitos

Cargado por

Copyright:

Formatos disponibles

Introduccin a

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos.................................

La ingeniera del software ...........................................................

La ingeniera de requisitos ..........................................................

Problemticas de la ingeniera de requisitos ...............................

Presentacin del caso prctico.......................................................

Requisitos de producto ...............................................................

Requisitos funcionales ...................................................

Requisitos no funcionales ..............................................

Requisitos de proceso ..................................................................

El proceso de la ingeniera de requisitos.....................................

Obtencin de requisitos ..............................................................

Gestin de requisitos ..................................................................

Documentacin de requisitos .....................................................

Validacin de requisitos ..............................................................

Verificacin de requisitos ............................................................

Requisitos del caso prctico............................................................

Tipos de requisitos ......................................................................

Requisitos de producto no funcionales .........................

Requisitos de productos funcionales .............................

Requisitos de proceso ....................................................

El proceso de la ingeniera de requisitos ....................................

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos

El principal objetivo de este mdulo es presentar al estudiante la ingeniera de

1. Situar la ingeniera de requisitos dentro del contexto de la ingeniera del

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos

1. Introduccin a la ingeniera de requisitos

La ingeniera de requisitos es la disciplina que nos ayuda a identificar,

Gestin del proyecto.

Identificacin, gestin y documentacin de requisitos.

Construccin y pruebas, incluyendo la verificacin de requisitos.

Cada mtodo puede dar ms o menos importancia a cada actividad, pero no

Los stakeholders son aquellas personas o entidades que tienen algn

Gestinderequisitos: estimar el coste que implica tener en cuenta cada

Documentacinderequisitos: documentar los requisitos de manera que

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos

al mismo tiempo, los stakeholders y los desarrolladores compartan la visin

Validacinderequisitos: comprobar que los requisitos elegidos para el

Diferenciasrespectoalainformacinconlaquetrabajanlasdiferentespartes. Los stakeholders tienen informacin sobre el dominio que los

Limitacionesdelcanalutilizado. Cualquier canal de comunicacin tiene

Limitaciones del lenguaje utilizado. Las personas que se comuniquen

Dificultaddedefinirelmejorsistemaposible. Muy a menudo es difcil

Introduccin a la ingeniera de requisitos

2. Presentacin del caso prctico

En este apartado presentaremos un caso prctico que servir de hilo conductor

Adems de la entrevista mantenida con l, de Joan obtenemos un plan de viaje

Introduccin a la ingeniera de requisitos

Introduccin a la ingeniera de requisitos

Maria Costa, propietaria de una agencia de viajes franquiciada

Introduccin a la ingeniera de requisitos

Snia Cases, directora de marketing de Viajes UOC

Introduccin a la ingeniera de requisitos