5.40M

Category:

education

Requirement Analysis

SoftServe Confidential
Agenda
• Requirements Definitions and Classification
• Characteristics of Good Requirements
• Types of documents through which requirements can be
communicated
• Requirements Analysis
• Traceability matrix
• Dependency Matrix

3.

Definition and Classifications

4.

SoftServe Confidential
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 errors and the most costly to fix

5.

SoftServe Confidential
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

6.

SoftServe Confidential
Requirements Levels and Types
Functional:
Business requirements
User requirements
Functional requirements
Nonfunctional:
Physical environment
Performance
Documentation
Quality attributes

7.

SoftServe Confidential
Requirements Levels and Types

8.

SoftServe Confidential
Requirements Levels and Types
Word processing application:
Business requirement:
"The product will allow users to correct
spelling errors in a document
efficiently."
User?
Functional?
Quality attribute?

9.

SoftServe Confidential
Explicit and Implicit requirements
Hidden or
‘assumed’ and not
stated explicitly
Implicit
Explicit
Clearly defined
and documented

10.

Characteristics
of Good requirements

11.

SoftServe Confidential
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
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?

12.

SoftServe Confidential
Characteristics of Good requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
Traceable
* 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?
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 ?

13.

SoftServe Confidential
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?
Bad Example
Good 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.
REQ4: The electronic batch records
shall be 21 CFR Part 11 compliant.
Do these refer to the same
regulation or different ones?
REQ47: An on-going training
program for 21 CFR Part 11 needs
to be established at the site.

14.

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

15.

SoftServe Confidential
Characteristics of Good requirements
Necessary
Complete
Can you determine whether the system
satisfies the requirement? Is it possible to
define a clear, unambiguous pass or fail
criterion?
Consistent
Unambiguous
Verifiable
Traceable
Bad Example
Good Example
REQ7: The system must be user
friendly.
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.
How should we measure user
friendliness?

16.

SoftServe Confidential
Characteristics of Good requirements
Necessary
Complete
Consistent
Unambiguous
Verifiable
Traceable
Is the requirement uniquely identified so
that it can be referenced
unambiguously?

17.

Types of documents through
which requirements can be
communicated

18.

SoftServe Confidential
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

19.

SoftServe Confidential
User Stories
User Stories - are short, simple descriptions 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>

20.

SoftServe Confidential
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.

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

22.

SoftServe Confidential
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

23.

Requirements Analysis

24.

SoftServe Confidential
QC and Requirements Analysis
The goal of testing is to ensure that software works according to mutually agreed
requirements
To do that QC engineer need to perform the following:
1. Test Requirements to be sure that they are qualitative. If no, contribute to
requirements clarification process
2. Design tests cases to fully cover requirement with tests
3. Execute tests
4. Report defects (if any)

25.

SoftServe Confidential
Requirements Analysis
The requirements analysis is a systematic project activity targeted at:
• determining whether the stated requirements possess qualities of a good
requirement
• resolving any apparent conflicts
Requirements analysis includes:
thorough reviews of requirements
documenting findings of review
meetings with stakeholders to resolve conflicts in requirements
update requirements

26.

SoftServe Confidential
Goodness Checklist: Is this
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 criterion 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.

27.

Traceability Matrix

28.

SoftServe Confidential
What is a Traceability Matrix?
• A traceability matrix is a document that corelates any two-baseline documents that
require a many-to-many relationship to check
the completeness of the relationship.
• Very often it is used to track the requirements
and to check the current project requirements
are met.

29.

SoftServe Confidential
How to create a Traceability Matrix?
1. Open Excel to create Traceability Matrix.
2. Define following columns:
1. Use case ID / requirement ID.
2. Use case / requirement description.
3. One column for each test case.
3. Identify all the testable requirements in granular level from requirement document.
Typical requirements you need to capture are as follows:
1. Used cases (all the flows are captured)
2. Error Messages
3. Business rules
4. Functional rules
5. Software requirement specifications
6. Functional requirement specifications
4. Identity all the test scenarios and test flows.
5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is one flow
or scenario. SR-1.1 and SR-1.2 are covered.
6. Now from above table you can easily identify which test cases cover which requirements and
which test cases need to be updated if there are any change requests.

30.

SoftServe Confidential
How to create a Traceability Matrix?
Requirement ID
Requirement Descriptions
TC 001
SR-1.1
User should be able to do this.
x
SR-1.2
User should be able to do that.
x
SR-1.3
On clicking this, the following
message should appear.
x
x
x
SR-1.6
SR-1.7
TC 003
x
SR-1.4
SR-1.5
TC 002
x
x

31.

SoftServe Confidential
What is a Requirement Traceability Matrix?
Requirement Traceability Matrix (RTM) captures all requirements
proposed by the client or development team and their traceability in
a single document delivered at the conclusion of the life-cycle.
In other words, 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.

32.

SoftServe Confidential
Requirements Traceability Matrix

33.

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

34.

Dependency Matrix

35.

SoftServe Confidential
A cycle
• a path which comes back to its origin;
• between 2 or more elements

36.

SoftServe Confidential
How to determine dependencies in cycle?
You said Graph?
Noooo!

37.

SoftServe Confidential
No!
Dependency it’s a relationship between conditions,
events, or tasks such that one cannot begin or becompleted 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.