Arterial Management Program
Table of Contents

Model Systems Engineering Documents for Adaptive Signal Control Technology (ASCT) Systems

E. SYSTEM REQUIREMENTS GUIDANCE

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 signal system projects need a set of requirements defining what is needed. 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 need a set of requirements. This is done for the system and the sub-systems. For simple systems one or two pages of requirements may be sufficient to fully define what the system is to do. In more complex systems this could be 10 to 20 pages or more.

Another factor that drives the number of requirements and depth of detail that needs to be written is the extent to which commercially available products are used. These products have their own specifications. For the non-adaptive requirements, it may be sufficient to reference the existing product specifications after they have been carefully 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 the non-adaptive functions that are required. The additional requirements would be for any 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 providing the required functionality.

When choosing from available products, your requirements don't need to be as detailed as they would be when developing a new system. These model documents apply only to the former situation. If your needs lead you to decide that new software must be developed, the project will be of sufficient scope and risk to warrant a more detailed and customized system engineering process than is provided by these model documents.

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

check Is there a definition of all the major system functions?

check 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.)

check Are all terms, definitions, and acronyms defined?

check Are all supporting documents such as standards, concept of operations, and others referenced?

check Does each requirement have a link (traceability) to a higher level requirement of a user-specified need or scenario?

check Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology (vendor) independent?

check Are all technology dependent requirements identified as constraints?

check Does each requirement have a method of verification defined?

check Does each requirement trace to a verification case?

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

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.

2 References (Chapter 2 of the System Requirements)

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

3 Requirements (Chapter 3 of the System Requirements)

This chapter lists all the requirements necessary to define the proposed adaptive system. Each requirement should be clear and concise, verifiable, feasible, necessary, unambiguous and technology independent. Each requirement should have a single statement. DO NOT use terms such as "and", "but", "except" and other modifiers that combine more than one thought into a single requirement. The requirements listed in the sample table are organized under the following headings:

  • Network characteristics
  • Type of operation
  • External/Internal interfaces
  • Crossing arterials and boundaries
  • Access and security
  • Data log
  • Advanced controller operation
  • Pedestrians
  • Special functions
  • Detection
  • Railroad and EV preemption
  • Transit priority
  • Failure events and fallback
  • Software
  • Training
  • Maintenance, support and warranty
  • Schedule
  • Performance measurement, monitoring and reporting.
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)
  • Performance requirements (How well the requirements should perform)
  • Non-Functional requirements (Reliability, safety, environmental)
  • Enabling requirements (Production, development, testing, training, support, deployment, and disposal). This can be done through references to other documents or can be explicitly defined in these requirements.
  • Constraints (e.g., Technology, design, tools, and/or standards)

If this document is describing a sub-system, the following may also be required:

  • Interface requirements (Definition of the interfaces)
  • Data requirements (Data elements and definitions)

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

4 Verification Methods (Chapter 4 of the System Requirements)

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 and volt meter.
  • 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.

Do not describe how, when or where the verification will be performed. This is separately covered in the Verification Plan, which is discussed in a later section.

5 Supporting Documentation (Chapter 5 of the System Requirements)

This optional chapter is a catch-all 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.

6 Traceability Matrix (Chapter 6 of the System Requirements)

This is a table that traces the requirements in this document to the needs expressed in the Concept of Operation. Table 2 contains an extract from a traceability matrix used in a project with multi-level requirements (Business, User and Functional).

Table 2. Example Traceability Matrix
User requirement User requirement description Satisfies business requirement Satisfied by functional requirement
TO Traffic Operations
TO-1 System operator needs to support vehicle, pedestrian and transit traffic mobility 1, 4, 8 3, 4, 9, 10
TO-2 System operator needs to identify changing traffic conditions 2, 5 13, 14, 15, 16
TO-3 System operator needs to adjust the operation based on the traffic conditions 2, 5 1, 2, 16, 20
TO-4 System operator needs to reduce the delay and travel time of the priority movements of each intersections 2 1, 5, 6, 7, 8
TO-5 System operator needs to minimize adverse effects caused by preemption and unexpected events 2 1, 11, 12, 19
H Hardware
H-6 The agency needs to reuse existing equipment where possible without reducing the service life of the system 10 17, 18

previous | next