John D. McGregor Session 4 Requirements V & V - continued

Slides:



Advertisements
Similar presentations
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
Advertisements

Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Business Area Analysis Focus: Domain View (selected business area) Goals: –Isolate functions and procedures that allow the area to meet its goals –Define.
SE 555 Software Requirements & Specification Requirements Validation.
1 Software Requirements Specification Lecture 14.
Software Quality Assurance For Software Engineering && Architecture and Design.
CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Engineering Practices with Techniques.
Typical Software Documents with an emphasis on writing proposals.
Copyright © Jerzy R. Nawrocki Requirements Review Requirements Engineering & Project.
1 Requirements Best Practices. Webinar Host Presenter: Cheryl Hill, PMP Requirements Experts
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Instructor: Peter Clarke
CPSC 873 John D. McGregor Session 4 Requirements V & V - continued.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Requirements Verification & Validation Requirements Engineering & Project Management.
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
John D. McGregor Session 2 Preparing for Requirements V & V
CPSC 372 John D. McGregor Module 2 Session 1 More on requirements and the Investment Decision.
© Mahindra Satyam 2009 Configuration Management QMS Training.
1 15 quality goals for requirements  Justified  Correct  Complete  Consistent  Unambiguous  Feasible  Abstract  Traceable  Delimited  Interfaced.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Develop Project Charter
CSCI 521 Final Exam Review. Why Establish a Standard Process? It is nearly impossible to have a high quality product without a high quality process. Standard.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
1 Quality Attributes of Requirements Documents Lecture # 25.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Requirements Validation
Validate Scope What we have: Requirement Traceability Matrix Verified Deliverables What we do: Inspection What we get: Accepted Deliverables.
Project Management Basics
CPSC 871 John D. McGregor Module 1 Session 4 Requirements Review.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Requirements Management Overview NIGMS Software Development.
1 Project Management C13PM Session 2 Project Initiation & Definition Russell Taylor Business Department Staff Workroom
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
SQA project process standards IEEE software engineering standards
Software Quality Control and Quality Assurance: Introduction
How To Apply Quality Management
Software Configuration Management (SCM)
Requirements Engineering
Software Quality Assurance
Requirements Engineering (continued)
Testing Process Roman Yagodka ISS Test Leader.
SQA project process standards IEEE software engineering standards
System Requirements Specification
SQA Role during Software Requirements Phase
Software Requirements analysis & specifications
UNIT II.
Engineering Processes
John D. McGregor Android Apps
Lockheed Martin Canada’s SMB Mentoring Program
מרעיון למוצר דני חייט.
Software Quality Assurance
G&W Chapter 20: Technical Reviews Software Specification Lecture 27
Software Verification, Validation, and Acceptance Testing
Requirement Documentation &
QA Reviews Lecture # 6.
Engineering Processes
SOFTWARE REQUIREMENT SPECIFICATION
PSS verification and validation
Software Reviews.
Presentation transcript:

John D. McGregor Session 4 Requirements V & V - continued CPSC 873 John D. McGregor Session 4 Requirements V & V - continued

Goals vs Requirements Goal: The aircraft will stop smoothly. Req.: The pressure in the brake shall increase smoothly and monotonically until the commanded amount of pressure is reached.

ReqSpec system requirements AP : "Requirements for the Autopilot subsystem of the Flight Guidance System" for Integrator::FGS::AP::prAutoPilot use constants Globals [ val AP_ProcessingBudget = 50.0 MIPS val AP_RAMBudget = 1.6 MByte val AP_ROMBudget = 16.0 MByte val AP_FlowPathLatency = 3.0 ms requirement R1: "Processing Budget" [ description "The processing needs of the AP subsystem shall not exceed “ UtilizationRatio " percent of AP_ProcessingBudget ] requirement R2_1: "RAM Memory Budget" [ description "The RAM memory needs of the AP subsystem shall not exceed “ UtilizationRatio " percent of “ AP_RAMBudget

A good requirement is Correct Unambiguous Complete Consistent Prioritized Verifiable Modifiable Traceable Necessary – for validation purposes

A good set of requirements is Complete Consistent - internally Feasible Implementation independent Traceable Conformant

Program of Reviews - government 1 Review process 1.1 Mission Concept Review (MCR) 1.2 System Readiness Review (SRR) 1.3 Mission Definition Review (MDR) 1.4 System Design Review (SDR) 1.5 Preliminary Design Review (PDR) 1.6 Critical Design Review (CDR) 1.7 Production Readiness Review (PRR) 1.8 Test Readiness Review (TRR) 1.9 System Acceptance Review (SAR) 1.10 Operational Readiness Review (ORR) 1.11 Flight Readiness Review (FRR)

Software Requirements Specification (SRS) The SRS is basically the set up agreement between supplier and the customer tell us about “what are we going to implement in software application.” As per the IEEE standard the characteristics of a great SRS should be Clear, Correct, Complete, Traceable, Modifiable, Verifiable, Ranked for importance and/or stability, Consistent and Unambiguous. http://www.softwaretestingclass.com/guidelines-to-review-software-requirements-specification-srs-document-the-complete-checklist/#sthash.GWzmUObV.dpuf

Reviews A meeting where requirements are discussed and evaluated Can be informal or formal depending on the business relationships and purpose Periodic reviews and acceptance review Roles Moderator – facilitates and keeps process moving Recorder – tracks the discussion notes key points SME – subject matter experts Business people – represent business requirements

Participants Stakeholders receiving the final product Stakeholders providing the requirements Business Technical Stakeholders supplying materials Stakeholders developing the product upstream producer downstream

Process Basically each requirement is read and discussed Any stakeholder may raise an objection Discussion is limited to the requirement under review SMEs give factual information and business people provide business information A decision process such as voting is used to make decisions

Process - 2 Questions that can not be resolved are listed as issues to be investigated Change requests are created for decisions that cause changes to the system A change control board examines and decides whether the change is to be made The report from a review captures all decisions, some rationales, and any patterns

Review checklists https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CCwQFjACahUKEwjp4q2_2tDHAhUKaz4KHRhWDh8&url=http%3A%2F%2Fwww.csis.pace.edu%2F~scharff%2Fcs3892005%2Freqreview.doc&ei=iOniVen-D4rW-QGYrLn4AQ&usg=AFQjCNGv9Su-01rT_vJPC0Zn1WV5AFkdDQ&cad=rja https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CDkQFjAEahUKEwjp4q2_2tDHAhUKaz4KHRhWDh8&url=http%3A%2F%2Fwww.uccs.edu%2FDocuments%2Ftboult%2FRequirements%2520Review%2520Checklist.doc&ei=iOniVen-D4rW-QGYrLn4AQ&usg=AFQjCNEDu8pHrpSQ3Dc_fBmnR5aSz2jEzw&cad=rja

Inspection A more structured review Uses a checklist – see link later Fagan, M. “Design and Code Inspections to Reduce Errors in Program Development.” IBM Systems Journal 15, 3 (1976): 182-211. (Please read by next class)

Design Inspection Process Initially designer gives overview A reader walks through the design directing the group’s attention Group searches for design errors I2 Same as I1 except no overview

What to look for

Design Error Types

Size of model

Overview of IBM process in 1990s

Defect density

Baseline for throughput Units/hour Lines of code Interface specifications

Fault Model 1.1 Incomplete decomposition 1.2 Omitted requirement 1.3 Improper translation 1.4 Operational environment incompatibility 1.5 Incomplete requirement description 1.6 Infeasible requirement 1.7 Conflicting requirement 1.8 Incorrect assignment of resources 1.9 Conflicting inter-system specification 1.10 Incorrect or missing external constants 1.11 Incorrect or missing description of initial system state 1.12 Over-specification of requirements 1.13 Incorrect input or output descriptions

Link to example checklist https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCUQFjABahUKEwia-c7d68vHAhVEoYAKHYWLDpE&url=http%3A%2F%2Fwww.uccs.edu%2FDocuments%2Ftboult%2FRequirements%2520Review%2520Checklist.doc&ei=hFzgVZqnGsTCggSFl7qICQ&usg=AFQjCNEDu8pHrpSQ3Dc_fBmnR5aSz2jEzw

AADL http://www.slideshare.net/iivanoo/aadl-42305750 http://www.slideshare.net/iivanoo/aadl-42305750?next_slideshow=2

Assignment Create a requirements review checklist specifically for the wbs example. What are the priorities for a requirements review for a system of this type? Submit a pdf by 11:59pm Wednesday Sept 12, 2018