Verification “Auditability” Can Be “Free” James H. Jones Optants Documented Decision Support Company (ODDSCO) www.optants.com.

Slides:



Advertisements
Similar presentations
© Telelogic AB Modeling DoDAF Compliant Architectures Operational Systems Technical.
Advertisements

© 2014 Systems and Proposal Engineering Company. All Rights Reserved Using Natural Language Parsing (NLP) for Automated Requirements Quality Analysis Chris.
Configuration Management
1.Quality-“a characteristic or attribute of something.” As an attribute of an item, quality refers to measurable characteristics— things we are able to.
ISO 9001:2000 Documentation Requirements
Software Quality Assurance Plan
CS 411W - Notes Product Development Documentation.
First Article Inspection Report
SAE AS9100 Quality Systems - Aerospace Model for Quality Assurance
Stepan Potiyenko ISS Sr.SW Developer.
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
SE 555 Software Requirements & Specification Beyond Requirements Based on Weigers Chapter17.
Systems Engineering for FDA Design Controls Compliance
Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition.
Software Configuration Management (SCM)
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Prepared by Long Island Quality Associates, Inc. ISO 9001:2000 Documentation Requirements Based on ISO/TC 176/SC 2 March 2001.
S R S S ystem R equirements S pecification Specifying the Specifications.
Defining the Activities. Documents  Goal Statement defines why helps manage expectations  Statement of Work what gets delivered defines scope  Software.
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Software Configuration Management
Software Engineering Institute Capability Maturity Model (CMM)
Effective Methods for Software and Systems Integration
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Overview of the Database Development Process
Introduction to Software Quality Assurance (SQA)
Software Engineering Term Paper
Ron Kratzke, Vitech Corporation MBSE for System Testing Managing the development of system testing using the principles of Model.
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design.
Software Configuration Management (SCM)
Software System Engineering: A tutorial
Copyright 2002 Prentice-Hall, Inc. Chapter 1 The Systems Development Environment 1.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
NIST Special Publication Revision 1
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
FCS - AAO - DM COMPE/SE/ISE 492 Senior Project 2 System/Software Test Documentation (STD) System/Software Test Documentation (STD)
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Configuration Management Non Government Std: EIA Standard-649 “A management process for establishing and maintaining consistency of a product’s performance,
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 2 The Software Process Discussion of the Software Process: Process Framework,
ISO / IEC : 2012 Conformity assessment – Requirements for the operation of various types of bodies performing inspection.
Copyright 2002 Prentice-Hall, Inc. 1.1 Modern Systems Analysis and Design Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 1 The Systems Development.
© Mahindra Satyam 2009 Configuration Management QMS Training.
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
QUALITY MANAGEMENT STATEMENT
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
The world leader in serving science Validation and Qualification Overview Mike Garry Software Product Manager Spectroscopy Software Platform Team.
~ pertemuan 4 ~ Oleh: Ir. Abdul Hayat, MTI 20-Mar-2009 [Abdul Hayat, [4]Project Integration Management, Semester Genap 2008/2009] 1 PROJECT INTEGRATION.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
ICAJ/PAB - Improving Compliance with International Standards on Auditing Planning an audit of financial statements 19 July 2014.
SQA project process standards IEEE software engineering standards
Chapter 1 The Systems Development Environment
Configuration Management
Chapter 1 The Systems Development Environment
Testing Process Roman Yagodka ISS Test Leader.
SQA project process standards IEEE software engineering standards
Configuration Management
Chapter 1 The Systems Development Environment
Software Requirements
Chapter 1 The Systems Development Environment
Software and System Delivery
System Requirements Specification
Chapter 1 The Systems Development Environment
PSS verification and validation
Chapter 1 The Systems Development Environment
Software Reviews.
Presentation transcript:

Verification “Auditability” Can Be “Free” James H. Jones Optants Documented Decision Support Company (ODDSCO)

2 Verification “Auditability” Can Be “Free” 1. Definitions of Key Words Auditability: Requirements clarity and traceability from elicitation through V&V. Permutation: A distinct and meaningfully separate instance of a requirement that must be part of a comprehensive verification. Requirement: A statement specifying a mandatory characteristic or some functional behavior to be provided by product/process.

3 Verification “Auditability” Can Be “Free” 1. Definitions of Key Words (Continued) Validation: Determining if “the right system was built” (for customer/user). Verification: Determining that “the system was built right” (according to specification). Verification Audit Support Standards: (VASS) Use of Requirements Management methods that automate the “auditability” of requirements verification.

4 Verification “Auditability” Can Be “Free” 2. Benefits of Audit Support Standards Assists proper system allocations. Supports % Complete project metrics, from each requirement to entire specification. Assists detailed technical review of plans and procedures for requirements V&V. Supports audit of V&V development tasks at any time during the project.

5 Verification “Auditability” Can Be “Free” 3. System Engineering 101 (FRAT) Functions are product “needs” from the user or customer perspective. Requirements specify mandatory function, performance, and qualification objectives. Architecture is an implementation concept for a specification fulfilling product. Testing (V&V) confirms (or denies) that the system fulfills all of its requirements.

6 Verification “Auditability” Can Be “Free” 4. Typical RVTM Format

7 Verification “Auditability” Can Be “Free” 5. Basic Requirements Writing Rules Although they may swap designation with priority change, differentiate requirements and “desirements” (non-mandatory items). Limit requirements to one function, unless listing closely affiliated items. Avoid implicit requirements. Avoid “shall not” wording that requires test of universe to prove a negative.

8 Verification “Auditability” Can Be “Free” 5. Requirement Writing Rules (Continued) Avoid redundancies of “be capable of”or “be able to” (use direct action verb). Until fully verifiable by instrumented test, demonstration, inspection, or analysis, a requirement is not valid. (So, be cautious with adverbs and, when possible, replace adjectives with measurable values, ranges, or limits.)

9 Verification “Auditability” Can Be “Free” 5. Requirement Writing Rules (Continued) A Formal Specification Language approach uses the following standard form for all the requirement statements: [Optional qualifier,] The (system/subsys- tem/process name) shall [use “should” or “will” if a desirement] (direct action verb statement of function) [, alternate position for the optional qualifier].

10 Verification “Auditability” Can Be “Free” 5. Requirement Writing Rules (Continued) The foregoing basic “rules” are a small subset of many commonly listed constraints and suggestions in requirements writing training courses, but they are sufficient to provide most users a consistently effective approach.

11 Verification “Auditability” Can Be “Free” 6. SRVTM (Tracking Permutations)

12 Verification “Auditability” Can Be “Free” 6. SRVTM (Hazard Abatement Trace) When a requirement in a subsidiary hardware or software specification has been assigned to accomplish necessary reduction of risk level for an item in system Hazard Analysis, insert a column for showing that hazard identifier. [Such a column is put in the System RVTM, because assignments in Hazard Analysis are to the System Spec.]

13 Verification “Auditability” Can Be “Free” 7. Test Procedure Suggestions (VASS) Identify all Test Procedures (TPs) used for Verification of the permutations of each requirement in the Subsidiary RVTM. To support reviewers and auditors (when more than one TP used), list in order every requirement tested therein [and number of instances, when multiple permutations are tested] in the introduction section of each.

14 Verification “Auditability” Can Be “Free” 7. Test Procedure Suggestions (Continued) In the Expected Results column (or in the automated test scripts or test program code comment statements [or output to the results file]), annotate each test step with both the requirement identifier and extent of testing (such as which permutation was exercised and identification of a Hazard depending on its fulfillment for risk level reduction).

15 Verification “Auditability” Can Be “Free” 7. Test Procedure Suggestions (Continued) To ensure test step will confirm risk level reduction for an assigned Hazard, annotate the requirement identifier with that Hazard identifier. Reported verification success for that test step then becomes evidence that the hazard was abated by the identified action.

16 Verification “Auditability” Can Be “Free” 8. Percent Complete Metric (PD/TP * 100)

17 Verification “Auditability” Can Be “Free” 9. Related Metrics Expansion Because each Subsidiary RVTM is separate, spreadsheets can be used to automate the results of updates computation. RVTMs can include a new column for each Verification development milestone. (Such as Design Done, Dry Run, Verified, and Reported.)

18 Verification “Auditability” Can Be “Free” 9. Related Metrics Expansion (Cont.) The verification procedure development milestone completion entry for each requirement is summed into its requirements specification subsection. Each subsection development milestone completion total is summed into its requirements specification section.

19 Verification “Auditability” Can Be “Free” 9. Related Metrics Expansion (Cont.) Each verification development milestone completion section total is summed into its requirements specification document total. Using requirements permutations totals for each subsection, section, and specification, compute actual verification development milestones % complete values for reporting to self, supervisor, and project management.

20 Verification “Auditability” Can Be “Free” 10. Requirements Management Tools For simpler projects, the RVTM and metrics computations are appropriately developed with an ordinary spreadsheet. For medium to large projects, requirements management tools such as DOORS support for producing the RVTMs as reports and permitting the recommended % complete metrics computation.

21 Verification “Auditability” Can Be “Free” 11. Conclusions VASS can provide comprehensive rigor at less cost than previous practices would, so “auditability” can be considered “free”. Requirements Verification development metrics that reflect reality and help you know and report your part of the project status are superior to traditionally estimated percent complete values.

22 Optants Documented Decision Support Co. Defense/Medical Systems Engineering Requirements Management Decision Modeling (incorporating project technical/schedule/cost risk) Process Improvement Training/Consulting