Difference between revisions of "MSc: Requirements Engineering"

From IU
Jump to navigation Jump to search
 
Line 1: Line 1:
  +
 
= Requirements Engineering =
  
= Requirements Engineering =
  +
* '''Course name''': Requirements Engineering
  +
* '''Code discipline''': SE-
  +
* '''Subject area''':
   
  +
== Short Description ==
−
* <span>'''Course name:'''</span> Requirements Engineering
  
  +
This course covers the following concepts: Requirements elicitation; Requirements specification; Requirements prototyping and implementation; Requirements verification; Requirements traceability.
−
* <span>'''Course number:'''</span> 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 ==
  
== Prerequisites ==
   
  +
=== Prerequisite subjects ===
−
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 Development
 
* Basics of Software Testing
  
* Basics of Software Testing
 
* Basics of Software design and Unified Modelling Language
  
* Basics of Software design and Unified Modelling Language
−
* Basics of Software Development process
+
* Basics of Software Development process
 
* Basics of Software Engineering
  
* Basics of Software Engineering
   
  +
=== Prerequisite topics ===
−
== 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:
  
−
* [https://www.youtube.com/watch?v=pquPUX1EihM What is Software Development]
  
−
* [https://www.youtube.com/watch?v=gNmrGZSGK1k What Are The Steps of the Software Development Lifecycle?]
  
−
* [https://www.youtube.com/watch?v=i-QyW8D3ei0 Software Development Lifecycle in 9 minutes!]
  
−
* [https://www.youtube.com/watch?v=oLc9gVM8FBM Software Testing Explained: How QA is Done Today]
  
−
* [https://www.youtube.com/watch?v=zCX-N1H8Vps Functional and Nonfunctional Requirements - Georgia Tech - Software Development Process]
  
−
* [https://www.youtube.com/watch?v=Z9QbYZh1YXY What is Agile?]
  
−
* [https://www.youtube.com/watch?v=Q0A35ZfgwHA What Professional Software Engineers ACTUALLY Do]
  
   
−
It can be an advantage to read introductory chapters of the main textbook:
  
−
Axel van Lamsweerde [https://www.wiley.com/en-us/Requirements+Engineering%3A+From+System+Goals+to+UML+Models+to+Software+Specifications-p-9780470012703 Requirements Engineering], Wiley Publishing (2009)
 
   
  +
== Course Topics ==
  +
{| class="wikitable"
  +
|+ Course Sections and Topics
  +
|-
  +
! Section !! Topics within the section
  +
|-
  +
| Requirements elicitation and documentation ||
  +
# 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
  +
|-
  +
| Requirements prototyping and implementation ||
  +
# 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
  +
|-
  +
| Requirements verification and traceability ||
  +
# Parameterized unit tests
  +
# Goal modelling
  +
# Scrum & User stories
  +
# Use case testing
  +
|}
  +
== Intended Learning Outcomes (ILOs) ==
   
−
=== Course Objectives Based on Bloom’s Taxonomy ===
 +
=== What is the main purpose of this course? ===
  +
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.
−  
−
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? ===
  
   
  +
=== ILOs defined at three levels ===
−
By the end of the course, the students should be able to recognize and define:
  
   
  +
==== Level 1: What concepts should a student know/remember/explain? ====
  +
By the end of the course, the students should be able to ...
 
* System requirements
  
* System requirements
 
* Software requirements
  
* Software requirements
Line 67: Line 72:
 
* Traceability links
  
* Traceability links
   
−
=== What should a student be able to understand at the end of the course? ===
 +
==== Level 2: What basic practical skills should a student be able to perform? ====
  +
By the end of the course, the students should be able to ...
−  
−
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 system and software requirements
 
* Difference between domain knowledge and environment assumptions
  
* Difference between domain knowledge and environment assumptions
Line 79: Line 82:
 
* Difference between vertical and horizontal traceability
  
* Difference between vertical and horizontal traceability
   
−
=== What should a student be able to apply at the end of the course? ===
 +
==== Level 3: What complex comprehensive skills should a student be able to apply in real-life scenarios? ====
  +
By the end of the course, the students should be able to ...
−  
−
By the end of the course, the students should be able to apply:
  
−  
 
* Requirements elicitation techniques
  
* Requirements elicitation techniques
 
* Requirements specification techniques
  
* Requirements specification techniques
Line 89: Line 90:
 
* Techniques for establishing traceability links, both vertical and horizontal
  
* Techniques for establishing traceability links, both vertical and horizontal
 
* Parameterized unit testing
  
* Parameterized unit testing
−
* Acceptance testing
 +
* Acceptance testing
  +
== Grading ==
   
  +
=== Course grading range ===
−
=== What inference can a student make based on the acquired knowledge? ===
  
  +
{| class="wikitable"
−  
  +
|+
−
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 ==
  
−  
−
{|
  
−
|+ Course grade breakdown
  
−
| Practical assignments
  
−
| 60
  
 
|-
  
|-
  +
! Grade !! Range !! Description of performance
−
| Reading assignments
  
−
| 18
  
 
|-
  
|-
  +
| A. Excellent || 80-100 || -
−
| Project presentations
  
−
| 12
  
 
|-
  
|-
  +
| B. Good || 65-79 || -
−
| Classroom participation
  
−
| 10
 +
|-
  +
| C. Satisfactory || 50-64 || -
  +
|-
  +
| D. Poor || 0-49 || -
 
|}
  
|}
   
  +
=== Course activities and grading breakdown ===
−
If necessary, please indicate freely your course’s features in terms of students’ performance assessment: None
  
  +
{| class="wikitable"
−  
  +
|+
−
=== Grades range ===
  
  +
|-
−  
  +
! Activity Type !! Percentage of the overall course grade
−
<div id="tab:ModelsCourseGradingRange">
  
−  
−
{|
  
−
|+ Course grading range
  
−
!
  
−
!
  
−
!align="center"| '''Proposed range'''
  
 
|-
  
|-
  +
| Practical assignments || 60
−
| A. Excellent
  
−
| 90-100
  
−
|align="center"| 80-100
  
 
|-
  
|-
  +
| Reading assignments || 18
−
| B. Good
  
−
| 75-89
  
−
|align="center"| 65-79
  
 
|-
  
|-
  +
| Project presentations || 12
−
| C. Satisfactory
  
−
| 60-74
  
−
|align="center"| 50-64
  
 
|-
  
|-
  +
| Classroom participation || 10
−
| D. Poor
  
−
| 0-59
  
−
|align="center"| 0-49
  
 
|}
  
|}
   
  +
=== Recommendations for students on how to succeed in the course ===
   
−
</div>
  
−
If necessary, please indicate freely your course’s grading features: The semester starts with the default range as proposed in the Table [[#tab:ModelsCourseGradingRange|1]], but it may change slightly (usually reduced) depending on how the semester progresses.
  
   
−
=== Resources and reference material ===
 +
== Resources, literature and reference materials ==
   
  +
=== Open access resources ===
 
* Handouts supplied by the instructor
  
* Handouts supplied by the instructor
−
*
 
−
*
 
−
*
 
   
−
== Course Sections ==
 +
=== Closed access resources ===
   
−
The main sections of the course and approximate hour distribution between them is as follows:
  
   
  +
=== Software and tools used within the course ===
−
{|
  
  +
−
|+ Course Sections
  
  +
= Teaching Methodology: Methods, techniques, & activities =
−
!align="center"| '''Section'''
  
  +
−
! '''Section Title'''
  
−
!align="center"| '''Teaching Hours'''
 +
== Activities and Teaching Methods ==
  +
{| class="wikitable"
  +
|+ Activities within each section
 
|-
  
|-
  +
! Learning Activities !! Section 1 !! Section 2 !! Section 3
−
|align="center"| 1
  
−
| Requirements elicitation and documentation
  
−
|align="center"| 20
  
 
|-
  
|-
  +
| Homework and group projects || 1 || 1 || 1
−
|align="center"| 2
  
−
| Requirements prototyping and implementation
  
−
|align="center"| 20
  
 
|-
  
|-
  +
| Testing (written or computer based) || 1 || 1 || 1
−
|align="center"| 3
  
  +
|-
−
| Requirements verification and traceability
  
  +
| Reports || 1 || 1 || 1
−
|align="center"| 20
  
−
|}
 +
|-
  +
| Discussions || 1 || 1 || 1
  +
|-
  +
| Development of individual parts of software product code || 0 || 1 || 1
  +
|-
  +
| Oral polls || 0 || 1 || 1
  +
|-
  +
| Essays || 0 || 0 || 1
  +
|}
  +
== Formative Assessment and Course Activities ==
   
−
=== Section 1 ===
 +
=== Ongoing performance assessment ===
−  
−
=== 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? ===
  
−  
−
<div class="tabular">
  
−  
−
<span>|a|c|</span> &amp; '''Yes/No'''<br />
  
−
Development of individual parts of software product code &amp; 0<br />
  
−
Homework and group projects &amp; 1<br />
  
−
Midterm evaluation &amp; 0<br />
  
−
Testing (written or computer based) &amp; 1<br />
  
−
Reports &amp; 1<br />
  
−
Essays &amp; 0<br />
  
−
Oral polls &amp; 0<br />
  
−
Discussions &amp; 1<br />
  
−  
−  
−  
−
</div>
  
−
=== 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 ===
  
   
  +
==== Section 1 ====
  +
{| class="wikitable"
  +
|+
  +
|-
  +
! Activity Type !! Content !! Is Graded?
  +
|-
  +
| Question || What is the WHY-Dimension of requirements engineering? || 1
  +
|-
  +
| Question || What criteria are recommended to use for stakeholders analysis? || 1
  +
|-
  +
| Question || Who is a stakeholder? || 1
  +
|-
  +
| Question || What is an artifact-driven elicitation technique? || 1
  +
|-
  +
| Question || What are the four principles for description in requirements engineering? || 1
  +
|-
  +
| Question || What are the four facets of relationship between the world and the machine? || 1
  +
|-
  +
| Question || What are the four kinds of denial in software engineering? || 1
  +
|-
  +
| Question || What is a descriptive statement? || 1
  +
|-
  +
| Question || What are the different kinds of information about the world? || 1
  +
|-
  +
| Question || Write down and present a project proposal for implementing during the course. || 0
  +
|-
  +
| Question || Propose a set of questions for a requirements elicitation interview. || 0
  +
|-
  +
| Question || Conduct, audio record and transcribe an elicitation interview. || 0
  +
|-
  +
| Question || Design use cases based on the elicitation transcript and audio recording. || 0
  +
|}
  +
==== Section 2 ====
  +
{| class="wikitable"
  +
|+
  +
|-
  +
! Activity Type !! Content !! Is Graded?
  +
|-
  +
| Question || What value do UML diagrams bring to the requirements engineering process? || 1
  +
|-
  +
| Question || Define the “extend” relationship between use cases. || 1
  +
|-
  +
| Question || Enumerate risk reduction tactics. || 1
  +
|-
  +
| Question || Describe defining characteristics of what Davis calls “knowledge structure”. || 1
  +
|-
  +
| Question || What activities does the risk management process involve? || 1
  +
|-
  +
| Question || How do you call an active component in a use case diagram? || 1
  +
|-
  +
| Question || What is the purpose of postconditions in use cases? || 1
  +
|-
  +
| Question || Name different types of relationships in use case modelling. || 1
  +
|-
  +
| Question || Categorize UML as either informal, semi-formal or formal notation. || 1
  +
|-
  +
| Question || Define the “generalization” relationship in UML. || 1
  +
|-
  +
| Question || Reflect, individually and in teams, on the use cases and the use case diagram that you received for implementation from another team. || 0
  +
|-
  +
| Question || Construct activity diagrams from the use cases and the use case diagram. || 0
  +
|-
  +
| Question || Construct classes based on the activity diagrams. || 0
  +
|-
  +
| Question || Design user interfaces based on the classes and activity diagrams. || 0
  +
|-
  +
| Question || Develop a minimum viable product (MVP) implementing your input requirements. || 0
  +
|}
  +
==== Section 3 ====
  +
{| class="wikitable"
  +
|+
  +
|-
  +
! Activity Type !! Content !! Is Graded?
  +
|-
  +
| Question || How do we call an active system component playing a specific role in goal satisfaction? || 1
  +
|-
  +
| Question || How do we call an autonomous and passive object in the object model, which cannot control the behaviours of instances of other objects? || 1
  +
|-
  +
| Question || What is a goal? || 1
  +
|-
  +
| Question || What goal pattern refers to every future state? || 1
  +
|-
  +
| Question || How do we call an association where the composite object and its components appear and disappear together in the system? || 1
  +
|-
  +
| Question || Describe the goal refinement process. || 1
  +
|-
  +
| Question || What is object specialization? || 1
  +
|-
  +
| Question || Define the “maintain” goal pattern. || 1
  +
|-
  +
| Question || Enumerate and describe different relationships between goals. || 1
  +
|-
  +
| Question || Construct parameterized unit tests for the MVP provided to you by another team. || 0
  +
|-
  +
| Question || Reflect, individually and in teams, on the MVP provided to you by another team. || 0
  +
|-
  +
| Question || Reflect, individually and in teams, on the user interface design of the MVP. || 0
  +
|-
  +
| Question || Develop the MVP into a usable production-quality software. || 0
  +
|-
  +
| Question || Construct use case tests and parameterized units tests for the final implementation; update the requirements document as you go. || 0
  +
|-
  +
| Question || Run the tests and fix the identified defects; update the requirements document as you go. || 0
  +
|-
  +
| Question || Ensure pairwise mutual completeness between the requirements, final implementation and tests. || 0
  +
|-
  +
| Question || Ensure pairwise mutual traceability between the requirements, final implementation and tests. || 0
  +
|-
  +
| Question || Write a document that will describe very clearly how to run and use the final implementation. || 0
  +
|-
  +
| Question || Describe in the document how to reproduce different use cases in the actual software. || 0
  +
|}
  +
=== Final assessment ===
  +
'''Section 1'''
 
# Present you experience of preparing and conducting the elicitation interview.
  
# Present you experience of preparing and conducting the elicitation interview.
 
# How did you choose the stakeholder for interviewing?
  
# How did you choose the stakeholder for interviewing?
Line 271: Line 288:
 
# How do the use cases trace to the interview transcript?
  
# How do the use cases trace to the interview transcript?
 
# How does the interview transcript trace to the use cases?
  
# How does the interview transcript trace to the use cases?
  +
'''Section 2'''
−  
−
=== 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? ===
  
−  
−
<div class="tabular">
  
−  
−
<span>|a|c|</span> &amp; '''Yes/No'''<br />
  
−
Development of individual parts of software product code &amp; 1<br />
  
−
Homework and group projects &amp; 1<br />
  
−
Midterm evaluation &amp; 0<br />
  
−
Testing (written or computer based) &amp; 1<br />
  
−
Reports &amp; 1<br />
  
−
Essays &amp; 0<br />
  
−
Oral polls &amp; 1<br />
  
−
Discussions &amp; 1<br />
  
−  
−  
−  
−
</div>
  
−
=== 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.
  
# Record and present a short demo of your MVP.
 
# What decisions did you have to take when implementing the MVP?
  
# What decisions did you have to take when implementing the MVP?
Line 333: Line 295:
 
# What requirements you decided to cover and not to cover in the MVP, and why?
  
# What requirements you decided to cover and not to cover in the MVP, and why?
 
# Present lessons learned from developing the MVP.
  
# Present lessons learned from developing the MVP.
  +
'''Section 3'''
−  
−
=== Section 3 ===
  
−  
−
=== Section title: ===
  
−  
−
Requirements verification and traceability
  
−  
−
=== Topics covered in this section: ===
  
−  
−
* Parameterized unit tests
  
−
* Goal modelling
  
−
* Scrum &amp; User stories
  
−
* Use case testing
  
−  
−
=== What forms of evaluation were used to test students’ performance in this section? ===
  
−  
−
<div class="tabular">
  
−  
−
<span>|a|c|</span> &amp; '''Yes/No'''<br />
  
−
Development of individual parts of software product code &amp; 1<br />
  
−
Homework and group projects &amp; 1<br />
  
−
Midterm evaluation &amp; 0<br />
  
−
Testing (written or computer based) &amp; 1<br />
  
−
Reports &amp; 1<br />
  
−
Essays &amp; 1<br />
  
−
Oral polls &amp; 1<br />
  
−
Discussions &amp; 1<br />
  
−  
−  
−  
−
</div>
  
−
=== 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.
  
# Present the final system developed from the MVP received from another team.
 
# Introduce the project and its business goals.
  
# Introduce the project and its business goals.
Line 403: Line 308:
 
# Describe strengths and weaknesses of the final implementation.
  
# Describe strengths and weaknesses of the final implementation.
 
# Write an essay detailing your reflections on the overall course experience.
  
# Write an essay detailing your reflections on the overall course experience.
  +
  +
=== The retake exam ===
  +
'''Section 1'''
  +
  +
'''Section 2'''
  +
  +
'''Section 3'''

Latest revision as of 11:59, 29 August 2022

Requirements Engineering

  • Course name: Requirements Engineering
  • Code discipline: SE-
  • Subject area:

Short Description

This course covers the following concepts: Requirements elicitation; Requirements specification; Requirements prototyping and implementation; Requirements verification; Requirements traceability.

Prerequisites

Prerequisite subjects

  • 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

Prerequisite topics

Course Topics

Course Sections and Topics
Section Topics within the section
Requirements elicitation and documentation
  1. Foundations of requirements engineering
  2. The world and the machine
  3. Domain understanding and requirements elicitation
  4. Questions for interviews
  5. The requirements process
  6. Use cases
  7. Requirements specification and documentation
Requirements prototyping and implementation
  1. Mapping use cases to object models
  2. From use cases to user interface design
  3. Activity diagrams
  4. The psychopathology of everyday things
  5. Seamless requirements
  6. The anatomy of requirements
Requirements verification and traceability
  1. Parameterized unit tests
  2. Goal modelling
  3. Scrum & User stories
  4. Use case testing

Intended Learning Outcomes (ILOs)

What is the main purpose of this course?

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.

ILOs defined at three levels

Level 1: What concepts should a student know/remember/explain?

By the end of the course, the students should be able to ...

  • 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

Level 2: What basic practical skills should a student be able to perform?

By the end of the course, the students should be able to ...

  • 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

Level 3: What complex comprehensive skills should a student be able to apply in real-life scenarios?

By the end of the course, the students should be able to ...

  • 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

Grading

Course grading range

Grade Range Description of performance
A. Excellent 80-100 -
B. Good 65-79 -
C. Satisfactory 50-64 -
D. Poor 0-49 -

Course activities and grading breakdown

Activity Type Percentage of the overall course grade
Practical assignments 60
Reading assignments 18
Project presentations 12
Classroom participation 10

Recommendations for students on how to succeed in the course

Resources, literature and reference materials

Open access resources

  • Handouts supplied by the instructor

Closed access resources

Software and tools used within the course

Teaching Methodology: Methods, techniques, & activities

Activities and Teaching Methods

Activities within each section
Learning Activities Section 1 Section 2 Section 3
Homework and group projects 1 1 1
Testing (written or computer based) 1 1 1
Reports 1 1 1
Discussions 1 1 1
Development of individual parts of software product code 0 1 1
Oral polls 0 1 1
Essays 0 0 1

Formative Assessment and Course Activities

Ongoing performance assessment

Section 1

Activity Type Content Is Graded?
Question What is the WHY-Dimension of requirements engineering? 1
Question What criteria are recommended to use for stakeholders analysis? 1
Question Who is a stakeholder? 1
Question What is an artifact-driven elicitation technique? 1
Question What are the four principles for description in requirements engineering? 1
Question What are the four facets of relationship between the world and the machine? 1
Question What are the four kinds of denial in software engineering? 1
Question What is a descriptive statement? 1
Question What are the different kinds of information about the world? 1
Question Write down and present a project proposal for implementing during the course. 0
Question Propose a set of questions for a requirements elicitation interview. 0
Question Conduct, audio record and transcribe an elicitation interview. 0
Question Design use cases based on the elicitation transcript and audio recording. 0

Section 2

Activity Type Content Is Graded?
Question What value do UML diagrams bring to the requirements engineering process? 1
Question Define the “extend” relationship between use cases. 1
Question Enumerate risk reduction tactics. 1
Question Describe defining characteristics of what Davis calls “knowledge structure”. 1
Question What activities does the risk management process involve? 1
Question How do you call an active component in a use case diagram? 1
Question What is the purpose of postconditions in use cases? 1
Question Name different types of relationships in use case modelling. 1
Question Categorize UML as either informal, semi-formal or formal notation. 1
Question Define the “generalization” relationship in UML. 1
Question Reflect, individually and in teams, on the use cases and the use case diagram that you received for implementation from another team. 0
Question Construct activity diagrams from the use cases and the use case diagram. 0
Question Construct classes based on the activity diagrams. 0
Question Design user interfaces based on the classes and activity diagrams. 0
Question Develop a minimum viable product (MVP) implementing your input requirements. 0

Section 3

Activity Type Content Is Graded?
Question How do we call an active system component playing a specific role in goal satisfaction? 1
Question How do we call an autonomous and passive object in the object model, which cannot control the behaviours of instances of other objects? 1
Question What is a goal? 1
Question What goal pattern refers to every future state? 1
Question How do we call an association where the composite object and its components appear and disappear together in the system? 1
Question Describe the goal refinement process. 1
Question What is object specialization? 1
Question Define the “maintain” goal pattern. 1
Question Enumerate and describe different relationships between goals. 1
Question Construct parameterized unit tests for the MVP provided to you by another team. 0
Question Reflect, individually and in teams, on the MVP provided to you by another team. 0
Question Reflect, individually and in teams, on the user interface design of the MVP. 0
Question Develop the MVP into a usable production-quality software. 0
Question Construct use case tests and parameterized units tests for the final implementation; update the requirements document as you go. 0
Question Run the tests and fix the identified defects; update the requirements document as you go. 0
Question Ensure pairwise mutual completeness between the requirements, final implementation and tests. 0
Question Ensure pairwise mutual traceability between the requirements, final implementation and tests. 0
Question Write a document that will describe very clearly how to run and use the final implementation. 0
Question Describe in the document how to reproduce different use cases in the actual software. 0

Final assessment

Section 1

  1. Present you experience of preparing and conducting the elicitation interview.
  2. How did you choose the stakeholder for interviewing?
  3. Did the interview go according to the plan?
  4. Which of the initially prepared questions you did not ask during the interview? Why?
  5. What questions you had to ask in addition to the initially prepared ones? Why?
  6. If you have been interviewed, how relevant were the interviewer’s questions?
  7. What conflicts did you have when merging the interview transcripts of your team members?
  8. How did you solve the merging conflicts?
  9. What lessons have you learned based on your experience as an interviewer and an interviewee?
  10. Present use cases constructed based on the elicited information.
  11. How do the use cases trace to the interview transcript?
  12. How does the interview transcript trace to the use cases?

Section 2

  1. Record and present a short demo of your MVP.
  2. What decisions did you have to take when implementing the MVP?
  3. How did you define your MVP?
  4. What did you have to change in the requirements document, and why?
  5. What requirements you decided to cover and not to cover in the MVP, and why?
  6. Present lessons learned from developing the MVP.

Section 3

  1. Present the final system developed from the MVP received from another team.
  2. Introduce the project and its business goals.
  3. Evaluate the quality of the interview transcript.
  4. Evaluate the quality of the use cases.
  5. Evaluate the quality of the MVP and user interfaces.
  6. Reflect on the quality management process.
  7. Record and present demo of test runs.
  8. Reflect on teamwork and communication with other teams.
  9. Present lessons learned while implementing different parts of different projects coming from the other teams.
  10. Record and present demo runs of the software using the use cases as the reference.
  11. Describe strengths and weaknesses of the final implementation.
  12. Write an essay detailing your reflections on the overall course experience.

The retake exam

Section 1

Section 2

Section 3

Retrieved from "https://eduwiki.innopolis.university/index.php?title=MSc:_Requirements_Engineering&oldid=7477"