Introducción a la ingeniería de requisitos Jordi Pradel Miquel Jose Raya Martos PID_00191265
CC-BY-SA • PID_00191265
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla o comunicarla públicamente 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
Introducción a la ingeniería de requisitos
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
Índice
Introducción...............................................................................................
5
Objetivos.......................................................................................................
6
1.
Introducción a la ingeniería de requisitos.................................
7
1.1.
La ingeniería del software ...........................................................
7
1.2.
Requisitos y stakeholders...............................................................
8
1.3.
La ingeniería de requisitos ..........................................................
8
1.4.
Problemáticas de la ingeniería de requisitos ...............................
9
2.
Presentación del caso práctico.......................................................
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 ingeniería de requisitos.....................................
20
4.1.
Obtención de requisitos ..............................................................
20
4.2.
Gestión de requisitos ..................................................................
21
4.3.
Documentación de requisitos .....................................................
22
4.4.
Validación de requisitos ..............................................................
23
4.5.
Verificación de requisitos ............................................................
24
Requisitos del caso práctico............................................................
25
5.1.
Identificación de stakeholders.......................................................
25
5.2.
Problemáticas ..............................................................................
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 ingeniería de requisitos ....................................
28
Resumen.......................................................................................................
30
Actividades..................................................................................................
31
Ejercicios de autoevaluación..................................................................
34
Solucionario................................................................................................
35
5.4.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
Glosario........................................................................................................
37
Bibliografía.................................................................................................
39
CC-BY-SA • PID_00191265
5
Introducción a la ingeniería de requisitos
Introducción
La ingeniería de requisitos es la disciplina que incluye todas aquellas actividades relacionadas con los requisitos del software. A pesar de estar muy relacionada con la ingeniería del software, se trata de disciplinas con objetivos diferentes. Mientras que la ingeniería del software tiene como objetivo desarrollar un producto de manera correcta, la ingeniería de requisitos tiene como objetivo desarrollar el producto correcto. Por este motivo requiere conocimientos y habilidades de otras disciplinas, como la psicología, el marketing o la organización de empresas. La ingeniería de requisitos tiene un gran impacto económico 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 podría haberse utilizado en desarrollar el producto correcto), sino que, además, habrá que dedicar esfuerzos a corregir la situación. En este módulo haremos un repaso de aquello que ya conocemos sobre la ingeniería de requisitos, por lo que ya hemos estudiado en otras asignaturas. Este repaso nos permitirá, en los módulos siguientes, estudiar con más detalle las problemáticas y técnicas específicas de la ingeniería de requisitos. Empezaremos hablando de la ingeniería de requisitos y de su objeto de estudio (los requisitos), así como de la relación de estos con los diferentes stakeholders del proyecto de desarrollo. A continuación, presentaremos el caso práctico que desarrollaremos en el resto de los módulos para presentar los diferentes conceptos y técnicas. Como la ingeniería 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 módulos. Una vez presentado el caso práctico, hablaremos del proceso de la ingeniería de requisitos y presentaremos las diferentes actividades que forman parte de él, que estudiaremos de manera más detallada en el resto de los módulos. Finalmente, veremos algunos ejemplos de requisitos basados en el caso práctico anteriormente mencionado.
Ved también Podéis encontrar más información sobre la ingeniería de requisitos en la asignatura Ingeniería del software.
CC-BY-SA • PID_00191265
6
Objetivos
El principal objetivo de este módulo es presentar al estudiante la ingeniería de requisitos y situarla en el contexto de la ingeniería del software. En concreto, el estudiante, al finalizar este módulo, debe ser capaz de:
1. Situar la ingeniería de requisitos dentro del contexto de la ingeniería del software. 2. Estar familiarizado con la terminología básica de la ingeniería de requisitos. 3. Conocer el proceso de la ingeniería de requisitos, así como las diferentes tareas involucradas en ella. 4. Saber aplicar el proceso de la ingeniería de requisitos a un caso práctico.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
7
Introducción a la ingeniería de requisitos
1. Introducción a la ingeniería de requisitos
La ingeniería de requisitos es la disciplina que nos ayuda a identificar, gestionar y mantener el conjunto de requisitos del software que hemos de desarrollar.
La ingeniería de requisitos, por tanto, tiene lugar dentro del mismo contexto que la ingeniería del software (el desarrollo de software), motivo por el cual se puede ver como parte de la ingeniería del software. Aun así, hay que tener en cuenta que la ingeniería de requisitos requiere conocimientos y habilidades propias de otras disciplinas, como por ejemplo la psicología, el marketing o el diseño. 1.1. La ingeniería del software El IEEE define la ingeniería del software como la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, la operación 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 también bastante claro, ya sea con éxito o fracaso. Por este motivo, el desarrollo se organiza en proyectos. Existen muchos métodos de desarrollo de software, muchos de ellos basados en otras disciplinas de la ingeniería. Cada método define uno o más procesos consistentes en decir qué tareas y en qué orden se deben llevar a cabo, qué roles tendrán 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 método tiene sus particularidades, pero todos ellos tienen una serie de actividades (conjuntos de tareas relacionadas) comunes: •
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.
Referencia bibliográfica IEEE Std (1993). IEEE Software Engineering Standard: glossary of Software Engineering Terminology. IEEE Computer Society Press.
CC-BY-SA • PID_00191265
8
Cada método puede dar más o menos importancia a cada actividad, pero no la puede obviar si lo queremos considerar un método de desarrollo completo. 1.2. Requisitos y stakeholders Para poder desarrollar un sistema informático, 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 ingeniería 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 características observables de un sistema que expresan una necesidad o restricción que un stakeholder tiene sobre él.
Los requisitos nos sirven, por lo tanto, para delimitar cuáles de las posibles soluciones a un problema son adecuadas (las que cumplen los requisitos) y cuáles no.
Los stakeholders son aquellas personas o entidades que tienen algún impacto o interés 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 implantación y que, por lo tanto, también tienen intereses en él. 1.3. La ingeniería de requisitos Denominamos ingeniería�de�requisitos a aquel subconjunto de la ingeniería del software que se encarga de las actividades siguientes: •
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,
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
9
Introducción a la ingeniería de requisitos
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.
Las tareas y artefactos concretos de la ingeniería de requisitos que se usen dependerán, en buena parte, del método empleado. Así, por ejemplo, los métodos que sigan un ciclo de vida en cascada necesitarán una documentación de requisitos mucho más exhaustiva que los métodos ágiles. 1.4. Problemáticas de la ingeniería de requisitos Las principales problemáticas de la ingeniería de requisitos radican en el hecho de que se trata de una actividad de comunicación entre personas y, como en cualquier actividad de este tipo, nos podemos encontrar con varias dificultades. Las más típicas son: •
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
Referencia bibliográfica Podéis ver la referencia completa en el artículo de Cusumano y otros en el apartado de bibliografía.
CC-BY-SA • PID_00191265
10
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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
11
2. Presentación del caso práctico
En este apartado presentaremos un caso práctico que servirá de hilo conductor a lo largo de los diferentes módulos de este material en cuanto a los ejemplos que se irán presentando. Se trata de un sistema de información para una agencia de viajes mayorista ficticia que denominaremos Viajes UOC. A continuación, se presentan unos fragmentos de las entrevistas hechas a ciertas personas clave de la organización, que son, evidentemente, stakeholders, para ver qué esperan del nuevo sistema. El caso práctico no se presenta completo en el sentido de que un caso realista completo queda fuera del espacio disponible en este módulo. Por esta razón, estas entrevistas no se transcriben completas y no contienen todos los requisitos ni todo el nivel de detalle que se encontraría 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 ambigüedades y contradicciones que son comunes en casos reales. 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.”
Además de la entrevista mantenida con él, de Joan obtenemos un plan de viaje que ha elaborado a mano:
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
12
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
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 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.”
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
14
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.”
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
15
Introducción a la ingeniería de requisitos
3. Tipos de requisitos
Como hemos visto, las principales problemáticas que debemos resolver en la ingeniería de requisitos son problemáticas propias de la comunicación entre personas y, una de ellas, es la limitación del lenguaje utilizado. Por esta razón, es especialmente interesante establecer y definir correctamente un vocabulario común, de tal manera que todos los participantes en el proceso de la ingeniería de requisitos entiendan lo mismo cuando se utiliza un determinado término. En este apartado establecemos una taxonomía para tipificar los requisitos con el fin de evitar la ambigüedad a la hora de determinar el tipo de un requisito. Cada obra e incluso cada organización usa su propia taxonomía, pero hay ciertos puntos comunes en la mayoría de ellas.
Hay que tener en cuenta, pues, que ninguna taxonomía puede clasificar cada requisito en una única categoría indiscutible. Siempre habrá casos en los que se podrá argumentar la pertenencia de un requisito a una u otra categoría según 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 práctico son: •
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.
Taxonomía Una taxonomía es una colección de términos de vocabulario controlados que se organiza en una estructura jerárquica.
CC-BY-SA • PID_00191265
16
Muchas veces, cuando se habla de requisitos a palo seco, por abuso del lenguaje, se quiere hacer referencia a requisitos de producto, por oposición 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é cálculos hace el sistema, qué datos mantiene, cómo los manipula, etc. Podemos distinguir, dentro de los requisitos funcionales, entre los requisitos de funcionalidad y los de datos.
Los requisitosde�funcionalidad, en general, describen cuál tiene que ser el comportamiento del sistema explicando qué respuesta debe dar ante los estímulos 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 práctico 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 requisitos�de�datos describen qué datos tiene que conocer el sistema. Estos son, típicamente, 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 práctico. 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 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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
17
Introducción a la ingeniería de requisitos
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
Terminología Los requisitos no funcionales se denominan, también, requisitos de calidad.
solución no satisface aquella calidad, no se considera válida. Los requisitos no funcionales suelen afectar a gran parte del sistema. Por ejemplo, si decimos que el sistema de Viajes UOC tiene que ser portátil a otras plataformas, esto no afecta solamente a la recomendación de hoteles o a la publicación de la opinión en Facebook, sino que afecta a todo el sistema.
Muchos autores y organismos de estandarización han intentado elaborar una taxonomía completa de requisitos no funcionales que se han de tener en cuenta. Veremos, a continuación, la que propone la plantilla Volere: •
Requisitos�de�presentación. Hacen referencia al aspecto visual del sistema y tienen en cuenta aspectos como la imagen corporativa de la organización. Un posible requisito conforme que todas las pantallas de la aplicación tienen que mostrar el logo de Viajes UOC, que no aparece en las entrevistas, sería un requisito de presentació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. La necesidad de poder usar el sistema con poca o nada formación, mencionada tanto por Joan Salvat como por Maria Costa, es un requisito de usabilidad y humanidad.
•
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. El requisito de que el sistema ha de permitir a las agencias continuar trabajando aunque se pierda la conexión a Internet, pedido por Dolors Sánchez, es un ejemplo de requisito de cumplimiento.
•
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á. Un requisito de que el sistema sea usable tanto desde ordenadores de escritorio como desde dispositivos móviles sería un requisito operacional y de entorno.
Referencia bibliográfica Podéis ver la referencia completa a la plantilla Volere en el apartado de bibliografía.
CC-BY-SA • PID_00191265
•
18
Introducción a la ingeniería de requisitos
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. La petición de Dolors Sánchez de que el sistema sea fácil de mantener es un ejemplo de requisito de mantenimiento y soporte.
•
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. Las necesidades expresadas por Sònia Cases de encriptar la información personal y grabar el acceso a esta información de carácter personal son dos requisitos de seguridad. A su vez, también son requisitos legales, como comentaremos más adelante.
•
Requisitos�culturales�y�políticos. Son aquellos que tienen en cuenta aspectos culturales y políticos de los usuarios. Un requisito cultural típico es lo referente al idioma de los usuarios. Así, quizá querremos que Viajes UOC pueda usarse en catalán, castellano e inglés. Esto no solo implica mostrar los mensajes en el idioma adecuado, sino también usar el formato que sea necesario para las fechas, los números, etc. Así, por ejemplo, una fecha como 1/3 puede querer decir el uno de marzo o el tres de enero según el ámbito cultural del usuario. De manera parecida, la semana podría empezar el lunes o el domingo.
•
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. Como ya se ha comentado, los requisitos de seguridad mencionados por Sònia 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 carácter personal.
LOPD LOPD son las siglas de la Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal de España, una ley orgánica española que tiene por objetivo garantizar y proteger los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente su intimidad y privacidad personal y familiar.
CC-BY-SA • PID_00191265
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 restricción 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 más importante es el coste de desarrollo, tanto en tiempo como en dinero. A pesar de no tratarse de una característica observable en el producto ya desarrollado, sí que lo es en el proceso. Y, evidentemente, los stakeholders tendrán necesidades y restricciones que imponer.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
20
Introducción a la ingeniería de requisitos
4. El proceso de la ingeniería de requisitos
Tal y como hemos visto anteriormente, el proceso concreto que seguiremos en un proyecto de software dado dependerá en gran medida del método de desarrollo que estemos siguiendo, la medida y cultura de la organización para la cual lo estamos desarrollando, así como otros factores, como la proximidad geográfica entre stakeholders y desarrolladores. En realidad, como veremos, no se puede desligar el proceso de la ingeniería de requisitos del proceso de la ingeniería del software. No obstante, sea cual sea la metodología 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 ingeniería de requisitos. 4.1. Obtención de requisitos La obtención de requisitos consiste en determinar cuáles 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 información interesantes, como por ejemplo las posibles soluciones de la competencia, las capa-
Elicitación La obtención de requisitos también es denominada, por algunos autores, elicitación.
cidades de la tecnología, los sistemas (informáticos o no) usados hasta ahora para satisfacer estas necesidades, etc. Por lo tanto, durante esta actividad se recogerá mucha información 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 conversión entre divisas. Las dos necesidades pueden ser requisitos, a pesar de que están a niveles de detalle muy diferentes.
Los requisitos recogidos durante la obtención, 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 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.
Ved también Veremos con más detalle la obtención de requisitos en el módulo “Obtención de requisitos”.
CC-BY-SA • PID_00191265
21
Introducción a la ingeniería de requisitos
Por ello, decimos que la obtención 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 podría 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 algún otro requisito que sí que queremos incluir. En nuestro caso, Dolors Sánchez nos pide un espacio propio para su agencia mientras que Sònia 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 inversión necesaria para su desarrollo. Por ejemplo, Marc García nos pide que el nuevo sistema de ventas se integre con el sistema de facturación para evitar que Maria pierda tres días al mes en copiar la información de un lugar al otro. Todavía no sabemos cuál es el coste de desarrollar esta integración y, por lo tanto, todavía no sabemos si será rentable o no para Viajes UOC incluir este requisito o si bien es preferible descartarlo o encontrar una solución intermedia.
La obtención de requisitos, como veremos más 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 sabíamos que estaban. Por este motivo, a menudo se usan términos como evocación/extracción de requisitos (requirements elicitation). 4.2. Gestión de requisitos En la introducción hemos visto que la ingeniería de requisitos tiene un gran impacto económico 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 gestión de requisitos puede hacer que un proyecto que se haya ejecutado de manera impecable desde el punto de vista de gestión 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 cuáles de los requisitos�candidatos formarán parte, finalmente, de los requisitos del producto que vamos a desarrollar. Para determinarlo, hay que decidir cuáles son los requisitos más impor-
Ved también Veremos con más detalle la gestión de requisitos en el módulo “Gestión de requisitos”.
CC-BY-SA • PID_00191265
22
Introducción a la ingeniería de requisitos
tantes, cuál es el coste de implementación de los diferentes requisitos (y cuál es la capacidad con la que contamos para implementarlos), así como resolver los conflictos que pueda haber entre requisitos. Dentro de la gestión de requisitos podemos discernir varias actividades: 1) El análisis�de�los�requisitos consiste en entender bien los requisitos candidatos e identificar dependencias, solapamientos y conflictos que puedan tener. 2) De cara a facilitar la posterior selección 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, además de la importancia de cada requisito hay que estimar el esfuerzo que supondría 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 selección para determinar el conjunto de requisitos que se tendrá en cuenta (para el proyecto o iteración 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 análisis, priorización, estimación y elección no se podrán hacer de manera secuencial solo al inicio, puesto que los requisitos son cambiantes. Por lo tanto, habrá que hacer, además, una gestión�del�cambio de los requisitos. Esta gestión 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. Documentación de requisitos Los requisitos seleccionados durante la gestión de requisitos son aquellos que se tendrán en cuenta para desarrollar el sistema. Para comunicar cuáles son estos requisitos al equipo de desarrollo y a los stakeholders se necesita, pues, documentarlos, puesto que, en la mayoría de los proyectos, una comunica-
Ved también Veremos con más detalle la documentación de requisitos en el módulo “Documentación de requisitos”.
CC-BY-SA • PID_00191265
23
Introducción a la ingeniería de requisitos
ción exclusivamente oral y confiar en la memoria de los implicados no será suficiente. El documento donde se recogen los requisitos se conoce como especificación:
La especificación de requisitos recoge el contrato entre los desarrolladores y los stakeholders y sirve como herramienta de comunicación para los dos grupos. Por ello, resulta un elemento central de cualquier método de desarrollo, especialmente en cuanto a la gestión del proyecto.
Las historias de usuario, los casos de uso y el lenguaje UML son herramientas habituales usadas en la documentación de requisitos para grabarlos a varios niveles de detalle y, a la vez, usar una forma de documentación que todos los implicados puedan entender. La documentación 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 documentación de requisitos puede ser tan exhaustiva como se quiera. Una simplicidad excesiva implica riesgos respecto a la interpretación de los detalles de los requisitos, puesto que se podría perder información. Es necesario, pues, que la documentación sea suficientemente detallada para minimizar estos riesgos. Por otro lado, una documentación demasiado costosa de elaborar puede ser difícil de mantener, especialmente si los requisitos van cambiando. Y no solo no tendría ningún valor, sino que tendría una repercusión 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 documentación 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. Validación de requisitos Una vez obtenidos los requisitos candidatos, seleccionados y documentados, ya disponemos de una documentación que, en principio, refleja las necesidades de los stakeholders sobre el sistema que se desarrollará. Pero, muchas veces, durante las actividades que nos han traído a este punto se cometen errores que pueden provocar que los requisitos documentados no reflejen correctamente lo que los stakeholders quieren.
Ved también Veremos con más detalle la validación de requisitos en el módulo “Validación y verificación de requisitos”.
CC-BY-SA • PID_00191265
24
Introducción a la ingeniería de requisitos
La validación de�requisitos 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 validación son errores de comprensión de la necesidad de los stakeholders, errores de gestión de requisitos y, sobre todo, errores de documentación. 4.5. Verificación de requisitos Si todo el propósito 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 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.
Hay que tener en cuenta que se deben verificar todos los tipos de requisitos y que cada tipo demandará una forma diferente de verificación. 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 estrés, 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 todavía satisface los requisitos (nuevos y previamente existentes). Por este motivo, en muchos casos es interesante automatizar el proceso de pruebas para poder realizar la verificación en el mínimo coste posible.
Ved también Veremos con más detalle la verificación de requisitos en el módulo “Validación y verificación de requisitos”.
CC-BY-SA • PID_00191265
25
Introducción a la ingeniería de requisitos
5. Requisitos del caso práctico
En este apartado estudiaremos el caso práctico desde el punto de vista de los stakeholders, las problemáticas propias de la comunicación con ellos, los tipos de requisitos y el proceso de la ingeniería de requisitos. 5.1. Identificación de stakeholders En el caso práctico, tal como se ha presentado, ya tenemos identificados ciertos stakeholders, que son los que se han entrevistado: •
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.
Además de los ya identificados, podemos identificar otros stakeholders. Una lista no exhaustiva de otros stakeholders que podemos identificar incluye: •
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 A lo largo del desarrollo del proyecto hay que tener en cuenta las problemáticas de la ingeniería de requisitos ya mencionadas.
Otros stakeholders Estos solo son algunos de los stakeholders que no habíamos identificado todavía, pero la lista puede ser muy larga y dependerá, en cada caso, de la organización 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
CC-BY-SA • PID_00191265
Introducción a la ingeniería de requisitos
Así, por ejemplo, en este caso se han usado entrevistas que se han transcrito para comunicar los requisitos. Al hacer la transcripción, se habrán perdido detalles y matices de la comunicación oral. Por otro lado, como ejemplo adicional de una problemática que nos podemos encontrar en Viajes UOC, los conocimientos de la tecnología seguramente estarán afectando a los stakeholders, que estarán 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 características que quieren sin saberlo. 5.3. Tipos de requisitos
5.3.1. Requisitos de producto no funcionales A continuación 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 descripción, su tipo (según la plantilla Volere), los stakeholders que están interesados y unos posibles criterios de aceptación.
Ved también Podéis ver los tipos de requisitos de la plantilla Volere en el subapartado 3.1.2 de este módulo.
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.
27
CC-BY-SA • PID_00191265
Introducción a la ingeniería de requisitos
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 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 quiero . •
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.
CC-BY-SA • PID_00191265
•
28
Como cliente quiero consultar el plan de viaje.
5.3.3. Requisitos de proceso En Viajes UOC también podemos identificar algunos requisitos de proceso. Así, por ejemplo, Marc García, el director financiero, dice que la inversión se tendría que recuperar en menos de dos años o no hacerse. Este objetivo se traduce en un requisito según 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 metodología de desarrollo que hay que emplear, los horarios que tiene que hacer el equipo de desarrollo, el idioma en el que se celebrarán las reuniones durante el desarrollo, etc. se trataría de requisitos de proceso. 5.4. El proceso de la ingeniería de requisitos En cuanto al proceso de la ingeniería de requisitos, a continuación se proporcionan ejemplos concretos de las distintas actividades que lo forman en el contexto del caso práctico. Así, durante la�obtención�de�requisitos, se han hecho las entrevistas que se han transcrito. En las entrevistas, como es normal, hay información a muchos niveles de detalle y detectamos necesidades muy variadas por parte de los stakeholders. Como parte de la gestión�de�requisitos, 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 Sánchez (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 Sònia 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 cuáles 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 según cuáles son más 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 Sònia Cases es más prioritario y, a la vez, menos costoso y, por lo tanto, quizá se selecciona como requisito, descartando el requisito candidato de Dolors.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
29
La actividad de documentación�de�requisitos consistirá en documentar los requisitos detectados. Así, para el requisito que Joan tiene de poder introducir una recomendación, quizá se documenta como una historia de usuario, si se sigue una metodología ágil con poca documentación, o quizá se documenta en forma de caso de uso si se hace una documentación más exhaustiva.
La validación�de�requisitos 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 traído hasta la documentación que hemos hecho. Finalmente, la actividad de verificación�de�requisitos 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 podría 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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
30
Resumen
En este módulo hemos hecho un breve repaso a lo que ya sabíamos sobre la ingeniería de requisitos. Hemos visto que la ingeniería 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 fácil obtener los requisitos a partir de nuestras conversaciones con ellos. Hemos visto también algunos ejemplos de clasificación de requisitos según la taxonomía propuesta por la plantilla Volere y hemos echado un primer vistazo al proceso de la ingeniería de requisitos, que hemos dividido en cuatro etapas, que estudiaremos en detalle en el resto de los módulos: •
Obtención de requisitos candidatos.
•
Gestión de requisitos.
•
Documentación de requisitos (especificación).
•
Validación de requisitos.
•
Verificación de requisitos.
Por último, hemos presentado el caso práctico que usaremos a lo largo de los materiales para ilustrar los diferentes conceptos y técnicas que iremos estudiando.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
31
Actividades Para las actividades de este módulo plantearemos otro caso práctico, el de CrowdArt. CrowdArt es una empresa de nueva creación que quiere ofrecer una plataforma de crowdfunding de proyectos artísticos. El crowdfunding consiste en buscar financiación directa basada en micropagos que hacen personas de todas partes, a cambio de una pequeña recompensa, como puede ser una mención en los títulos de créditos de la obra o algún tipo de material de promoción. A continuación presentamos algunas notas tomadas durante las entrevistas a diferentes personas implicadas en el proyecto: 1)�Imma�Nàcher, emprendedora y propietaria de CrowdArt Imma es la emprendedora que hay detrás del proyecto CrowdArt y nos ha explicado el origen de esta idea. “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.” 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 más detalle cómo 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 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
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
32
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.” 2)�Sebastià�Reixach, 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 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.” 3)�Júlia�Maimó, directora técnica 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 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.” 4)�Fina�Mas, community manager de CrowdArt Fina es la community manager de CrowdArt. Un community manager se encarga de la relación entre la compañía y los usuarios de Internet, la comunidad de usuarios. Su trabajo, por lo
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
33
tanto, tiene mucho que ver con cómo ven los usuarios CrowdArt, crear una buena imagen del producto, mantener la compañía activa en las redes sociales, etc. “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.” 5)�Nicolau�Estruch, un mecenas Nicolau es una persona con intereses artísticos y ha hecho mecenazgo de varios proyectos artísticos con anterioridad. Hará, por lo tanto, de representante de los mecenas. “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.” 6)�Carlota�Balasch, la directora de un pequeño teatro Carlota es una amiga de Imma, que estaba con ella el día de la entrevista de Imma, y resultó que, como directora de teatro, tenía su opinión sobre CrowdArt.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
34
“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.” 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 según los tipos presentados en el subapartado 2.2.3 y los stakeholders interesados. Proponed también, para cada requisito, unos criterios de aceptación y cuestiones que aclarar. 2. Indicad cinco requisitos funcionales que identifiquéis en la entrevista a Imma. Para documentarlos, utilizad el formato de las historias de usuario (sin conversación y sin los criterios de aceptación): Como quiero [para ]. 3. Identificad un caso en el que dos requisitos estén en conflicto. Indicad cuáles son los requisitos (mediante una frase que los identifique) y cuáles 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 cuáles son los requisitos (mediante una frase que los identifique) y cuáles son los stakeholders interesados en cada uno.
Ejercicios de autoevaluación 1. ¿Qué son los requisitos del software? 2. ¿Quiénes son los stakeholders de un proyecto de desarrollo de software? 3. ¿En cuál de las actividades del proceso de ingeniería 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 especificación de requisitos del software? 8. ¿En qué consiste la verificación de requisitos?
Introducción a la ingeniería de requisitos
35
CC-BY-SA • PID_00191265
Introducción a la ingeniería de requisitos
Solucionario Actividades 1. 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.
2.
• • •
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.
CC-BY-SA • PID_00191265
• •
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 aportación 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 cobrarán 50 € por cada proyecto que un artista dé de alta. Sebastià, en cambio, dice que hay que rebajar al mínimo las barreras de entrada a los artistas y pone como ejemplo que no tengan que dar los datos bancarios. Están 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 financiación y después se eche atrás. Fina Mas, por su parte, señala que hay que pedir los datos de pago en el momento de hacer un compromiso de aportación 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 atrás.
Ejercicios de autoevaluación 1. Los requisitos son características observables de un sistema que expresan una necesidad o restricción que un stakeholder tiene sobre el software que queremos desarrollar (podéis ver el subapartado 1.2). 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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
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 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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
38
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.
Introducción a la ingeniería de requisitos
CC-BY-SA • PID_00191265
39
Bibliografía Bibliografía principal Pradel, J.; Raya, J. Ingeniería del Software. Editorial UOC. Los materiales de la asignatura de Ingeniería del software, especialmente el módulo 3, tratan los requisitos de manera introductoria. Bibliografía complementaria Davis, A. M. (2005). Just Enough Requirements Management. Dorset House. En esta obra, Alan Davis propone un enfoque pragmático para la obtención y la gestión 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 ingeniería del software. Se puede consultar en la dirección http://www.computer.org/portal/web/swebok/htmlformat (Fecha de consulta: febrero del 2012). Referencias bibliográficas 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).
Introducción a la ingeniería de requisitos
