RM Benefits

Presented at a SA staff meeting at NCEN
by Liz Lavaveshkul
Source: TeleLogic

What is requirements management?
“The purpose of requirements
management is to establish a
common understanding between
the customer and the … project …
This agreement with the customer
is the basis for planning and
managing the … project.”
The Capability Maturity Model for Software (CMM) from the
Software Engineering Institute at Carnegie Mellon University.
www.sei.cmu.edu/cmm

Why is RM so important?
Approximately 60 – 70% of projects failures
result from poor requirements gathering,
analysis, and management.
-- Mela Group, March 2003

Why bother with Requirements?
• To show what results the users want
• To communicate and focus team members
on clear goals
• To tell decision-makers what is required
vs. desired
• To allow the design to be optimized

Why bother with Requirements?
• To supply confidence in the system
THOUGHOUT its development
• To check that the system and all its parts
do what is wanted
• To prevent over design or omitted needs
• To control development and outsourcing

Why do you need requirements
management?
• The status of the project is never clear until we find
we’ve missed project milestones
• We have very little formal development process
• The objectives always seem to change at the worst
times
• Change is very costly and time consuming for us
• We have difficulty communicating intent between
departments
• We end up over-engineering our solutions, which is
costly
Do any of the following statements seem familiar?

Why do you need requirements
management?
• We have trouble testing against original intent and stated
need
• We are never sure whether our tests are full and
complete
• Our test cycles are often too long and costly
• Our customers often include design in the requirements
• We have difficulty organizing requirements into smaller
manageable sets

Who should use a RM tool?
• Systems Engineers
demand functionality
• Highly advanced requirements
management and analysis
• Distributed users
demand collaboration
• Analyst/Architect
demand a common
language
• Reviewers demand
instant access from
any location
• Interested in central set of
requirements accessed
globally
• Need for multi-disciplines to
communicate more efficiently
• Not so advanced, mainly
interested in review
functionality

The Benefits of Requirements
Management
• Satisfaction
• Integration
• Testability
• Communication
• Visibility
• Change control
• Quality
• Optimization
• Compliance

Management
• Satisfaction: real business needs met
• Integration
• Testability
• Communication
• Visibility
• Change control
• Quality
• Optimization
• Compliance

Management
• Integration: the pieces work together
• Testability
• Communication
• Visibility
• Change control
• Quality
• Optimization
• Compliance

Management
• Testability: know what to test the delivery against
• Communication
• Visibility
• Change control
• Quality
• Optimization
• Compliance

Management
• Communication: consistent ideas of what the
solution is for
• Visibility
• Change control
• Quality
• Optimization
• Compliance

Management
• Communication: consistent ideas of what the solution is for
• Visibility: managers can take a global
view
• Change control
• Quality
• Optimization
• Compliance

Management
• Visibility: managers can take a global view
• Change control: the impact of change
can be assessed
• Quality
• Optimization
• Compliance

Management
• Change control: the impact of change can be assessed
• Quality: we know what quality means for
the business
• Optimization
• Compliance

Management
• Quality: we know what quality means for the business
• Optimization: we deliver only what is wanted
• Compliance: demonstrate compliance with regulatory authorities and SOX

Management
• Quality: we know what quality means for the business
• Optimization: we deliver only what is wanted
• Compliance: demonstrate compliance with
regulatory authorities and SOX

Types of Requirements
• User Requirements – define
the results the users expect
from the system
• System Requirements –
define what the system must
do to satisfy the users
• Design Requirements –
define all of the components
necessary to achieve the
system requirements
“The homeowner shall hear an
alarm when smoke is
detected.”
“The alarm will produce a
sound between 125 – 155
dBA.”
“The alarm will be produced by
part # 123-45-678.”

Writing a requirement
• Uses complete sentences
• States subject and predicate
– Subject is a user type or the system under consideration
– Predicate is a condition, action, or intended result
• Consistent use of language
• Specifies:
– Desired goal or result (User requirement)
– Function (System requirement)
– Constraint (either)
• Contains a success criterion or other
measurable indication of the quality

Language
• Use consistent language, for example:
– “Shall,” “will,” or “must” are mandatory
– “Should” is optional, but omission must be justified
– “May” is desirable
• Use consistent terminology
– Define terms – use a Glossary
– Avoid using the same name for different things
– Avoid using different names for the same thing

Anatomy of a Good User Requirement
“The Internet user shall be able to access their
current account balance in less than 5 seconds.”
Defines a user type
Defines a positive end result
“To be” verb
Performance criteria

• This requirement sentence identifies a specific
user and end result that is wanted within a
specified time.
Defines a user type “To be” verb
Defines a positive end result Performance criteria
The challenge is to seek out the user type, end result, and
success measure in every requirement you define.

• It also defines the success in measurable
terms: “access … account balance in less
than 5 seconds.”
Defines a user type “To be” verb
Defines a positive end result Performance criteria
The challenge is to seek out the user type, end result, and
success measure in every requirement you define.

Characteristics of a Good Requirement
• Correct
• Complete
• Clear
• Consistent
• Verifiable
• Traceable
• Feasible
• Modular
• Design-Free
• Positive

• Correct
• Complete
• Clear
• Consistent
• Verifiable
Technically and legally possible

• Correct
• Complete
• Clear
• Consistent
• Verifiable
Expresses a whole idea or statement

• Correct
• Complete
• Clear
• Consistent
• Verifiable
Unambiguous and not confusing

• Correct
• Complete
• Clear
• Consistent
• Verifiable
Not in conflict with other requirements

• Correct
• Complete
• Clear
• Consistent
• Verifiable
Not in conflict with other requirements
It can be determined that the system
meets the requirement

• Traceable
• Feasible
• Modular
• Design-Free
• Positive
Uniquely identified and can be tracked

• Traceable
• Feasible
• Modular
• Design-Free
• Positive
Can be accomplished within cost & schedule

• Traceable
• Feasible
• Modular
• Design-Free
• Positive
Can be changed without excessive impact

• Traceable
• Feasible
• Modular
• Design-Free
• Positive
Does not impose specific solution on design
(i.e., implementation free)

• Traceable
• Feasible
• Modular
• Design-Free
• Positive
Does not impose specific solution on design
(i.e., implementation free)
Written in the affirmative, not the negative

Requirements Should be Correct
• The requirement should be technically and
legally achievable
– Have studies been completed?
– Does the technology exist?
– Will the implementation of the requirement stay within
existing legal guidelines?

A correct requirement is one which does not try to
achieve some “pie in the sky” objective.
For example, the
requirement “The system
shall be 100% reliable” is
technically not achievable.

A requirement may be technically achievable, but
not necessarily legally feasible because it may be
outside the framework of existing legal regulations.
For example, allowing the
user to access private
information online, without
the necessary security
checking, is technically
achievable, but is contrary to
current federal regulations.

Requirements Should be Complete
• Express a whole idea or statement
– Is the requirement standalone?
– Is the requirement dependent on preceding
requirements at that level of achievement?
– Is the requirement necessary for subsequent
requirements at that level of development?

A complete requirement should not depend on
other requirements to be implemented. If a
requirement states “The radar system shall track
aircraft,” it leaves the reader asking “How many?
Inbound or outbound?”

Also, beware of multiple requirements contained
within a single statement. For example, “The
system shall determine the number of users
online at all times and pass the number of users
to the system administrator who shall have the
ability to disconnect users from the Internet.”

Instead, the statement can be broken down into
atomic statements:
Beware of multiple requirements contained within a single statement.
For example, “The system shall determine the number of users
online at all times and pass the number of users to the system
administrator who shall have the ability to disconnect users from
the Internet.”
“The system shall maintain a log of online users.”
“The system shall provide log information to the system
administrator.”
“The system shall allow the system administrator to
disconnect user(s) from the network.”

Requirements Should be Clear
• The requirement should be unambiguous
and not confusing
– Use words that are not confusing
– Use a commonly agreed set of terms
– The construct of the sentence should be standard
– Use definite, concrete terms
– Omit needless words
– Avoid language the target reader may not understand
– Do not overwrite

When writing a requirement, always strive to
maintain clarity. An excellent reference is “The
Elements of Style” by Strunk and White.
For example, don’t “utilize” a function,
rather “use” a function.

When you use the word “system,” do all the readers
have the same understanding of the word?
If you try to impress your readers with
arcane grammar only used in graduate-
level English classes, you will most likely
confuse and irritate them, as they will
have to reach for the dictionary too many
times.

Requirement Should be Consistent
• The requirement should not be in conflict
with other requirements
– Are there redundancies?
– Are the same terms used throughout?
– Are all requirements referencing the same dictionary?
– Requirements repeated in many sections can be
pulled into a common requirements set to avoid
duplication

Requirements Should be Verifiable
• Verification Methods:
– Testing
– Analysis
– Demonstration
– Inspection

• It can be determined that the system
meets the requirement using one of the
standard verification methods:
• Testing: Usually the most
comprehensive of the verification
methods. This is also commonly referred
to as “white box” testing.
This method tests not only the output,
but also how the output is achieved,
considering the unique internal
deviations as a result of different states
and nodes.

• Analysis: This method generally uses
mathematical algorithms
(expressed nowadays in computer
simulations) to ensure the
requirement is met.

• Demonstration: also known as
“black box” testing, where the
system is given input, and the output
is compared against the expected
results.

• Inspection: As the name implies,
this method checks or inspects the
system to ensure conformity to the
requirement.

• You should always ask, “Is the
requirement testable?”
• When the requirement is implemented and
the system is built, you need to verify that
the system, indeed, does what is required
of it.
– To verify the system, people generally use
one of the four classic verification methods
mentioned previously. (Testing, Analysis,
Demonstration, and Inspection)

Requirements Should be Traceable
• The requirement should have a unique
identifier and traced to its origin.
– Ensures completeness
– Prevents “scope creep”
– It is a specific goal in any Requirements Management
process
– Allows quick impact assessment when requirements
change

• A primary aim of any requirements
management process is traceability of
requirements.
How much traceability?
100%!

• According to Standish Group, 52% of
required functionality is never included in
the finished system. Then, when system
testing commences, you discover the
missing functionality. You then have to not
only fix the system to accommodate the
missing functionality, but you have to test
all of the other requirements again to
ensure that the fixed requirement will not
break any existing functions (commonly
referred to as regression)

• When requirements change, as they
almost always do, the impact must be
accessed to ensure that the potential
change will still satisfy the parent
requirements and not adversely impact the
child requirements.

Requirements Should be Feasible
• The requirement should be written so as to
be achievable within cost and schedule
– Do you have the resources?
– Do you have the time?
– Do you have the right people?

Requirements Should be Feasible
A requirement may be technically achievable, but
way beyond the scope of current project
resources.
For example, you have a requirement that states,
“The system shall maintain a 99.9% mean time
between failures,” but the costs of achieving
99.9% reliability may be so exorbitant that the
other requirements may not be implemented due
to insufficient resources.

Requirements Should be Modular
• The requirement should have limited
cross-referencing interdependency.
– Group similar requirements together
– The use of a standardized outline structure helps
tremendously with achieving modularity.

This allows the requirement to be changed
without excessive impact. For example,
the I.E.E.E. 12207 standard contains the
different outline templates for the various
types of requirements in a system, from
the Concept of Operations (CONOPS) to
the Software Test Plan (STP).

• When you use these templates, you
achieve several goals:
– You start achieving modularity
– You are starting to standardize your process

Requirements Should be Design-Free
• The requirement should be
implementation-free
– Avoid design
– Describe what is required, not how it would be
implemented
– The requirement should be written with enough detail
to satisfy the level above
– The requirement should be written at a level of
abstraction to be design free for the next level below

Requirements Should be Design-Free
• During requirements development, we tend to want to
jump right into the design of the system
• Instead of trying to describe the desired functionality or
stakeholder wants, we tend rather to state how the
system will be implemented. Many times, this leads to
increased cost and complexity because the optimal
design space has now been restricted.
• For example, a system requirements document may
state: “The network shall use an ATM protocol.” This
constrains the design of the network to use ATM
technology, when another protocol may be the more cost
effective solution.

Requirements Should be Positive
• Requirements should be written in the
affirmative.
– Reduces the chances of having two requirements say
the same thing.
– Reduces the possibility of two requirements being
inconsistent — one stating something in the
affirmative and one in the negative but with different
conditions or numeric values
– Helps with the verification — it is much easier to test
to a positive statement where something observable
will happen as a result of a user action

– A negative statement that a user action or
statement that something will not result in a
condition would be more difficult to test and
observe
– Less chance of misinterpretation, especially in
the case of double or multiple negatives

For instance, instead of stating:
“No unsuccessful login attempts will go
unrecorded.”
Try rather:
“All unsuccessful login attempts shall be
recorded.”

Rate this Requirement
“The Order Entry system provides for quick,
user-friendly and efficient entry and
processing of all orders.”
Is this a good requirement? If not,
recommend an improvement.

“Invoices, acknowledgements, and shipping
notices shall be automatically faxed during
the night, so customers can get them first
thing in the morning.”

“The system OS shall be upgraded in one
whack.”

“The ATM user shall be able to view the
current account balance after an update
within 5 seconds.”

RM Benefits

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a RM Benefits

Similar a RM Benefits (20)

Último

Último (20)

RM Benefits