Professional Documents
Culture Documents
Team Software Project (TSP) June 12, 2007: Requirements Inspection & High Level Designs
Team Software Project (TSP) June 12, 2007: Requirements Inspection & High Level Designs
6/12/2007
2007_06_12_Rqmts.ppt
Outline
Key Discussions from last week (Project Risks) Configuration Management Schedule & Cross Team Inspections Requirements Overview
General Specifics to look for in LOC Counter SRS
Reviews & Inspection Summary SRS Inspection Process Measurement Data Collection <SRS Inspection> Design Phase Overview
6/12/2007
2007_06_12_Rqmts.ppt
6/12/2007
2007_06_12_Rqmts.ppt
Milestones
Requirements (SRS)
Initial Draft out for review Final draft for inspection Inspection Baselined June 10 June 12 June 12 June 15 June 17 June 19 June 22 June 19
6/12/2007
2007_06_12_Rqmts.ppt
Configuration Management
Types of product elements Maintained (e.g. software) Baselined & Maintained (e.g. SRS) Quality Records (e.g. meeting notes, action item list) Key Functions
Latest Version of each product element (software, documents, quality records) Copies of prior versions of each product element Who changed from previous version When changed What changed Why changed
6/12/2007 2007_06_12_Rqmts.ppt 6
Configuration change request form (CCR, aka CR) Baseline Process (see page 326) Backup procedures & facilities Configuration status reports (CSR) Software Change Management status reports @ weekly meeting
6/12/2007 2007_06_12_Rqmts.ppt 7
Baseline Considerations
Criteria
Defined in Configuration Management Plan Review / inspection completed & stakeholders recommend approve for baseline All major and blocking issues should be resolved CRs tracking any remaining (and unresolved) issues Update version # to reflect baselined document (e.g. 1.0) Place under change control
Actions
6/12/2007
2007_06_12_Rqmts.ppt
6/12/2007
2007_06_12_Rqmts.ppt
Change Workflow
New / Proposed
Study
Assigned
Resolved
Integrated
Delivered
Verified
6/12/2007
2007_06_12_Rqmts.ppt
10
Requirements Phase
Outputs:
Completed & Inspected SRS document Completed Inspection form (INS) Time, defect & size data collected Configuration Management Plan* Updated project notebook
Note: On baselining SRS, the document should be placed under change control
6/12/2007
2007_06_12_Rqmts.ppt
11
Requirements Drivers
Functional Needs Statement
SW Requirements Specification
Development
Test
User Documentation
Customer
6/12/2007
2007_06_12_Rqmts.ppt
12
Standards:
IEEE610.12 1990, IEEE Standard Glossary of Software Engineering Terminology IEE830 1998, IEEE Recommended practice for Software Requirements Specifications IEEE 1220-1998 Application and Management of the Systems Engineering Process IEEE 1233-1998 Guide for Developing System Requirements Specifications
6/12/2007
2007_06_12_Rqmts.ppt
13
Correctness:
describes a condition or attribute that is required of the final product & all agree this is the case Also, each rqmts statement must be compatible with prior information
Verifiable:
Requirement can be verified prior to delivery to customer by inspection or test To satisfy, use concrete terms and measurable quantities whenever possible
Consistency:
Assure individual requirements do not conflict with one another
Completeness:
All significant requirements for the product are provided (e.g. input: responses for both valid & invalid data)
6/12/2007
2007_06_12_Rqmts.ppt
14
Quality:
Various attributes including reliability, usability, efficiency, maintainability, portability, etc.
Performance: Regulatory:
Industry Standards (TL9000) Government/Regulatory (e.g. UL)
Security:
6/12/2007 2007_06_12_Rqmts.ppt 15
Security Requirements
Policy: what to secure, against what threats, by what means? Who is authorized? Confidentiality: preventing unauthorized reading or knowledge Integrity: preventing unauthorized modification or destruction Availability: accessible to authorized users Privileges: controlling access and actions based on authorizations Identification & authentication: challenging users to prove identity (e.g. passwords, codes) Correctness: mediation of access to prevent bypassing controls or tampering with system/data Audit: log to assist in identifying when a security attack has been attempted
6/12/2007
2007_06_12_Rqmts.ppt
16
Requirements Identification
Requirements should be numbered or labeled
e.g. Requirement XX Start Requirement XX End Requirement XX comment
Include release (e.g. cycle) number as part of label Traceable to functional need statement (see next slide)
6/12/2007
2007_06_12_Rqmts.ppt
17
Requirements Traceability
Backwards Traceability includes explicit information that identifies the higher level requirements that the lower level requirement derives from
Traceability should cover all phases (e.g. functional need requirements, requirements design, design code, requirements test) Ensures:
nothing is left out of product, change impact assessments
Trace Tables:
Backwards trace table showing link from lower level (e.g. SRS) to higher level (e.g. Strat form)
Part of lower level document
Forwards trace table shows lower level requirements derived from an upper level requirement
Version 2.0 Cycle 2 baseline version Adds the following features . Version 2.1
6/12/2007 2007_06_12_Rqmts.ppt 19
Traceable to functional need statement Inspected & baselined Maintained under change control Document includes structural elements including:
Baseline/change history Approval page Customer documentation specifications
6/12/2007 2007_06_12_Rqmts.ppt 20
6/12/2007
6/12/2007
2007_06_12_Rqmts.ppt
22
Inspections vs Reviews
Inspections Formal, typically requires face to face meetings Measurement data collected Disposition of product agreed to Quality records available Reviews Informal Can be face to face, email exchange Measurement data and quality records optional Typically used for early product work & small code changes
6/12/2007 2007_06_12_Rqmts.ppt 23
Peer Reviews
Review Objectives:
Find defects Improve software element Consider alternatives Possibly, educate reviewers
Types:
Desk Check: informal, typically single peer, effectiveness? Walk-through: informal, several peers, notes taken, data collection optional Variant: test walk-through
6/12/2007
2007_06_12_Rqmts.ppt
24
Inspections
Inspection Objectives
Find defects at earliest possible point Verify to specification (e.g. design to requirements) Verify to standards Collect element and process data Set baseline point
Exit Criteria
All detected defects resolved Outstanding, non-blocking issues tracked
Inspection Logistics
Identify moderator (for TSPi, use process manager) Inspection briefing (identify inspection roles, set date/time for inspection) Review product
Individual reviews Record time spent reviewing Identify defects, but do not log on LOGD form
(defects recorded during inspection on INS & LOGD forms)
Inspection meeting
6/12/2007
Obtain & record preparation data Step through product one line or section at a time Raise defects or questions Defects recorded by moderator on INS form Defects recorded by producer on LOGD form (no need to use Change Requests) Peripheral issues & action items should be recorded in ITL log*
2007_06_12_Rqmts.ppt 26
Conclude meeting
Agree on verification method for defects Agree on disposition (e.g. approved, approved with modification, reinspect)
Rework product & verify fixes (e.g. moderator) Obtain signatures of all inspectors on baseline sheet (file as quality record)
6/12/2007
2007_06_12_Rqmts.ppt
27
Measures
Preparation rate = # pages / average preparation time Inspection rate = # pages / inspection time Inspection defect rate = # major defects / inspection time Defect density = # estimated defects / # of pages Inspection yield = # defects / # estimated defects (individual & team)