Difference between revisions of "MSc: Requirements Engineering"
Jump to navigation
Jump to search
I.konyukhov (talk | contribs) m (I.konyukhov moved page MSc:RequirementsEngineering to MSc:RequirementsEngineering.F21) |
R.sirgalina (talk | contribs) |
||
(7 intermediate revisions by 2 users not shown) | |||
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- |
||
− | == |
+ | == 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 === |
||
− | * Requirements elicitation |
||
− | * Requirements specification |
||
− | * Requirements prototyping and implementation |
||
− | * Requirements verification |
||
− | * Requirements traceability |
||
− | === What is the purpose of this course? === |
||
+ | == Course Topics == |
||
− | The course has the following key objectives: |
||
+ | {| class="wikitable" |
||
− | |||
+ | |+ Course Sections and Topics |
||
− | * 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. |
||
+ | ! Section !! Topics within the section |
||
− | * To let the students experience the actual requirements-caused problems faced by real software teams. |
||
+ | |- |
||
− | |||
+ | | Requirements elicitation and documentation || |
||
− | === Course Objectives Based on Bloom’s Taxonomy === |
||
+ | # Foundations of requirements engineering |
||
− | |||
+ | # The world and the machine |
||
− | The “Requirements Engineering” course develops students’ skills at all the 6 levels of the Bloom’s taxonomy. |
||
+ | # 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) == |
||
− | === |
+ | === 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 === |
||
− | 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 44: | Line 72: | ||
* Traceability links |
* 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 ... |
||
− | |||
− | 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 56: | Line 82: | ||
* Difference between vertical and horizontal traceability |
* 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 ... |
||
− | |||
− | 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 66: | 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 |
||
− | | |
+ | |- |
+ | | 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, literature and reference materials == |
|
+ | === Open access resources === |
||
* Handouts supplied by the instructor |
* Handouts supplied by the instructor |
||
− | * |
||
− | * |
||
− | * |
||
− | == |
+ | === 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''' |
||
− | + | == 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 == |
||
− | === |
+ | === 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> & '''Yes/No'''<br /> |
||
− | Development of individual parts of software product code & 0<br /> |
||
− | Homework and group projects & 1<br /> |
||
− | Midterm evaluation & 0<br /> |
||
− | Testing (written or computer based) & 1<br /> |
||
− | Reports & 1<br /> |
||
− | Essays & 0<br /> |
||
− | Oral polls & 0<br /> |
||
− | Discussions & 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 248: | 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> & '''Yes/No'''<br /> |
||
− | Development of individual parts of software product code & 1<br /> |
||
− | Homework and group projects & 1<br /> |
||
− | Midterm evaluation & 0<br /> |
||
− | Testing (written or computer based) & 1<br /> |
||
− | Reports & 1<br /> |
||
− | Essays & 0<br /> |
||
− | Oral polls & 1<br /> |
||
− | Discussions & 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 310: | 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 & 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> & '''Yes/No'''<br /> |
||
− | Development of individual parts of software product code & 1<br /> |
||
− | Homework and group projects & 1<br /> |
||
− | Midterm evaluation & 0<br /> |
||
− | Testing (written or computer based) & 1<br /> |
||
− | Reports & 1<br /> |
||
− | Essays & 1<br /> |
||
− | Oral polls & 1<br /> |
||
− | Discussions & 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 380: | 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
Section | Topics within the section |
---|---|
Requirements elicitation and documentation |
|
Requirements prototyping and implementation |
|
Requirements verification and traceability |
|
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
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
- 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
- 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
- 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.
The retake exam
Section 1
Section 2
Section 3