0% found this document useful (0 votes)
44 views33 pages

S5 - Working With System Requirements

The document discusses two types of system requirements - functional and non-functional. It focuses on non-functional requirements, explaining some examples like performance, load, data volume, concurrent users, and SLA. It emphasizes the importance of defining non-functional requirements in numbers and working with clients to set realistic expectations.

Uploaded by

Hussein Said
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
44 views33 pages

S5 - Working With System Requirements

The document discusses two types of system requirements - functional and non-functional. It focuses on non-functional requirements, explaining some examples like performance, load, data volume, concurrent users, and SLA. It emphasizes the importance of defining non-functional requirements in numbers and working with clients to set realistic expectations.

Uploaded by

Hussein Said
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 33

Understanding

System
Requirements

Memi Lavi
www.memilavi.com
Two Types of Requirements

• “What the System Should Do”

• Business Flows

• Business Services

• User Interfaces
The Other Kind…

• “What Should the System Deal With”


Non-Functional
• Performance Requirements
• Load
• Data Volume
• Concurrent Users
• SLA
Remember!
• Non-Functional

Requirements are

Important

• BUT - Do Not Ignore

Functional Requirements!

• Part of the Business


Non-Functional Requirements

• “What the System Should Deal With”


• Performance
• Load
• Data Volume
• Concurrent Users
• SLA
https://en.wikipedia.org/wiki/Non-functional_requirement
Performance

What is the required performance for this system?

Fast
Performance

• Always talk in numbers

• Latency & Throughput


Performance

• Always talk in numbers

Talk To Your Client!


1 sec > 100 ms
>
Icon made by freepik.com
Latency
How much time does it

" take to perform a single

task?
Examples:
- How much time will it take for the API to save the user data in the database?

- How much time will it take to read a single file from the file system?
Throughput

" How many tasks can be

performed in a given time unit?

Examples:
- How many users can be saved in the database in a minute?

- How many files can be read in a second?


Let’s Crunch Numbers…

Saving User Data


Latency 1 Second
Let’s Crunch Numbers…

Saving User Data


Latency 1 Second
Throughput ?
Let’s Crunch Numbers…

Saving User Data


Latency 1 Second
Throughput Well designed
app: >1000
Let’s Crunch Numbers…

Saving User Data


Latency 1 Second
Throughput Well designed
app: >1000
Badly designed
app: < 60
Load

• Quantity of Work Without Crashing

• Example: In WebAPI – How Many Concurrent Requests

Without Crashing
Load vs Throughput

Throughput
Load
Load vs Throughput

Throughput 100 requests / sec


Load
Load vs Throughput

Throughput 100 requests / sec


Load 500 requests without crashing

Always plan for extreme cases!


Data Volume

• How Much Data the System Will Accumulate Over Time

• Helps With:

• Deciding on Database Type

• Designing Queries

• Storage Planning
Data Volume

• Two Aspects:

• Data Required on “Day One”

• Data Growth
Data Volume

• Example:

Day One 500 MB


Annual Growth 2 TB
Concurrent Users

• How Many Users Will Be Using the System

Simultaneously
Concurrent Users vs Load

Concurrent Users Including “Dead Times”


Load
Concurrent Users vs Load

Concurrent Users Including “Dead Times”


Load Actual Requests

Rule of Thumb:

Concurrent = Load X 10
SLA (Service Level Agreement)

• Required Uptime for the System

Source: https://azure.microsoft.com/en-us/support/legal/sla/cosmos-db/v1_1/
SLA (Service Level Agreement)

• 99.99% Equals To:

24 X 365 = 8760 hrs / year

8760 X 99.99% = 8759.12

8760 – 8759.12 = 0.88 hrs downtime / year


SLA (Service Level Agreement)

• Manage Client’s Expectations

• 99.999% Uptime Is Not a Realistic Goal…


Non-Functional Requirements

Never
start working before setting them!
Who Defines
Non-Functional Client? System
Requirements? Analyst?
Defining Non-Functional Requirements

What is the SLA for the system?

Always!
Defining Non-Functional Requirements

What is the required response time for the API?

10 ms!
Defining Non-Functional Requirements

• Architect’s Roles:

• Framing the requirements’ boundaries

• Discuss numbers
Non-Functional Requirements
Conclusion
• Define what the system will have to deal with

• Performance, SLA, Load, etc.

• Client won’t be able to define them

• Never begin working on a system without Non-

Functional Requirements in place

You might also like