MSc: Requirements Engineering - Revision history

R.sirgalina at 08:59, 29 August 2022

2022-08-29T08:59:53Z

M.petrishchev at 08:06, 26 April 2022

2022-04-26T08:06:53Z

R.akhmetzyanov: /* Prerequisites */

2022-04-22T13:34:26Z

Prerequisites

@@ Line 30: / Line 30: @@
 * Basics of Software Development process
 * Basics of Software Engineering
 == Recommendations for students on how to succeed in the course ==

M.petrishchev: /* Prerequisites */

2022-04-21T06:46:01Z

Prerequisites

@@ Line 30: / Line 30: @@
 * Basics of Software Development process
 * Basics of Software Engineering
 == Recommendations for students on how to succeed in the course ==

R.akhmetzyanov: /* Prerequisites */

2022-04-18T07:53:06Z

Prerequisites

← Older revision		Revision as of 07:53, 18 April 2022
Line 31:		Line 31:
	* Basics of Software Engineering		* 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:		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=pquPUX1EihM What is Software Development]

M.petrishchev: M.petrishchev moved page MSc:Requirements Engineering to MSc: Requirements Engineering

2022-04-15T08:42:24Z

M.petrishchev moved page MSc:Requirements Engineering to MSc: Requirements Engineering

← Older revision	Revision as of 08:42, 15 April 2022
(No difference)

M.petrishchev at 08:31, 11 April 2022

2022-04-11T08:31:49Z

@@ Line 21: / Line 21: @@
 * 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.
 === Course Objectives Based on Bloom’s Taxonomy ===

M.petrishchev: M.petrishchev moved page MSc:RequirementsEngineering.F21 to MSc:Requirements Engineering

2022-04-10T12:36:33Z

M.petrishchev moved page MSc:RequirementsEngineering.F21 to MSc:Requirements Engineering

← Older revision	Revision as of 12:36, 10 April 2022
(No difference)

I.konyukhov: I.konyukhov moved page MSc:RequirementsEngineering to MSc:RequirementsEngineering.F21

2021-11-14T17:17:04Z

I.konyukhov moved page MSc:RequirementsEngineering to MSc:RequirementsEngineering.F21

← Older revision	Revision as of 17:17, 14 November 2021
(No difference)

10.90.136.11: Created page with "= Requirements Engineering = * '''Course name:''' Requirements Engineering * '''Course number:''' SE- == Course characteristics == === Key concept..."

2021-07-30T12:12:16Z

Created page with "= Requirements Engineering = * '''Course name:''' Requirements Engineering * '''Course number:''' SE- == Course characteristics == === Key concept..."

New page

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

=== 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 ==

{|
|+ Course grade breakdown
| 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 ===

<div id="tab:ModelsCourseGradingRange">

{|
|+ Course grading range
!
!
!align="center"| '''Proposed range'''
|-
| A. Excellent
| 90-100
|align="center"| 80-100
|-
| B. Good
| 75-89
|align="center"| 65-79
|-
| C. Satisfactory
| 60-74
|align="center"| 50-64
|-
| D. Poor
| 0-59
|align="center"| 0-49
|}

</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 ===

* Handouts supplied by the instructor
*
*
*

== Course Sections ==

The main sections of the course and approximate hour distribution between them is as follows:

{|
|+ Course Sections
!align="center"| '''Section'''
! '''Section Title'''
!align="center"| '''Teaching Hours'''
|-
|align="center"| 1
| Requirements elicitation and documentation
|align="center"| 20
|-
|align="center"| 2
| Requirements prototyping and implementation
|align="center"| 20
|-
|align="center"| 3
| Requirements verification and traceability
|align="center"| 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? ===

<div class="tabular">

|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 

</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 ===

# 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? ===

<div class="tabular">

|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 

</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.
# 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? ===

<div class="tabular">

|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 

</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.
# 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.

← Older revision		Revision as of 08:06, 26 April 2022
Line 49:		Line 49:
	The “Requirements Engineering” course develops students’ skills at all the 6 levels of the 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? ===	+	=== 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:		By the end of the course, the students should be able to recognize and define:
Line 67:		Line 67:
	* Traceability links		* Traceability links

−	=== - What should a student be able to understand at the end of the course? ===	+	=== 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):		By the end of the course, the students should be able to describe and explain (with examples):
Line 79:		Line 79:
	* 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? ===	+	=== 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:		By the end of the course, the students should be able to apply:
Line 91:		Line 91:
	* Acceptance testing		* Acceptance testing

−	=== - What inference can a student make based on the acquired knowledge? ===	+	=== What inference can a student make based on the acquired knowledge? ===

	By the end of the course, the students should be able to identify:		By the end of the course, the students should be able to identify:
Line 101:		Line 101:
	* Incompletely elicited requirements		* Incompletely elicited requirements

−	=== - What judgements can a student make about the studied field? ===	+	=== What judgements can a student make about the studied field? ===

	By the end of the course, the students should be able to judge:		By the end of the course, the students should be able to judge:
Line 112:		Line 112:
	* Presentations of other students		* Presentations of other students

−	=== - What actions can students take based on their judgement? ===	+	=== 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:		By the end of the course, the students should be able to take appropriate actions for: