- Briefing Room
U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Requirements are the foundation for building Intelligent Transportation Systems [ITS]. They determine WHAT the system must do and drive the system development. Requirements are used to determine [verify] if the project team built the system correctly. The requirements development process identifies the activities needed to produce a set of complete and verifiable requirements.
Requirements development is a set of activities that will produce requirements for the system and sub-systems. The systems engineering standard [EIA 632] defines “requirement” as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” Requirements define the functions, performance, and environment of the system under development to a level that can be built:
Does the system do WHAT it is supposed to do? - These are Functional requirements.
How well does the system do its functions? - These are Performance requirements.
Under what conditions [e.g. environmental, reliability, and availability.], does the system have to work and meet its performance goals? – These are Environmental and Non-Functional requirements.
There are other types of enabling requirements that are also needed but often overlooked. They define other aspects of systems development that are needed [but do not show up] as part of the system. Some examples are: development, testing, support, deployment, production, training, and in some cases disposal. Primarily the Functional, Performance, Environmental, and Non – Functional Requirements are contained in the System and Sub-system requirements documents. The enabling requirements may also be in these documents but they mainly show up in the various plans [SEMP and project plan], statements of work for contracted work, and memorandums of understandings among participating stakeholders.
CONTEXT OF PROCESS:
REQUIREMENTS DEVELOPMENT PROCESS
Concept of Operations documents the user needs, expectations, goals, and objectives. It describes the way the system is intended to operate from the user’s perspective.
Regional ITS Architecture defines the regional framework [environment] in which this project must operate. Major external interfaces, high level functional requirements, and stakeholders are identified.
Feasibility Study produces the conceptual high-level design and requirements which can be used as a starting point for the project.
Project Plan/SEMP contain various plans, such as the review plans, configuration management plans, and risk plans. [Control the requirements development].
Configuration management [CM] identifies the process to control changes to the requirements and manage the baseline documentation.
Risk management is used to monitor, control, and mitigate high risk requirements.
Technical reviews are used to identify defects, conflicts, missing, or unnecessary requirements. Then, the requirements review control gate [formal review] is used to approve the final set of requirements.
Stakeholder involvement is essential for validating the requirements. Are these the correct requirements?
Elicitation enables the discovery and understanding of the needed requirements.
A technical trade study is used to analyze and compare alternative requirements and their technical and cost impacts on the system.
Traceability of requirements to user needs & requirements, support documentation, and constraining policies [e.g., safety requirements & regional ITS architecture].
System and Sub-system Requirements Documents must be complete, verifiable, and validated. After formal review and approval by the system owner and stakeholders, they are put under configuration control.
Verification Plan [from the verification process] documents the plan to verify each system requirement.
The first step is to develop requirements from the stakeholder needs and input products. Once requirements are documented, they are prioritized, de-conflicted, and validated with the stakeholders.
Write and document requirements
Characteristics of "good" system requirements are: they should be necessary, testable, clear, concise, technology-independent, feasible, and stand-alone. Requirements must be documented in order to establish the base to build upon [called a baseline], and for managing changes to the requirements.
A complete set of requirements defines all system functions that are needed to satisfy the stakeholder needs with their associated performance, environmental, and other non-functional requirements.
Analyze, refine, and decompose requirements
This process examines each requirement to see if it meets the characteristics of a good requirement [e.g., clear, unambiguous, and verifiable]. Each requirement will be decomposed into a more refined set of requirements that are allocated to sub-systems, and performance requirements are defined. Newly derived requirements are expected to emerge from this process, which continues until all requirements are defined and analyzed and the final project architecture is defined.
Each requirement must be validated to ensure that these are the correct requirements. This will be done through stakeholder walkthroughs and tracing requirements to an associated need.
Once the requirements have been accepted and a baseline is established by the stakeholders, changes to the requirements are controlled using a change management process.
Where does the Requirements Development take place in the project timeline?
Is there a policy or standard that talks about Requirements?
The FHWA Final Rule requires that requirements be developed for ITS projects funded with the Highway Trust Fund, including the Mass Transit Account. The IEEE 1233 Guide for developing system requirements specifications provides a standard for developing requirements.
Which activities are critical for the System's owner to do?
How do I fit these activities to my project? [Tailoring]
In this activity, there are no shortcuts. Requirements development is a critical process for new systems. On small systems, the owner may be able to reduce the number of requirements documents by combining the system and sub-system requirements.
What should I track in this process step to reduce project risks and get what is expected? [Metrics]
On the technical side:
On the project management side:
Checklist: Are all the bases covered?
|Were the requirements documented?|
|Was a requirements walkthrough held to validate the requirements?|
|Was each requirement checked to see that it met all of the following?|
|- Necessary [trace to a user need]|
|- Concise [minimal]|
|- Feasible [attainable]|
|- Testable [measurable]|
|- Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]|
|- Unambiguous [Clear]|
|- Complete [function fully defined]|
|Was a verification case for each requirement developed? [test, demonstration, analysis, inspection]|
|Was each user need fully addressed by one or more system requirement(s)?|
|Is the requirement set complete? Have the following types of requirements been defined?|
|- Enabling [training, operations & maintenance support, development, testing, production, deployment, disposal]|
|- Non-functional [reliability, availability, safety, and security].|
|Were attributes [quality factors] assigned to each requirement [Priority, risk, cost, owner, date, and verification method]? Verification methods could include demonstration, analysis, test, and inspection.|
|Were the requirements reviewed and approved by the stakeholders and was a baseline [reference point for future decisions] established?|
|During this process step, were periodic reviews performed? Were the reviews done in accordance with the review plan documented in the SEMP?|
Are there any other recommendations that can help?
Requirements development activity
Give ample time to this activity. This is an area of high stakeholder involvement. This activity addresses risk early in the development cycle where the cost impacts are low; instead of later where the cost impacts are high.
Do not approve [Baseline] the requirements too early. Give ample time to develop a set of requirements that are complete and well written.
Once developed and approved, the requirements baseline will need to be managed using a change control process [See Chapter 3.7.3].
Changes [e.g. additions, changes or deletion of requirements] after the baseline has been established normally will mean a cost and/or schedule change. [Scope creep or loss of functionality]
Tools are essential in managing requirements on large ITS systems with hundreds of requirements. There are a number of tools that can help in the development of requirements. These tools manage the tracing of requirements, requirements attributes, and perform change management for requirements. For an extensive list of tools please see http://www.incose.org .
A closer look at attributes, baseline, and completeness of requirements:
Attributes are user-defined quality factors assigned to each requirement. Some of the more common attributes used are:
These attributes can help track the technical and project performance. Attributes help in sorting and monitoring requirements. Requirements management tools have features that allow for managing these attributes along with the requirements.
Requirements Baseline [reference point] — Has the requirements document been formally approved by the system owner and stakeholders? If so, all future development and project decisions are based on the requirements baseline. New requirements that are added, and existing ones that are changed or deleted, would be controlled closely using a change management process identified in the Configuration Management Plan. Once changes have been approved by the stakeholders, a new baseline would be established.
Completeness of requirements ensures that all aspects of user needs are completely defined by a set of requirements. There is a trap in looking at functions as "stove-pipes" in isolation of other functions. This may cause problems when the functions are integrated together.
One way to mitigate this is to make sure that all functions are thoroughly understood and that the analysis of requirements through decomposition integrates all required functions.