Team Software Project TSP June 12 2007 Requirements

Team Software Project (TSP) June 12, 2007 Requirements Inspection & High Level Designs 6/12/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 Design Phase Overview 6/12/2007_06_12_Rqmts. ppt

SRS & Test Plan System Test manager participates in SRS inspection of other team** Reviews for clarity and completeness of requirements Requirements provide basis for test plan Test plan (baseline next week) inspected by other team** 6/12/2007_06_12_Rqmts. ppt

Milestones Requirements (SRS) Initial Draft out for review Final draft for inspection Inspection Baselined June 10 June 12 June 15 System Test Plan Draft out for review Inspection Baselined June 17 June 19 June 22 High Level Design (SDS) Inspected & Baselined 6/12/2007 June 19 2007_06_12_Rqmts. ppt

Configuration Management Process Three aspects: Change Tracking Version Control Library Objectives: Product content known & available at all times Product 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 impact prior to go/no go decisions 6/12/2007_06_12_Rqmts. ppt 5

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_06_12_Rqmts. ppt 6

Configuration Management Plan Configuration identification • Name Configuration items • Owner • Storage location Configuration 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. urgency 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_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 Actions – – Update version # to reflect baselined document (e. g. 1. 0) Place under change control Project “Baseline” – snapshot of CIs, baselined & current versions 6/12/2007_06_12_Rqmts. ppt 8

Automated Configuration Mgmt Lucent: Sablime / SBCS & SCCS Rational: DDTS / Clear. Case Perforce Software: Perforce Microsoft: Visual Source. Safe MKS 6/12/2007_06_12_Rqmts. ppt 9

Change Workflow New / Proposed Study Assigned No. Change Deferred Declined Resolved Integrated Delivered Verified 6/12/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_06_12_Rqmts. ppt

Requirements Drivers Functional Needs Statement SW Requirements Specification Development 6/12/2007 Test User Documentation 2007_06_12_Rqmts. ppt Customer

Software Requirements Specification (SRS) Objective: Provide information necessary for understanding the proposed product and to explain/justify the need for various product attributes (user code & documentation) Standards: IEEE 610. 12 – 1990, IEEE Standard Glossary of Software Engineering Terminology IEE 830 – 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_06_12_Rqmts. ppt

Software Requirements Statements • Unambiguous: All involved (e. g. customers, 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: 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_06_12_Rqmts. ppt

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 including reliability, usability, efficiency, maintainability, portability, etc. • Performance: • Regulatory: Industry Standards (TL 9000) Government/Regulatory (e. g. UL) • Security: 6/12/2007_06_12_Rqmts. ppt

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_06_12_Rqmts. ppt

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_06_12_Rqmts. ppt

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 LOC Project – generate a backwards trace table* 6/12/2007_06_12_Rqmts. ppt

SRS Document Baseline/Change History Tracks all versions and modifications Version numbering scheme documented in CM plan Change request information tracks to CRs e. 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 – delete support for VB files Version 2. 0 – Cycle 2 baseline version Adds the following features …. Version 2. 1 … 6/12/2007_06_12_Rqmts. ppt

SRS Characteristics Summary Detailed, clearly delineated, concise, unambiguous & testable (quantifiable) Changes Defects Clarifications Additions / Enhancements 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 6/12/2007_06_12_Rqmts. ppt Customer documentation specifications

LOC Counter Requirements (See also TSPi pp 112 -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 (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 statements / 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) Concurrency HW requirements (e. g. processor, hard drive, display resolution, OS, peripherals such as mouse) 6/12/2007_06_12_Rqmts. ppt

Why Do Reviews / Inspections? Can identify defects early in the process more efficient (i. e. cheaper) defect removal Leverages knowledge of multiple engineers Leverages different viewpoints Improves defect detection odds Broadens understanding of product being inspected* 6/12/2007_06_12_Rqmts. ppt

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_06_12_Rqmts. ppt

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_06_12_Rqmts. ppt

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 Techniques & Methods Generic checklists & standards Inspectors prepared in advance Focus on problems, not on resolution Peers only “Mandatory” data collection Roles: Moderator, reader, recorder, inspector, author 6/12/2007_06_12_Rqmts. ppt

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) – Typically want 3 -5 days for an adequate review period 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

Inspection Logistics (continued) 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, reinspect) Rework product & verify fixes (e. g. moderator) Obtain signatures of all inspectors on baseline sheet (file as quality record) 6/12/2007_06_12_Rqmts. ppt

Measurement Data & Metrics Base Metrics # & Type of Defects found (major, minor) For each defect, who found # of pages inspected, preparation time (per inspector), inspection time 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) SRS Phase Defect Containment (%) = 100% * # Defects removed @ step / ( Incoming defects + Injected defects) 6/12/2007_06_12_Rqmts. ppt