T3 Webinar:

ITS Systems Engineering (SE) for ITS:
Using FHWA's New SE Handbook

Webinar File(s)

• PowerPoint® presentation used in webinar
• PowerPoint® presentation used in webinar (text version)
• Transcript of Question and Answer discussion (post-presentation)

Back to T3 Archive front page

Text version of the PowerPoint presentation. Description of image or images on a slide contained in brackets.

Systems Engineering (SE) for ITS: Using FHWA's New SE Handbook — March 2007

[A photo of each presenter appears.]

Emiliano Lopez
FHWA Office of Transportation Management
(202) 366-2199
Emiliano.Lopez@fhwa.dot.gov

Mac Lister
FHWA Resource Center
(708) 283-3532
Mac.Lister@fhwa.dot.gov

Who's Participating in this T3?
(Please reply with the most appropriate answer:)

• Local/municipal agency
• State agency
• Federal agency
• Education
• Other

Chances are that you already use some form of SE practice, but we would like to know your level of familiarity with SE.

(Please reply with the most appropriate answer:)

• I am not familiar with SE.
• I have heard of SE.
• I am familiar with some SE concepts.
• I have started using some SE methods.

Have you looked at or read the FHWA SE for ITS Handbook?

(Again, please reply with the most appropriate answer:)

• No
• I am aware of the Handbook
• I have glanced at the Handbook
• I have read portions of the Handbook
• I have read most of the Handbook

• Learning goals/outcomes
• New SE for ITS Handbook
• Benefits of using SE
• "V" Model
• Overview of Handbook chapters
• Available SE training & resources

• Identify what is in the Handbook
• Describe the key features of the Handbook
• List key content chapters in the Handbook including:
  • technical processes
  • project management processes
  • applying SE

• About the Handbook
  • Developed by FHWA SE Deployment Team
  • Designed for Federal and public ITS professionals
  • Provides a basic understanding of SE and how to apply it to ITS projects
  • Assists those deploying ITS projects
  • Available via CD and online using the following link: http://ops.fhwa.dot.gov/publications/seitsguide/index.htm

• Reduced risk of schedule and cost overruns
• Increased likelihood that the implementation will meet user's needs
• Improved stakeholder participation
• More adaptable and resilient systems
• Verified functionality and fewer defects
• Higher level of reuse from one project to the next
• Better documentation

[Pie chart that shows success rates for IT projects across all industries. Chart shows that 15% of projects failed; 51% of projects were challenged; 34% of project succeeded. ]

The systems engineering analysis shall include, at a minimum:

1. Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture)
2. Identification of participating agencies roles and responsibilities
3. Requirements definitions
4. Analysis of alternative system configurations and technology options to meet requirements
5. Procurement options
6. Identification of applicable ITS standards and testing procedures
7. Procedures and resources necessary for operations and management of the system

• FHWA representation of SE methods
• Representation of system development process
• Addresses the project lifecycle
• Aligns with the traditional project development process

[This slide shows the V Model. The V Model resembles the letter "V" with the addition of two wings extending from the top left and right of the V. The V is divided into 14 steps, beginning on the top left wing and ending at the right wing. The steps are in sequence and extend down the left side of the V, to the bottom of the V, and up the right side of the V. The steps, from left to right are:]

• Regional Architecture(s) (the lone step on the left wing)
• Feasibility Study/Concept of Exploration
• Concept of Operations
• System Requirements
• High-level Design
• Detailed Design
• Software/Hardware Development and Field Testing (the step at the bottom of the V)
• Unit/Device Testing
• Subsystem Verification
• System Verification & Deployment;
• System Validation
• Operations and Maintenance
• Changes and Upgrades (the first step on the right wing) and Requirements/Replacement (the last step on the right wing and last step on the V Model).

[Opposite the steps running down left side of the V is an arrow "Decomposition and Definition." Along the bottom of the V is an arrow "Timeline." Running up, along the right side of the V, is an arrow "Integration and Recomposition." Finally, arrows within the V connect steps on the left and right sides of the V, indicating a validation process of a left side step that take place in a right side step. From top to bottom:]

• Concept of Operations (step)-System Validation Plan--System Validation (step)
• System Requirements (step)-System Verification Plan-System Verification and Deployment
• High-Level Design-Subsystem Verification Plan-Subsystem Verification
• Detailed Design-Unit/Device Test Plan-Unit/Device Testing

[This slide displays the overlap between the traditional transportation project model and the V Model. Across the top of the slide, the steps to the traditional model appear from left to right. The steps are:]

• Transportation Planning
• Programming/Budgeting
• Project Initiation
• Preliminary Engineering
• Plans, Specifications & Estimates
• Construction
• Project Closeout
• Operations & Maintenance
• Changes & Updates
• Retirement/Replacement.

[Below the traditional model appears the V Model. The V Model resembles the letter "V" with the addition of two wings extending from the top left and right of the V. The V is divided into 14 steps, beginning on the top left wing and ending at the right wing. The steps are in sequence and extend down the left side of the V, to the bottom of the V, and up the right side of the V. The steps, from left to right are:]

• Regional Architecture(s) (the lone step on the left wing)
• Feasibility Study/Concept of Exploration
• Concept of Operations
• System Requirements
• High-level Design
• Detailed Design
• Software/Hardware Development and Field Testing (the step at the bottom of the V)
• Unit/Device Testing
• Subsystem Verification
• System Verification & Deployment; System Validation
• Operations and Maintenance
• Changes and Upgrades (the first step on the right wing) and Requirements/Replacement (the last step on the right wing and last step on the V Model).

[Opposite the steps running down left side of the V is an arrow "Decomposition and Definition." Along the bottom of the V is an arrow "Timeline." Running up, along the right side of the V, is an arrow "Integration and Recomposition."]

[Finally, four broken lines drop from the traditional model at the top of the slide to various steps on the V Model, indicating the parallel processes on both models. A line drops from Project Initiation on the traditional model to Concept of Operations on the V Model; from Preliminary Engineering to Systems Requirements; from Plans, Specifications, and Estimates to Software/Hardware Development and Field Testing; and from Construction to System Validation.]

[The cover of the handbook appears: "Systems Engineering for Intelligent Transportation Systems — An Introduction for Transportation Professionals". An image of the "V" model, described in a previous slide, is superimposed over a transportation photo collage. The date on the cover is January 2007. The report is the product of the United States Department of Transportation's Federal Highway Administration/Federal Transit Administration.]

• Based on project level efforts
• Focused on 3 primary Activities
  • Developing the right system
    • Based on user needs
  • Managing ITS elements on the project
    • Stay on time and on budget
  • Applying SE to projects
• Modular to address different knowledge needs
• Navigating the Document
• Innovative use of icons
  • Tips
  • Cautions
  • Resources
  • Tailoring
  • Tool
  • Rule/Policy
  • Terminology

[Slide shows first three chapters. Chapters provide general information on who the book was written for and how to use it. It also gives general knowledge on systems engineering and its benefits.]

Table of Contents (page i, Chapters 1–3

1		INTRODUCTION		page 1
		1.1	Purpose	page 1
		1.2	Intended Audience	page 1
		1.3	Navigating the Document	page 1
		1.4	About the Icons	page 2
2		WHY USE SYSTEMS ENGINEERING?		page 3
		2.1	Value of Systems Engineering	page 3
		2.2	US DOT Policy	page 4
3		WHAT IS SYSTEMS ENGINEERING?		page 5
		3.1	A Few Definitions	page 5
		3.2	Key Principals	page 6
		3.3	The "V" Systems Engineering Model	page 10

[Slide shows image of the Systems Engineering Handbook Table of Contents. Three chapters are highlighted and the objective of each is defined. Chapter 4 — ITS Technical Processes ("Building it right"); Chapter 5 — ITS Project Management Processes ("On time, on budget"); Chapter 6 — Apply Systems Engineering.]

[Slide shows the Table of Contents for Chapter 4:]

Technical Processes

4		ITS TECHNICAL PROCESSES		page 13
		4.1	Using the Regional ITS Architecture	page 13
		4.2	Feasibility Study/Concept Exploration	page 20
		4.3	Concept of Operations	page 26
		4.4	System Requirements	page 33
		4.5	System Design	page 43
		4.6	Software/Hardware Development and Testing	page 54
		4.7	Integration and Verification	page 59
		4.8	Initial Deployment	page 65
		4.9	System Validation	page 70
		4.10	Operations and Maintenance	page 75
		4.11	Retirement/Replacement	page 80

[The subsections of chapter 4 correspond to the processes depicted in the "V" model.]

• Explains SE through use of the"V"
  • Objectives
  • Inputs (Things needed to begin this step)
  • Processes (key activities)
  • Outputs (Deliverables)
  • Reviews (when it's safe to move the project forward)
• Aids in project definition, specification, design and build
• Includes examples of SE documentation

[Slide shows the V Model with circles around the steps on the left and right wings indicating steps that are tied to the life cycle. This indicates how the system will be operated and maintained will have a significant impact on what system requirements will need to be specified and what equipment selected.]

[Slide shows an example of a Summary Chart for the Concept of Operations section (step) in Chapter 4. A Summary Chart provides objectives, inputs, outputs, key activities, and technical review elements for each step in the V model. A quick high-level overview of the SE technical processes by going through Chapter 4 and reading these summary charts.]

[Text on Summary Chart:]

OBJECTIVES	High-level identification of user needs and system capabilities in terms that all project stakeholders can understand Stakeholder agreement on interrelationships and roles and responsibilities for the system Shared understanding by system owners, operators, maintainers, and developers on the who, what, why, where, and how of the system Agreement on key performance measures and a basic plan for how the system will be validated at the end of project development
INPUT Sources of Information	Stakeholder lists, roles and responsibilities, and other components from the regional ITS architecture Recommended concept and feasibility study from the previous step Broad stakeholder input and review
PROCESS Key Activities	Identify the stakeholders associated with the system/project Define the core group responsible for creating the Concept of Operations Develop an initial Concept of Operations, review with broader group of stakeholders, and iterate Define stakeholder needs Create a System Validation Plan
OUTPUT Process Results	Concept of Operations describing the who, what, why, where, and how of the project/system, including stakeholder needs and constraints System Validation Plan defining the approach that will be used to validate the project delivery
Review Proceed only if you have:	Received approval on the Concept of Operations from each stakeholder organization Received approval on the System Validation Plan from each stakeholder organization

• Input
  • Feasibility Study
  • Stakeholder input and review
• Processes
  • Develop an initial ConOps
  • Define stakeholder needs
  • Develop an initial validation plan
• Output
  • System Validation Plan
  • ConOps
• Review
  • Approved ConOps and Validation Plan

[Slide shows the Handbook's use of Operational Scenarios. Operational scenarios describe needed system functionality in an operational setting and focus on the functions the system must perform in order to satisfy the needs of the users. The operational scenario displayed on the slide is the following:]

Marcel, a StarTran bus operator, usually begins his work shift with administrative activities. After receiving supervisory direction, he boards the bus and prepares the AVL system. He begins by logging into the system.

The system then prompts Marcel for the route to be followed. He enters the planned route number, and the AVL system retrieves the appropriate route and schedule information from the AVL system server. The bus' AVL system then asks Marcel to verify the appropriate route and schedule information were properly retrieved.

Once he provides verification, the bus' head sign is automatically updated to reflect the appropriate route information. The fare payment schedule is automatically adjusted to reflect the verified route, modified as necessary by the system clock to reflect any applicable time-differential rates.

The system then loads the appropriate bus stop announcements for the chosen route. These prerecorded announcements are consistent regardless whether Marcel or another bus operator is driving the route, and have been verified as ADA compliant. These announcements are then broadcast at the appropriate bus stop throughout the route.

[Slide shows the Summary Chart at the beginning of the Systems Requirements section of in Chapter 4 of the Handbook. On the slide, the Concept of Operations, developed in the previous step, is circled in red, highlighting that it is an input to the System Requirements.]

[Text on Summary Chart:]

OBJECTIVES	Develop a validated set of system requirements that meet the stakeholders' needs
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 Constraints (required legacy system interfaces, hardware/software platform, etc.)
PROCESS Key Activities	Elicit requirements Analyze requirements Document requirements Validate requirements Manage requirements Create a System Verification Plan Create a System Acceptance Plan
OUTPUT Process Results	System Requirements document System Verification Plan Traceability Matrix System Acceptance Plan
Review Proceed only if you have:	Received approval on the System Requirements document from each stakeholder organization, including those that will deploy, test, install, operate, and maintain the new system Received approval on the System Verification Plan from the project sponsor, the test team, and other stakeholder organizations Received approval on the System Acceptance Plan from the project sponsor, the Operations & Maintenance (O&M) team, and other stakeholder organizations

• Input
  • Concept of Operations (stakeholder needs)
• Processes
  • Develop requirements from user needs
  • Review and refine user needs
  • Trace requirements to user needs
• Output
  • System Requirements Document
  • Traceability Matrix
• Review
  • Approve system requirements

[This slide displays an example of how the Handbook offers guidance on preparing good system requirements. An attribute list like the one displayed on the slide can be converted into a checklist that prompts reviewers to ask themselves the right questions as they are reviewing the requirements.]

[Text on attribute list:]

Validating Quality Attributes of Good Requirements

Quality Attribute	Validate by:
Necessary	Make sure that each requirement traces to either a stakeholder need in the ConOps 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	Some requirements management tools can help with this by looking for red-flag words and constructs in the requirements (e.g., "user friendly", "optimum", "real-time", pronouns, and complex sentences). Most 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.
Complete	Does every stakeholder or organizational need in the ConOps 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 second.
Correct	In general, it takes a walkthrough to verify that the requirements accurately describe the functionality and performance that must be delivered. The stakeholders must validate that the highest-level system requirements are correct. 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 the 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 judgment 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. Since system performance is dependent on system design and technology choices, requirements feasibility will continue to be monitored and addressed as the system design is developed.
Verifiable	Does the requirement have a verification method assigned? (This is something a 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.

[This slide displays a System Design Summary Chart. On the slide, several items are circled in red, highlighting that they compliment traditional project development and deployment process. The circled steps on the slide are in bold text on the following table:]

[Text on System Design Summary Chart:]

OBJECTIVES	Produce a high-level design that meets the system requirements and defines key interfaces, and that facilitates development, integration, and future maintenance and upgrades
INPUT Sources of Information	Concept of Operations System Requirements document Off-the-shelf products Existing system design documentation ITS standards Other industry standards
PROCESS Key Activities	Evaluate off-the-shelf components Develop and evaluate alternative high-level designs Analyze and allocate requirements Document interfaces and identify standards Create Integration Plan, Subsystem Verification Plans, and Subsystem Acceptance Plans Develop detailed component-level design specifications
OUTPUT Process Results	Off-the-shelf evaluation and alternatives summary reports High-level (architectural) design Detailed design specifications for hardware/software Integration Plans, Subsystem Verification Plans, Subsystem Acceptance Plans, and Unit/Device Test Plans
Review Proceed only if you have:	Approved high-level design for the project Defined all system interfaces Traced the system design specifications to the requirements Approved detailed specifications for all hardware/software components

• The Systems Requirements Document is an input from the previous step.
• Developing design models and specifications are similar to doing final design and engineering for a road and bridge project. In these phases, preliminary documents are refined into detailed project documentation.
• Just like roadway plans and specifications, these documents need to convey correctly project expectations to the contractor.
• Also like road and bridge contract documentation, methods of inspection and testing are identified for the system. Systems Engineers call this process system verification, but the point is the same. The work needs to be verified to make sure that it meets the system design and specifications.

• Leverage and optimize prior work
  • Reuse and build on existing design documentation
  • Update old documentation with new functionality or interfaces
• Do not reinvent the wheel for each project

[This slide displays the a Summary chart showing both the System Verification and Subsystem Verification steps of the V. The slide shows that outputs from the previous steps appear as inputs to this step.]

OBJECTIVES	Integrate and verify the system in accordance with the high-level design, requirements, and verification plans and procedures Confirm that all interfaces have been correctly implemented Confirm that all requirements and constraints have been satisfied
INPUT Sources of Information	System Requirements document High-level design specifications Detailed design specifications Hardware and software components Integration plan System and Subsystem Verification Plans Subsystem Acceptance Plans
PROCESS Key Activities	Add detail to integration and verification plans Establish integration and verification environment Perform integration Perform verification
OUTPUT Process Results	Integration plan (updated) Verification plan (updated) Integration test and analysis results Verification results, including corrective actions taken
Review Proceed only if you have:	Documented evidence that the components, subsystems, and system meet the allocated requirements Documented evidence that the external and internal interfaces are working and consistent with the interface specifications

• Input
  • Design specifications
  • Verification Plans
• Key Activities
  • Perform verification
  • Perform integration
• Output
  • Integration testing and analysis results
  • Verification results including problem resolutions
• Review
  • Documented evidence that the system meets requirements

• The systems engineering analysis requirements identified in FHWA Rule 940.11/FTA Policy Section VI require identification of testing procedures; verification procedures described in the Handbook cover this.
• Verification Techniques
  • Inspection
  • Demonstration
  • Test
  • Analysis

[This slide shows examples of system verification plans. System verification should be traceable back to individual system requirements or software requirements.]

Verification Procedure Example: ODOT TripCheck Functional Test Plan (Excerpt)

STEP	INPUT	SCRIPT	EXPECTED RESULT
1	None	Test winter travel links
1.a		Select Chain Laws	Opens: Pages/RCMap.asp?curRegion=ChainLaws
1.b		Select Traction Tires	Opens: Pages/RCMap.asp?curRegion=TractionTires
1.c		Select Minimum Chain Requirements	Opens: Pages/RCMap.asp?curRegion=MinChainReqs
2	None	Test related links	Each link opens a browser window with an external URL

CHART II Integration Test Plan (Excerpt)

Test ID: General 1
Purpose: To show that a valid username/password is accepted for logging in to CHART II within 15 seconds, and that an invalid combination is rejected. In addition, this test case also demonstrates that the system returns control to the user and the user is not prevented from performing activities in other windows on the desktop. CHART-27, CHART-10, CHART-21, CHART-275, CHART-276, CHART-29, CHART-26			Test Start Date:
Test Pre-Conditions: This test assumes a valid username and password of a user in the CHART2 system is known.			Test End Date:
Test Step No.	Test Steps	Expected Behavior	Results As Expected (Y/N)	Comments
1	Click on the Login button on the GUI toolbar.	An hourglass should display immediately, within 5 seconds, till the login window is displayed. Then, you should be prompted for a UserID and password.
2	Attempt to login with an invalid username or password.	The system should popup an error message indicating that an invalid user ID or password was specified.
3	Attempt to login with the valid UserID and password.	The system should indicate that the user is logged in by showing Operations Center:Username on the GUI toolbar window.
4	Click on Navigator	Navigator window is opened.
5	Click on DMS node	List of DMSs is displayed on the right hand side of the Navigator.

ODOT TripCheck 2.0 System Test Results (Excerpt)

DESCRIPTION OF TEST	INPUT DATA	EXPECTED RESULTS	ACTUAL RESULTS
1 Enter an incident of type Herbicide Application.	An incident of type Herbicide Application.	Does not appear in TripCheck.	As expected, incident did not go into the transaction table.
2 Enter an incident that is then put on hold.>	An incident that is on hold.	Does not appear in TripCheck.	When incident is put on hold a delete transaction is entered in the shadow table. An error occurred with this delete transaction and the incident remained on TripCheck.
3 Put the incident from step 2 back into active status in HTCRS.		Incident is on TripCheck.	As expected.

[This slide displays the Table of Contents for Chapter 5 of the SE Handbook.]

Table of Contents — Project Management Processes

5		ITS PROJECT MANAGEMENT PROCESSES		page 83
		5.1	Project Planning	page 83
		5.2	Project Monitoring and Control	page 85
		5.3	Risk Management	page 88
		5.4	Configuration Management (CM)	page 91

• Cross-cutting/project-wide processes
  • Project Planning
  • Project monitoring and control
    • Risk management
    • Configuration management

• Project Plan (Section 5.1.1)
  • Accounts for project activities, resources & budget
  • Includes project time-line
  • A "how-to" implementation manual
• SE Management Plan (Section 5.1.3)
  • Top level plan for the SE activities
  • Includes technical planning and control

• Project Tracking (Section 5.2.1)
  • Methods for measuring progress against the plans/contract
  • Serves as a trend indicator for meeting budget and schedule
• Project Reviews (Section 5.2.2)
  • Structured and organized communication of progress and product development
    • Formal or informally done
    • Typically conducted at the end of a V phase and before beginning the next phase

(Table 19) Risk Prioritization

		Probability of Occurrence
		High	Medium	Low
Severity of Impact	High	A	B	C
	Medium	D	E	F
	Low	G	H	I

(Table 10) Traceability of Work Products

Requirement Source	System Requirement	High-Level Design Component	Code Unit	Test Case
UN1.1	R00220	7.2.3	System Monitor	UT 4.2
	R00330	7.3.1	CalcVolume	UT 5.5
	R00331	7.3.1	CalcCount

(Figure 33) Operations & Maintenance Planning

• Document Maintenance and Operations Activities
• Develop and Maintain a Cost Database for Maintenance and Operations
• Analyze Maintenance and Operations Requirements
• Analyze Staffing Requirements for Maintenance and Operations
• Develop a Training Program for Maintenance and Operations Personnel
• Prioritize Maintenance Needs
• Develop and Maintain a Spare Parts Inventory
• Develop a Maintenance Plan
• Develop an Operations Manual

Table of Contents — Applying Systems Engineering

6		APPLYING SYSTEMS ENGINEERING		page 94
		6.1	The Traditional Project Life Cycle and Systems Engineering	page 94
		6.2	Applying Systems Engineering on Your Project	page 97
		6.3	Applying Systems Engineering in Your Organization	page 105

• Tailoring SE for your project
  • Enhances current project delivery practices
  • Helps focus on risky project steps
  • Allows selection of "as-needed" project deliverables and processes
  • Not an opportunity to skip steps!
    • Even the small projects need documented expectations

• Include experienced Systems Engineers on each ITS project
• Adopt a defined organizational process for SE
• Acquire SE tools to help manage the process

• Develop repeatable processes
  • Incorporate SE into existing business processes and practices
• Hold post project reviews to assess the application of SE (what worked — what needs to be refined)
• Modify processes based on lessons learned

A quotation appears at the bottom of the slide: "The quality of a product is largely determined by the quality of the process that is used to develop and maintain it." – Shewart, Juran, Deming, and Humphrey

[This slide displays the overlap between the traditional transportation project model, previously described on Slide 14. Across the top of the slide, the steps to the traditional model appear from left to right. The steps are:]

• Transportation Planning
• Programming/Budgeting
• Project Initiation
• Preliminary Engineering
• Plans, Specifications & Estimates
• Construction
• Project Closeout
• Operations & Maintenance
• Changes & Updates
• Retirement/Replacement.

[This slide appears to recap the information already presented. On this slide, it is the same information already discussed on Slide 14.]

[This slide displays the overlap between the traditional transportation project model and the V Model. Across the top of the slide, the steps to the traditional model appear from left to right. The steps are:]

• Transportation Planning
• Programming/Budgeting
• Project Initiation
• Preliminary Engineering
• Plans, Specifications & Estimates
• Construction
• Project Closeout
• Operations & Maintenance
• Changes & Updates
• Retirement/Replacement.

[Below the traditional model appears the V Model. The V Model resembles the letter "V" with the addition of two wings extending from the top left and right of the V. The V is divided into 14 steps, beginning on the top left wing and ending at the right wing. The steps are in sequence and extend down the left side of the V, to the bottom of the V, and up the right side of the V. The steps, from left to right are:]

• Regional Architecture(s) (the lone step on the left wing)
• Feasibility Study/Concept of Exploration
• Concept of Operations
• System Requirements
• High-level Design
• Detailed Design
• Software/Hardware Development and Field Testing (the step at the bottom of the V)
• Unit/Device Testing
• Subsystem Verification
• System Verification & Deployment; System Validation
• Operations and Maintenance
• Changes and Upgrades (the first step on the right wing) and Requirements/Replacement (the last step on the right wing and last step on the V Model).

[Opposite the steps running down left side of the V is an arrow "Decomposition and Definition." Along the bottom of the V is an arrow "Timeline." Running up, along the right side of the V, is an arrow "Integration and Recomposition."]

[Finally, four broken lines drop from the traditional model at the top of the slide to various steps on the V Model, indicating the parallel processes on both models. A line drops from Project Initiation on the traditional model to Concept of Operations on the V Model; from Preliminary Engineering to Systems Requirements; from Plans, Specifications, and Estimates to Software/Hardware Development and Field Testing; and from Construction to System Validation.]

[This slide displays the Table of Contents for Chapter 7 of the SE Handbook.]

Table of Contents — SE Resources

7		RESOURCES		page 109
		7.1	ITS-Specific Publications	page 109
		7.2	General Systems Engineering References	page 109
		7.3	Selected Systems Engineering Standards	page 110
		7.4	Systems Engineering Training	page 110

The slide highlights the California Systems Engineering Guidebook for ITS. If project personnel do not have access to full Industry standards they may want to take a look and the templates that California developed.]

[This slide displays the California Systems Engineering Guidebook for ITS Requirements Document checklist.]

Checklist: Critical Information

• 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, who is assigned to do it, and under what conditions [e.g. environmental, reliability, and availability.]
• Are all the terms, definitions and acronyms defined?
• Area all supporting documents such as standards, concept of operations, and others referenced.
• Does each requirement have a ling [traceability] to a higher level requirement of a user-specified need?
• Is each requirement concise, verifiable, clear, feasible, necessary, unambiguous, and technology independent?
• Are all technology dependent requirements identified as constraints?
• Does each requirement have a method of verification defined?

[The screen shot shows a System and Sub-System Requirements Template. The sections include:]

Title page
1.0 Scope of System or Sub-System
2.0 References
3.0 Requirements

Other sections of the template not pictured are: Verification Methods, Supporting Documentation, Traceability Matrix, and a Glossary of Terms.]

[7.2 General Systems Engineering References]

• INCOSE Systems Engineering Handbook, International Council on Systems Engineering, http://www.incose.org
• NASA Systems Engineering Handbook, National Aeronautics and Space Administration, http://ocw.mit.edu/NR/rdonlyres/Aeronautics-and-Astronautics/16-892J
  Fall-2004/9722DD5E-CDBB-4B0F-8F5E-791CFF5FD359/0/nasasysenghbook.pdf
• Department of Defense (DOD) Systems Engineering Plan (SEP) Preparation Guide: http://www.acq.osd.mil/ds/se/publications/pig/sep_prepguide_v1_2.pdf
• Buede, D.M., The Engineering Design of Systems: Models and Methods, Wiley Inter-Science, 2000
• Hooks, Ivy, Writing Good Requirements. Paper written for the Third INCOSE Symposium and published in the Proceedings of the Third International Symposium of INCOSE — Volume 2, 1993, http://www.complianceautomation.com/papers/writingreqs.htm
• McConnell, Steve, Software Project Survival Guide, Microsoft Press, 1998
• Young, R.R., Effective Requirements Practices, Addison-Wesley, March 2001, http://www.ralphyoung.net/

[7.3 Selected Systems Engineering Standards]

• AIAA G-043-1992, Guide for the Preparation of Operational Concepts Document
• ANSI/EIA-632, Processes for Engineering a System
• CMMI SWE/SE/IPPD/SS, Capability Maturity Model-Integration for Software Engineering, Systems Engineering, Integrated Product and Process Development and Supplier Sourcing
• EIA-649, National Consensus Standard for Configuration Management
• IEEE 830, Recommended Practice for Software Requirements Specifications
• IEEE 1012, IEEE Standard for Software Verification and Validation Plans
• IEEE 1220, Application and Management of the Systems Engineering Process
• IEEE 1233 — Guide for Developing System Requirements Specifications
• IEEE 1362, Guide for Information Technology — System Definition — Concept of Operations Document
• ISO/IEC 15288, Systems Engineering — System Life Cycle Processes

[7.4 Systems Engineering Training]

The SAFETEA-LU reauthorization allows states to use 100% federal funding for professional development, covering the systems engineering training courses listed here and any other public or privately offered courses in your region. Check with your FHWA Division Office for more information. A broad range of courses for ITS practitioners, including courses related to systems engineering and project management, are available through the National Highway Institute (NHI) and the Consortium for ITS Training and Education (CITE). Current course offerings are listed on these websites:

ITS Professional Capability Building Program: http://www.pcb.its.dot.gov/

Consortium for ITS Training and Education (CITE): http://www.citeconsortium.org

• Contact FHWA Resource Center/Division Offices
• Systems Engineering Web Page (FHWA)
  http://www.ops.fhwa.dot.gov/int_its_deployment/sys_eng.htm
• Lessons Learned Knowledge Resource (ITS JPO)
  http://www.itslessons.its.dot.gov/its/benecost.nsf/LessonSystemsEng
• Solutions Center (ITS JPO) — Coming Soon
• Archived T3
  http://www.pcb.its.dot.gov/res_t3_archive.asp
• California SE Guide Book
  http://www.fhwa.dot.gov/cadiv/segb
• Guide to Contracting ITS Projects (NCHRP)
  http://www.trb.org/nchrp/its/index.htm

• Read the HQ SE for ITS Handbook first to get a solid foundation on what SE is and how to apply it
• If needed, reference the CA Guide Book for specific details
• In some cases, states/locals will only need to read the HQ SE for ITS Handbook in order to manage a project consultant/contractor
• The CA Guide Book will be an additional reference for managing the consultant/contractor and cross-checking and validating the consultants' work

Emiliano Lopez
FHWA Office of Transportation Management
(202) 366-2199
Emiliano.Lopez@fhwa.dot.gov

Mac Lister
FHWA Resource Center
(708) 283-3532
Mac.Lister@fhwa.dot.gov