| Related: |  |
 |
|
OBJECTIVES |
· Develop a validated set of system requirements that meet the stakeholder’s needs. |
|---|---|
|
Description |
The stakeholder needs identified in the Concept of Operations are reviewed, analyzed, and transformed into verifiable requirements for the system. Working closely with stakeholders, the requirements are elicited, analyzed, validated, documented, and baselined. |
|
Context |
|
|
INPUT Sources of Information |
· Concept of Operations (Stakeholder Needs) · Functional requirements, interfaces, and applicable ITS standards from the regional ITS architecture · Applicable statutes, regulations, and policies |
|
PROCESS Key Activities |
· Elicit requirements · Analyze requirements · Document requirements · Validate requirements · Manage requirements · Define Acceptance Criteria |
|
OUTPUT Process Results |
· System Requirements Document · System Verification Plan · Traceability Matrix · System Acceptance Criteria |
The Electronics Industry Association (EIA) Standard 632, Processes for Engineering a System defines requirement as “something that governs what, how well, and under what conditions a product will achieve a given purpose.” This is a good definition because it touches on the different types of requirements that must be defined for a project. Functional requirements define “what” the system must do, performance requirements define “how well” the system must perform its functions, and a variety of non-functional environment requirements define “under what conditions” the system must operate.
One of the most important attributes of a successful project is a clear statement of requirements that meet the stakeholder’s needs. Unfortunately, creating a “clear statement of requirements” is often much easier said than done. The initial list of stakeholder needs will normally be a jumble of requirements, wish lists, technology preferences, and other disconnected thoughts and ideas. A lot of analysis must be performed to develop a good set of requirements from this initial list.
Needs are Satisfied: The key risk being managed is that the system defined will satisfy all the needs identified in the previous process. This ensures that the ITS project system requirements, i.e., how the project “works”, supports the selected project needs (traceability to needs), and conversely, that all project needs are supported by one or more system requirements. As described above the requirements should address the functions to be performed by the system, how well the system performs these functions, and the conditions under which the functions must be performed.
The basic activities of requirements definition are shown in Figure 14 and include the basic steps of elicitation, analysis, documentation, validation, and management. The actual approach taken to performing these steps will vary by organization and project. There isn’t one “right” approach for requirements development. Different organizations develop requirements in different ways. Even in the same organization, the requirements development process for a small ITS project can be much less formal than the process for the largest ITS projects that specify complex hardware/software systems. The differences are primarily in the details and in the level of formality.
Figure 14: Requirements Definition Activities
(Source: FHWA)
Note that each of these activities shown in the figure can be highly iterative. In the course of a day, a systems engineer may do a bit of each of the activities as a new requirement is identified, refined, and documented.
Elicit Requirements – Building on the stakeholder needs and other input such as the functional requirements from the regional ITS architecture, and any relevant statutes, regulations, or policies, define a strawman set of system requirements and review and expand on these requirements, working closely with the project stakeholders. There are many different elicitation techniques that can be used including interviews, scenarios (see discussion under the Concept of Operations), prototypes, facilitated meetings, surveys, and observations. Each of these techniques can be used in combination to discover the stakeholder’s requirements.
As part of this step, the requirements developers should identify the classes of requirements that will be the subject of their effort:
Elicit and elicitation are words you may not run into every day. Elicit means to draw forth or to evoke a response. This is the perfect word to use in this case because you have to do some work to draw out the requirements from the stakeholders and any existing documentation. More work is implied by “elicit requirements” than if we said “collect requirements” or even “identify requirements”, and this is intended.
Having the right stakeholders involved can
make or break a requirements development effort. It isn’t enough to make sure
the right organizations are involved. You should ensure that the right
individuals within those organizations are involved. For example, it isn’t
enough to engage someone from the maintenance organization – it should be an
electrical maintenance person who has experience with ITS equipment maintenance
for ITS projects. Finding individuals with the right combination of knowledge
of current operations, vision of the future system, and time to invest in
supporting requirements development is one of the key early challenges in any
requirements development effort.
Analyze Requirements – The stakeholder requirements that are elicited are analyzed in detail and the stakeholders negotiate to select the requirements that must be implemented and priorities may be assigned to the requirements. This is where the requirements are cleaned up – conflicts are resolved, gaps are identified and addressed, ambiguity and redundancy are removed, and the requirements are organized and decomposed into more specific supporting requirements.
For larger systems, it can be very difficult to
“get your arms around” all of the requirements. Requirements modeling tools
provide a graphical way to define requirements so that they are easier to
understand and analyze. Tools range from simple repositories that allow you to
manage your requirements and traceability to user needs and design elements to
full-featured requirements management systems that store many attributes for
each requirement that allow you to track requirements changes, supporting
baseline management over the life of the project. These tools are particularly
useful for more complex ITS projects.
There are numerous requirements modeling tools
and techniques available that can help you model the system as part of the
analysis process. These tools support a variety of development methodologies
(e.g. agile) and can range from simple database extensions to applications that
support development of system models from different perspectives, fully
integrate diagrams and text and will support creation of documentation of the
requirements.
INCOSE and the Object Management Group
(OMG) have collaborated on a standard System Modeling Language (SysML) that is
an extension of the Universal Modeling Language (UML) specifically to support
SE. INCOSE maintains a data repository of available modeling tools that is
available on their web site. These tools do require effort (possibly
significant in the case of the most complete applications) to set up and
maintain, so their use is likely justified only in the largest ITS projects.
Document Requirements – The requirements are documented in a well-organized and approachable fashion so that the system stakeholders and system development team can all easily understand and review the requirements. Normally, a combination of plain language and diagrams are used to define the requirements.
The level of detail needed in the requirements definition phase can depend on later design choices. For example, planning to use a proven off-the-shelf solution for a component of the project design may mitigate the need for detailed requirements analysis of the selected solution. In this case only higher-level requirements covering the overall selected solution may be sufficient.
If requirements for a project are identical to requirements for a prior project – those requirements can be referenced and not necessarily redeveloped. Note that because requirements are generally technology neutral, the design for reused requirements (using newer and current technology) may still be necessary.
As the requirements are documented, a plan for verifying the system based on the requirements is defined. A verification method is identified for every requirement – normally you select one of four fundamental ways to verify each requirement: Test, Demonstration, Inspection, or Analysis. The purpose of this early assignment, long before the requirements will actually be verified, is to make sure the requirements author thinks about how the requirement will be verified from the very start. Only verifiable requirements should find their way into the system requirements.
The method of verification is only one of the
attributes that should be tracked for each requirement. A rich set of
attributes is particularly important for large complex projects. Consider
specifying attributes like the following for each of your requirements if you
are developing a large complex project: Source, author, creation date, change
history, verification method, priority, and status. The historical and change
tracking attributes are particularly important since they allow management to
measure and track requirements stability.
Traceability is another important aspect of the requirements documentation. Each requirement should trace to a higher-level requirement, a stakeholder need or other governing rules, standards, or constraints that the requirement is derived from. As the project is developed, each requirement will also be traced to the verification test case that will verify the requirement, more detailed “child” requirements that may be derived from it, and design elements that will implement the requirement, as applicable. Establish and populate the traceability matrix at this stage and then continue its population during development; don’t wait until the end.
Validate Requirements – The documented requirements are carefully checked for consistency, accuracy, and completeness. Also check for “compound requirements”, which are requirements that contains two or more statements, each of which is a distinct requirement with its own individual verification path. This is a critical step that is intended to identify requirements defects as early in the process as possible when correcting defects is most economical. To support validation, requirements walkthroughs are held to review the requirements in a systematic way with the project stakeholders and project team.
Table 5 identifies an oft-repeated list of attributes of good requirements. As part of the validation process, you do your best to make sure that the requirements have all of these desired attributes. Unfortunately, computers today can only do a fraction of this validation and people have to do the rest. Techniques for validating a requirement against each of these quality attributes are also shown in Table 5. An attribute list like this can be converted into a checklist that prompts reviewers to ask themselves the right questions as they are reviewing the requirements.
Table 5: Validating Quality Attributes of Good Requirements
|
Quality Attribute |
Validate By: |
|---|---|
|
Necessary |
Make sure that each requirement traces to a stakeholder need or a parent requirement. A computer can check that the traceability is complete, but people have to verify that the identified traces are valid. |
|
Clear |
Look for red flag words and constructs in the requirements e.g. “user friendly”, “optimum”, “real-time”, “and/or”, “etc.”. The vast majority of this aspect of validation relies on walkthroughs and other reviews to make sure the requirements aren’t subject to different interpretations. The main culprit here is ambiguity in the English language. One of the most common findings during a walkthrough is that the wording of a requirement is not clear to all the stakeholders, a condition that can usually be resolved by rewording of the requirement |
|
Complete |
Does every stakeholder or organizational need trace to at least one requirement? If you implement all of the requirements that trace to the need, will the need be fully met? A computer can answer the first question, but only stakeholder(s) can answer the last. |
|
Correct |
In general, it takes a walkthrough to verify that the requirements accurately describe the functionality and performance that must be delivered. Only the stakeholders can say whether the highest-level system requirements are correct and consistent. Traceability can assist in determining the correctness of lower level requirements. If a child requirement is in conflict with a parent requirement, then either the parent or child requirement is incorrect. |
|
Feasible |
Again, this must be determined by review and analysis of the requirements. A computer can help with the analysis and possibly even flag words like “instant” or “instantaneous” that may be found in infeasible requirements, but a person ultimately makes the judgement of whether the requirements are feasible. In this case, it is the developer who can provide a reality check and identify requirements that may be technically infeasible or key cost drivers early in the process. |
|
Verifiable |
Does the requirement have a verification method assigned? (This is something the computer can check.) Is the requirement really stated in a way that is verifiable? (This much more difficult check can only be performed by people.) For example, ambiguous requirements are not verifiable. |
Manage Requirements – Processes and tools are established to manage the requirements and associated information that is collected, track changes to the requirements, and provide facilities that support traceability, requirements retrieval and reporting, etc.
Like the other requirements engineering
activities, the requirements management capabilities should be scaled based on
the complexity and size of the ITS project. Large complex ITS projects can
benefit from a tool specifically for requirements management such as DOORS or
Requisite-Pro. Requirements for smaller scale ITS projects can easily be
managed with a general-purpose database like Microsoft Access. A professional
requirements management tool includes a long list of capabilities including
change management, requirements attributes storage and reporting, impact
analysis, requirements status tracking, requirements validation tools, access
control, and more. Whether simple or sophisticated, every project should have
some means of managing their requirements baseline.
No matter how you developed your requirements, you must document them in some consistent, accessible, and reviewable way. The requirements development process may result in several different levels of requirements over several steps in the “Vee” – stakeholder requirements, system requirements, subsystem requirements, etc. that may be documented in several different outputs. For example, stakeholder requirements might be documented in a Concept of Operations in a series of Use Cases, system requirements may be documented in a System Requirements Specification, and subsystem requirements may be documented in subsystem specifications. Ideally, all of these requirements are managed in a single repository that can be used to manage and publish the requirements at each stage of the project.
It is much easier to use a standard template for
the requirements than it is to come up with your own, and numerous standard
templates are available. If your organization does not have a standard
requirements template, then you can start with a standard template like the one
contained on this website (see Section 6.5 for the Requirements Template) or
ISO/IEC/IEEE 29148:2018, Systems and software engineering - Life cycle
processes - Requirements engineering. Starting with a template saves time and
ensures that the requirements specification is complete. Of course, the
template can be modified as necessary to meet the needs of the project.
Another good starting point is a model document. FHWA has developed a set of model documents around systems that are commonly deployed around the country. Currently there are several published model documents:
· Model Systems Engineering Documents for Central Traffic Signal Systems, FHWA-HOP-19-019
· Model Systems Engineering Documents for Adaptive Signal Control Technology (ASCT) Systems, FHWA-HOP-11-027
· Model Systems Engineering Documents for Dynamic Message Sign (DMS) Systems, FHWA-HOP-18-080
· Model Systems Engineering Documents for Closed Circuit Television (CCTV) Systems, FHWA-HOP-18-060
Each is available in HTML or PDF from https://ops.fhwa.dot.gov/publications/publications.htm.
A set of system requirements should fully specify the function, performance, and environmental characteristics of the system to be developed. The requirements document should include the following information:
· System boundary with interfacing systems clearly identified
· External interface requirements for interfacing with other systems and people
· Functional requirements and associated performance requirements
· Cybersecurity requirements
· Environmental requirements (physical as well as technology environment if appropriate)
· Lifecycle process requirements supporting production, deployment, transition, operations and maintenance, change and upgrade, and retirement/replacement, as applicable. Possibly including cost requirements of each or some of the stages of the lifecycle.
· Staffing, human factors, safety, and security requirements.
· Physical constraints (weight, form factors).
Define Acceptance Criteria- As a part of this step, the acceptance criteria are identified and documented. Acceptance is the final step taken before the system initial deployment is undertaken. One of the key aspects of Acceptance Criteria is successful verification of the system against the Verification Plan. However, the acceptance step may include additional criteria, such as a period of successful operations by the agency operation staff. Depending on the scope and complexity of the project, the Acceptance Criteria may be defined in a separate document, or included in the Verification Plan.
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. For systems that are being expanded, the initial set of requirements may be sufficient to support the expansion, but any existing requirements should be reviewed to see if they completely address all the needs. Finally, if the project relates to the devices covered by Model SE documents, then those documents may be an excellent source of requirements that can be tailored to the specific project.
The FHWA Regulation requires that requirements be developed for ITS projects funded with the Highway Trust Fund, including the Mass Transit Account. ISO 29148 describes the processes and products related to requirements engineering for systems and software.
The key artifact determined by the System Requirements development process are the Requirements, identified in Table 6 with their backward and forward traceability to other process artifacts or external documents.
Table 6: Stakeholder Requirements Traceability
|
Traceable Artifacts |
Backward Traceability To: |
Forward Traceability To: |
|---|---|---|
|
System Requirements |
Needs in the Concept of Operations |
· High-Level Design Modules · Low-Level Design Specifications · System Verification Tests |
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Were the requirements documented?
R Was a requirements walkthrough held to validate the requirements?
R Was each requirement checked to see that it met all of the following?
R Necessary [trace to a user need]
R Concise [minimal]
R Feasible [attainable]
R Testable [measurable]
R Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
R Unambiguous [Clear]
R Complete [function fully defined]
R Was a verification case for each requirement developed? [test, demonstration, analysis, inspection]
R Was each user need fully addressed by one or more system requirement(s)?
R Is the requirement set complete? Have the following types of requirements been defined?
R Functional
R Performance
R Enabling [training, operations & maintenance support, development, testing, production, deployment, disposal]
R Data
R Interface
R Environmental
R Non-functional [reliability, availability, safety, and security].
R 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.
R Were the requirements reviewed and approved by the stakeholders and was a baseline [reference point for future decisions] established?
R During this process step, were periodic reviews performed? Were the reviews done in accordance with the review plan documented in the SEMP?
| Related: | |
|
