System requirements

Project name

Classification	Select an element
Status	Select an element
Program name
Project number
Project manager	Project manager
Version	0.1
Date	Click here to enter a date
Project sponsor	Project sponsor
Author(s)
Distribution

List of changes

Version	Date	Change	Author
0.1

Table 1:	Change control

Description

The system requirements describe requirements for the future system. They are structured according to requirement categories. They include business requirements, operating requirements, support requirements and security requirements, for example, and they are prioritized according to their importance. The documentation of the system requirements is based on and uses the standards/notations of the requirement engineering method used.

Rough requirements

Taken from the study

ID	Requirement	Type 1	Acceptance criterion	Importance 2	Urgency 3
A1	Enter course registration	F	Successful tests according to test case specification	5	5
A2	Display confirmation	Q	Within 2 seconds in 90% of tests in a real system environment	3	4
A3	Confirmations must be sent on a daily basis	B	Within 24 hours following the decision to carry out a course	3	3
A4	Transmit data with encryption	S	Successful tests according to test case specification	5	4
A5	Ensure methodological coherence	C	Validate method components with HERMES CD	5	3
A6
1) Type = Requirement type: B = Business organization, F = Functional, Q = Quality, S = Security, M= Migration, A = Architecture, O = Operation, C = Compliance (legislation, directives, standards and guidelines) 2) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 3) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent

Table 2:	Rough requirements

System overview

A graphical overview of the system helps to enter the specifications in a structured manner. Various techniques can be used for creating the graphical overview.

Technique 1: Function tree

Fig. 1 –	Function tree

Technique 2: Use case

Use case package diagram

Fig. 2 –	Use case package diagram

Use case diagram

Fig. 3 –	Use case diagram

Detailed requirements

Business organization requirements

Organizational requirements are not described here. They are documented in the business organization concept.

Functional requirements

Various techniques can be used to describe the requirements

Technique 1: Description using a general form

Rough requirement	n.nn	Source	Author	Dependence for	Date	13.12.21	Status
Name
Brief functional description
Input	From DB
Processing steps/rules	Step Step Step
Output
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 3:	Technique 1 form

Technique 2: Description using a user story form

Criteria that the product must meet in order to be approved

Per requirement:

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name	US-Name
Descriptions and notes
Acceptance criteria
As <user role> I want <the objective> [, so that <reason for the objective>]
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 4:	Technique 2 form

Technique 3: Description using a use case form

Criteria that the product must meet in order to be approved

Per requirement:

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Developer and contact person
Brief description
Technical trigger (event)
Players
Preconditions
Procedure/interaction
Postconditions
Special cases (alternative progressions 1 - n) (incl. postconditions)
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 5:	Technique 3 form

Quality requirements

User-related non-functional requirements such as user-friendliness, ergonomics, response times, etc.

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name
Description
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 6:	Quality requirements

Operating concept requirements

Operation-related non-functional requirements such as reliability, availability, etc.

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name
Description
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 7:	Operating concept requirements

System architecture requirements

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name
Description
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 8:	System architecture requirements

Migration concept requirements

Migration-related requirements

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name
Description
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 9:	Migration concept requirements

ISDP concept requirements

Information security and data protection requirements

Rough requirement	n.nn	Source	Author	Dependence for	Date	20.12.21	Status
Name
Description
Acceptance criteria
Importance 1	Urgency 2	Risk 3	Outlay 4
1) Importance: 5 = mandatory implementation; 4 = very important; 3 = important; 2 = normal; 1 = not important 2) Urgency: 5 = must be implemented immediately, 4 = very urgent, 3 = urgent, 2 = normal, 1 = not urgent 3) Risk/critical nature: 5 = unacceptable risk, 4 = very high risk, 3 = medium risk, 2 = low risk, 1 = no risk whatsoever 4) Outlay: 5 = unacceptable outlay, 4 = very high outlay, 3 = high, 2 = reasonable, 1 = negligible or no outlay

Table 10:	ISDP concept requirements

Abbreviations and glossary

Abbreviation/specialist term	Explanation
HERMES	Methodology for projects and programs HERMES 5 is an eCH standard

Table 11:	Abbreviations and glossary

Contents

List of changes	1

Description	1

1	Rough requirements	2

2	System overview	2

2.1	Technique 1: Function tree	2

2.2	Technique 2: Use case	3

2.2.1	Use case package diagram	3

2.2.2	Use case diagram	3

3	Detailed requirements	4

3.1	Business organization requirements	4

3.2	Functional requirements	4

3.2.1	Technique 1: Description using a general form	5

3.2.2	Technique 2: Description using a user story form	6

3.2.3	Technique 3: Description using a use case form	7

3.3	Quality requirements	8

3.4	Operating concept requirements	9

3.5	System architecture requirements	10

3.6	Migration concept requirements	11

3.7	ISDP concept requirements	12

Abbreviations and glossary	13

Contents	14

Figures	15

Tables	15

Figures

Fig. 1 –	Function tree	2

Fig. 2 –	Use case package diagram	3

Fig. 3 –	Use case diagram	3

Tables

Table 1:	Change control	1

Table 2:	Rough requirements	2

Table 3:	Technique 1 form	5

Table 4:	Technique 2 form	6

Table 5:	Technique 3 form	7

Table 6:	Quality requirements	8

Table 7:	Operating concept requirements	9

Table 8:	System architecture requirements	10

Table 9:	Migration concept requirements	11

Table 10:	ISDP concept requirements	12

Table 11:	Abbreviations and glossary	13