Requirements

1.

Requirements

2.

Definition
Requirement: A condition or capability needed by a user to solve a problem or achieve an
objective that must be met or possessed by a system or system component to satisfy a contract,
standard, specification, or other formally imposed document.
Requirement is a singular documented physical and functional need that a particular design,
product or process must be able to perform.
Requirements errors are the most common type of systems
development error and the most costly to fix

3.

Why requirements matter
Requirements errors are the most common type of software development errors and
the most costly to fix
85% of projects identify poor requirements specification the #1 source of
software problems
60%-80% of project failures attributed directly to bad requirements. This
represents a $60 billion annual problem involving cancelled or failed projects
(only USA)
50% of product defects originate in the requirements

4.

Requirements Types
Functional:
Business requirements
User requirements
Functional requirements
Nonfunctional:
Physical environment
Performance
Documentation
Quality attributes

5.

Requirements Levels and Types

6.

Levels of requirements
1. Business requirements (Vision and Scope document)
Example:
“We need a tool for selecting commercial data from different sources and converting it to easy-to-read forms.”
2. User requirements (User Stories, Use Case)
Example:
“When the user logs into the system the welcome page should be opened”.
3. Functional and non-functional requirements (Specification):
Example:
“The device should check all valid sources during installation. All invalid sources must be visible but disabled for a
regular user.”

7.

Explicit and Implicit requirements
Hidden or
‘assumed’ and not
stated explicitly
Implicit
Explicit
Clearly defined
and
docum ented

8.

Characteristics of Good requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
Traceable
Can be traced back to the business
problem or business need that initiate it
Bad Example
Good Example
Explicit
REQ1: All
requirements
specified in the Vision
document shall be
implemented and tested.
All requirements
specified in the Vision
document should meet
the health care standard
ICS 11.020.
Does the requirement
present some business
need?

9.

Characteristics of Good requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
* Is the requirement stated as a complete sentence?
* Is the requirement stated entirely in one place and in a
manner that does not force the reader to look at additional
information to understand the requirement?
Explicit
Bad Example
Good Example
REQ3: On loss of power, the
battery backup must
support normal operations.
REQ3: On loss of power, the
battery backup must
support normal operations
for 20 minutes.
For how long ?
Traceable

10.

Characteristics of Good requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
Traceable
* Is the requirement in conflict with other requirements?
* Is the terminology used consistent with other requirement
and glossary terms?
Explicit
Bad Example
REQ4: The electronic batch records
shall be Part 11 compliant.
REQ47: An on-going training
program for 21 CFR Part 11 needs to
be established at the sites.
Do these refer to the same
regulation or different ones?
Good Example
REQ4: The electronic batch records
shall be 21 CFR Part 11 compliant.
REQ47: An on-going training
program for 21 CFR Part 11 needs to
be established at the site.

11.

Characteristics of Good requirements
Necessary
Complete
Consistent
Bad Example
REQ2: All screens should
appear on monitor quickly
Good Example
REQ2: When the user accesses
any screen, it must appear on
the monitor within 2 seconds.
How quickly?
Explicit
Unam biguous
Verifiable
Traceable
Anyone who reads the requirement should arrive at a single
interpretation of it

12.

Characteristics of Good requirements
Necessary
Complete
Consistent
Unam biguous
Verifiable
Traceable
Bad Example
REQ7: The system must be user
friendly.
How shouldExplicit
we measure user
friendliness?
Good Example
REQ7: The user interface shall
be menu driven. It shall
provide dialog boxes, help
screens, radio buttons,
dropdown list boxes, and spin
buttons for user inputs.
Can you determine whether the system satisfies the
requirement? Is it possible to define a clear,
unambiguous pass or fail criterion?

13.

Characteristics of Good requirements
Necessary
Complete
Consistent
Bad Example
Good Example
Maintain student informationmapped to BRD req.ID?
Maintain student informationMapped to BRD req ID 4.1
The requirement
id is not given
Explicit
over here
Unam biguous
Verifiable
Traceable
Every requirement should be traceable on different
levels of requirement across entire project

14.

How do we know who is “children”? – Complete.
Only when school works? – Complete .
What does “present” mean – on a sidewalk, behind a fence? – Unambiguous.
Because of this requirement is not verifiable.
If some of the qualities are missing, there is a problem with the requirement.
And there will be bugs.

15.

Examples
The system shall work with any browser.
The system shall respond quickly to user clicks.
The system shall work with Firefox.
The system shall work with IE.
The system shall respond within 10ms to any user click.

16.

Types of documents through which
requirements can be communicated
Explicit

17.

Software Requirements Specification
SRS – it’s a description of a software system to be developed, laying out
functional and non-functional requirements
Contents of SRS (Section 5 of IEEE 830)
• Introduction
• General description of the software product
• Specific requirements (detailed)
• Additional information such as appendixes and index, if necessary

18.

User Stories
User Stories - are short, simple description of a feature told from the
perspective of the person who desires the new capability, usually a user or
customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.

19.

Examples of user story
As a administrator, I can:
•Add new user to database
•Delete new user from database
•Verify count of registered users
•Verify count of users who have discount

20.

Use Cases
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.
Might be represented in two major forms:
Diagram
Structural textual description

21.

Use Case Diagram
A Use Case Diagram for the interaction
of a client (the actor) and a restaurant (the
system)

22.

Use Case Diagram

23.

Use Cases Structural Text
Use Case’s structure
might be tailored to
projects need

24.

Requirements Analysis
Requirements analysis includes:
thorough reviews of requirements
documenting findings of review
meetings with stakeholders to resolve conflicts
in requirements
update requirements

25.

Goodness Checklist: Is this Requirement…
Free of ambiguous terms?
•Examples: as appropriate, etc., and/or, support, but not limited to, be able to, be capable of
Understandable only in one way?
Free of indefinite pronouns?
•Examples: this, these
Free of unverifiable terms?
•Examples: flexible, user-friendly, robust, light-weight, maximize, adequate, small, portable, easily - other “ly” words and
other “ize” words
Quantifiable?
•Ask “Do we have an exact criteria to objectively measure the system operation?”
Necessary?
•Ask “Why do we need the requirement?”; the answer may lead you to the real requirement.
Free of implementation?
•Requirement should state WHAT is needed, NOT HOW to provide it, i.e., state the problem not the solution.

26.

Traceability Matrix

27.

What is a Requirement Traceability Matrix?
Requirement Traceability Matrix (RTM) it is a document that maps and traces user
requirement with test cases. The main purpose of RTM is to see that all test cases are
covered so that no functionality should miss while testing.
It captures all requirements proposed by the client or development team and their
traceability in a single document.

28.

Traceability Matrix importance
1.
2.
3.
4.
Information structuring
A means to evaluate completeness, consistency, and traceability of the requirements
of a system
Leads to full transparency and leverages test coverage and defects to the
requirements that need to be met
Requirements changes tracking

29.

Dependency Matrix
Dependency it’s a relationship between conditions, events, or tasks such that one cannot
begin or be-completed until one or more other conditions, events, or tasks have occurred,
begun, or completed.
Dependency Structure Matrix (DSM) is a matrix used to represent the project
dependencies. It’s a compact way to represent complex system.

30.

Dependency Matrix
Origin: process optimization
Applied to dependency in software
reengineering
Compact
Support cycle and layer identification

31.

Dependency Matrix importance
1. Information structuring
2. Testing Sequencing
3. Impact Analysis:
• Analyze possible impact before
implementation
• Analyze possible impact before
testing

32.

Which characteristic says that anyone who reads the requirement
should arrive at a single interpretation of it?
A) Complete
C) Unambiguous
B) Necessary
D) Traceable

33.

Diagram for the interaction of the actor and the system is?
A) User Story
C) SRS
B) Dependency matrix
D) Use case

34.

Traceability Matrix is a trace between
A) Module and Module
C) Requirement and Test Case
B) Test Case and Test Case
D) Test Suite and Test Case

35.

36.

Task