1、6/12/2007,2007_06_12_Rqmts.ppt,1,Team Software Project (TSP) June 12, 2007Requirements Inspection & High Level Designs,6/12/2007,2007_06_12_Rqmts.ppt,2,Outline,Key Discussions from last week (Project Risks) Configuration Management Schedule & Cross Team Inspections Requirements Overview General Spec
2、ifics to look for in LOC Counter SRS Reviews & Inspection Summary SRS Inspection Process Measurement Data CollectionDesign Phase Overview,6/12/2007,2007_06_12_Rqmts.ppt,3,SRS & Test Plan,System Test manager participates in SRS inspection of other team* Reviews for clarity and completeness of require
3、ments Requirements provide basis for test plan Test plan (baseline next week) inspected by other team*,6/12/2007,2007_06_12_Rqmts.ppt,4,Milestones,Requirements (SRS) Initial Draft out for review June 10 Final draft for inspection June 12 Inspection June 12 Baselined June 15 System Test Plan Draft ou
4、t for review June 17 Inspection June 19 Baselined June 22 High Level Design (SDS) Inspected & Baselined June 19,6/12/2007,2007_06_12_Rqmts.ppt,5,Configuration Management Process,Three aspects: Change Tracking Version Control Library Objectives: Product content known & available at all times Product
5、configuration is documented & provides known basis for changes Products labeled & correlated w/ associated requirements, design & product info Product functions traceable from requirements to delivery All product contents properly controlled & protected Proposed changes identified & evaluated for im
6、pact prior to go/no go decisions,6/12/2007,2007_06_12_Rqmts.ppt,6,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, doc
7、uments, 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,7,Configuration Management Plan,Configuration identification Name Configuration items Owner Storage location Configuration
8、control procedure Process for making changes, lock-out procedures (e.g. check-out, check-in procedures) Configuration control board (CCB) Reviews all change requests Determine if change is appropriate, well understood & resources available Approvals, commitments ? Defects: holding for CCB vs. urgenc
9、y of change ? 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,8,Baseline Considerations,Criteria Defined in Config
10、uration 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 Actions Update version # to reflect baselined document (e.g. 1.0) Place under change controlProject
11、“Baseline” snapshot of CIs, baselined & current versions,6/12/2007,2007_06_12_Rqmts.ppt,9,Automated Configuration Mgmt,Lucent: Sablime / SBCS & SCCS Rational: DDTS / ClearCase Perforce Software: Perforce Microsoft: Visual SourceSafe MKS,6/12/2007,2007_06_12_Rqmts.ppt,10,Change Workflow,New / Propose
12、d,Assigned,Resolved,Study,Integrated,Delivered,Verified,NoChange Deferred Declined,6/12/2007,2007_06_12_Rqmts.ppt,11,Requirements Phase,Outputs: Completed & Inspected SRS document Completed Inspection form (INS) Time, defect & size data collected Configuration Management Plan* Updated project notebo
13、okNote: On baselining SRS, the document should be placed under change control,6/12/2007,2007_06_12_Rqmts.ppt,12,Requirements Drivers,Functional Needs Statement,SW Requirements Specification,Development,Test,Customer,User Documentation,6/12/2007,2007_06_12_Rqmts.ppt,13,Software Requirements Specifica
14、tion (SRS),Objective: Provide information necessary for understanding the proposed product and to explain/justify the need for various product attributes (user code & documentation)Standards: IEEE610.12 1990, IEEE Standard Glossary of Software Engineering Terminology IEE830 1998, IEEE Recommended pr
15、actice 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,14,Software Requirements Statements,Unambiguous: All involved (e.g. custo
16、mers, developers, testers) interpret statement in same way Glossary defining each important term can help 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
17、: 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 pro
18、vided (e.g. input: responses for both valid & invalid data),6/12/2007,2007_06_12_Rqmts.ppt,15,Software Requirements Types,Functional: Specific actions that program needs to perform in order to meet users needs Defined or quantified based upon customer expectations Quality: Various attributes includi
19、ng 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,16,Security Requirements,Policy: what to secure, against what threats, by what means? Who is authori
20、zed? 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 prov
21、e 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,17,Requirements Identification,Requirements should be numbered
22、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,18,Requirements Traceability,Backwards Traceability includes explicit information
23、 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: Ba
24、ckwards 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 LOC Project generate a backwards trace table*,6/12/2007,2007_06_12_Rqmts.ppt,19,SRS
25、Document Baseline/Change History,Tracks all versions and modifications Version numbering scheme documented in CM plan Change request information tracks to CRse.g. Version 0.1 Pre-baseline version for review Version 1.0 Cycle 1 baseline version Version 1.1 CR 101 Clarify security requirements CR 102
26、delete support for VB files Version 2.0 Cycle 2 baseline version Adds the following features . Version 2.1 ,6/12/2007,2007_06_12_Rqmts.ppt,20,SRS Characteristics Summary,Detailed, clearly delineated, concise, unambiguous & testable (quantifiable) Changes Defects Clarifications Additions / Enhancemen
27、ts Requirements should be numbered or labeled e.g. Requirement XX Start Requirement XX End Requirement XX comment Traceable to functional need statement Inspected & baselined Maintained under change control Document includes structural elements including: Baseline/change history Approval page Custom
28、er documentation specifications,6/12/2007,2007_06_12_Rqmts.ppt,21,LOC Counter Requirements,(See also TSPi pp112-113 ) Overall description and framework of GUI (if provided) Input File formats (ANSI text) & extensions (.c, .cc) supported Limits on file names (e.g. max characters) Additional features
29、(e.g. browsing for input file) Error cases, one or both files empty, non-existent, unable to be opened Results of Comparison Algorithm Output if identical lines moved (e.g. Line A, B, C, D vs. Line A, C, B, D) Treatment of comments (in-line & alone), blank lines, braces (LOC counting) Multi-line sta
30、tements / comments Output Format and location of output (e.g. screen, file, directory) Errors All errors including messages (invalid inputs, algorithm errors, etc.) Other Product installation & execution User documentation plan Response time Security Scalability (e.g. max file sizes supported) Concu
31、rrency HW requirements (e.g. processor, hard drive, display resolution, OS, peripherals such as mouse),6/12/2007,2007_06_12_Rqmts.ppt,22,Why Do Reviews / Inspections?,Can identify defects early in the processmore efficient (i.e. cheaper) defect removal Leverages knowledge of multiple engineers Lever
32、ages different viewpoints Improves defect detection odds Broadens understanding of product being inspected*,6/12/2007,2007_06_12_Rqmts.ppt,23,Inspections vs Reviews,Inspections Formal, typically requires face to face meetings Measurement data collected Disposition of product agreed to Quality record
33、s 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,24,Peer Reviews,Review Objectives: Find defects Improve software element Consider alternatives Poss
34、ibly, 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,25,Inspections,Inspection Objectives Find defects at earliest possible poi
35、nt 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 Techniques & Methods Generic checklists & standards Inspectors prepared in advance Foc
36、us on problems, not on resolution Peers only “Mandatory” data collection Roles: Moderator, reader, recorder, inspector, author,6/12/2007,2007_06_12_Rqmts.ppt,26,Inspection Logistics,Identify moderator (for TSPi, use process manager) Inspection briefing (identify inspection roles, set date/time for i
37、nspection) 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) Typically want 3-5 days for an adequate review period Inspection meeting Obtain & record preparation data Step through produ
38、ct 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*,6/12/2007,2007_06_12_Rqmts.ppt,27,Inspection Logistics (con
39、tinued),Estimate remaining defects TBD (but, for each defect, record all members who identified it) Conclude meeting Agree on verification method for defects Agree on disposition (e.g. approved, approved with modification, re-inspect) Rework product & verify fixes (e.g. moderator) Obtain signatures
40、of all inspectors on baseline sheet (file as quality record),6/12/2007,2007_06_12_Rqmts.ppt,28,Measurement Data & Metrics,Base Metrics # & Type of Defects found (major, minor) For each defect, who found # of pages inspected, preparation time (per inspector), inspection timeMeasures Preparation rate
41、= # 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)SRS Phase Defect Containment (%) = 100% * # Defects removed step / ( Incoming defects + Injected defects),
