1 Quality CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 25, 2004.

Slides:



Advertisements
Similar presentations
Verification and Validation
Advertisements

Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Code Inspections CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 23, 2003.
1 Interviewing CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 13, 2004.
1 Problem Analysis CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 9, 2004.
1 Brainstorming CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 16, 2004.
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Team Skill 6 - Building The Right System Part 2: Traceability, Change and Quality (Chapters of the requirements text) CSSE 371 Software Requirements.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Introduction to Requirements (Chapters 1-3 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman Institute.
1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
1 Usability Testing Roles CSSE 376 Software Quality Assurance Rose-Hulman Institute of Technology April 23, 2006.
Slide 1 Requirements Wrap-up (Chapter 31 of requirements text) and Interaction Design: Introduction (Chapters 1 of Interaction Design text) CSSE 371 Software.
Lifecycle of Testing CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 6, 2007.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Diversity of Interaction in a Quality Assurance Course Mark Ardis, Rose-Hulman Institute Cheryl Dugas, Indiana State University FIE 2005.
1 Quality Assurance in Construction and Maintenance (Section 13.4 of Maintenance Text; Chapter 20 of Code Complete) Steve Chenoweth CSSE 375, Rose-Hulman.
Software Quality Processes – Part II CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 19, 2007.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
Risk Management CS 414, Software Engineering I Mark Ardis, Rose-Hulman Institute January 28, 2003.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
IS&T Project Management: How to Engage the Customer September 27, 2005.
Verification and Validation
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
RUP Requirements RUP Artifacts and Deliverables
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Lecture #9 Project Quality Management Quality Processes- Quality Assurance and Quality Control Ghazala Amin.
Supplementary Specifications (Chapters 20,22 - Requirements Text) 1.
S Q A.
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.
Chapter 7 Applying UML and Patterns Craig Larman
Usability Tests and Reports Brian Gastle Western Carolina University.
Traceability, Change and Quality – Chapters Requirements Text Steve Chenoweth & Chandan Rupakheti RHIT Question 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
Requirements and Testing Peer Reviews and Walkthroughs CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 8, 2007.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Verification and Validation Assuring that a software system meets a user's needs.
M253 Team Work in Distributed Environments Week (3) By Dr. Dina Tbaishat.
Requirements Development in CMMI
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Team Skill 6: Building the Right System Assessing Requirements Quality (29)
Pair Development Framework Monvorath (Molly) Phongpaibul.
RequisitePro Software Requirement Management Tool A peresentation by: Mojdeh Jalali-Heravi Maryam Daneshi.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Traceability, Change and Quality – Chapters Requirements Text Sriram Mohan/Steve Chenoweth.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
Software Quality Control and Quality Assurance: Introduction
Software Verification and Validation
Software Verification and Validation
Engineering Processes
Inspection and Review The main objective of an Inspection or a Review is to detect defects. (Not for Giving Alternative Solutions) This activity and procedure.
Introduction to Requirements Management
Team Skill 6 - Building The Right System Part 2: Traceability, Change and Quality Sriram Mohan.
Engineering Processes
Managing Change and Quality
Software Reviews.
Requirements Development in CMMI
Some Closing Thoughts Software Engineering.
Presentation transcript:

1 Quality CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 25, 2004

2 Outline Verification vs. Validation Products vs. Processes Review Methods Checklists

3 Verification vs. Validation Verification is building the system right: conformance to the specifications. How do you ensure this? Validation is building the right system: customer satisfaction with the solution. How do you ensure this?

4 Products vs. Processes Organizations that produce high-quality products invest in high-quality processes. Product quality can be measured through testing. How can we measure process quality?

5 Review Methods Informal ask a peer to read and give comments Formal ask a peer to prepare for review record and report results of review Active interrogate reviewer

6 Checklists Look for anticipated defects Some defects apply to almost all artifacts Does the artifact exist? Some defects are artifact-specific Have you identified all stakeholders?

7 Problem Statement Checklist 1. Has a problem statement been drafted? 2. Is it written in an easy-to-understand way? 3. Does the team understand it? 4. Has it been circulated for agreement to the key stakeholders, including management? 5. Do the team members have agreement that this is the problem they are trying to solve?

8 Supplementary Specification Checklist (1/2) 1. Have you established an appropriate template? 2. Are all non-functional requirements included in the supplementary specification? 3. Have requirements for usability, reliability, performance and supportability been captured?

9 Supplementary Specification Checklist (2/2) 4. Have design constraints been identified? 5. Have supplementary requirements been linked to use cases where appropriate?

10 Checklist Exercise