Requirements. Module-3 презентация

Levels and types of requirements
Business Requirements
User Requirements
Functional Requirements

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

HOW DO I KNOW
WHETHER
THE REQUIREMENT
IS QUALITATIVE?

Necessary Complete Consistent Unambiguous Verifiable Traceable
Characteristics of Good Requirements

Characteristics of Good Requirements
Clear
Correct
Feasible
Independent
Atomic

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
Necessary

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.

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?)
Complete

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

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
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)
Consistent

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…
Unambiguous

UNAMBIGUOUS REQUIRMENTS
GOOD REQIURMENTS
REQ5. All screens should appear on monitor quickly
How quickly?
REQ5. When the user accesses any screen, it must appear on the monitor within 2 seconds.
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”
Unambiguous

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
Verifiable

UNVERIFIABLE REQUIRMENTS
GOOD REQIURMENTS
REQ7: The system must be user friendly.
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.
Verifiable

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
Traceable

Traceable
UNTRACEABLE REQUIREMENT
GOOD REQIUREMENT
REQ10: Page list should contain 3 products per line regularly according to SRS, section 1.
REQ11: Page list should contain 4 products from clearance per line during the big holidays according to SRS, section 2.
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.11- 10.01 according to SRS, sections 1 & 2.

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

Requirement Analysis in SCRUM

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

Requirement Analysis: OMS APPLICATION

To: [e-mail] 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 I have found incomprehensibility of the next requirement: 'Report creation should be quick and correct'.
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!
Requirement Analysis: OMS APPLICATION

Requirement Analysis: OMS APPLICATION