1

>

Requirements engineering

Dr. Anıl Koyuncu

> Definition: Requirements Engineering
RE is the process of establishing
• the services that the customer requires from a system
and
• the constraints under which it operates and is developed.

2
> Definition: Requirements Engineering
RE means to
dig up, understand, write down, check, prioritize, select, follow
up on
the functions
and
properties
of (software) products

3
> The Goal of RE

4
> How do we gather requirements?
The requirements engineering process
>

6
> Feasibility study implementation
➢Questions for people in the organization
• What if the system is not implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?
> Requirements elicitation and analysis
➢Sometimes called requirements elicitation or requirements discovery.
➢Involves technical staff working with customers to find out about the
application domain, the services that the system should provide and the
system’s operational constraints.
➢May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions, etc. These are called stakeholders.

8
> Requirements elicitation
➢work with stakeholders to find out
• application domain,
• the services that the system should provide,
• the required system performance,
• hardware constraints,
• other systems,
• etc.

9
> Stakeholders

standardization
Requirements middleware organization
engineers providers
architects

site
marketing administrators
Lawyers Security
officers

tool end users

component
component application vendors
developers
testers testers
10
> Problems of requirements elicitation

11
>
> Problems of requirements elicitation
➢It typically involves many stakeholders.
➢Stakeholders don’t know what they really want.
➢Stakeholders express requirements in their own terms.
➢Different stakeholders may have conflicting requirements.
➢Organisational and political factors may influence the system requirements.
➢The requirements change during the analysis process.
➢New stakeholders may emerge and the business environment may change.

13
> The requirements elicitation and analysis process

14
> Requirements discovery
➢The process of gathering information about the required and
existing systems and distilling the user and system requirements
from this information.

15
> Elicitation Techniques
1. Analyzing existing documents & data
2. “Brainstorming ”possible requirements
• within the dev. Team
3. Interviews(one-on-one)
4. Focus groups or workshops(one-on-many)
5. Prototyping/mockups
6. Meetings with the customer/users
• e.g. for checkpoints, or showing prototypes

16
> Requirements specification
➢The process of writing down the user and system requirements in
a requirements document.
➢User requirements have to be understandable by end-users and
customers who do not have a technical background.
➢System requirements are more detailed requirements and may
include more technical information.
➢The requirements may be part of a contract for the system
development
• It is therefore important that these are as complete as possible.

17
> Ways of writing a system requirements specification
➢Natural language (plus supporting tables and graphs)
➢Structured natural language / Scenarios
• e.g., use case descriptions, user stories, ...
➢Semi-formal notations
• e.g., UML diagrams (use case diagrams, class diagrams, state diagram,
sequence charts, etc.)
➢Formal notations (with formal semantics)

18
> Use Cases
➢A use case is a description of how a user will use the system-to-be
to achieve business goals
• Detailed use cases are usually written as usage scenarios or scripts,
listing a specific sequence of actions and interactions between the actors
and the system

19
> What is a use case?
➢A use case captures some visible function of the system.
• A use case is a goal that an actor can accomplish using a system,
through a series of user interactions.
• Transfer funds.
• Query balance.
• This may be a large or small function.
• Depends on the chosen level of detail.
• Withdraw Funds vs Validate PIN

- 20 -
> Use Cases
● Accompanied by a use case description detailing the user
interactions required to accomplish the use case.
● Acquired through interviews with stakeholders and viewpoint
analysis.
● Useful for eliciting and refining requirements.

- 21 -
> Use case
Terminology
➢Actor: someone (or another system) interacting with the system
➢Primary actor: person who initiates the action
➢Goal: desired outcome of the primary actor

➢Use cases capture functional requirements of a system!

- 22 -
> What is an Actor?
➢An actor is a role a user plays with respect to
the system.
● Actors carry out use cases. An actor can perform
many use cases. A use case can involve multiple
actors.
● A single user can be multiple actors, depending on
how they use a system.
● Actors do not need to be human - can be an external
system (hardware or software) that interacts with the
system being built.
● Actor is a logical entity, so receiver and sender actors
are different (even if the same person)

- 23 -
> Primary Actor
➢Primary actor: The main actor who initiates a
UC
➢ UC is to satisfy his goals
➢ The actual execution may be done by a system or
another person on behalf of the Primary actor

- 24 -
> Scenarios

➢Scenario: a set of actions performed to achieve a goal

under some conditions
• Actions specified as a sequence of steps
• A step is a logically complete action performed either by the actor or the
system
➢Main success scenario – when things go normally and
the goal is achieved
➢Alternate scenarios: When things go wrong and goals
cannot be achieved

- 25 -
> Use cases
A use case describes the possible sequences of interactions among the system
and one or more actors in response to some initial stimulus by one of the actors
– Each way of using the system is called a use case
– A use case is not a single scenario but rather a description of
a set of scenarios
– For example: Creating an account
– Individual use cases are shown as named ovals in use case diagrams

Creating an
account

- 26 -
> Use cases
➢A use case involves a sequence of interactions between the
initiator and the system, possibly involving other actors.
➢In a use case, the system is considered as a black-box. We are
only interested in externally visible behavior

- 27 -
> Use cases
➢To define a use case, group all transactions that are similar in nature
➢A typical use case might include a main case, with alternatives taken in
various combinations and including all possible exceptions that can
arise in handling them
– Use case for a bank: Performing a Transaction at the Counter
• Subcases could include Making Deposits, Making Withdrawals, etc.,
together with exceptions such as Overdrawn or Account Closed
– Apply for a Loan could be a separate use case since it is likely to involve very
different interactions
➢Description of a use case should include events exchanged between
objects and the operations performed by the system that are visible to
actors

- 28 -
> Library System

29
> 4 steps for creating a use case
1. Identify actors and goals
● Actors: What users and (sub)systems interact with our system?
● Goals: What does each actor need our system to do?

- 30 -
>
➢Borrower: The library user who takes books and other materials
on loan.
➢Attendant: The staff member who assists borrowers with
checking out, returning, and finding resources.
➢Librarian: The professional responsible for managing the library’s
collection, providing research support, and overseeing library
services.
➢Supplier: The entity that provides materials to the library, ensuring
a steady flow of books, journals, and other resources.

31
> Actors diagram (level 0)

32
> 4 steps for creating a use case
1. Identify actors and goals
2. Write the main success scenario
● Highest abstraction level where each top - level business process
is transformed into a use case
● Capture each actor's intent and responsibility, from trigger to goal

- 33 -
> Use Case diagram (level 1) – Summary Use Case

34
> 4 steps for creating a use case
1. Identify actors and goals
2. Write the main success scenario
3. List the details/variations/exceptions
● Refine and decompose uses in Level -1

- 35 -
> Use Case diagram (level 2)

36
> 4 steps for creating a use case
1. Identify actors and goals
2. Write the main success scenario
3. List the details/variations/failure
4. Refine more

- 37 -
> Use Case diagram (level 3)

38
> Complete Use case

39
> Defining use cases
1. Identify the boundary of the application, identify the objects outside
the boundary that interact with the system
2. Classify the objects by the roles they play, each role defines an actor
3. Each fundamentally different way an actor uses the system is a use
case
4. Make up some specific scenarios for each use case (plug in
parameters if necessary)
5. Determine the interaction sequences: identify the event that initiates
the use case, determine if there are preconditions that must be true
before the use case can begin, determine the conclusion
6. Write a prose description (main flow) of the use case
7. Consider all the exceptions that can occur and how they affect the
use case

- 40 -
>

41
> Defining System and Context Boundaries

- 42 -
> Purpose of the System Context
➢Which questions answers thought about the system context?

- 43 -
> System Context

- 44 -
> Considering Boundaries

- 45 -
> Context models
➢Context models are used to illustrate the operational context of a
system - they show what lies outside the system boundaries.
➢Social and organisational concerns may affect the decision on
where to position system boundaries.
➢Architectural models show the system and its relationship with
other systems.

46
> System boundaries
➢System boundaries are established to define what is inside and
what is outside the system.
• They show other systems that are used or depend on the system being
developed.
➢The position of the system boundary has a profound effect on the
system requirements.
➢Defining a system boundary is a political judgment
• There may be pressures to develop system boundaries that increase /
decrease the influence or workload of different parts of an organization.

47
> Context Boundary

- 48 -
> The context of the Health Care Patient Management
System

49
> Setting the System Boundary
➢The system boundary will affect your actors and use-cases.

- 50 -
> System Boundary - Weather Forecast
➢The system boundary will affect your actors and use-cases.

Option 1: Software Boundary

● System is just the software. Users, Sensors,
and Database are all actors.
● Four use-cases: Get Temperature, Get
Humidity, Get Statistics, Update Update Records
Records.

- 51 -
> System Boundary - Weather Forecast
➢The system boundary will affect your actors and use-cases.

Option 2: Computer Boundary

● System is the computer unit. Database is no
longer an external actor.
● Still four use-cases: Get Temperature, Get
Humidity, Get Statistics, Update Records.

- 52 -
> System Boundary - Weather Forecast
➢The system boundary will affect your actors and use-cases.

Option 3: Computer+Sensors Boundary

- 53 -
> Use cases
➢Use-cases are a kind of scenario that are included in the UML.
➢Use cases identify the actors in an interaction and which describe
the interaction itself.
➢A set of use cases should describe all possible interactions with
the system.
➢High-level graphical model supplemented by more detailed tabular
description.
➢UML sequence diagrams may be used to add detail to use-cases
by showing the sequence of event processing in the system.

65
> Use Case Diagrams and Descriptions

66
> Step 3: Documenting the Use Case Typical Course
Step 3: Documenting the Use Case Typical
> Course (concluded)
> Example project: smart fridge
Scenario
● Dinner/party time.
● On the way home.
● Inviting a lot of friends.
● Is the fridge stocked?

- 70 -
> DIY smart fridge requirements
Solution
● DIY smart fridge.
● Realtime data.
● Mobile app.

- 71 -
Example: Home Access Control
>

72
>

73