Introducción a la ingeniería de requisitos

Índice
- Introducción
- Objetivos
- 1.Introducción a la ingeniería de requisitos
- 2.Presentación del caso práctico
- 3.Tipos de requisitos
- 3.1.Requisitos de producto
- 3.1.1.Requisitos funcionales
- 3.1.2.Requisitos no funcionales
- 3.2.Requisitos de proceso
- 3.1.Requisitos de producto
- 4.El proceso de la ingeniería de requisitos
- 5.Requisitos del caso práctico
- Resumen
- Actividades
- Ejercicios de autoevaluación
- Solucionario
- Glosario
- Bibliografía
Introducción
Objetivos
-
Situar la ingeniería de requisitos dentro del contexto de la ingeniería del software.
-
Estar familiarizado con la terminología básica de la ingeniería de requisitos.
-
Conocer el proceso de la ingeniería de requisitos, así como las diferentes tareas involucradas en ella.
-
Saber aplicar el proceso de la ingeniería de requisitos a un caso práctico.
1.Introducción a la ingeniería de requisitos
1.1.La ingeniería del software
-
Gestión del proyecto.
-
Identificación, gestión y documentación de requisitos.
-
Modelización.
-
Construcción y pruebas, incluyendo la verificación de requisitos.
-
Calidad.
-
Mantenimiento y reingeniería.
1.2.Requisitos y stakeholders
1.3.La ingeniería de requisitos
-
Obtención de requisitos: identificar las fuentes de información de los posibles requisitos del sistema y obtener cuáles son estos requisitos candidatos.
-
Gestión de requisitos: estimar el coste que implica tener en cuenta cada requisito, priorizarlos según la importancia que tengan para los stakeholders y así poder seleccionar los requisitos que finalmente se tendrán en cuenta en la etapa actual de desarrollo del sistema.
-
Documentación de requisitos: documentar los requisitos de manera que quede constancia del resultado del proceso de gestión de requisitos y que, al mismo tiempo, los stakeholders y los desarrolladores compartan la visión de cuál es el producto que se ha de desarrollar. Esta documentación puede formar parte o no de la documentación final del sistema.
-
Validación de requisitos: 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 obtención, priorización, selección y documentación.
-
Verificación de requisitos: verificar si el sistema desarrollado (o parcialmente desarrollado en el caso de ciclos de vida iterativos) satisface o no los requisitos y cuáles.
1.4.Problemáticas de la ingeniería de requisitos
-
Diferencias respecto a la información con la que trabajan las diferentes partes. Los stakeholders tienen información sobre el dominio que los desarrolladores no tienen, mientras que los desarrolladores tienen información sobre la capacidad de la tecnología que los stakeholders, no. Esto suele condicionar la visión del problema que tienen unos y otros, y puede afectar negativamente a la comunicación.
-
Limitaciones del canal utilizado. Cualquier canal de comunicación tiene limitaciones. Así, por ejemplo, la comunicación escrita pierde los matices del lenguaje inmediato y no verbal, mientras que la comunicación verbal impide o, cuando menos, dificulta la revisión 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 catalán, el castellano, etc.) son los más comunes, pero son propensos a la ambigüedad. Existen lenguajes más formales, pero resultan poco útiles si no son conocidos por todas las partes que se comunican.
-
Dificultad de definir el mejor sistema posible. Muy a menudo es difícil descubrir cuál es el mejor sistema posible, en el sentido de que puede ser difícil saber qué quieren realmente los stakeholders. Muchas veces ni ellos mismos lo sabrán decir con certeza, puesto que estarán condicionados por su desconocimiento de la tecnología, por soluciones que ya conocen, etc.
2.Presentación del caso práctico
Joan Salvat, empleado de una agencia de viajes franquiciada“Todavía 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 había explicado cómo hacer las cosas. Lo que pediría a los informáticos es que o bien hagan un sistema que se pueda usar para vender viajes sin necesidad de formación o bien nos hagan una formación sobre la herramienta. En cualquier caso, no querría estar más de dos semanas con esta sensación de no encontrar nada. Sinceramente, no creo que sea tan difícil de conseguir lo que pido, hay muchas webs como Facebook o Hotmail que te permiten hacer cosas igual de complicadas sin necesitar ninguna formación.
En cuanto a los aspectos más 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 más 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é cuáles tendrían que evitar. Por lo tanto, si la relación con el cliente debe ser a través de Internet, el sistema me tiene que permitir dar esta misma información a través del nuevo canal y, evidentemente, el cliente ha de saber que la información le ha venido de Joan Salvat de la agencia de la calle Mallorca y que, si le gusta mi criterio, puede consultar otras recomendaciones mías o, mejor todavía, pedir una cita para hablar conmigo sobre su viaje. Sin esto, nos convertiremos en burócratas que solo hacen que despachar documentos de viaje y será una situación 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 información sobre traslados (horario de un vuelo, aeropuerto, terminal y compañía), hoteles (número de noches, teléfono 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, dónde los pueden localizar.”

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 través 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 ningún 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 avión, 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 también la preocupación 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 algún problema informático. Como muy bien dice Martí, el nuevo sistema debe hacer su trabajo más fácil y no complicarlo. De todos modos, supongo que los informáticos ya habrán pensado en un mecanismo para que los clientes puedan solucionar sus problemas informáticos sin tener que ir o hablar con alguien de la agencia.
También en esta línea quiero remarcar que el sistema tendría que funcionar sin necesidad de formación 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 Sánchez, 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 están trabajando conmigo y no con cualquier otra agencia. Además, 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 campañas de publicidad que se mostrarán a mis clientes.
Por otro lado, el nuevo sistema debe permitir reducir el coste del mantenimiento de mi infraestructura informática y no complicarla, pero no me fío 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 García, director financiero de Viajes UOC“Ahora mismo, lo que más me preocupa es de dónde sacaremos el dinero para financiar este proyecto, puesto que estamos bastante endeudados por el programa de expansión que llevamos a cabo el año pasado, del cual no se espera obtener nuevos rendimientos hasta de aquí a un par de años. Además, tenemos una inversión muy fuerte comprometida de aquí a dos años y, por lo tanto, no podemos llegar más endeudados de lo que estamos actualmente: la inversión se debería recuperar en menos de dos años 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 expansión).
Problemas de financiación aparte, me gustaría que el nuevo sistema me ofreciera información consolidada de las ventas en todas las agencias, puesto que, ahora mismo, cada agencia usa un sistema de facturación independiente y nos cuesta mucho hacer los informes de facturación. Ya puestos, se tendría que integrar con nuestro sistema de facturación para evitar que Maria (trabajadora de mi departamento) dedique tres días cada mes a copiar manualmente la información de un lugar al otro.”
Sònia 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 tecnologías 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 campañas 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 compañías, etc. También queremos una aplicación para Facebook que permita publicar en el muro de los clientes información sobre sus vacaciones (cosas del tipo “Gerard López está pensando si ir a Costa Rica o a China este verano” o “Gerard López acaba de volver de su viaje a Brasil”).
Por último, un amigo mío abogado me ha dicho que para cumplir la ley de protección de datos es necesario que el sistema guarde constancia de todos los accesos que se hacen a información personal de los clientes y que, para evitar problemas en caso de robo de datos, lo mejor sería guardar estos datos de manera encriptada en la base de datos. Esto sí, no me preguntéis cuáles son estos datos personales ni cómo 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 algún tipo de versión demo o periodo de pruebas para que los propietarios de las agencias puedan ver las ventajas del nuevo sistema.
Por otro lado, también nos debería servir para vender productos complementarios. Por ejemplo, si llegamos a un convenio con una compañía aseguradora, el sistema nos tiene que permitir ofrecer los seguros de la compañía cada vez que un cliente compra un viaje.”
3.Tipos de requisitos

3.1.Requisitos de producto
-
Como usuario quiero poder consultar las recomendaciones de los agentes sobre un hotel.
-
El sistema debe conocer el nombre, los apellidos, la dirección de correo electrónico, la dirección y el teléfono de los clientes.
-
El sistema tiene que permitir a las agencias continuar trabajando aunque se pierda la conexión en Internet.
-
Requisitos funcionales.
-
Requisitos no funcionales.
3.1.1.Requisitos funcionales

-
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.
-
El sistema tiene que conocer el cliente de un viaje; en particular, debe saber el nombre, los apellidos, la dirección de correo electrónico, la dirección postal y el teléfono.
-
El sistema tiene que conocer el hotel u hoteles de un viaje. De los hoteles tiene que saber el nombre, la dirección y el teléfono. En relación con el viaje tiene que saber las fechas de entrada y salida, las horas de check-in y check-out, el tipo de habitación, las observaciones del hotel y la opinión del agente que ha reservado el viaje.
3.1.2.Requisitos no funcionales
-
Requisitos de presentación. Hacen referencia al aspecto visual del sistema y tienen en cuenta aspectos como la imagen corporativa de la organización.
-
Requisitos de usabilidad y humanidad. Son los relacionados con el hecho de que el sistema sea ergonómico y usable. Estos factores dependerán 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 satisfacción, etc.
-
Requisitos de cumplimiento. Se trata de los requisitos sobre la manera de cumplir las responsabilidades del sistema, incluyendo características como la velocidad, la latencia, la fiabilidad, la robustez, etc.
-
Requisitos operacionales y de entorno. Agrupan los requisitos relativos a la manera o el entorno en el que se usará el software, como por ejemplo el entorno físico en el que se usará.
-
Requisitos de mantenimiento y soporte. Hacen referencia a los requisitos relativos al mantenimiento (correctivo y evolutivo) del sistema y al soporte a los usuarios de este.
-
Requisitos de seguridad. Son, como su nombre indica, los que se ocupan de la seguridad del sistema, incluyendo aspectos como permisos de acceso, integridad, privacidad, auditoría, etc.
-
Requisitos culturales y políticos. Son aquellos que tienen en cuenta aspectos culturales y políticos de los usuarios.
-
Requisitos legales. Son requisitos que hay que satisfacer en virtud de la ley que se aplicará sobre la organización responsable del sistema, pero también requisitos de aplicación de estándares reconocidos.

3.2.Requisitos de proceso
4.El proceso de la ingeniería de requisitos
4.1.Obtención de requisitos
-
Entre los distintos stakeholders habrá necesidades en conflicto, de tal modo que una misma solución 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.
4.2.Gestión de requisitos
4.3.Documentación de requisitos
4.4.Validación de requisitos
4.5.Verificación de requisitos
5.Requisitos del caso práctico
5.1.Identificación de stakeholders
-
Joan Salvat, empleado de una agencia de viajes franquiciada.
-
Maria Costa, propietaria de una agencia de viajes franquiciada.
-
Dolors Sánchez, propietaria de una agencia de viajes franquiciada.
-
Marc García, director financiero de Viajes UOC.
-
Sònia Cases, directora de marketing de Viajes UOC.
-
Albert Jorba, director comercial de Viajes UOC.
-
Los clientes de la agencia de viajes, por ejemplo, son también stakeholders, puesto que usarán el sistema.
-
Marc García menciona a Maria, una persona de su departamento que se podría ahorrar bastante trabajo con el nuevo sistema y que, por lo tanto, también es una stakeholder.
-
María Costa menciona a alguien llamado Martí, un empleado de la agencia que no quiere convertirse en personal de apoyo y que, por lo tanto, también es un stakeholder.
-
Todas las personas que tengan que interactuar técnicamente con el sistema también serán stakeholders. Esto incluirá a las personas que lo instalen, que lo administren y que le den soporte, por ejemplo.
5.2.Problemáticas
5.3.Tipos de requisitos
5.3.1.Requisitos de producto no funcionales
Requisito |
Tiene que poderse usar sin formación previa. |
Descripción |
El sistema se debe poder utilizar sin necesidad de recibir formación previa. |
Tipo |
Usabilidad y humanidad |
Criterios de aceptación |
Se hará una prueba piloto con empleados de las agencias y estos tienen que ser capaces de dar información y vender un viaje sin haber recibido formación previa. |
Stakeholders |
Joan Salvat (empleado de agencia de viajes) María Costa (propietaria de agencia franquiciada) |
Cuestiones pendientes |
Alternativamente, se puede considerar dar una formación mínima, pero, en un máximo de dos semanas, el personal tiene que poder usar el nuevo sistema. |
Requisito |
Tiene que ser fácil de mantener. |
Descripción |
El sistema debe ser fácil de mantener sin necesidad de contratar personal para hacer la configuración de los ordenadores. Las copias de seguridad se harán de manera totalmente automatizada. |
Tipo |
Mantenimiento y soporte |
Criterios de aceptación |
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 Sánchez (propietaria de agencia franquiciada) |
Cuestiones pendientes |
Requisito |
Tiene que poder trabajar sin red. |
Descripción |
El sistema debe permitir que una agencia pueda vender viajes cuando no haya red. |
Tipo |
Operacional |
Criterios de aceptación |
Se hará una prueba piloto que consistirá en desconectar de la red una oficina y verificar que puede acceder a la información necesaria para vender un viaje. |
Stakeholders |
Dolors Sánchez (propietaria de agencia franquiciada) |
Cuestiones pendientes |
Requisito |
Tiene que soportar 200 agencias. |
Descripción |
El sistema debe soportar 95 agencias en el momento de la puesta en producción y tiene que poder crecer hasta 200 agencias a lo largo de dos años. 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) |
Criterios de aceptación |
Se hará una prueba de carga con usuarios simulados. |
Stakeholders |
Marc García (director financiero) |
Cuestiones pendientes |
Requisito |
Tiene que guardar constancia de todos los accesos a información personal de los clientes. |
Descripción |
En cumplimiento de la LOPD, el sistema debe guardar constancia de todos los accesos que se hacen a información personal de los clientes. |
Tipo |
Legal/Seguridad |
Criterios de aceptación |
Se accederá a la información personal de un cliente aleatorio y se verificará que el acceso ha quedado registrado. Se hará una auditoría específica para el cumplimiento con la LOPD. |
Stakeholders |
Sònia Cases, directora de marketing Departamento legal de Viajes UOC |
Cuestiones pendientes |
Definir exactamente qué datos se consideran personales. |
5.3.2.Requisitos de productos funcionales
-
Como cliente quiero informarme de un destino.
-
Como cliente quiero ver la información de un viaje que he comprado.
-
Como agente quiero introducir una recomendación.
-
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.
-
Como cliente quiero consultar el plan de viaje.
5.3.3.Requisitos de proceso
5.4.El proceso de la ingeniería de requisitos
Resumen
-
Obtención de requisitos candidatos.
-
Gestión de requisitos.
-
Documentación de requisitos (especificación).
-
Validación de requisitos.
-
Verificación de requisitos.
Actividades
“CrowdArt nace con la vocación de llenar un vacío en el país en cuanto a la financiación de pequeñas obras de teatro, cortometrajes y todo tipo de proyectos artísticos que no pueden financiarse por los medios habituales.
La empresa ofrecerá, básicamente, una herramienta web mediante la cual los artistas podrán proponer los proyectos que quieren financiar. Tendrán que proponer su proyecto de manera atractiva y franca e indicar la financiación mínima que necesitan para poderlo llevar adelante. La idea es que si consiguen suficiente financiación hagan el proyecto, pero si no, no cobren dinero, puesto que no lo podrán llevar a cabo.
El negocio de CrowdArt consiste en cobrar a los artistas una comisión del 5% de la financiación que recojan los proyectos exitosos. Además, para evitar tener muchos artistas usando la plataforma para darse visibilidad pero sin llegar a financiar sus proyectos, se cobrarán 50 € por cada proyecto que un artista dé de alta en el sistema.”
“De acuerdo. Lo primero es que los artistas propongan proyectos. Para hacerlo, el artista tiene que indicar un título, una descripción y cualquier otro material audiovisual que tenga para vender su proyecto a los posibles mecenas. También tiene que decidir qué inversiones y recompensas quiere que se puedan hacer. Así, por ejemplo, puede decidir que por una aportación de 10 € hará constar el nombre del usuario en los títulos de créditos de su obra, que por 30 €, además de los créditos, dará dos entradas para el espectáculo, etc. Finalmente, es necesario que indique la financiación que necesita. Es importante que hile cuidadosamente, puesto que los mecenas solo pagarán 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á automáticamente, o no lo es. En el último caso, se informaría al artista del motivo y el proyecto sería desestimado. El artista podría continuar haciendo propuestas de proyectos (ya sea el mismo, con mejoras, o nuevos proyectos).
Una vez publicado, un proyecto tendrá 40 días para reunir la financiación 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 aportación por uno de los importes definidos por el artista que creó el proyecto.
Los usuarios también podrán consultar el perfil de otros usuarios, donde constarán los proyectos iniciados y las aportaciones hechas a otros proyectos, además de una fotografía opcional, un texto descriptivo, etc.
Cuando finalice el plazo de un proyecto, si ha reunido la financiación necesaria, el sistema cobrará a los mecenas las aportaciones que prometieron y marcará el proyecto como exitoso. Si no ha reunido la financiación necesaria, sencillamente se marcará el proyecto como finalizado (sin éxito). En ambos casos el proyecto continuará apareciendo en las buscas, pero como finalizado y no se podrán hacer más 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 comisión de CrowdArt).
La web incluirá, está claro, un pequeño apartado de comunicación 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 cómo evoluciona el proyecto.”
“Esto del crowdfunding es un fenómeno curioso, porque algunos mecenas financian proyectos de manera desinteresada pero muchos quieren algún tipo de recompensa y prácticamente 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. Además, como algunas recompensas son físicas, hay que poder indicar un número máximo de aportaciones por aquel valor. Recuerdo una vez que ofrecí una entrada para ver mi corto para quien aportara 10 € y, por sorpresa mía, tuve más de 200 aportaciones de 10 €... ¡No cabía todo el mundo en la sala que había reservado y tuve que hacer dos proyecciones!
Otra experiencia problemática que tuve, esta mucho peor, sucedió en una ocasión en la que me fui enredando en sacar adelante una obra de teatro para la cual había conseguido la financiación por crowdfunding pero uno de los inversores que se había 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 ningún concepto y que sea CrowdArt quien se asegure, persiguiendo, si es necesario, a quien no respete su compromiso y respondiendo por él.
También es importante tener un espacio de discusión, tipo foro, donde poder resolver dudas a los usuarios sobre tu proyecto. Algunos usuarios se lo piensan bastante antes de hacer según qué aportaciones y quieren tener información más detallada.
Por otro lado, yo utilizo esta vía de financiación a menudo. Creo que esto es un mérito que los posibles mecenas tienen en cuenta. Confían más 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 círculos que nosotros nos movemos. Muchos artistas no conocen todavía el crowdfunding o solo han oído hablar del él. Por ello, sería interesante rebajar al mínimo las barreras de entrada. Así, por ejemplo, muchos preferirán no dar datos bancarios hasta que algún proyecto suyo haya funcionado y tengan que cobrar dinero.
Es de vital importancia que la empresa, CrowdArt, solo se involucre en la financiación de la obra, por lo que nosotros conservamos todos los derechos de nuestras obras.”
“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 técnico que necesito para trabajar.
En cuanto a la explotación, usaremos la tecnología de la nube, el famoso cloud. Esto implicará que el diseño tendrá que estar preparado para este tipo de arquitectura hardware.”
“Los artistas son usuarios con inquietudes estéticas por naturaleza; lo mismo podemos decir de los mecenas de proyectos artísticos. Por lo tanto, el aspecto estético de la página 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 conocerán el crowdfunding a priori y, por lo tanto, es importante que el sistema incluya una página de información donde se explique muy claramente tanto el funcionamiento de la página web como los conceptos de crowdfunding, mecenazgo, etc. Más 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 financiación, no se pueden echar atrás. Para ello, es importante pedir los datos de pago en el momento en el que el mecenas hace un compromiso de aportación e, incluso, retenerle, mediante un cargo a una tarjeta de crédito 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 catálogo. Por esta razón, los artistas tienen que poder proponer sus proyectos sin ningún coste. Así tendremos un catálogo de proyectos más interesantes y la fuente de ingresos será los proyectos exitosos. Los artistas que hayan conseguido su objetivo de financiación no tendrán ningún inconveniente en pagar un porcentaje de esta financiación.
En cuanto a dar visibilidad al proyecto, nos centraremos en PeixCuc, la red social de más éxito hoy en día. Los usuarios tendrán que poder clicar el clásico “Me gusta” para cualquier proyecto del catálogo, así como publicar en su muro cualquier pieza de información 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.”
“Yo empecé a hacer pequeñas aportaciones a obras artísticas 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 entrarán en la web, se informarán, etc.
Lo que es muy importante, por tanto, es que la información 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 (financiación que les falta, días 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 más divertido, podía asistir a los ensayos y una invitación para 4 personas para la fiesta de estreno que hacía el equipo y reparto. Me gasté mucho dinero, pero nos lo pasamos muy, ¡muy bien!
Por otro lado, lo digamos o no, muchos queremos, también, 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 tablón de mi PeixCuc cuando financio un proyecto.”
“No conocía este tipo de financiación hasta que Imma me habló de esto, hace unos años. ¡Es fantástico! 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 todavía 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 detrás. Me interesa mucho ver qué artistas están triunfando, es decir, cuáles están consiguiendo financiación para sus proyectos, porque serán, seguramente, promesas de quien estar pendiente para programar si hacen algún espectáculo interesante.
Por otro lado, también me interesa poder consultar los tipos de proyecto (teatro, cine, música, fotografía, etc.). Incluso sería interesante tenerlos clasificados por género o estilo, puesto que, en mi caso, por ejemplo, resultaría muy interesante ver si hay bastante interés por el teatro experimental o hasta qué punto el teatro de vanguardia tiene seguidores.”
Ejercicios de autoevaluación
Solucionario
Requisito |
La empresa quiere ofrecer una herramienta web. |
Descripción |
La herramienta se usará a través de la web. |
Tipo |
Operacional y de entorno |
Stakeholders |
Imma Nàcher, propietaria de CrowdArt. |
Criterios de aceptación |
Se harán pruebas para comprobar que el sistema se pueda usar mediante los navegadores más populares. |
Cuestiones pendientes |
Habría que aclarar cuáles son los navegadores que hay que soportar y qué versiones de estos navegadores. |
Requisito |
Usar la pasarela de pago de La Faixa. |
Descripción |
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 |
Criterios de aceptación |
Se usará un entorno de pruebas de la pasarela de pago y se escribirán y ejecutarán pruebas automatizadas de pago mediante la pasarela. |
Cuestiones pendientes |
Además de todos los detalles técnicos 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 estética de la página web tiene que ser atractiva. |
Descripción |
La estética del aplicativo web debe ser atractiva tanto para artistas como para mecenas. |
Tipo |
Presentación |
Stakeholders |
Fina Mas, community manager |
Criterios de aceptación |
Se elegirá un grupo de usuarios a los que se dejará usar el sistema. Después se les pasará una encuesta para evaluar su opinión respecto a la estética. |
Cuestiones pendientes |
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 harán pruebas sobre una maqueta de la interfaz gráfica, etc. Finalmente, habrá que definir los detalles de la encuesta y cuál es el resultado mínimo que consideraremos válido. |
-
Como artista quiero proponer un proyecto creativo para obtener financiación 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.
-
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 aportación para un proyecto para financiarlo en caso de que reciba suficientes promesas y recibir el premio o reconocimiento que ofrece.
2. Los stakeholders son aquellas personas o entidades que tienen algún impacto o interés en el sistema a desarrollar (podéis ver el subapartado 1.2).
3. Gestión de requisitos (podéis ver el subapartado 1.3).
4. Es un requisito de producto (podéis ver el subapartado 3.1).
5. Es un requisito funcional (podéis ver el subapartado 3.1).
6. Un requisito candidato es una necesidad o deseo expresada por un stakeholder que podría devenir un requisito del sistema pero que quizá no se tiene en cuenta a la hora de desarrollar el software (podéis ver el subapartado 4.1).
7. La especificación de requisitos del software es el documento donde se recogen los requisitos aceptados del software (podéis ver el subapartado 4.3).
8. La verificación 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.
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 ingeniería 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 informático 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.).
- ingeniería f
- Aplicación de un enfoque sistemático, disciplinado y cuantificable a las estructuras, máquinas, productos, sistemas o procesos para obtener un resultado esperado.
- ingeniería del software f
- Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, la operación y el mantenimiento del software; es decir, la aplicación de la ingeniería al software. Véase el subapartado 1.1.
- ingeniería de requisitos f
- Disciplina que nos ayuda a identificar, gestionar y mantener el conjunto de requisitos del software a desarrollar. Véase el subapartado 1.3.
- fiabilidad f
- Capacidad de un sistema informático de proporcionar información correcta de manera robusta (es decir, tolerante a posibles errores por parte de los usuarios o del hardware).
- mantenibilidad f
- Capacidad de un sistema informático de ser fácil de mantener. Es decir, que sea fácil tanto corregir los errores que se encuentren (mantenimiento correctivo) como añadir nuevas funcionalidades (mantenimiento evolutivo).
- método m
- Definición de las características del proceso o procedimiento disciplinado utilizado en la ingeniería de un producto o en la prestación de un servicio.
- metodología f
- Ciencia que estudia los métodos. Conjunto de los métodos de una disciplina.
- proceso m
- Conjunto de fases en una acción progresiva.
- rendimiento m
- Medida de la relación entre el volumen de trabajo hecho y el consumo de recursos empleado.
- requisito m
- Condición exigida o necesaria para una cosa. En el campo de la ingeniería del software, necesidad o restricción que afecta a un producto de software definiendo qué soluciones son adecuadas (lo cumplen) y cuáles no (no lo cumplen) desde el punto de vista de esta necesidad o restricción. Una solución será adecuada si satisface todos los requisitos del sistema.
- requisito candidato m
- Necesidades o restricciones obtenidas en una primera etapa de obtención de requisitos y que se convertirán en requisitos solo si son seleccionados como tales a la hora de definir el alcance del proyecto para desarrollar. Véase 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. Véase 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 estímulos que le llegan desde el exterior. Véase el subapartado 3.1.1.
- requisito de proceso m
- Requisito que expresa una necesidad o restricción que no es del producto una vez terminado, sino del proceso que se sigue para desarrollarlo. Véase 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.
- requisito funcional m
- Requisito que describe la funcionalidad esperada del sistema; es decir, que describe el comportamiento del sistema ante los estímulos que le llegan del exterior. Véase el subapartado 3.1.1 y también requisito no funcional.
- requisito no funcional m
- Requisito que restringe el conjunto de soluciones posible, típicamente en forma de restricción, sin hablar de la funcionalidad. Véase el subapartado 3.1.2.
- rol m
- En el contexto de la ingeniería del software, función que una persona cumple en el seno de un equipo de desarrollo de software.
- seguridad f
- Capacidad de un sistema informático de proteger la información ante robos, usos fraudulentos, corrupción de los datos, etc.
- stakeholder m y f
- Persona o entidad con un interés sobre el producto que estamos desarrollando.
- tarea f
- Como parte de la ejecución 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 informático de ser fácil de utilizar.
- usuario m
- Persona que utiliza un sistema informático.