| Related: |  |
 |
This document describes what the system is to do [functional requirements], how well it is to perform [performance requirements], and under what conditions [non-functional and performance requirements]. This document does not define how the system is to be built. It pulls together requirements from a number of sources including but not limited to:
§ Concept of Operations and Scenarios
§ Elicitation process – previous studies, “Day in the Life” studies, interviews, and workshops
§ Constraints that are put onto a project, such as policies that will drive constraints on the system. [Example, the Agency policy is to use Oracle in ITS]
ITS projects have a Requirements Specification at the system and sub-system levels.
This document sets the technical scope of the system to be built. It is the basis for verifying the system and sub-systems when delivered [via the Verification Plan].
Any ITS projects will need a set of requirements defining what is needed. The tailoring is in how extensive to document these requirements. One way to gauge how many requirements to write and/or how much detail to have in the requirements document is to start at the finish line. The following should be asked when starting at the top level of the system:
§ What are all the functions needed in order to satisfy for the agency that the system is doing what it is expected to do?
§ How well does the system need to perform the required functions?
§ Under what conditions does the system need to operate?
§ What tests are needed to show the system operates as intended
Each of these tests will need a requirement. This is done for the system and the sub-systems. For simple systems there may only be 1 or 2 pages of requirements that can fully define what the system is to do. In more complex systems this could be 10 to 20 pages or more.
Other factors that drive the extent to which requirements need to be written are the amount of commercial products that are used. These products have their own specifications. So, it may be sufficient to reference them after they have been reviewed to determine if the product will meet the agency’s intended need. For example, the traffic control systems that are on the market have sufficient documentation to cover the majority of functions that are required. The additional requirements would be for any modifications or enhancements needed.
R Is there a definition of all the major system functions?
R For each function, do requirements describe: what the function does, what performance is needed, and under what conditions [e.g. environmental, reliability, and availability] the system performs the function?
R Are all terms, definitions, and acronyms defined?
R Are all supporting documents such as standards, concept of operations, and others referenced?
R Does each requirement have a link [traceability] to a higher-level requirement or a user-specified need?
R Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent?
R Are all technology dependent requirements identified as constraints?
R Does each requirement have a method of verification defined?
SYSTEM AND SUB-SYSTEM REQUIREMENTS TEMPLATE
IEEE Std 1233 Guide for developing System Requirements Specifications
|
section |
contents |
|---|---|
|
Title Page |
The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information: § SYSTEM REQUIREMENTS/SUB-SYSTEM REQUIREMENTS [insert name of project] AND [insert name of transportation agency] § Contract number § Date that the document was formally approved § The organization responsible for preparing the document § Internal document control number, if available § Revision version and date issued |
|
1.0 Scope of System or Sub-system |
§ Contains a full identification of the system § Provides a system overview and briefly states the objectives of the system § Describes the general nature of the system § Summarizes the history of system development, operation, and maintenance § Identifies the project stakeholders, acquirer, users, and support agencies § Identifies current and planned operating sites |
|
2.0 Reference |
Identifies all needed standards, policies, laws, concept of operations, concept exploration documents and other reference material that supports the requirements. |
|
3.0 Requirements |
Functional requirements [What the system shall do] Performance requirements [How well the requirements should perform] Interface requirements [Definition of the interfaces] Data requirements [Data elements and definitions of the system] Non-Functional requirements, such as reliability, safety, environmental [temperature] Enabling requirements [Production, development, testing, training, support, deployment, and disposal]. This can be done through references to other documents or embedded in the requirements Constraints – [e.g. Technology, design, tools, and/or standards] |
|
4.0 Verification Methods |
For each requirement, identify one of the following methods of verification: Demonstration is a requirement that the system can demonstrate without external test equipment. Test is a requirement that requires some external piece of test equipment. E.g. logic analyzer, and/or volt meter. Analyze is a requirement that is met indirectly through a logical conclusion or mathematical analysis of a result. E.g. Algorithms for congestion: the designer may need to show that the requirement is met through the analysis of count and occupancy calculations in software or firmware. Inspection is verification through a visual comparison. For example, quality of welding may be done through a visual comparison against an in-house standard. |
|
5.0 Supporting Documentation |
Catch-all for anything that may add to the understanding of the Requirements without going elsewhere [Reference section] Examples: diagrams, analysis, key notes, memos, rationale, stakeholders contact list |
|
6.0 Traceability Matrix |
This is a table that traces the requirements in this document to the higher-level requirements or if this is a top-level requirements document, it should trace to the User Needs (which are defined in the Concept of Operations) |
|
7.0 Glossary |
Terms, acronyms, definitions |
| Related: | |
|
