Home › Guides, Handbooks, Reports & Papers › Requirements Analysis ›

Requirements Management Starter Kit

Document metadata
Document date: 
1998
Document type: 
conference article
Pages: 
6
Author(s)
Lorraine A. Pajerek
Organization(s)
International Council on Systems Engineering (INCOSE)
Lockheed Martin
Lockheed Martin Federal Systems
Attachment(s)
FileSize (KB)MIME typeLanguage
Reqts_Mgmt_P3_3.PDF41.16application/pdfEnglishDOWNLOAD!

SESA/INCOSE SE98 - 1

Abstract

The value of performing requirements
management throughout the life of a programme or
project has gained wide acceptance throughout the
defence industry, and is beginning to be recognised
within the commercial sector as well. Managers are
becoming increasingly aware that rigorous
management of requirements can help control cost
and schedule growth, and support the overall
management of a programme through its lifecycle.

Thus the need for application of requirements
management skills and technology is growing, as
many organisations with little or no tradition of
requirements management are attempting to
incorporate it into their business and/or engineering
processes. This includes contractors and customers
alike.

For projects lacking expertise in this arena, a
generic "starter kit" can be very helpful in getting
them quick-started. A starter kit is tool specific, but
the nature of its contents is the same regardless of
which tool is selected. A starter kit includes:

1. Basic data base schema
2. Scripts for running standard reports
3. User's Guide matched to the schema and
scripts
4. Training package matched to the schema
and scripts
5. Tailoring guidance

With such a kit, subject matter experts can
quickly help individual programs get off the ground.
For sites with an in-house process or tools group,
this is a natural home for engineers with the
knowledge to tailor the starter kit, and provide
consulting to bootstrap programmes to the point of
self-sufficiency.

This paper presents general guidelines for
creating a Requirements Management Starter Kit. It
also describes a specific example of a starter kit
designed to be used with a specific requirements
management tool, RTMÒ from Integrated
Chipware.

It must be noted that successful use of a tool
requires the existence of a process. The tool
supports the process; it does not substitute for the
process. If an organisation attempts to use an
automated tool without at least some level of
process definition beforehand, it is almost certain to
run into implementation problems downstream that
will result in significant rework, or perhaps
scrapping the tool altogether.

Extract(s)

The change in terminology from “requirements
traceability” to “requirements management” implies
an expanded scope of activity, which in fact is what
the industry has witnessed over the past decade.
The discipline of requirements management is now
understood to include a number of elements, of
which traceability is only one. Traceability is still
an important part of requirements management, of
course. This term generally refers to tracing
requirements both upward (to their source
documents, and - for derived requirements - to their
parent requirements) and downward (to child
requirements and to design elements).
In addition to maintaining this kind of
traceability information, requirements management
also encompasses:
· allocating requirements to the physical and
functional hierarchies of the system;
· categorising requirements;
· capturing information associated with
requirements (e.g., assumptions, rationale);
· assessing the system design for compliance
to each requirement;
· verifying requirements in the as-built
system;
· computing requirements metrics;
· managing requirements change;
· generating ad hoc reports;
· generating and maintaining specifications;
and
· tracking all the above activity in a common
repository (i.e., data base).
All of these tasks are now supported by
automated COTS tools.

FIVE LEVELS OF TECHNOLOGY
INSERTION
As engineering professionals, we are nearly all
familiar with the five levels of process maturity
defined by the CMM. Less well known are the five
levels of technology insertion:

1. Blank Incomprehension
2. Active Hostility
3. Wary Skepticism
4. Grudging Resignation
5. Loving Embrace

Well, maybe we’re being a little optimistic
about the Loving Embrace; how about Weary
Acceptance?

Kidding aside, we all know that getting an
organisation to embrace a new technology (whether
a new process or a new tool, or both) is difficult.

Rating
4
Referenced standards and/or methodologies
Standard: DOD-STD-2167 - Defense Systems Software Development
Standard: EIA/IS-731: Systems Engineering Capability Model
Standard: ISO 9000