Ingeniería de Requisitos (ER)

Comprender la necesidad y aprender a determinar, especificar y validar los requisitos (funcionales y no funcionales) de un sistema de software.

Conocimientos

1. Comprender la necesidad, la importancia, los objetivos y el contexto en que se realizan las actividades de determinación, especificación y validación de los requisitos en la ingeniería del software.
2. Conocer los métodos principales para la determinación de requisitos y las situaciones en que se pueden aplicar.
3. Comprender el papel que juega la documentación y le especificación formal e informal de los requisitos en el proceso de desarrollo de un sistema, y las propiedades que deberían tener. Conocer los estándares existentes.
4. Conocer los métodos de modelado conceptual orientados a objetos y basados en el lenguaje UML.
5. Conocer los métodos principales para la validación de los requisitos y las situaciones en que se pueden aplicar.
6. Comprender las diferencias en las actividades de ingeniería de requisitos según si se trata de desarrollar un sistema o una línea de productos nuevos, o adquirir e integrar sistemas o componentes ya existentes.

Habilidades

1. Saber determinar, especificar y validar los requisitos de sistemas pequeños y medios, usando los métodos más apropiados.
2. Saber especificar formalmente los requisitos funcionales de un sistema usando el lenguaje UML (y el OCL).
3. Poder participar de forma efectiva en equipos de proyectos de sistemas muy complejos o de dominios muy especializados.

Competencias

1. Capacidad para resolver problemas aplicando los métodos de la ciencia y la ingeniería.
2. Capacidad para crear y utilizar modelos de la realidad.
3. Capacidad para diseñar sistemas, componentes o procesos que se ajusten a unes necesidades, usando los métodos, técnicas y herramientas más adecuadas en cada caso.
4. Saber aplicar el ciclo de resolución de problemas típico de la ciencia y la ingeniería: especificación, generación de ideas y alternativas, diseño de una estrategia de solución, ejecución de la estrategia, validación, interpretación y evaluación de los resultados. Capacidad para analizar el proceso una vez finalizado.
5. Capacidad para resolver problemas poco estructurados.
6. Capacidad para trabajar efectivamente en grupos de personas para la resolución de un problema de dificultad media.
7. Capacidad para actuar autónomamente: Saber trabajar de forma independiente, recibiendo sólo la información indispensable y unas guías mínimas.
8. Transversal: Planificar y utilizar la información necessaria para un trabajo académico a partir de una reflexión crítica sobre los recursos de información utilitzados. Gestionar la información de manera competente, independente y autónoma. Evaluar la informació localizada e identificar las lagunas.

La asignatura se impartirá con el método docente PBL (Project Based Learning, o Problem Based Learning).

Hay una clase (convencional) de una hora a la semana donde el profesor presenta temas muy generales (por ejemplo, qué es la ingeniería de requisitos) o los propios estudiantes plantean y discuten los puntos centrales de la assignatura o aspectos que no quedan suficientemente cubiertos con las otras dos actividades.

Una de las dos partes principales del curso es la determinación de los requisitos de un sistema de software concreto. El profesor plantea una situación concreta (diferente de un curso a otro), para la cual los estudiantes han de determinar y especificar los requisitos de un sistema de software, usando unos métodos y lenguajes que han de aprender previamente. Este trabajo se hace en grupo. El número de personas y la composición del grupo se define al empezar el curso. Cada grupo nombra un coordinador, un secretario y dos responsables de calidad. Cada grupo se reúne al menos una vez a la semana durante dos horas, en horario prefijado. El resultado del trabajo se presenta en al menos dos plazos durante el curso.


La otra parte importante del curso es la realización de ejercicios (cortos). El profesor plantea unos diez ejercicios durante el curso. Cada estudiante ha de presentar su propia solución a los ejercicios, en el plazo indicado (aproximadamente una semana). La realización del ejercicio requiere el aprendizaje de nuevos conocimientos. Los ejercicios se corrigen pronto, y se publica una o más de las soluciones correctas que se hayan presentado.


Nota: El método docente usado en la asignatura requiere que el estudiante adquiera nuevos conocimientos de manera autónoma, usando fuentes bibliográficas que normalmente están en inglés. Es imprescindible que el estudiante tenga un nivel de inglés suficiente para asimilar sin demasiadas dificultades esta bibliografía (técnica).

La evaluación continua de la asignatura consta de tres componentes: trabajo de grupo (30%), ejercicios individuales (35%), participación (25%) y la competencia transversal (10%)

La evaluación del trabajo de grupo es la misma para todos los miembros del grupo. Se evalúa a partir del resultado del trabajo (documentos y, si es el caso, presentaciones). Como se ha indicado antes, este resultado se presenta en al menos dos plazos durante el curso. La parte principal de la evaluación del trabajo del grupo (aproximadamente el 90%) se obtiene al acabar el curso. La otra parte (aproximadamente el 10%) se obtiene a mediados de curso, una vez hecha la primera presentación de resultados.

La evaluación de los ejercicios individuales es propia de cada estudiante. Es necesario presentar un mínimo de seis ejercicios durante el curso, en el plazo indicado para cada ejercicio, y al menos deben aprovarse tres de ellos. La evaluación es la media de las evaluaciones de todos los ejercicios presentados.

La participación también es propia de cada estudiante. Se basa en el grado de su contribución al trabajo del grupo, la función realizada en el grupo (coordinador, secretario, presentador, responsable de calidad, etc.), el nivel de asistencia a las reuniones del grupo y a las clases, el número de ejercicios individuales realizados correctamente y la participación en general a las diversas actividades del curso. Para poder ser evaluado en participación hay que asistir a un mínimo del 80% de las classes y reuniones programadas.

La evaluación de la competencia transversal también es propia de cada estudiante. Se basa en una parte del trabajo en grupo que será evaluada específicamente. La evaluación tendrá en cuenta la calidad del trabajo hecho (igual evaluación para todos los miembros del grupo) y la participación de cada estudiante en el trabajo (individual).

• Suzanne and James Robertson Mastering the requirements process, Addison-Wesley, 1999.
• Antoni Olivé Conceptual modeling of information systems, Springer,, 2007.
• Cockburn, Alistair Writing Effective Use Cases, Addison-Wesley, 2001.
• Axel van Lamsweerde Requirements engineering, Wiley, 2009.
• Pohl, Klaus Requirements Engineering, Springer, 2010.

• Ian Sommerville and Pete Sawyer Requirements engineering : a good practice guide, John Wiley & Sons, 1997.
• Soren Lauesen Software requirements : styles and techniques, Addison-Wesley, 2002.
• Aurum, Aybüke; Wohlin, Claes (Eds.) Engineering and Managing Software Requirements, Springer, 2005.
• Anderson, James Value Merchants, Harvard Business School, 2007.

1. http://web.uccs.edu/adavis/UCCS/reqbib.htm
   



2. http://www.volere.co.uk/
   



3. http://www-pagines.fib.upc.es/~modeling/
   



4. http://www.c2c-solutions.com/kano_tutorial.htm
   



5. http://agilesoftwaredevelopment.com/2006/12/kano-model-of-customer-satisfaction
   



6. http://www.comp.lancs.ac.uk/computing/resources/re-gpg/re-general.html#general
   

El estudiante ha de saber que la ingeniería de requisitos es una parte de la ingeniería del software. Ha de tener también una buena base en la especificación (formal) de sistemas de información con orientación a objetos, y usando el UML y el OCL.

A la vista de estas capacidades previas, entendemos que Ingeniería del software I debería ser prerrequisito.