MANUAL TESTER

Requirement Engineering
1

Module
 1. The Basics of
Requirement
Engineering
2

This chapter is based on the IREB syllabus v2.2.1 (2017)

IREB Certi ed Professional for Requirement Engineering
Download page
 1.1 De nition
and classi cation of 3

requirements
De nition and classi cation of requirements
Requirement
1. The condition or ability required by stakeholders to solve a given problem or achieve a certain
goal.
2. Conditions or abilities which have to be met or obtained by the system or an element of the
system for provisions of a contract, standard, speci cation or another formally imposed
document to be met.
3. A documented representation of a condition or abilities de ned in items 1. and 2.
4

A requirement is a certain description of a solution - a collection of characteristics of a solution

that are required by the user, customer, or another stakeholder for the assumed goal to be
achieved. 

The purpose of a requirement should be known and identi ed.

Classi cation of requirements

5
Classi cation of requirements - limitations
Limitations are certain conditions that limit the possibilities of the process of designing, operating
or the solution, or its life-cycle.
Business limitations: Technical limitations:
nancial limitations hardware and software platforms
schedule limitations programming language and technology
resource limitations size of a database
skills and abilities of the project team the use of hardware resources 6

legal constraints, norms maximum number and size of les

legislation
Classi cation of requirements - limitations
Limitations in uence the way in which a solution is being developed. They can be related to:

• production cost - how much the client is able to pay for the development of the solution.
• organization of the development process – what approach should be assumed (the client may
require a certain methodology, technology or tools to be employed).
• documentation – what scope and sort of documentation is necessary for the client's requirements
to be ful lled? Is complete documentation required or are basic artefacts su cient?
7

Examples - limitations
• The software is to be developed in Java.
• The project is to be carried out according to Prince 2 principles.
Classi cation of requirements - Product requirements
Product requirements are the characteristics of product quality.

• Functional requirements de ne what the system does.

• Non-functional requirements describe how the system works.

Example - product requirements

• The system should check whether the operator of the bank has access to a speci c report. 8

• The system should authorize the user before granting access to the application.
Classi cation of product requirements - examples
Functional product requirements
• The system must allow the user to nd a client with the use of an ID.
• The system is to generate trend analysis reports based on data obtained from transactions.

Non-functional product requirements

• The system must allow carrying out 10.000 transactions per day.
• The client must have access to their account 24/7. 9
Types of requirements
Requirements can also be quali ed to re ect the levels of abstraction which they represent in the
process of solution development.

Basic types of requirements include:

• business requirements - high-level requirements set by representatives of the business and
regarding a business problem (e.g. "there is a need to automate the process of reporting").
• solution/system requirements – those which describe features of the solution necessary for
meeting business requirements (e.g. "data required for the reports to be compiled must be 10

downloaded from the CRM module").

• product/component requirements – detailed description of system requirements (e.g. "the
system generates a report including the following information: ... in the following format ...").
1.2 Requirement 11

attributes
Requirement attributes
Main attributes:
obligation - is the degree of obligation for the requirement to be ful lled.
priority - de nes the importance/urgency of the requirement towards the business.
criticality - de nes the risk/damage in case the requirement is not ful lled.

12
Requirement attributes
Attributes which should be de ned:
identi er - each requirement should be clearly identi ed.
feasibility - de nition of whether the requirement can be ful lled considering current
infrastructure, budget and time constraints, as well as available resources.
risk - risks relate to potential nancial damages, business features which potentially will not be
accepted may lead to loss of stakeholder trust.
source - indicates where the requirement originated.
13
type - helps to classify requirement.
Requirement attributes - SOLUTION

"must", "should", "could", "won't"

MoSCoW
M - Must have
S - Should have 14

C - Could have
W - Won't have this time but will have in the future
Requirement attributes
Example of a template of a requirement description usually used in sequential methods of software
development.

15
Problems related to requirements
The following are the most common problems related to requirements:
Unclear purpose of the project – we do not know the business value which the project is to
deliver and we do not know the role of the solution to be implemented.
Communication issues – the client is not able to precisely state their needs and true goals.
Language issues – even if international project teams use the same language, there may be
some issues with understanding resulting from such things as accents and using regional terms.
Knowledge barriers – these may result from the lack of understanding of the complexity of the
development process and the role of the client in that process. The service provider might not 16

have su cient business knowledge regarding the business domain of the client's organization.
Unclear requirements – requirements must be clear and concise. The rule of thumb here is "the
less the better". Use precisely selected words and simple phrases.
Problems related to requirements - cont.
Changing requirements – if at the initial stages of the project not all crucial requirements,
limitations and assumptions have been stated, there is a high probability that requirements will
change at further stages.
Low quality of requirements – quality of requirements directly in uences the quality of the
product.
Insu cient engagement of stakeholders – lack of engagement of stakeholders in the
engineering process may lead to creating a solution which will not ful ll the needs of the
business. Insu cient cooperation may cause some requirements to be missed during the
17
analysis phase.
Omitted classes of stakeholders – in case not all key participants of the project or their points
of view have been de ned, there is a risk that the project will not fully provide for carrying out
business processes.
Problems related to requirements - cont.
Planning errors – in some cases the high-level requirements de ned by the client in the software
product development contract are improperly analyzed and estimated by the service provider.
This may lead to a situation where the time planned for further project activities, including
requirement analysis, is insu cient.
Insu cient speci cation of requirements/solution – in some cases organizations which
develop products, especially software, do not prepare su cient product speci cation as they
focus on implementation. In other cases, speci cations include very general information, which
may lead to creating a product that will not meet the client's expectations.
18
2. Requirement 19

engineering
 2.1 Identifying
requirements - (V- 20

model)
Identifying requirements
The process of identifying requirements begins with de ning the needs of the client and assessing
the vision of goals of the project.

The main purposes of requirement identi cation include:

• de ning all required features, characteristics, limitations and expectations towards the planned
solution;
• orientation of requirements against the vision of the project;
•
21
detailing high-level requirements with the purpose of de ning the necessary features and
services;
• excluding the characteristics which the stakeholders obviously do not need.
Identifying requirements
Identi cation of requirements most frequently takes place with the use of:
• questionnaires,
• interviews,
• self-registration,
• the help of a client representative who joins the project team,
• analysis of existing documents,
• reusing existing speci cations, 22

• brainstorming,
• on-site observations,
• internship,
• requirement workshops.
FURPS
FURPS is an acronym representing the model for
classifying functional and non-functional
requirements. This approach may be used as a
great checklist, which allows for considering all
of the most crucial elements of the project.
Functionality
Usability
Functionality
1. What does the system need? – all functional
requirements of the client
2. Administration – management panel
3. Audit – storing and reading records of all
activities performed in the system (logs)
4. Connections - connections and 23

synchronisation, protocols
Reliability
5. Reusability - dependence on a programming
Performance language, framework, environment etc.
Supportability 6. Expandability - ability to add new plugins
7. Licensing - the licensing model for the system
FURPS
Usability Reliability

1. Ergonomics – ease of use 1. Precision – correctness of results (a particular

2. Look and Feel – aesthetics of the system degree of it)
3. Coherence – what elements of the system 2. Availability – time between periods of
should work in the same way downtime
4. Accessibility - possibility to use the system by 3. Recovery – how long it should take for the
users with special needs, e.g. handicapped, system to recover after an error 24

visually impaired 4. Veri ability – reporting the correct operation

5. Localization - language versions of the system of the system
6. Help - help for the users 5. Recovery mechanisms - what types of errors
the system should handle by itself
FURPS
Performance
1. Capacity – what level of tra c the system
should suport
2. Responsiveness – the time the system needs
to respond
3. Scalability - how the system can be scaled
4. Speed – how fast the system works
Supportability
1. Adaptability – how the system can be adapted
to other conditions
2. Auditability – access to logs
3. Compatibility - possibility to work with
previous versions of the system
4. Con gurability - ease and means of 25
con guring the system
5. Deployability - ease and means of installation
6. Repair speed - how quickly the system can be
xed
7. Testability – levels of testing (functional, unit,
integration, etc.)
2.2 Identi cation of
requirements - 26

(SCRUM)
User stories
Scrum and V-model production approach requirements in two completely di erent ways. In the case
of the sequential process of development, requirements are often non-negotiable and very detailed
from the very beginning.

In Scrum, the details of requirements are negotiated in continuous discussions throughout

the production process.

27
User stories

User stories
are a convenient form of expressing the expected business value. User stories are stored in a way
which allows them to be comprehended both by representatives of the business side of the project
and by engineers. They have a simple structure and they are a good basis for further conversation.

28

Source
User story - template
A proper high-level user story (non-detailed) should include:

• Name - concise name of the requirement

• User Story
   As ......[who?] (user)
   I want to ......[what?] (feature of the product or problem which we intend do solve) 29

   to...... [why?] (why does the user need such feature and what value does it bring them).
User story - examples
User registration
   As [who?] an unregistered user
   I want to [what?] register within the service
   to [why?] have the ability to log in.

Navigation
30
   As a user
   I want to have access to the top menu of the application from every place in the application
   to be able to easily navigate the site.
User stories - examples
Link - Price Drop/strong
   As a user
   I want to display only discounted products (using the "Price Drop" link),
   to be able to quickly nd cheaper stock.

Link - Personal info

31
   As a registered user
   I want to have access to information about my account (through the “Personal info” link)
   to be able to change my details.
Development of user stories

32

Initially user stories refer to broad scopes of business value and are not very detailed. While the
time passes, user stories are discussed numerous times by stakeholders, the product owner and
the development team, and they are broken into collections of smaller, more detailed elements of
product register. In the end, they become small and detailed enough to become part of a sprint,
where the features which they describe will be designed, built and tested.
 2.3 Modelling 33

UML requirements
UML (Uni ed Modeling Language)
The UML language is a language for graphical modelling of di erent applications and systems. It is a
standardized notation for analysis and design of systems. It includes di erent types of diagrams:
Behavior diagrams Structure diagrams
• activity diagram • class diagram
• use case diagram • object diagram
• state diagram • component diagram
• sequence diagram • implementation diagram 34
UML - activity diagram
Activity diagrams are probably the most broadly used among all UML language diagrams. They can
be used to model all types of behaviors: business processes, software processes, work ows. Activity
diagrams are used to depict activities which include smaller actions.

35

Source: https://www.uml-diagrams.org/online-shopping-uml-activity-diagram-example.html?context=activity-examples
UML - activity diagram

36

Source: https://www.uml-diagrams.org/shopping-process-order-uml-activity-diagram-example.html?context=activity-examples
UML - use case diagram
In UML, use cases are used to depict system features. They include named fragments of features
(use cases), persons or things which call those features (actors) and elements responsible for
implementation of use cases (subjects).

37

Source: https://www.lucidchart.com/pages/uml-use-case-diagram
UML - class diagram
When developing software, programmers must constantly make decisions: what classes store
references to other classes, which class "holds" another class, etc. Diagrams of classes allow them to
present a physical structure of the system.

38
Exercise

Prepare at least 10 requirements which will describe a Visuality Student Book app. The
requirements are to represent your vision of what a Visuality Student Book app should look like.
Use the user story method. Remember to also assign proper obligation level to your requirements
using the MoSCoW method.
39

Duration of the exercise: 30-45 minutes