Ch. 5 Lecture Notes IN4MTX 113 January 2010 Requirements Quality Assurance.

Slides:



Advertisements
Similar presentations
Process and Product Quality Assurance (PPQA)
Advertisements

Testing and Quality Assurance
Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
More CMM Part Two : Details.
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Evaluating Requirements
® IBM Software Group © 2014 IBM Corporation Innovation for a smarter planet MBSE for Complex Systems Development Dr. Bruce Powel Douglass, Ph.D. Chief.
Basic guidelines for the creation of a DW Create corporate sponsors and plan thoroughly Determine a scalable architectural framework for the DW Identify.
Lecture 5 Themes in this session Building and managing the data warehouse Data extraction and transformation Technical issues.
Software Testing and Quality Assurance
Evaluating Requirements
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
SE 555 Software Requirements & Specification Requirements Validation.
Evaluating Requirements
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
Software Quality Assurance For Software Engineering && Architecture and Design.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
Effective Methods for Software and Systems Integration
Dr. MaLinda Hill Advanced English C1-A Designing Essays, Research Papers, Business Reports and Reflective Statements.
S T A M © 2000, KPA Ltd. Software Trouble Assessment Matrix Software Trouble Assessment Matrix *This presentation is extracted from SOFTWARE PROCESS QUALITY:
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
Software Quality Assurance Activities
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Formal and Informal Peer Reviews
CSCI 6231 Software Engineering ( Chapter 10?) Requirements Workflow Instructor: Morris Lancaster.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
CPSC 873 John D. McGregor Session 4 Requirements V & V - continued.
Requirements Verification & Validation Requirements Engineering & Project Management.
IT Requirements Management Balancing Needs and Expectations.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
Lecture 7: Requirements Engineering
CS 350, slide set 5 M. Overstreet Old Dominion University Spring 2005.
This chapter is extracted from Sommerville’s slides. Textbook chapter
Writing requirements specifications. Why we need requirements specifications To give structure to your desires To avoid waste of resources To avoid slippage.
2131 Structured System Analysis and Design By Germaine Cheung Hong Kong Computer Institute Lecture 8 (Chapter 7) MODELING SYSTEM REQUIREMENTS WITH USE.
Develop Project Charter
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
Verification and Validation Assuring that a software system meets a user's needs.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Requirements Validation
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
Evaluating Requirements
Requirements Analysis
Capturing Requirements. Questions to Ask about Requirements 1)Are the requirements correct? 2)Consistent? 3)Unambiguous? 4)Complete? 5)Feasible? 6)Relevant?
This chapter is extracted from Sommerville’s slides. Textbook chapter 22 1 Chapter 8 Validation and Verification 1.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
What has been accomplished at the end of MSD 1 & 2?
T Project Review MTS [PP] Iteration
Information Technology Project Management, Seventh Edition.
PRODUCT VERIFICATION Adapted from the NASA Systems Engineering Handbook for CSULB EE 400D by Alia Bonetti.
SOFTWARE TESTING TRAINING TOOLS SUPPORT FOR SOFTWARE TESTING Chapter 6 immaculateres 1.
02086 Writing Inspirations Aalto University
CIS 375 Bruce R. Maxim UM-Dearborn
Document Development Cycle
02086 Writing Inspirations Aalto University
Software Verification and Validation
02086 Writing Inspirations Aalto University
Requirements Verification and Validation
SQA Role during Software Requirements Phase
Software Requirements analysis & specifications
Software Quality Engineering
John D. McGregor Session 4 Requirements V & V - continued
Unit 1 :Basic Of Software Testing
QA Reviews Lecture # 6.
Engineering Processes
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Ch. 5 Lecture Notes IN4MTX 113 January 2010 Requirements Quality Assurance

Chapter 5 Topics Inspections and Reviews Queries using a Requirements Database Validation by Specification Animation Verification through Formal Checks 2

Congrats. You wrote your first RD. … but who checked it? 3

Why Have Inspections and Reviews? Validate that the RD: Reflects stakeholder needs Explains the system accurately Get feedback Progress Customer feedback Subject matter experts that can catch your mistakes End goal: have an accurate, complete, and consolidated RD 4

Requirements Inspection Process 5

6

Inspection Planning 7 Different terms: Walkthroughs, Colleague Reviews, Peer Reviews Subtle differences involving scope and format of these reviews Which one to use? Planning involves the basics: schedule, scope, have your document ready to review, decide who is getting invited, find a conference room, etc

Some Guidance to Inspection Planning 8 Time it well Limit the number of people attending: key experts and stakeholders only (max: 7, min: 3) Don’t invite any manager Give your reviewers enough time Get your comments ahead of time Customers are tricky

Requirements Inspection Process 9

Individual Reviewing 10 Free Form/Free Style No direction given Find what you can Checklist-based Specifics you want your reviewers to provide feedback: format, readability, clarity, consistency (defects), language and semantics Process-based Assign roles Seek different perspectives from specific disciplines: safety, design, test, quality

Example: Defect-based Checklist 11 Omission: Was something greatly missed? Contradiction: Consistent with other requirements/concepts? Inadequacy:Did this meet the stakeholders needs? Ambiguity:Too many interpretations? Immeasurability: Are these requirements verifiable? Noise: Are these statements relevant? Over specificationDo these requirements add any value to verify? UnfeasibilityIs this possible? UnintelligibilityWhy is this statement/requirement here? Poor StructuringBad wording? Forward ReferenceIs the concept defined later in the document? RemorseHas the concept been used before definition? Propagated ChangesWould a change here propagate elsewhere? OpacityAre the dependencies visible?

Some Guidance to Individual Reviewing 12 Ask yourself: what are you seeking? Technical accuracy? Clarity in wording? … then ask your reviewers for the same. Providing direction will yield the best results: go with checklist-based or process-based reviews.

Requirements Inspection Process 13

Defect Evaluation at Review Meetings 14 Have the inspection review meeting, collect comments. Tips: Excel is very powerful / matrix comments, resolution, action items Document the problem … analyze later.

15 Defect Evaluation at Review Meetings an example

Requirements Inspection Process 16

RD Consolidation 17 Consolidate comments Tip: decide your next action Resolve conflicting comments Defer if the conflict gets out of hand Disagreeing with a comment Reconcile comments with your updated RD

Requirements Inspection Process 18

Queries on a Database 19 √ Consistency Checks √ Metrics √ Deltas Data/Models In Outputs Requirements Database A B

20 Full Inspection Review of Version A Delta Inspection Review of Version B Queries on a Database A B √Deltas

Queries on a Database 21 Queries can be made to determine consistency in wording and assigned entities Queries for metrics: # of requirements: Volatile requirements comparison (Version A vs Version B) # of specific requirements: i.e. how many requirements related to interfaces? Safety requirements? Traceability: finding orphaned requirements, childless parents Deltas from one baseline of an RD to the next

22

Validation by Specification Animation 23 The point: to check the adequacy of requirements and the assumptions you’ve made Extracting an executable model from the specification: what perspective do we want to animate? Validation Scenarios Does the system behave as expected? Mimic possible behaviors of the environment Demonstrate that the software can respond to outside events

24

Pitfalls using Animation/Simulation 25 You still need a formal specification Tricky things can happen in the environment Simulated models will not catch these anomalies Experts are needed Not everything can be represented Gaps will exist between animated model and original specification Adequacy of model vs inadequacy of what was specified

Verification through Formal Checks 26 Language Checks Dedicated Consistency and Completeness Checks Model Checking Theorem Proving

Model Checking 27

28 Proof by Counterexample init: (doorsClosed, trainStopped) start: (doorsClosed, trainMoving) [speed = 0]: (doorsClosed, trainStopped) opening: (doorsOpen, trainStopped) start: (doorsOpen, trainMoving) Missing from DoorsState = ‘closed’