Model Systems Engineering Documents for Central Traffic Signal Systems

Chapter 3. System Requirements Guidance

The model System Requirements can be found in Appendices B and C. Appendix B lists the requirements with backward traceability to the needs, and Appendix C shows the method by which each requirement can be verified. The sections below describe the typical outline of a standard requirements document, as described by the International Organization for Standardization (ISO)/ Institute of Electrical and Electronics Engineers (IEEE) 29148:2011(E). For the projects targeted by these model documents, all of these sections may not be necessary, or are adequately covered in the Concept of Operations. We include them here for general information and context. The parts of the outline that are critical, however, include Chapters 3 and 4 of the IEEE outline, which include the requirements and verification methods. For this reason, the numbering for the functional requirements listed in Appendices B and C start with a "3.1". This numbering approach is an artifact of the standardized numbering.

The chapters required for the System Requirements document are:

1. Scope of System or Sub-system
2. References
3. Requirements
4. Verification Methods
5. Supporting Documentation
6. Traceability Matrix
7. Glossary

This document sets the technical scope of the system to be built. It is the basis for verifying (via the Verification Plan) the system and sub-systems when delivered.

This document must be tailored to your project. All Central Traffic Signal System (CTSS) projects need a set of requirements defining what will be provided by the vendor. You will need to decide how extensively to document these requirements. One convenient 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 demonstrate to 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?

Each of these tests will refer to a set of requirements. This is done for the system and the sub- systems. The depth of detail provided in these requirements derive from the task of selecting currently available products. These requirements do not provide sufficient depth to support significant development, particularly software development, as may occur in projects that are beyond the scope of model documents.

For many requirements, it may be sufficient to reference the existing product specifications after the requirements have been carefully reviewed. For example, the CTSS products that are on the market may have sufficient documentation to demonstrate that most requirements are fulfilled. The additional requirements would be for any minor modifications or enhancements needed. However, great care must be taken when referencing existing commercial product specifications to ensure the wording does not unnecessarily or unintentionally limit compliance to a single system when more than one is capable of fulfilling the requirements. The wording of the requirements is therefore derived from the meaning and wording of the needs to which they trace.

Once the requirements document has been completed, use this checklist to confirm that all critical information has been included.

• Is there a definition of all the major system functions?
• With each function of the system, is there a set of requirements that describes: what the function does, and under what conditions (e.g., environmental, reliability, and availability)?
• Are all terms, definitions, and acronyms defined?
• Are all supporting documents such as standards, concept of operations, and others referenced?
• Does each requirement have a link (traceability) to a higher-level requirement of a user- specified need or scenario?
• Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology (vendor) independent?
• Are all technology dependent requirements identified as constraints?
• Does each requirement have a method of verification defined?
• Does each requirement trace to a verification case?

Scope of System or Sub-System (Chapter 1 of the Requirements Document)

This chapter is a brief overview of the system and statement of the purpose of this document. Briefly describe the contents, intention and audience for this document. Summarize the history of system development, the proposed operation, and maintenance. Identify the project stakeholders, acquiring agency, users and support agencies. Identify current and planned operating sites. Generally, the similar material in the Concept of Operations provides sufficient coverage of this material, and thus is not needed for the projects for which the model documents are appropriately applied.

References (Chapter 2 of the Requirements Document)

This chapter identifies all standards, policies, laws, the Concept of Operations document, concept exploration documents and other reference material that are needed to support the requirements. These documents are usually adequately referenced in the Concept of Operations.

Requirements (Chapter 3 of the Requirements Document)

This chapter lists all the requirements necessary to define the proposed CTSS. Each requirement should be clear and concise, verifiable, feasible, necessary, unambiguous and technology independent. Each requirement should have a single statement. If adding or modifying requirements, DO NOT use terms such as "and", "but", "except" and other modifiers that combine more than one thought into a single requirement.

In general, each of the sample requirements falls into one of the following categories, although they are not expected to be organized in this manner:

• Functional Requirements (What the system shall do).
• Constraints (e.g., Technology, design, tools, and/or standards).

Sample requirements that may be used in the Requirements document are included in the System Requirements samples table (Appendix B). Each of these is directly related to one or more statements of need in the Concept of Operation.

Some of the requirements and their corresponding user needs will require additional specification and tailoring to the CTSS environment. The requirements indicate where this is necessary by brackets such as "[specify]".

Note that the order of the requirements in Appendix B is organized by major system function, while the requirements are shown in "need order" in Appendix A. This helps vendors and system providers navigate the requirements more efficiently. Any changes to the requirements made while working through the Concept of Operations Sample Statements in Appendix A must be transferred to the model requirements in Appendix B.

Verification Methods (Chapter 4 of the Requirements Document)

In this chapter, identify one of the following methods of verification for each requirement.

• Demonstration is used for a requirement that the system can demonstrate without external test equipment.
• Test is used for a requirement that requires some external piece of test equipment (such as logic analyzer or voltmeter).
• Analyze is used for a requirement that is met indirectly through a logical conclusion or mathematical analysis of a result. For example, 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 used for verification through a visual comparison. For example, quality of welding may be done through a visual comparison against an in-house standard.

Suggested verification methods that may be used in the Requirements document are included in the Suggested Requirements Verification Methods table (Appendix C). Do not describe how, when or where the verification will be performed. This is separately covered in the Verification Plan document.

Supporting Documentation (Chapter 5 of the Requirements Document)

This optional chapter is a catchall for anything that may add to the understanding of the Requirements and cannot be logically located elsewhere. Examples of supporting documents include: diagrams, analysis, memos, stakeholders contact list and published documents related to similar projects. Most routine signal system projects will not need anything in this chapter.

Traceability Matrix (Chapter 6 of the Requirements Document)

The traceability matrix traces the requirements in this document to the needs expressed in the Concept of Operation. Every requirement must support at least one user need. Appendix B provides traceability directly.

Glossary (Chapter 7 of the Requirements Document)

The glossary is a list of terms unique to the project. A glossary of terms is provided in this document.