MSc: Requirements Engineering
Requirements Engineering
- Course name: Requirements Engineering
- Course number: SE-
Course characteristics
Key concepts of the class
- Requirements elicitation
- Requirements specification
- Requirements prototyping and implementation
- Requirements verification
- Requirements traceability
What is the purpose of this course?
The course has the following key objectives:
- To introduce the motivation, conceptual background and terminology on which requirements engineering relies.
- To provide a comprehensive account of state-of-the-art techniques for requirements engineering.
- To let the students experience the actual requirements-caused problems faced by real software teams.
Prerequisites
The course has been designed to be self-included as much as possible. It can be useful to have a general understanding of the following:
- Basics of Software Development
- Basics of Software Testing
- Basics of Software design and Unified Modelling Language
- Basics of Software Development process
- Basics of Software Engineering
Recommendations for students on how to succeed in the course
I suggest here some simple video material that can help a smooth introduction with the course:
- What is Software Development
- What Are The Steps of the Software Development Lifecycle?
- Software Development Lifecycle in 9 minutes!
- Software Testing Explained: How QA is Done Today
- Functional and Nonfunctional Requirements - Georgia Tech - Software Development Process
- What is Agile?
- What Professional Software Engineers ACTUALLY Do
It can be an advantage to read introductory chapters of the main textbook: Axel van Lamsweerde Requirements Engineering, Wiley Publishing (2009)
Course Objectives Based on Bloom’s Taxonomy
The “Requirements Engineering” course develops students’ skills at all the 6 levels of the Bloom’s taxonomy.
- What should a student remember at the end of the course?
By the end of the course, the students should be able to recognize and define:
- System requirements
- Software requirements
- Domain knowledge
- Environment assumptions
- Environment-controlled phenomena
- Machine-controlled phenomena
- Environment-observed phenomena
- Machine-observed phenomena
- Problem space
- Solution space
- Prescriptive statements
- Descriptive statements
- Traceability links
- What should a student be able to understand at the end of the course?
By the end of the course, the students should be able to describe and explain (with examples):
- Difference between system and software requirements
- Difference between domain knowledge and environment assumptions
- Pairwise difference between environment- and machine-controlled (observed) phenomena
- Difference between the world and the machine
- Difference between problem and solution space
- Difference between prescriptive and descriptive statements
- Difference between vertical and horizontal traceability
- What should a student be able to apply at the end of the course?
By the end of the course, the students should be able to apply:
- Requirements elicitation techniques
- Requirements specification techniques
- Prototyping and implementation techniques
- Negotiation techniques for modifying requirements
- Techniques for establishing traceability links, both vertical and horizontal
- Parameterized unit testing
- Acceptance testing
- What inference can a student make based on the acquired knowledge?
By the end of the course, the students should be able to identify:
- Lack of traceability links
- Incorrectly implemented requirements
- Incorrectly elicited requirements
- Incompletely implemented requirements
- Incompletely elicited requirements
- What judgements can a student make about the studied field?
By the end of the course, the students should be able to judge:
- Completeness of a requirements document specified by others
- Correctness of a requirements document specified by others
- Completeness of an implementation developed by others wrt requirements
- Correctness of an implementation developed by others wrt requirements
- Traceability for software artifacts created by others
- Presentations of other students
- What actions can students take based on their judgement?
By the end of the course, the students should be able to take appropriate actions for:
- Eliciting lacking requirements from stakeholders
- Negotiating requirements modifications with stakeholders
- Implementing lacking functionality, wrt to requirements, in software developed by others
- Fixing functionality that incorrectly implements requirements in software developed by others
- Introducing missing traceability links
- Writing additional tests to achieve sufficient requirements coverage
Course evaluation
Evaluation
| Practical assignments | 60 |
| Reading assignments | 18 |
| Project presentations | 12 |
| Classroom participation | 10 |
If necessary, please indicate freely your course’s features in terms of students’ performance assessment: None
Grades range
| Proposed range | ||
|---|---|---|
| A. Excellent | 90-100 | 80-100 |
| B. Good | 75-89 | 65-79 |
| C. Satisfactory | 60-74 | 50-64 |
| D. Poor | 0-59 | 0-49 |
If necessary, please indicate freely your course’s grading features: The semester starts with the default range as proposed in the Table 1, but it may change slightly (usually reduced) depending on how the semester progresses.
Resources and reference material
- Handouts supplied by the instructor
Course Sections
The main sections of the course and approximate hour distribution between them is as follows:
| Section | Section Title | Teaching Hours |
|---|---|---|
| 1 | Requirements elicitation and documentation | 20 |
| 2 | Requirements prototyping and implementation | 20 |
| 3 | Requirements verification and traceability | 20 |
Section 1
Section title:
Requirements elicitation and documentation
Topics covered in this section:
- Foundations of requirements engineering
- The world and the machine
- Domain understanding and requirements elicitation
- Questions for interviews
- The requirements process
- Use cases
- Requirements specification and documentation
What forms of evaluation were used to test students’ performance in this section?
|a|c| & Yes/No
Development of individual parts of software product code & 0
Homework and group projects & 1
Midterm evaluation & 0
Testing (written or computer based) & 1
Reports & 1
Essays & 0
Oral polls & 0
Discussions & 1
Typical questions for ongoing performance evaluation within this section
- What is the WHY-Dimension of requirements engineering?
- What criteria are recommended to use for stakeholders analysis?
- Who is a stakeholder?
- What is an artifact-driven elicitation technique?
- What are the four principles for description in requirements engineering?
- What are the four facets of relationship between the world and the machine?
- What are the four kinds of denial in software engineering?
- What is a descriptive statement?
- What are the different kinds of information about the world?
Typical questions for seminar classes (labs) within this section
- Write down and present a project proposal for implementing during the course.
- Propose a set of questions for a requirements elicitation interview.
- Conduct, audio record and transcribe an elicitation interview.
- Design use cases based on the elicitation transcript and audio recording.
Test questions for final assessment in this section
- Present you experience of preparing and conducting the elicitation interview.
- How did you choose the stakeholder for interviewing?
- Did the interview go according to the plan?
- Which of the initially prepared questions you did not ask during the interview? Why?
- What questions you had to ask in addition to the initially prepared ones? Why?
- If you have been interviewed, how relevant were the interviewer’s questions?
- What conflicts did you have when merging the interview transcripts of your team members?
- How did you solve the merging conflicts?
- What lessons have you learned based on your experience as an interviewer and an interviewee?
- Present use cases constructed based on the elicited information.
- How do the use cases trace to the interview transcript?
- How does the interview transcript trace to the use cases?
Section 2
Section title:
Requirements prototyping and implementation
Topics covered in this section:
- Mapping use cases to object models
- From use cases to user interface design
- Activity diagrams
- The psychopathology of everyday things
- Seamless requirements
- The anatomy of requirements
What forms of evaluation were used to test students’ performance in this section?
|a|c| & Yes/No
Development of individual parts of software product code & 1
Homework and group projects & 1
Midterm evaluation & 0
Testing (written or computer based) & 1
Reports & 1
Essays & 0
Oral polls & 1
Discussions & 1
Typical questions for ongoing performance evaluation within this section
- What value do UML diagrams bring to the requirements engineering process?
- Define the “extend” relationship between use cases.
- Enumerate risk reduction tactics.
- Describe defining characteristics of what Davis calls “knowledge structure”.
- What activities does the risk management process involve?
- How do you call an active component in a use case diagram?
- What is the purpose of postconditions in use cases?
- Name different types of relationships in use case modelling.
- Categorize UML as either informal, semi-formal or formal notation.
- Define the “generalization” relationship in UML.
Typical questions for seminar classes (labs) within this section
- Reflect, individually and in teams, on the use cases and the use case diagram that you received for implementation from another team.
- Construct activity diagrams from the use cases and the use case diagram.
- Construct classes based on the activity diagrams.
- Design user interfaces based on the classes and activity diagrams.
- Develop a minimum viable product (MVP) implementing your input requirements.
Test questions for final assessment in this section
- Record and present a short demo of your MVP.
- What decisions did you have to take when implementing the MVP?
- How did you define your MVP?
- What did you have to change in the requirements document, and why?
- What requirements you decided to cover and not to cover in the MVP, and why?
- Present lessons learned from developing the MVP.
Section 3
Section title:
Requirements verification and traceability
Topics covered in this section:
- Parameterized unit tests
- Goal modelling
- Scrum & User stories
- Use case testing
What forms of evaluation were used to test students’ performance in this section?
|a|c| & Yes/No
Development of individual parts of software product code & 1
Homework and group projects & 1
Midterm evaluation & 0
Testing (written or computer based) & 1
Reports & 1
Essays & 1
Oral polls & 1
Discussions & 1
Typical questions for ongoing performance evaluation within this section
- How do we call an active system component playing a specific role in goal satisfaction?
- How do we call an autonomous and passive object in the object model, which cannot control the behaviours of instances of other objects?
- What is a goal?
- What goal pattern refers to every future state?
- How do we call an association where the composite object and its components appear and disappear together in the system?
- Describe the goal refinement process.
- What is object specialization?
- Define the “maintain” goal pattern.
- Enumerate and describe different relationships between goals.
Typical questions for seminar classes (labs) within this section
- Construct parameterized unit tests for the MVP provided to you by another team.
- Reflect, individually and in teams, on the MVP provided to you by another team.
- Reflect, individually and in teams, on the user interface design of the MVP.
- Develop the MVP into a usable production-quality software.
- Construct use case tests and parameterized units tests for the final implementation; update the requirements document as you go.
- Run the tests and fix the identified defects; update the requirements document as you go.
- Ensure pairwise mutual completeness between the requirements, final implementation and tests.
- Ensure pairwise mutual traceability between the requirements, final implementation and tests.
- Write a document that will describe very clearly how to run and use the final implementation.
- Describe in the document how to reproduce different use cases in the actual software.
Test questions for final assessment in this section
- Present the final system developed from the MVP received from another team.
- Introduce the project and its business goals.
- Evaluate the quality of the interview transcript.
- Evaluate the quality of the use cases.
- Evaluate the quality of the MVP and user interfaces.
- Reflect on the quality management process.
- Record and present demo of test runs.
- Reflect on teamwork and communication with other teams.
- Present lessons learned while implementing different parts of different projects coming from the other teams.
- Record and present demo runs of the software using the use cases as the reference.
- Describe strengths and weaknesses of the final implementation.
- Write an essay detailing your reflections on the overall course experience.