As stated in the From Requirements to Analysis post I would like to
propose a template for the Requirements Document. The document itself is
not expected to be complete when first introduced (unless someone is
really ambitious) but will probably be filled in throughout the
discussion of the requirement statement. I assume that "CoreLinux++
should have a Thread Class" in not nearly sufficient to even enter
Analysis with.
This is, for the most part, a somewhat shortened System Requirement
Specification (SRS) that I had in my past experience. I took the liberty
to removed some of the specification as they overlap with what the
Analysis documentation would otherwise provide.
AS ALWAYS THIS IS OPEN FOR DISCUSSION (I will omit this statement in
future posts as it is my opinion that is is implicit in Open Source
philosophy).
A software requirements specification should include the following
sections.
Title :
Requirement ID: (message ID from the Requirement Forum)
1. Introduction
Provide an overview of the requirement in relationship to the system.
1.1 Deliverables Overview
Describe the major functions and components of the product. Summarize
the rationale for building the deliverables for readers unfamiliar with
the project.
2. Functional Requirements
Describe the services, operations, data transformations, etc., provided
by the requirement, user interfaces, and the relationship of the
requirement to its environment. This portion of a requirements document
is usually the largest, because functionality must be described as fully
and precisely as possible.
2.1 User Interface Specifications
If applicable, describe screens, windows, graphics, and other visual
aspects of the requirement. Define any command languages. Specify the
interaction or dialog conventions governing the user interface in
complete detail. User interface prototypes may be used. For the most
part, the CoreLinux++ effort is not to provide widgets or dialogs for
EUI so this would typically be NA.
2.2 Product Services
Describe the computations, data transformations, services, and so forth
provided by the product. State all the services the product will
provide, but not how they will be provided.
2.3 External Interfaces and Database Requirements
If applicable, describe the interfaces to other systems or the
environment. Describe the logical organization of databases used by the
system.
2.4 Error Handling
Catalog exceptional conditions and error conditions, and responses to
these conditions, as completely as possible.
2.5 Foreseeable Functional Changes and Enhancements
State any foreseeable changes and enhancements in functionality for the
benefit of the designers and implementers.
3. Non-Functional Requirements
Discuss the constraints under which the deliverables must operate, the
environment in which they must operate, any standards they must conform
to, etc.
3.1 Performance Requirements
State any efficiency, reliability, robustness, portability, memory size,
response time, or similar requirements.
3.2 User Documentation and Other User Aids
State the tutorials, reference material, data, examples, test programs,
and so forth that will accompany each deliverable.
3.3 Development Requirements
State any quality standards or guidelines, independent verification and
validation requirements, testing strategies, development methods, tools,
techniques, or policies, or other development constraints imposed by the
customer or the development organization.
3.5 Foreseeable Non-Functional Changes
State any foreseeable changes in non-functional requirements for the
benefit of the designers and implementers. Such changes generally arise
from hardware evolution, changing user needs, new systems in the
operating environment, etc.
4. Remarks and Guidelines for Later Life Cycle Phases
Draw attention to any problems or pitfalls, potential solutions to
foreseen problems, or other helpful information produced during
requirements analysis and generation that may be useful later in the
life cycle.
5. Term Glossary
Add whatever terms we have introduced.
|
