The systems engineering process is laid out in Chapter 3. This section discusses how to apply that process in three general cases- for low, medium, and high-risk projects, providing agency guidance for the tailoring of the different steps of the systems engineering process for the project
When tailoring the systems engineering process for different projects, a given step may be performed very informally (e.g., on the back of an envelope, or in an engineer’s notebook); on other projects, the activity may be performed very formally, with interim products under formal configuration control. This document is not intended to advocate any level of formality for the different levels of risk, but provide approaches that can be applied to relevant situations as applicable.
The systems engineering analysis
requirements identified in FHWA 23 CFR 940.11/FTA Policy Section VI allow the
systems engineering analysis effort to be tailored so that it is on a scale
commensurate with project scope.
INCOSE also stresses variation in the systems engineering process:
Like all processes, the Systems Engineering process at any company should be documented, measurable, stable, of low variability, used the same way by all, adaptive, and tailorable! This may seem like a contradiction. And perhaps it is. But one size does not fit all.
This
message is particularly important for ITS projects because so many of our
projects are smaller, less complex, less risky projects like signal system
upgrades. Even for small projects, you still should have documented
requirements, design, and verification procedures. Tailoring allows you to
adjust the amount of formal documentation and reviews and to focus the process
on those steps that are most critical to your project’s success. Ultimately,
you want to define a process that will address the project’s risks, no more and
no less, so a preliminary risk analysis is a good way to determine how much
process is appropriate.
The table below summarizes approaches for tailoring the process based on the three types of projects. These approaches should take into account your own environment, process requirements, and staff experience when you tailor the process for your own project. The best approach is to think about the risks of your particular project and determine how to best mitigate those risks with a tailored systems engineering process. Think about the process ahead of time and write down what you are going to do so that everyone on your team and your stakeholders understand and agree on the right steps to follow and the level of detail that is needed. Whether you call it a project plan, a systems engineering management plan (SEMP), or something else, it’s critical to put your process and your plan into writing. A further discussion of how a SEMP supports the management of a project in contained in Section 3.3.4.
Table 15: Tailoring the Systems Engineering Process
|
Process Step |
Low Risk Project |
Medium Risk Project |
High Risk Project |
|---|---|---|---|
|
Regional ITS Operations Planning (Regional ITS Architecture) |
Effort: None-low Existing architecture mapping applies |
Effort: Low Add new services or interfaces to existing mapping |
Effort: Low New mapping |
|
Feasibility Study, Concept Exploration |
Effort: None May be an existing study, but if not, none needed due to well understood system upgrade or expansion (e.g. a common low risk project) |
Effort: None No new feasibility study likely to be needed. |
Effort: Medium Depending on nature of risks, a concept exploration might be desirable that would survey existing system and alternatives |
|
Stakeholder Needs (Concept of Operations) |
Effort: None Existing ConOps should apply |
Effort: Low Depending on nature of risks, some new needs likely and should be defined. If an existing ConOps, it likely needs update. |
Effort: Medium If ConOps does not exist, one should be developed, or if one exists, it may need a more extensive update |
|
System Requirements |
Effort: None Existing SRS applies – review for any changes needed |
Effort: Medium Define new requirements either modifying existing SRS or creating a new one. |
Effort: Medium Develop requirements document and verification plan |
|
Design Definition |
Effort: None OTS products. Existing specs apply |
Effort: Low Limited design definition likely needed. Define project architecture illustrating any new interfaces. |
Effort: Medium Design definition needs to be developed, or if existing, updated. |
|
Implementation |
Effort: Low Purchase existing and previously documented HW/SW and Identify any configuration needed |
Effort: Low-Medium Purchase existing HW/SW that will be used in a way beyond current agency implementations.. Develop any custom SW |
Effort: Medium-High Develop Custom SW. Level of effort depends upon complexity of project and level of new development. |
|
Integration/Testing |
Effort: Low Verify factory tests performed. Verify devices and comm working. Reuse original procedures |
Effort: Medium Unit test custom SW. Checkout purchased HW and SW. Host/integrate custom SW on HW. New procedures for new capabilities. All documentation ready. |
Effort: Medium-High Tasks similar to Medium Notes, difference is in the level of effort based on complexity of project. |
|
Initial Deployment |
Effort: Low HW/SW previously used by the agency to address similar requirement, which has normal construction issues |
Effort: Low-medium Need system installed and configured, staff trained in operation |
Effort: Medium Need system installed and configured, staff trained in operation |
|
System Validation |
Effort: None System validation already performed |
Effort: Low-medium Validate new needs are met |
Effort: Medium Validate needs, performance, user and maintainer satisfaction |
Many of the projects in the Low to Medium risk category relate to deployment of ITS field devices that are readily available from many manufacturers. In these projects, the risk can often be addressed by proper bounding of the procurement process- ensuring that all needs and requirements are properly described and documented prior to procurement. These types of risks are particularly relevant when the agency is smaller or less experienced with ITS deployments. To help address these conditions, FHWA has developed a set of Model Systems Engineering documents which support procurement of the following field devices:
· CCTV
· Dynamic Message Signs
· Central Traffic Signal Systems (recently completed, but not yet available on line)
· Transportation Sensor & Detection System (TSDS) (currently under development)
These documents provide a set of sample statements that can be used to create SE documentation that supports deployment of these ITS systems. Specifically, the documents support development of the following SE documentation:
· Concept of Operations
· System Requirements
· Verification Plan
· Validation Plan
In addition, these Model SE documents provide suggested approaches for using the documentation to support the procurement of these systems, emphasizing the importance of defining key requirements as part of the procurement process.
