1. Requirements Analysis

2. 2
Requirement
Requirement – specified functional or physical need that a
particular software must perform.
Software
Requirements
Client ‘s
Idea
Client’s
Business Needs
Requirements origin

3. 3
Types of requirements
Functional requirements explain what should be done.
 identify tasks or activities that must be met
 define the steps that the system must be capable of
performing, communications input/output behavior of the
system.
Example
 Req01: there should be a possibility to associate the .pdf,
.docx, .xlsx files up to 35 KB in size with an exam record.
There should be not more than 5 files associated with 1
exam record.

4. 4
Types of requirements
Non-functional requirements define the criteria of the system as a
whole rather than individual behavior scenarios.
 Physical environment (equipment, multiple sites, etc.)
 User & human factors (who are the users, their skill level etc.)
 Performance (how effectively is software functioning)
 Documentation (what kind of documentation need to be created
for end users)
 Security (backup, firewall)
 Others (UI and technical design, architectural constrains, etc )
Example
 Req02: with 100 concurrent users file upload time should be less
than 1 sec for any of the .pdf, .docx, .xlsx files up to 35 KB in size.

5. 5
Usually software requirements are presented to the
project team in the following views:
SRS (Software Requirements Specification)
a document that lists all requirements to a
software, grouped by type into logical sections
Product Backlog
a list of requirements (called User Stories) that is
maintained for a product developed using the Agile
SDLC (Scrum) methodology
Requirements view

6. 6
Software Requirements Specification
Software Requirements
Specification consists
of following sections:
Introduction
Overall description
Specific requirements
Supporting information

7. 7
Product Backlog
The entry of a Product Backlog is a User
Story.
Format:
Example:
A User Story is one or more sentences stated
in the everyday language of the end user that
captures what a user does or needs to do as
part of his or her job function.

8. 8
Use Case
To describe complex functional requirements
(often grouped into scenarios of software
usage), Use Cases are used instead of plain
text.
Use Cases might be represented in two major
forms:
Diagram
Structural textual description
A Use Case is a list of steps, typically defining
interactions between a role (known in UML as an
"actor") and a system, to achieve a goal. The actor
can be a human or an external system.

9. 9
Use Case Diagram

10. 10
Use Case as Structural Text
 Use Case’s structure
 Title: "goal the use case is trying to satisfy"
 Main Success Scenario: numbered list of steps
Step: "a simple statement of the interaction between
the actor and a system
 Extensions: separately numbered lists, one per Extension
Extension: "a condition that results in different
interactions from .. the main success scenario". An
extension from main step 3 is numbered 3a, etc.
 Use Case’s structure might be tailored to projects need

11. 11
Good requirement
 A requirement is considered as Good One if it possesses
following qualities:
 Necessary
 Complete
 Verifiable
 Unambiguous
 Consistent
 Example:
 Req03: when a user accesses any screen, it must appear
on the monitor within 1 second.

12. 12
Thank You!