Requirements Statement Template
Version history:
Draft 1: 15 October 1996 - for comment by Riley Hayes, Dave King
& Dennis van Langen
Draft 1.1: 25 October, incorporating an example, in html format,
for comment by Dennis van Langen
Draft 2: 7 November 1996, incorporating Dennis van Langen's comments.
For review by OGCC-SC, Product Managers & Program Group Chairs
A Requirements Statement must contain
enough information for it to be usable by the people who are going
to turn the requirement into product. It also needs to contain
information about the business rationale behind the requirement,
including, where possible, information about the business background
from which the requirement arises, together with a view of the
urgency of the requirement.
A flexible template approach has been adopted. Either a single
requirement or a group of closely related requirements can be
expressed using a single document based upon the template. When
multiple requirements are stated, they should apply to a single
application or technology and apply to the same component or sub-system
unless there is a clearly understood relationship or dependency
among the requirements. The maximum amount of clarifying information
should be supplied in each instance, but blank entries, as indicated
for individual data items of the template, can be left when the
information is unavailable, inappropriate, or beyond the technical
understanding of the submitter. If supporting information, e.g.,
business rationale, is available under separate documentation,
this information can be appended to the Requirement Statement
or a locating reference to such material can be given.
In the statement of a specific requirement, precise, unambiguous
language should be used. The requirement should be expressed in
terms of a measurable or quantifiable value.
The following paragraphs contain guidance on how to complete a
Requirements Statement Template. The Template is divided into
three Sections each containing a number of Parts, some of which
are optional, as indicated.
Follow the links to see an example.
Return to index
- Program Group name (mandatory)
- Requirement Number (mandatory)
- Date (mandatory)
The date on which the Requirement was signed-off by the Program
Group as complete in the format YYYY/MM/DD.
- Program Group Chair's signature or printed name (mandatory)
The signature of the Program Group Chair, indicating that the
Requirement has been signed-off by the Program Group as complete.
A printed name will suffice on electronic copies of the Requirement
Statement.
- Requirement Title (mandatory) .
The Requirements Title should be a clear, brief description of
the requirement. A short phrase is desirable but the title should
be sufficiently unique to differentiate it from other requirements
which may fall in the same requirement topic area. If multiple
requirements are presented, all should be consistent with the
subject identified in this title
- Referenced Documents (optional)
Identify the complete name and source of any documents used in
the requirement description.
- Product, Technology, or Standard Addressed
(mandatory)
Requirements are normally associated with specific software products,
technologies, or standard specifications associated with technologies.
This item identifies the association of the requirement to the
product, technology, or standard.
- Subsystem or Component Addressed (optional)
.
For further clarification of the applicability of the requirement,
identify a subsystem or component of the item identified in item
6. For an application program, for example a word processor, the
component might be things such as filing system, spell checker,
search/find, or table support. Another example, reflecting a higher
level of software such as an API, might have subsystem of "data
interchange protocol" or "transport layer."
If a subsystem or component associated with the requirement cannot
be identified, this section can be left blank
- Requirement Category (optional) .
The submitter should identify aspects of the requirement to help
categorize it.
The following non-exhaustive list includes many of the requirements
categories where the customer/user plays a critical role in defining
needs.
Functional requirements are derived from overall system
requirements, for example, hardware versus software trades; behaviour
in presence of failure or incorrect inputs; human aspects of the
system.
Performance requirements involve numerical values such
as rate, frequency, or speed.
Interface requirements include interconnection between
hardware and software, software with software, and connectivity
protocols.
Operational requirements involve how the software runs
and communicates with human operators.
Reliability requirements are stated conditions, using statistical
terminology, which must be met to insure access to the software
and system
Return to index
- Concise Statement of Requirement (mandatory)
.
The Program Group must give a detailed statement
of the requirement. It should be user-oriented, unambiguous in
meaning and be measurable or verifiable when implemented. If multiple
requirements are presented in one Requirement Statement, each
should be in a separate, numbered paragraph to emphasize that
each requirement is distinct and to support traceability.
Too much information is better than too little. On the other hand,
Program Groups should avoid specifying a solution rather
than a requirement. If the need is for some form of guide, advice,
education, etc., the statement should make clear exactly what
is wanted.
There must be an explanation of the Program Group's understanding
of the nature and scope of the work to be performed by The Open
Group (or other organizations) to satisfy the requirement. This
understanding should be the result of discussion with the Product
Manager assigned to the Program Group and liaison between the
Program Group and the appropriate Specification Working Groups(s)
and/or Technology Development Groups (PSTs etc.). References to
existing Open Group specifications and other publications are
highly desirable.
If, in the course of the requirement's development, it has been
established that there is relevant work going on in organizations
outside The Open Group it should be reported.
Information must be provided about the interaction (if any) between
this requirement, other requirements arising from this Program
Group, and the work of other Program Groups.
If more than one Program Group collaborated in developing the
requirement, it should be stated. In particular, if the requirement
spanned more than one Program Group but was developed by a single
Program Group, the agreement of the other Program Group(s) should
be indicated. If for any reason it is thought that the requirement
could impact (an)other Program Group(s), but no agreement has
been reached on the nature of the impact, details should be recorded
on the Requirements Statement
- Current need or deficiency addressed (mandatory)
.
The Program Group should describe in as much detail as possible
the problem which is addressed by each requirement. This description
should supply the explicit lack or problem which arises with the
existing software or proposed software. Additionally, this problem
should be described, to the best of the ability of the Program
Group, in terms of:
Business: a description of the impact of the problem upon
users' business activities. This is mandatory: it indicates to
suppliers the severity of the problem in the business environment.
Function: a discussion of the operational difficulties
in the use of the software which would be alleviated by implementation
of a solution to the requirement. This should be included if appropriate.
Technical: a description of technical details of the problem
should be given if it is within the technical capabilities of
the Program Group. This level of detail is optional
- Relationships (optional) .
Identify any interface, technical or functional relationships
involved in this requirement. Describe any required characteristics
of the requirement products or services (such as specific data,
records, messages, communication protocols, encryption algorithms,
etc.).
- Other Characteristics (optional) .
Include a description of any "local unique" implementation
features (such as a table of organization codes to be supplied
by the user), any safety critical considerations, security or
privacy concerns, environment considerations (such as "military
ruggedized usage"), and any special hardware/software/communications
required features.
- Desired implementation timetable (mandatory)
The Program Group must provide a reasonable timetable for useful
implementation of the solution to the requirement. A short rationale
supporting the timetable should be included.
Return to index
- Business Case (mandatory)
The Program Group must provide a detailed business case for implementation
of a requirement. If an appropriate business case exists in other
documentation, a pointer should be provide a reference or the
documentation attached.
The business case should supply information which suppliers can
use to aid in determining the economic justification for implementation
in response to the requirement. Note that the business case differs
from the business need statement contained in Section 2(2). In
2(2) the emphasis is on the problem/benefit to the user's business
activities whereas here the emphasis here is on the potential
benefit to suppliers in making an investment in responding to
the requirement.
In broad terms, what is needed here is an indication of the importance
to the user community of satisfying the requirement. The kinds
of indicators that may be used are:
1. how many organizations are likely to be affected by the problem
that has given rise to the requirement? If this assessment can
be based on market research, so much the better, but some inspired
guesswork is acceptable as long as it is clearly labeled as such.
2. what savings might arise if the problem was fixed? Conversely,
what costs arise because the problem is not fixed? These measures
can be expressed in many ways, eg cash savings in absolute terms
or as a percentage of IT spend; people savings; unit cost reductions
in hardware or software. What the Program Group can say here depends
on the information they have or can obtain.
3. if it is impossible to assess financial savings, can the importance
of the requirement be expressed in some other way? A statement
about its impact on enterprise strategy is one possibility. Another
is to make some estimate of the frequency with which the problem
is encountered.
4. what will be the impact on users' IT environments when a solution
to the problem(s) that gave rise to the requirement is provided?
Useful information would include, for example, an assessment of
the potential market for products incorporating the solution,
the preferred packaging of the product, the price the user community
might be prepared to pay, and the kinds of applications that might
be enabled by the solution.
5. if there are concerns about backwards compatibility, they should
be stated.
The importance of providing this type of information is that
it will persuade system and software vendors that there is a potential
market for products in which the solution to the requirement is
incorporated, and therefore to bring such products to market.
- Other rationale (optional)
The Program Group should provide any additional rationale which
would justify implementation.
This section may be particularly important for non-commercial
software, i.e., specially developed or limited market products,
in the justification of further development.
Completion of this item is highly desirable, as it will affect
how seriously the requirements are considered by vendor organizations
and may be used to establish implementation priorities.
- Implications for or impact on other systems or subsystems.
(optional)
If known, the Program Group should provide a description
of how changes made to implement the requirement may affect related
products, components, or technologies.
- Quality Factors (optional)
This section enables the evaluation of partial solutions
to the requirement. The Program Group should provide a description
of the essential capabilities to resolve this requirement. Any
other aspects of the requirement should be prioritized and weighted
to reflect relative importance.
- Evaluation Method (optional)
Describe how the Program Group will evaluate the
proposed product or solution. Approaches include Branding, demonstrations,
testing (instrumentation), analysis (review of pertinent data),
inspection (documentation review), and others (special tools,
techniques, etc.).
Return to index
REQUIREMENTS STATEMENT
SECTION 1 - DESIGNATORY INFORMATION
1. Program Group name...................................................
2. Requirement number...........
3. Date........................................................
4. Program Group Chair's signature...........................................
----------------------------------------------------------------------------------------------------------------
5. Requirement title
----------------------------------------------------------------------------------------------------------------
6. Referenced Documents
----------------------------------------------------------------------------------------------------------------
7. Product, Technology, or Standard Addressed
----------------------------------------------------------------------------------------------------------------
8. Subsystem or Component Addressed
----------------------------------------------------------------------------------------------------------------
9. Requirement Category
SECTION 2 - REQUIREMENT DETAILS
1. Concise Statement of Requirement
----------------------------------------------------------------------------------------------------------------
2. Current need or deficiency addressed
----------------------------------------------------------------------------------------------------------------
3. Relationships
----------------------------------------------------------------------------------------------------------------
4. Other Characteristics
----------------------------------------------------------------------------------------------------------------
5. Desired implementation timetable
SECTION 3 - BUSINESS CASE AND OTHER INFORMATION
1. Business Case
----------------------------------------------------------------------------------------------------------------
2. Other rationale
----------------------------------------------------------------------------------------------------------------
3. Implications for or impact on other systems or subsystems
----------------------------------------------------------------------------------------------------------------
4. Quality Factors
----------------------------------------------------------------------------------------------------------------
5. Evaluation Method
Return to index
The following example of a completed Requirements Statement
form is based on a real requirement produced in 1996 by the Distributed
Systems Management Program Group.
The form itself is printed in normal font. Requirement details
are in italics.
REQUIREMENTS STATEMENT
SECTION 1 - DESIGNATORY INFORMATION
1. Program Group name ..Dist. Systems Management
2. Requirement number XR/DSMG/Gnn
3. Date 1996/06/18
4. Program Group Chair's signature...........................................
----------------------------------------------------------------------------------------------------------------
5. Requirement title
Common Agent Services Return to main document
----------------------------------------------------------------------------------------------------------------
6. Referenced Documents
X/Open Preliminary Specification for Remote Procedure Call
----------------------------------------------------------------------------------------------------------------
7. Product, Technology, or Standard Addressed
Systems Management software Return to main document
----------------------------------------------------------------------------------------------------------------
8. Subsystem or Component Addressed
Systems Management Agent (within the Manager-Agent
model) Return to main document
----------------------------------------------------------------------------------------------------------------
9. Requirement Category
Interface Return to main document
1. Concise Statement of Requirement
Establish product interoperability by converging agents
and their associated functionality.
Common agent services are required to support systems management
functionality across a distributed heterogeneous computing environment
- enterprise servers through desktop platforms. These common agent
services will interoperate within a standard framework to enable
plug and play (service related) functionality.
Common Agent Services:
Brandable MIB (Host Resource MIB), and MIF attribute specifications.
Common file/information transfer service.
Brandable component discovery capability.
Return to main document
----------------------------------------------------------------------------------------------------------------
2. Current need or deficiency addressed
Each management system currently utilizes its own discrete
and unique agent within the manager-agent model construct.
Within the Manager-Agent Model construct, intelligent management
agents using common agent services need to perform management
activities for a Resource Manager and/or independently of a Resource
Manager (autonomous agent execution functions). The model should
utilize 'states' based upon event triggers as outlined below:
Suppose the event shown is generated by a deviation from a
defined operating state and subsequently one of the actions noted
is taken.
Further, these agents should be able to correlate faults, determine
problems, and take corrective action(s) utilizing the above mentioned
states and their relationships. To insure optimal configuration
management, the agent should use event states to perform auto
discovery, auditing against defined configurations, and information
transfer (as required) in support of operating policies.
----------------------------------------------------------------------------------------------------------------
3. Relationships
Scalability:
Services will span a computing environment with multiple domains
(levels of autonomy). It is expected that from a few to 100,000s
of devices (macro components, e.g. servers and desktop devices
not components contained within the device) and a ratio of 7 to
1 objects to macro component will be managed.
Extensibility and interoperability:
A standard common agent services framework will be provided
to support plug and play functionality, especially for the introduction
of new capabilities. This framework will enable interoperability
of the systems management functionality provided by different
suppliers of distributed systems management products. More specifically,
the functionality of one supplier's product can access and use
the data generated and stored by another supplier's product.
All implementations must be capable of interoperability with
implementations from other suppliers using the X/Open Preliminary
Specification for Remote Procedure Call.
----------------------------------------------------------------------------------------------------------------
4. Other Characteristics
Security Requirement:
Common agent services will ascertain whether the requesting
manager is authenticated to request the agent's backstore data
or information .
----------------------------------------------------------------------------------------------------------------
5. Desired implementation timetable
The common agent services requirement should have a very
high priority on the list of distributed systems management requirements
to be met in 1996-97.
1. Business Case
The benefits of common agent services are:
High availability (7X24) for Decision Support Systems, enabling
mitigation of $ millions per hour lose incidents, e.g. when a
manufacturing facility must wait until IS technology is recovered
and available, as a result of unscheduled downtime or decision
malfunction.
Mitigation of roughly $8000 per year per LAN user for support
cost and lost of revenue due to missed service levels agreements
or service level objects.
Mitigation of administrative overhead associated with support
of multiple agents reflecting duplication of services and their
associated information files.
Optimize the processing and storage overhead across many networked
components as a result of having to support multiple agents with
duplicate attribute information as well as duplication of services.
Return to main document
----------------------------------------------------------------------------------------------------------------
2. Other rationale
None
----------------------------------------------------------------------------------------------------------------
3. Implications for or impact on other systems
or subsystems
Security - see above.
----------------------------------------------------------------------------------------------------------------
4. Quality Factors
----------------------------------------------------------------------------------------------------------------
5. Evaluation Method
The requirement will be satisfied when products which include
the following reach the market:
Brandable MIB (Host Resource MIB), and MIF attribute specifications.
Brandable component discovery capability
