Model Systems Engineering Documents for Dynamic Message Sign (DMS) 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 International Organization of Standardization (ISO)/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 DMS system 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 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 even 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 many requirements, it may be sufficient to reference the existing product specifications after the requirements have been carefully reviewed. For example, the DMS systems that are on the market have sufficient documentation to demonstrate that most requirements are fulfilled. 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 fulfilling the requirements.

When choosing from available products, your requirements do not need to be as detailed as they would be when developing a new system. This document applies 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.

• 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.

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.

Requirements (Chapter 3 of the Requirements Document)

This chapter lists all the requirements necessary to define the proposed DMS 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.

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 DMS System environment. The requirements indicate where this is necessary by square brackets “[specify]”.

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.

Traceability Matrix (Chapter 6 of the Requirements Document)

This is a table that traces the requirements in this document to the needs expressed in the Concept of Operation. Every requirement must support at least one user need.

Glossary (Chapter 7 of the Requirements Document)

This is a standard glossary of terms unique to the project.