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:
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:
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.
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.
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.
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:
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]”.
In this chapter, identify one of the following methods of verification for each requirement.
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.
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.
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.
This is a standard glossary of terms unique to the project.
United States Department of Transportation - Federal Highway Administration