Requirements. Module-3

1.

Requirements
Module 3.
Characteristics of good
requirements

2.

Levels and types of requirements
Business Requirements
User Requirements
Functional Requirements

3.

AGENDA
Characteristics of Good Requirements
Examples of good and bad Requirements
Requirements analysis

4.

HOW DO I KNOW
WHETHER
THE REQUIREMENT
IS QUALITATIVE?

5.

Characteristics of Good Requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
5
Traceable

6.

Characteristics of Good Requirements
Independent
Correct
Clear
Feasible
Atomic
6

7.

Necessary
A Necessary requirement
Is one that can be traced back to the business problem or business
need that initiate it
Is one that must be present to meet system objectives
Leads to a deficiency in the system if it is removed
7

8.

Necessary
UNNECESSARY REQUIREMENT
GOOD REQIURMENT
REQ1: All requirements specified in the
Vision document should be implemented
and tested.
REQ1: All requirements specified in the
Vision document should meet the health
care standard ICS 11.020.
8

9.

Complete
A Complete requirement
Contains all the information that is needed to define the system
function
Leaves no one guessing (For how long?, 50 % of what?)
Includes measurement units (inches or centimeters?)
9

10.

Complete
UNCOMPLETE REQUIREMENT
REQ2: On loss of power, the battery
backup must support normal operations.
What operations? For how long?
GOOD REQIURMENT
REQ2: On loss of power, the battery
backup must support system under
100% load for 20 minutes.
10

11.

Consistent
A Consistent requirement
Does not conflict with other requirements in the requirement
specification
Uses the same terminology throughout the requirement specification
Does not duplicate other requirements or pieces of other requirements or
create redundancy in any way
11

12.

Consistent
REQUIREMENTS CONFLICT
GOOD REQIURMENTS
REQ3: Date should be displayed in the
mm/dd/yyyy format.
REQ32: Date should be displayed in the
dd/mm/yyyy format.
REQ3: Date should be displayed based
on the format defined in the user’s web
browser.
REQ4: Payment by PayPal should be
available.
REQ34: Only credit card payments
should be accepted
REQ34: Only credit card payments shall
be accepted
(REQ4 was deleted)
12

13.

Unambiguous
An Unambiguous requirement
• Must be easily read and understood by non technical people,
• Must be interpreted in one way
• Must consist of a single requirement, no more than 30-50 words in length
Should not contain words: may, usually, sometimes, under normal
circumstances, often, few, many, most, several, any, some, somebody…
13

14.

Unambiguous
UNAMBIGUOUS REQUIRMENTS
REQ5. All screens should appear on
monitor quickly
GOOD REQIURMENTS
REQ5. When the user accesses any screen, it
must appear on the monitor within 2 seconds.
How quickly?
REQ6. The system should not accept
passwords longer than 15 characters.
REQ6. The system should not accept
passwords longer than 15 characters. If the
user enters more than 15 characters in the
‘Password’ field, an error message should
appear on the right of this field: “Password
must be less than 15 characters”
14

15.

Verifiable
A Verifiable requirement
• Is stated in such a way that it can be tested by inspection, analysis, or
demonstration
• Makes it possible to evaluate whether the system met the requirement
Makes it possible to define a clear, unambiguous pass or fail criterion
15

16.

Verifiable
UNVERIFIABLE REQUIRMENTS
REQ7: The system must be user friendly.
GOOD REQIURMENTS
How should we measure user
friendliness?
REQ7: The user interface should be menu
driven. It should provide dialog boxes, help
screens, radio buttons, dropdown list boxes, and
spin buttons for user inputs.
REQ8: User should have ability to filter
information about reservations based on
Last Name, Date, etc.
REQ8: User should have ability to filter
information about reservations based on Last
Name, Date, Address.
16

17.

Traceable
A Traceable requirement
• is linked to its source: a higher-level system requirement, a use
case, or a voice-of-the-customer statement
• is linked to design elements, source code, and test cases that are
constructed to implement and verify the requirement
• is uniquely labeled and is written in a structured, fine-grained way
17

18.

Traceable
UNTRACEABLE REQUIREMENT
GOOD REQIUREMENT
REQ10: Page list should contain 3 products
per line regularly according to SRS, section
1.
REQ12: Page list should contain 3 products per
line during the period 11.01-24.11 and 4
products per line from clearance during 25.1110.01 according to SRS, sections 1 & 2.
REQ11: Page list should contain 4 products
from clearance per line during the big
holidays according to SRS, section 2.
18

19.

Requirement Analysis
Requirements analysis
is a systematic project activity targeted at:
▪ determining whether the stated requirements possess
qualities of a good requirement
▪ resolving any apparent conflicts

20.

Requirement Analysis in SCRUM
20

21.

Requirement Analysis
REVIEW OF REQUIREMENTS
Test Requirements to be sure that they are qualitative.
If no, contribute to requirements clarification process
DOCUMENT FINDINGS OF REVIEW
Letter to PO with:
Clarifications
Improvements
RESOLVE CONFLICTS IN REQUIREMENTS
Meetings with Stakeholders
UPDATE REQUIREMENTS

22.

Requirement Analysis: OMS APPLICATION

23.

Requirement Analysis: OMS APPLICATION
To:
[email protected] Product owner
Subject: Clarification. OMS:LvQCQC-25. As a Supervisor I want to create a report with all existing
products
Mr. Product owner!
During requirements analysis on user story LvQCQC-25 for OMS application
incomprehensibility of the next requirement: 'Report creation should be quick and correct'.
I have found
Could you please clarify how much time report creation should take or what performance criteria it should
meets ?
It would also be helpful if you could explain what do you mean by the phrase “Report creation should be
correct"
Thank you in advance!

24.

Requirement Analysis: OMS APPLICATION

25.

Requirement Analysis: OMS APPLICATION