Saltar al contingut Menu
Map
  • Home
  • Information
  • Contact
  • Map

Engineering of Requirements (ER)

Credits Dept.
7.5 (6.0 ECTS) ESSI

Instructors

Person in charge:  (-)
Others:(-)

General goals

To understand the need and to learn how to determine, specify and validate the requirements (both functional and non-functional) of a software system.

Specific goals

Knowledges

  1. Understand the need for and importance of software engineering, its objectives, and the context in which it takes place.
  2. Understand the main methods for determining requirements and the situations in which they can be applied.
  3. Understand the role played by documentation and formal specifications in developing a system, and the properties they must possess. Acquaintance with current standards.
  4. Understand object-oriented modelling concepts based on UML language.
  5. Understand the main methods for determining requirements and the situations in which they can be applied.
  6. Understand the differences between the activities involved in requirement engineering, depending on whether development concerns a system, a new line of products, or acquiring a system or integrating existing systems and components.

Abilities

  1. Understand how to determine and validate small and medium-sized systems, using the most appropriate methods.
  2. Ability to formally specify the functional requisites of a system using UML language UML (and OCL).
  3. Ability to form effective project groups for work on highly complex systems/highly specialised fields.

Competences

  1. Ability to solve problems through the application of scientific and engineering methods.
  2. Ability to create and use models of reality.
  3. Ability to design systems, components and processes meeting certain needs, using the most appropriate methods, techniques and tools in each case.
  4. Know-how to apply the solution cycle to common scientific and engineering problems: specification, coming with ideas and alternatives, design solution strategies, carrying out the strategy, validation, interpretation and evaluation of results. Ability to analyse the process on completion.
  5. Ability to solve poorly-structured problems.
  6. Ability to work effectively in groups to solve problems of middle difficulty.
  7. Ability to act independently: Ability to work on one"s own with just the bare minimum of knowledge and guidance.
  8. Cross: Planning and using the information required for an academic work, from a critical assessment of the information resources used. Managing the information in a competent, independent and autonomous way. Evaluating the information obtained and identifying the gaps.

Contents

Estimated time (hours):

T P L Alt Ext. L Stu A. time
Theory Problems Laboratory Other activities External Laboratory Study Additional time

1. Introduction to requirement engineering. Context, process, variants, management and tools.
T      P      L      Alt    Ext. L Stu    A. time Total 
14,0 0 0 0 0 14,0 0 28,0

2. Methods and techniques for identifying requirements.
T      P      L      Alt    Ext. L Stu    A. time Total 
0 0 0 10,0 0 24,0 0 34,0

3. Writing down, analyzing, prioritising, and classifying requirements.
T      P      L      Alt    Ext. L Stu    A. time Total 
0 0 0 10,0 0 30,0 0 40,0

4. Extending the conceptual modelling of information systems.
T      P      L      Alt    Ext. L Stu    A. time Total 
0 0 0 4,0 0 25,0 0 29,0

5. Validation of requirements.
T      P      L      Alt    Ext. L Stu    A. time Total 
0 0 0 4,0 0 5,0 0 9,0


Total per kind T      P      L      Alt    Ext. L Stu    A. time Total 
14,0 0 0 28,0 0 98,0 0 140,0
Avaluation additional hours 10,0
Total work hours for student 150,0

Docent Methodolgy

The course will be taught using the PBL (Project-Based Learning, or Problem-Based Learning) approach.

There is a conventional class (one hour a week) in which the teacher explains general themes (e.g. the nature of requirement engineering) or -more often- the students themselves formulate and discuss central points of the course or aspects not adequately dealt with in the other two course activities.

One of the two main parts of the course covers the determination of a given software engineering system. The teacher will set out a specific situation (which will vary between courses) in which students have to determine and specify software system requirements, using previously learnt methods and languages. This work will be carried out in groups. The number of students in each group and its precise make-up will be established at the beginning of the course. Each grup nominates a coordinator,a secretary and two responsibles of quality. Each group will meet at least once a week for two hours, at a pre-arranged time. There will be at least two submissions of the group's work during the course.

The other important part of the course involves carrying out short exercises. The teacher will set around ten exercises during the course. Each student must submit his or her own solution to the exercises within the set deadlines (students are given roughly a week to do each exercise). Carrying out the exercises involves the learning of new knowledge. The exercises are corrected soon, and the best solutions are published.

Note: The teaching method employed for the course requires students to acquire new knowledge in an autonomous fashion, using bibliographic sources that are normally in English. Accordingly, students' level of English must be up to the task of using such technical bibliography without special difficulties.

Evaluation Methodgy

Continuous assessment comprises three parts: Group work (30%), individual exercises (35%), student participation (25%) and the cross competence (10%).

Assessment of group work is applied equally to all the group members. It is based on the work done (documents or, where applicable, presentations). As indicated earlier, there will be at least two submissions of the group"s work during the course. The main part of the work group grade (about 90%) is obtained at the end of the course. The other one (about 10%) is obtained at half the course, once the first results presentation is done.

Each student is assessed on the individual exercises. At least six exercises must be submitted during the course and before the deadline established in each case, and at least three of them must get a grade of five or more. The grade awarded is the average of all the handed out exercises.

Students are also graded on their individual participation. This is based on their contribution to group work, the role in the group (coordinator, secretary, presenter, quality responsible, etc.), the level of assistance to the work meetings and classes, the number of individual exercises carried out correctly, and their general participation in the various activities making up the course. A student is evaluated on participation only if the student attends at least the 80% of the scheduled meetings and classes.

The evaluation of the cross competence is also individual. It is based on a part of the group work that will be specifically evaluated. The evaluation takes into account the quality of the work done (this is the same for all members of the group) and the participation of each student in that part of the group work (individual evaluation).

Basic Bibliography

  • 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.

Complementary Bibliography

  • 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.

Web links

  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


Previous capacities

Students should be aware that software engineering in an integral part of the course. Students also need to have a good grounding in (formal) specifications of object-oriented information systems, using UML and OCL.

In view of the foregoing, Software Engineering I is a prerequisite for this course.


Compartir

 
logo FIB © Barcelona school of informatics - Contact - RSS
This website uses cookies to offer you the best experience and service. If you continue browsing, it is understood that you accept our cookies policy.
Classic version Mobile version