Testing Programs for Transportation Management Systems – Practical Considerations Meaning of Requirements Statements Terms Testing is an important part.

Slides:



Advertisements
Similar presentations
Quality Assurance/Quality Control Plan Evaluation February 16, 2005.
Advertisements

Effective Contract Management Planning
Joint Contingency Contracting
November 19, 2013 Preparing a Successful RFP to get Desired Results.
Chapter 7: Key Process Areas for Level 2: Repeatable - Arvind Kabir Yateesh.
CS 411W - Notes Product Development Documentation.
Chapter 12 – Strategies for Effective Written Reports
ACA Directorate of Contracting, Fort Bragg RECAP OF COR FUNDAMENTALS BY ADMINISTRATION DIVISION 15 February 2007.
Chapter 3 Project Initiation
1 Software Requirements Specification Lecture 14.
ISO 9001 Interpretation : Exclusions
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Specification Writing Presentation Training & Development.
Chapter 3 Project Initiation. The stages of a project  Project concept  Project proposal request  Project proposal  Project green light  Project.
Guiding principles for the Federal acquisition system
Application Amendments and Budget Transfers (Part 2) Virginia Department of Education Office of Program Administration and Accountability Title I University,
1 1 Roles and Responsibilities in the CDBG Program For Grant Administrators.
A SOUND INVESTMENT IN SUCCESSFUL VR OUTCOMES FINANCIAL MANAGEMENT FINANCIAL MANAGEMENT.
Hartley, Project Management: Integrating Strategy, Operations and Change, 3e Tilde Publishing Chapter 11 Procurement Management Embedding value into the.
Introduction to Software Quality Assurance (SQA)
To teach specification preparation  the importance of well-prepared specifications in procurement  the different types of specifications  basic writing.
Program Standard Provides the minimum baseline requirements for the performance of an activity. Establishes the “WHAT” that an activity should accomplish.
FAR Part 2 Definitions of Words and Terms. FAR Scope of part (a)This part – (1) Defines words and terms that are frequently used in the FAR; (2)
Standards Provides the minimum baseline requirements for the performance of an activity. Establishes the “WHAT” that an activity should accomplish.
Using the AASHTO Audit Guide for the Development of A/E Consultant Indirect Cost Rates Introduction Target Audience Course Structure Learning Outcomes.
1 CDBG Roles and Responsibilities For Local Officials.
1 Developing the Specification/ Statement of Work Susan Georgis Master Agreements & Contracts Ben Martin Procurement Engineering.
ITS Procurement Workshop Module 2: ITS Procurement Characteristics and Challenges.
1 BUYING LIGHTNING DATA LESSONS LEARNED AND FUTURE CHALLENGES TO AVOID ANTI-DEFICIENCY DAN CLEVER DIRECTOR NWS ACQUISITION DIVISION 6/15/05.
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
U.S. General Services Administration An Advanced Overview of MAS Contracts for Contractors.
Webinar for FY 2011 i3 Grantees February 9, 2012 Fiscal Oversight of i3 Grants Erin McHughJames Evans, CPA, CGFM, CGMA Office of Innovation and Improvement.
Protecting Data Rights Under DoD Contracts October 14, 2009 NCMA Workshop Cape Canaveral Chapter Keith R. Szeliga Sheppard Mullin Richter & Hampton.
Writing requirements specifications. Why we need requirements specifications To give structure to your desires To avoid waste of resources To avoid slippage.
1 Quality Attributes of Requirements Documents Lecture # 25.
Systems Engineering “Understanding Where it Fits in Your Agency” a session in fhwa’s Systems Engineering t3 series aug. 02, 2007.
International Atomic Energy Agency Roles and responsibilities for development of disposal facilities Phil Metcalf Workshop on Strategy and Methodologies.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
HIT Policy Committee NHIN Workgroup HIE Trust Framework: HIE Trust Framework: Essential Components for Trust April 21, 2010 David Lansky, Chair Farzad.
Maintaining and Sustaining System Integrity Configuration Management for Transportation Management Systems Configuration management (CM) describes a series.
Communicating Marketing Research Findings
It was found in 1946 in Geneva, Switzerland. its main purpose is to promote the development of international standards to facilitate the exchange of goods.
RECOMMENDATIONS OF THE GOVERNOR ’ S TASK FORCE ON CONTRACTING AND PROCUREMENT REVIEW Report Overview PD Customer Forum September 2002.
Software Requirements Specification (SRS)
Introductions and Conclusions CSCI102 - Systems ITCS905 - Systems MCS Systems.
How the NCSX Project Does Business
CHAPTER 3 – JOB ANALYSIS. KEY CONCEPTS AND SKILLS ➲ Define job analysis ➲ Reasons for conducting job analysis ➲ Types of information required for job.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Content and interpretation of Contracts The vast majority of the contracts pose no problems - they are usually a simple interchange of cash for goods/services.
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
The Contract Management Process Contract Formation.
1 Statements of Work – Getting Them Right!!. 2 Today’s Agenda A.The Basics B. Sources of Information C. Scenario #1: Procurement is in the loop D. Scenario.
1 Auditing Your Fusion Center Privacy Policy. 22 Recommendations to the program resulting in improvements Updates to privacy documentation Informal discussions.
PRIIA 305 Technical Subcommittee Systems Engineering Processes for Passenger Equipment Acquisition and Life Cycle Support Presented at: NGEC Executive.
By: Wilmer Arellano.  1. Form a team  2. Find a Team Leader  3. Find Three Potential Topics  4. Find a Mentor  5. Select a Topic.
 System Requirement Specification and System Planning.
Statements of Work – Getting Them Right!!
INTERNAL AUDIT REPORTS
Project Quality Management
CONTRACT ADMINISTRATION
IUID and Government Furnished Property Basics
FAR Part 2 - Definitions of Words and Terms
Writing Requirements Lecture # 23.
What is Policy? Julie M. Slavens Indiana School Boards Association
PRODUCT EVALUATION & TESTING BRANCH SUPPLIER SUPPORT DIVISION II
Middle States Update to President’s Cabinet October 8, 2018
Centralization of Texas State Contract Compliance Functions
Dr. Jiacun Wang Department of Software Engineering Monmouth University
NGEC Executive Board Meeting
Software Reviews.
Presentation transcript:

Testing Programs for Transportation Management Systems – Practical Considerations Meaning of Requirements Statements Terms Testing is an important part of the deployment of a TMS. The purpose of testing is two-fold. First, testing is about verifying that what was specified is what was delivered - it verifies that the product (system) meets the functional, performance, design, and implementation requirements identified in the procurement specifications. Therefore, a good testing program requires that there are well-written requirements for both the components and the overall system. Without testable requirements, there is no basis for a test program. Secondly, testing is about managing risk for both the acquiring agency and the system’s vendor/developer/integrator. The test program that evolves from the overarching systems engineering process, if properly structured and administered, allows managing the programmatic and technical risks to help assure the success of the project. The testing program is used to identify when the work has been “completed” so that the contract can be closed, the vendor paid, and the agency can transition the system to the warranty and maintenance phase of the project. The language, syntax, and structure of you requirements statements are extremely important as they directly affect the quality and thoroughness of the test program that is based on them. Certain terms used in requirements statements have specific contractual implications. “Shall” is used to confer a requirement on the provider of the product or service and is typically understood to mean at the time of delivery. “Will” is used to confer a requirement on the receiver (the accepting agency) of the product or service when that product or service is delivered. “Will” is also used to imply a future requirement on the provider that should be clear from the context of the statement. “May” is a conditional term and implies that either the provider or the receiver has the option to meet the stated requirement. “May” statements are generally not testable unless additional conditions are included to indicate what is expected if the provider or receiver elects that option. “Should” falls into same category as “may” and is considered an optional requirement that may or may not be included in the system depending on the provider’s perspective. “Must” is used to add additional emphasis to the requirement statement that can be directed at either the provider or receiver, but more typically the provider. “Must” is typically used in a requirement that has specific legal or contractual ramifications such as may be invoked by requiring a particular State statute or governing regulation be strictly adhered to in the performance of the work. In the contract specifications, it has the same basic meaning as “shall.” From a contracting perspective, only requirements with MUST and SHALL statements are likely to be provided by the contractor. All other requirements should be considered part of a “wish list” and will not be part of the testing program.

Federal Highway Administration U.S. Department of Transportation th Street, S.W. (HOP) Washington, DC Toll-Free “Help Line” Publication No.: FHWA-OP-0X-XXX EDL Document No.: XXXXX February 2007 Additional Resources The Testing Handbook for Transportation Management Systems is intended to provide direction, guidance, and recommended practices for test planning, test procedures, and test execution for the acquisition, operation, and maintenance of transportation management systems and ITS devices. For a non-technical audience, the TMS Testing Primer identifies key aspects of testing, identifies the benefits of developing and using testing programs, and profiles successful practices of existing programs. The material is available on the Federal Highway Administration website at Handbook, FHWA-OP , EDL# Primer, FHWA-OP , EDL# The requirements statements contained within the procurement specifications are the basis for test and acceptance. Poor or missing requirements statements result in requirements that cannot be verified and products or services that don’t meet expectations. Requirements statements should be written as clear, unambiguous, declarative sentences. Proper grammatical sentence structure is as important as is use of “shall” and “must,” particularly in defining who is the responsible party for providing the product or service and who will be accepting delivery of that product or service. The following are some do’s and don’ts for writing and reviewing testable requirements. Writing Testable Requirements – Do’s and Don’ts Avoid the use of “may” and “should” in the requirement statement unless you specifically want to give the provider an option in how that requirement can be met, or give the receiver an acceptance option or an “out.” Avoid negative requirements. Positive statements are better, because they can be definitively measured for acceptance testing. Don’t mix dissimilar or unrelated requirements in the same statement. This practice complicates requirements traceability and verification testing. Unrelated requirements will usually be verified at different times, under different test conditions, and using different test procedures or methods. Write the requirement in simple, understandable, concise terms; be short and to the point. If complex technical terminology is necessary, make sure those terms are defined or well understood by the provider as well as the receiver. For each [individual] requirement there should be one shall or must statement. If the requirements are complex, then they should be subdivided into a string of individual requirements to the greatest extent possible. Write the requirement as a positive statement. If something is not desired, try to phrase the requirement to state what is desired. Have a test method, such as inspection, certificate of compliance, analysis, demonstration or test, and pass/fail criteria in mind when writing or reviewing the requirement. If you can’t figure out how to verify the requirement or what criteria constitutes acceptance, you can’t expect the provider to demonstrate compliance with the requirement. Consider the complexity, technical expertise, and expense of the testing that may be necessary to verify the requirement — simplifying the requirement may result in the same end product or service, but at a reduced test expense. When preparing the requirements statement, make sure that the requirements will have the same interpretation regardless of the background and experience of the reader. Add clarifying information when necessary to ensure a common understanding by readers with radically different backgrounds. Do’s – Don’ts –