Tamplate Pressman

33
SYSTEM SPECIFICATION 1.0 Introduction This section provides an overview of the entire system or product. This document describes all subsystems including hardware, software, human activities, documents, and process. 1.1 Goals and objectives Overall business s goals and project objectives are described. 1.2 System statement of scope A description of the entire system is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail. 1.3 System context The system is placed in a business or product line context. Strategic issues relevant to context are discussed. The intent is for the reader to understand the "big picture." 1.4 Major constraints Any business or product line constraints that will impact the manner in which the system is to be specified, designed, implemented or tested are noted here. 2.0 Functional and Data Description This section describes overall system function and the information domain in which it operates. 2.1 System architecture A context-level model of the system architecture is presented. 2.1.1 Architecture model (e.g., ACD) A context-level model of the system architecture is presented. 2.1.2 Subsystem overview Each subsystem noted in the architecture model is described briefly. 2.2 Data Description Top-level data objects that will be managed/manipulated by the system or product are described in this section. 2.2.1 Major data objects Data objects and their major attributes are described. 2.2.2 Relationships

Transcript of Tamplate Pressman

Page 1: Tamplate Pressman

SYSTEM SPECIFICATION

1.0 Introduction

This section provides an overview of the entire system or product. This document describes all subsystems including hardware, software, human activities, documents, and process.

1.1 Goals and objectives

Overall business s goals and project objectives are described.

1.2 System statement of scope

A description of the entire system is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail.

1.3 System context

The system is placed in a business or product line context. Strategic issues relevant to context are discussed. The intent is for the reader to understand the "big picture."

1.4 Major constraints

Any business or product line constraints that will impact the manner in which the system is to be specified, designed, implemented or tested are noted here.

2.0 Functional and Data Description

This section describes overall system function and the information domain in which it operates.

2.1 System architecture

A context-level model of the system architecture is presented.

2.1.1 Architecture model (e.g., ACD)

A context-level model of the system architecture is presented.

2.1.2 Subsystem overview

Each subsystem noted in the architecture model is described briefly.

2.2 Data Description

Top-level data objects that will be managed/manipulated by the system or product are described in this section.

2.2.1 Major data objects

Data objects and their major attributes are described.

2.2.2 Relationships

Relationships among data objects are described using an ERD- like form. No attempt is made to provide detail at this stage.

2.2.3 System level data model

Page 2: Tamplate Pressman

An ERD for the system is developed (this section may be omitted).

2.3 Interface Description

The system's interface(s) to the outside world are described.

2.3.1 Machine interfaces

Interfaces to other machines (computers or devices) are described.

2.3.2 External system interfaces

Interfaces to other systems, products or networks are described.

2.3.3 Human interface

An overview of any human interfaces to be designed for the system/product is presented.

3.0 Subsystem Description

A description of each subsystem is presented.

3.1 Description for Subsystem n

A detailed description of each subsystem is presented. Section 3.1 is repeated for each of n subsystems.

3.1.1 Subsystem scope

A statement of scope for subsystem n is presented.

3.1.2 Subsystem flow diagram

A diagram showing the flow of information through the subsystem and the transformation that it undergoes is presented.

3.1.3 Subsystem n components

A detailed description for each component of subsystem n is presented. Section 3.1.3 is repeated for each of k components.

3.1.3.1 Component k description (processing narrative)

3.1.3.2 Component k interface description

3.1.4 Performance Issues

Special performance required for the subsystem is specified.

3.1.5 Design Constraints

Any design constraints that will impact the subsystem are noted.

3.1.6 Allocation for Subsystem n

The allocation for implementation (e.g., will the subsystem be implemented in hardware, software, by a human, etc.) is described.

3.2 Diagrammatic model for Subsystem n

Page 3: Tamplate Pressman

A diagrammatic model for each subsystem is presented. Section 3.2 is repeated for each of n subsystems.

4.0 System Modeling and Simulation Results

If system modeling and simulation and/or prototyping is conducted, these are specified here.

4.1 Description of system modeling approach (if used)

The system modeling approach (including tools and/or mathematical models) is described.

4.2 Simulation results

The results of any system simulation are presented with specific emphasis on data throughput, timing, performance, and/or system behavior.

4.3 Special performance issues

Special performance issues are identified.

4.4 Prototyping requirements

If a system prototyping is to be built, its specification and implementation environment are described here.

5.0 Project Issues

An overview of the overall system/product project plan is presented.

5.1 Projected development costs

The results of system-level cost estimates are presented.

5.2 Project schedule

A top-level schedule for the development project is proposed.

6.0 Appendices

Presents information that supplements the System Specification.

6.1 Business Process Descriptions

If the specification is developed for a business system, a description of relevant business processes is presented here.

6.2 Product Strategies

If the specification is developed for a product, a description of relevant product strategy is presented here.

6.3 Supplementary information (as required)

Page 4: Tamplate Pressman

SOFTWARE PROJECT PLAN

1.0 Introduction

This section provides an overview of the software engineering project.

1.1 Project scope

A description of the software is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail.

1.2 Major software functions

A functional decomposition of the software (for use during estimation and scheduling) is developed here.

1.3 Performance/Behavior issues

Any special requirements for performance or behavior are noted here.

1.4 Management and technical constraints

Any special constraints that affect the manner in which the project will be conducted (e.g., limited resources or 'drop dead' delivery date) or the technical approach to development are noted here.

2.0 Project Estimates

This section provides cost, effort and time estimates for the projects

2.1 Historical data used for estimates

Describes the historical data that is relevant to the estimates presented.

2.2 Estimation techniques applied and results

A description of each estimation technique and the resultant estimates are presented here.

2.2.1 Estimation technique m

Tables or equations associated with estimation technique m are presented. Section 2.2.1 is repeated for each of m techniques.

2.2.2 Estimate for technique m

Estimate generated for technique m.

2.3 Reconciled Estimate

The final cost, effort, time (duration) estimate for the project (at this point in time) is presented here.

2.4 Project Resources

People, hardware, software, tools, and other resources required to build the software are noted here.

3.0 Risk Management

This section discusses project risks and the approach to managing them.

Page 5: Tamplate Pressman

3.1 Project Risks

Each project risk is described. The CTC format may be used.

3.2 Risk Table

The complete risk table is presented. Name of risk, probability, impact and RM3 pointer are provided.

3.3 Overview of Risk Mitigation, Monitoring, Management

An overview of RM3 is provided here. The Complete RM3 is provided as a separate document or as a set of Risk Information Sheets.

4.0 Project Schedule

This section presents an overview of project tasks and the output of a project scheduling tool.

4.1 Project task set

The process model, framework activities and task set that have been selected for the project are presented in this section.

4.2 Functional decomposition

A functional breakdown to be used for scheduling is presented here.

4.3 Task network

Project tasks and their dependencies are noted in this diagrammatic form.

4.4 Timeline chart

A project timeline chart is presented. This may include a time line for the entire project or for each staff member.

5.0 Staff Organization

The manner in which staff are organized and the mechanisms for reporting are noted.

5.1 Team structure

The team structure for the project is identified. Roles are defined.

5.2 Management reporting and communication

Mechanisms for progress reporting and inter/intra team communication are identified.

6.0 Tracking and Control Mechanisms

Techniques to be used for project tracking and control are identified.

6.1 Quality assurance and control

An overview of SQA activities is provided. Note that an SQA Plan is developed for a moderate to large project and may be a separate document or included as an appendix.

6.2 Change management and control

Page 6: Tamplate Pressman

An overview of SCM activities is provided. Note that an SCM Plan is developed for a moderate to large project and may be a separate document or included as an appendix.

7.0 Appendix

Supplementary information is provided here.

Page 7: Tamplate Pressman

SOFTWARE QUALITY ASSURANCE (SQA) PLAN

1.0 Introduction

This section provides an overview of the SQA Plan.

1.1 Scope and intent of SQA activities

A description of the overall SQA focus includingobjectives, organizational responsibilities.

1.2 SQA organizational role

Description of where the SQA group sits organizationally (including reporting structure and the manner in which SQA will interact with software engineering teams

2.0 SQA Tasks

This section details all important SQA tasks and assigns responsibility for each. Note that many SQA tasks are performed by software team members. Others may be performed by SQA specialists.

2.1 Task Overview

An overview of each task.

2.1.1 Description of SQA task m

Task is described and responsibility is allocated. Section 2.1.1 is repeated for each of m tasks.

2.1.2 Work products and documentation

SQA work product and documentation produced as a consequence of task m is described.

2.2 Standards, Practices and Conventions (SPC)

SPC that will be used to govern software engineering work are described here.

2.3 SQA Resources

People, hardware, software, tools, and other resources required to perform SQA tasks are noted here.

3.0 Reviews and Audits

This section discusses major project reviews conducted by SQA staff and software team members

3.1 Generic Review Guidelines

A set of guidelines for all formal technical reviews (FTR's) is presented in this section.

3.1.1 Conducting a Review

General guidelines for conducting a review.

3.1.2 Roles and Responsibilities

The roles people play during a FTR and the responsibilities of each player.

Page 8: Tamplate Pressman

3.1.3 Review work products

Documents, forms, lists produced as a consequence of the FTR.

3.2 Formal Technical Reviews

A description of the specific character and intent of each major FTR conducted during the software process.

3.2.n Description of review n

The sections that follow are included for each Section 3.2.n

3.2.n.1 Description and focus of the review

3.2.n.2 Timing of the review

3.2.n.3 Description and focus of the review

3.2.n.4 Work products produced

3.2.n.5 Review n checklist

The sections that follow represent typical reviews conducted as part of a software engineering project and are included as part of Section 3.2.n

3.2.1 System specification review

3.2.2 Software project plan review

3.2.3 RMMM review

3.2.4 Requirements reviews (models, specification)

3.2.5 Data design review

3.2.6 Architectural design review

3.2.7 Interface (GUI) design review

3.2.8 Component design review(s)

3.2.9 Code Reviews

3.2.10 Test specification review

3.2.11 Change control reviews and audits

3.3 SQA Audits

A description of audits performed by the SQA group with the intent of assessing how well SQA and software engineering activities are being conducted on a project.

4.0 Problem Reporting and Corrective Action/Follow-up

This section describes problem reporting mechanisms that occur as a consequence of the FTR's that are conducted and the means for corrective action and follow-up.

4.1 Reporting mechanisms

Page 9: Tamplate Pressman

Describes how and to whom problems are reported

4.2 Responsibilities

Describes who has responsibility for corrective actions and follow-up.

4.3 Data collection and evaluation

Describes the manner in which error/defect data are collected and stored for future or real-time evaluation.

4.4 Statistical SQA

Describes the quantitative techniques that will be applied to error/defect data in an effort to discern trends and improvement.

5.0 Software Process Improvement Activities

The SQA group (and others) is often chartered with responsibility for software process improvement (SPI). This section describes the work associated with SPI.

5.1 Goal and objectives of SPI

The goal and objectives of SPI are defined.

5.2 SPI tasks and responsibilities

Specific to the SQA group

6.0 Software Configuration Management Overview

A brief overview of the content of the SCM Plan is presented here. Alternatively, the SCM plan is referenced.

7.0 SQA Tools, Techniques, Methods

Specialized tools, techniques and methods to be used by the SQA group are described here.

8.0 Appendix

Supplementary information is provided here.

Page 10: Tamplate Pressman

TECHNICAL REVIEW SUMMARY REPORT AND ISSUES LIST

The technical review summary report (TRSR) and issue list are often represented as printed or electronic forms rather than documents. The outline that follows is intended to provide an indication of the content of the TRSR. The actual organization of the TRSR may vary depending on its implementation.

1.0 Work Product Identification

This section identifies the software engineering workproduct (or portion of a workproduct) that has undergone review.

1.1 Name, identification and description of workproduct

The name, version/control numbers of the work product is specified, including page numbers if a review of only part of a document is conducted. A brief description is provided.

1.2 Producer

The name of the person who produced the work product.

1.3 Reviewers

The names of all review participants and their roles.

1.4 Date, Location, and time

When and where the review was conducted.

2.0 Review Summary

This section presents a brief summary of the outcome of the review including major problems (if any) and workproduct appraisal.

2.1 Comments

Discusses the findings of the review team.

2.2 Appraisal

This is a checklist of three options: accepted, accepted with minor modification; not accepted rework required.

2.3 Reviewer signatures

The signatures all reviewers

3.0 Issues List

This section contains a list of all issues raised during the review. This list may be organized into errors that require correction and issues that require investigation. All entries on the issues list require some action and follow-up must be conducted.

Page 11: Tamplate Pressman

SOFTWARE CONFIGURATION MANAGEMENT (SCM) PLAN

1.0 Introduction

This section provides an overview of the SCM Plan.

1.1 Scope and intent of SCM activities

A description of the overall SCM focus including objectives, organizational responsibilities.

1.2 SCM organizational role

Description of where the SCM group sits organizationally (including reporting structure and the manner in which SCM will interact with software engineering teams

2.0 SCM Tasks

This section details all important SCM tasks and assigns responsibility for each. Note that many SCM tasks are performed by software team members. Others may be performed by SCM specialists.

2.1 Identification

A description of how SCI's will be identified for SCM.

2.1.1 Description

Task is described and responsibility is allocated.

2.1.2 Work products and documentation

Identification work products and documentation produced as a consequence are described.

2.2 Configuration Control

A description of how change will be controlled

2.2.1 Description

The configuration control process is described, including a complete process diagram or task flow. Responsibilities for tasks are also described here.

2.2.2 Description of configuration control task m

Task is described and responsibility is allocated. Section 2.2.2 is repeated for each of m tasks.

2.2.3 Work products and documentation

SCM work product and documentation produced as a consequence of task m is described.

2.3 Version Control

A description of how different versions of the software or SCI's will be controlled.

2.3.1 Description

The version control process is described

2.3.2 Description of version control task m

Page 12: Tamplate Pressman

Task is described and responsibility is allocated. Section 2.3.2 is repeated for each of m tasks.

2.3.3 Work products and documentation

SCM work product and documentation produced as a consequence of task m is described.

2.4 Configuration status accounting (CSA)

A description of how information about changes is communication to members of the software team and others with a need to know.

2.4.1 Description

CSA tasks are described and responsibility is allocated.

2.4.2 Work products and documentation

CSA work products and documentation produced as a consequence are described.

2.5 Audits and Reviews

A description of SCM audits and review is presented here.

2.5.1 Description

The specific audits and reviews (along with responsibilities) are described here.

2.5.2 Work products and documentation

Audit work products are described.

2.6 Data collection and evaluation

Describes the manner in which change data are collected and stored for future or real-time evaluation.

3.0 Standards, Practices and Conventions (SPC)

SPC that will be used to govern SCM work is described here.

4.0 SCM Resources

People, hardware, software, tools, and other resources required to perform SQA tasks are noted here.

5.0 Software Quality Assurance Overview

A brief overview of the content of the SQA Plan is presented here. Alternatively, the SQA plan is referenced.

6.0 SCM Tools, Techniques, Methods

Specialized tools, techniques and methods to be used by the SCM group are described here.

7.0 Appendix

Supplementary information is provided here.

SOFTWARE CHANGE REQUEST

Change request, change report and engineering change order are generated as part of the configuration control

Page 13: Tamplate Pressman

activity within the SCM process. These documents are often represented as printed or electronic forms. The outline that follows is intended to provide an indication of the content of each. The actual structure of this SCM information may vary depending on its implementation.

The change document is completed whenever a formal request for change of a base lined SCI is requested.

1.0 SCI Identification

This section identifies the SCI for which a change has been requested.

1.1 Name, identification and description of SCI(s)

The name, version/control numbers of the SCI is specified, including page numbers if a document is involved. A brief description is provided.

1.2 Requester

The name of the person requesting the change

1.3 Contact information

How to contact the requester.

1.4 Date, location, and time

When and where the change was requested

2.0 Description of the change

This section presents a brief description of the requested change

2.1 Description

This section presents a detailed description of the circumstances that precipitated the change reqest and the request desired.

2.2.1 Underlying circumstances

Background information regarding the request.

2.2.2 Examples

Supporting information, e.g., printouts containing an error in a report or an incorrect screen image

2.2.3 The change

A detailed discussion of the change requested.

2.2 Reasons and justification

This section discusses why the change has been requested and the justification for the request.

2.3 Perceived affects

The requester's perception of the affects of the change.

2.4 Alternatives

Page 14: Tamplate Pressman

The requester's perception of any alternatives to the change.

2.5 Requester priority

The priority assigned by the requester to the work generally chosen from a five-value scale

Page 15: Tamplate Pressman

SOFTWARE CHANGE REPORT

Change request, change report and engineering change order are generated as part of the configuration control activity within the SCM process. These documents are often represented as printed or electronic forms. The outline that follows is intended to provide an indication of the content of each. The actual structure of this SCM information may vary depending on its implementation. The software change report (SCR) is completed as a consequence of a formal request for change of a baselined SCI. The SCR is completed after the change request has been evaluated by software engineering staff.

1.0 SCI identification

This section identifies the SCI(s) for which a change has been requested.

1.1 Name, identification and description of SCI's

The name, version/control numbers of the SCI is specified, including page numbers if a document is involved. A brief description is provided.

1.2 Requester

The name of the person requesting the change .

1.3 Evaluator

The name of the person who has evaluated the change request.

1.4 Contact information

How to contact the requester and the evaluator.

1.5 Date, Location, and time

When and where the change report was generated.

2.0 Evaluation of the change request

This section presents a brief evaluation of the requested change.

2.1 Description of SCI(s)affected

This section discussed the SCIís to be affected by the requested change.

2.2 Change categorization

This section places the change into one or more generic change categories.

2.3 Scope of the change

The evaluator's assessment of the scope of the change including a listing of all SCIís that will be affected and all users who must be informed.

2.3.1 Technical work required

A description of the work required to accomplish the change

2.3.2 Tools/special resources

Required tools or other special resources are noted here.

2.4 Interoperability effects

Page 16: Tamplate Pressman

The impact of the change on other systems.

2.5 Technical risks

The risks associated with making the change are described.

3.0 Cost Assessment

This section presents a cost assessment of the requested change including an estimate of effort and time required.

4.0 Recommendation/Disposition

This section presents the evaluator's recommendation regarding the change, its internal priority, and the ultimate disposition of the request, based on further evaluation by the CCB/CCA.

4.1 Recommendation

Should the change be made?

4.2 Internal priority

How important is this change in light of on-going work and other business/product considerations?

4.3 Disposition

Will the change be made, and if so, when?

Page 17: Tamplate Pressman

ENGINEERING CHANGE ORDER

Change request, change report and engineering change order are generated as part of the configuration control activity within the SCM process. These documents are often represented as printed or electronic forms. The outline that follows is intended to provide an indication of the content of each. The actual structure of this SCM information may vary depending on its implementation. The engineering change order (ECO) is completed when a change request has been approved for a baselined SCI. The ECO is a mini-requirements specification for the change.

1.0 SCI Identification

This section identifies the SCI(s) for which a change will be made.

1.1 Name, identification and description of SCI(s)

The name, version/control numbers of the SCI is specified, including page numbers if a document is involved. A brief description is provided.

1.2 Requester

The name of the person requesting the change.

1.3 Evaluator

The name of the person who has evaluated the change request.

1.4 Contact information

How to contact the requester and the evaluator.

2.0 Description of the change to be made

This section presents a brief description of the change.

2.1 Description of SCI(s) affected

This section discusses the SCIís to be affected by the requested change.

2.2 Change categorization

This section places the change into one or more generic change categories.

2.3 Scope of the change

The evaluator's assessment of the scope of the change including a listing of all SCIís that will be affected and all user who must be informed.

o 2.3.1 Technical work required

A description of the work required to accomplish the change.

2.3.2 Tools/special resources

Required tools or other special resources are noted here.

2.4 Interoperability effects

The impact of the change on other systems.

Page 18: Tamplate Pressman

2.5 Technical risks

The risks associated with making the change are described.

3.0 Analysis and design modifications

A description of the analysis and design modifications that will be required.

3.1 Description of analysis model modifications

Changes required to the analysis model are described. Data, function and behavior models are all considered.

3.2 Description of design model modifications

Changes required to the design model are described. Data, architectural, interface and component-level models are all considered.

4.0 Validation requirements

A description of the SQA activities and testing approach required to ensure that the change has been made without side effects.

4.1 Review plan

Describes the types of reviews that will be conducted.

4.2 Test plan

Describes the regression tests and new tests that will be required.

Page 19: Tamplate Pressman

SOFTWARE REQUIREMENTS SPECIFICATION

1.0 Introduction

This section provides an overview of the entire requirement document. This document describes all data, functional and behavioral requirements for software.

1.1 Goals and objectives

Overall goals and software objectives are described.

1.2 Statement of scope

A description of the software is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail.

1.3 Software context

The software is placed in a business or product line context. Strategic issues relevant to context are discussed. The intent is for the reader to understand the 'big picture'.

1.4 Major constraints

Any business or product line constraints that will impact the manner in which the software is to be specified, designed, implemented or tested are noted here.

2.0 Usage scenario

This section provides a usage scenario for the software. It organized information collected during requirements elicitation into use-cases.

2.1 User profiles

The profiles of all user categories are described here.

2.2 Use-cases

All use-cases for the software are presented.

2.3 Special usage considerations

Special requirements associated with the use of the software are presented.

3.0 Data Model and Description

This section describes information domain for the software

3.1 Data Description

Data objects that will be managed/manipulated by the software are described in this section.

3.1.1 Data objects

Data objects and their major attributes are described.

3.1.2 Relationships

Page 20: Tamplate Pressman

Relationships among data objects are described using an ERD- like form. No attempt is made to provide detail at this stage.

3.1.3 Complete data model

An ERD for the software is developed

3.1.4 Data dictionary

A reference to the data dictionary is provided. The dictionary is maintained in electronic form.

4.0 Functional Model and Description

A description of each major software function, along with data flow or class hierarchy (OO) is presented.

4.1 Description for Function n

A detailed description of each software function is presented. Section 4.1 is repeated for each of n functions.

4.1.1 Processing narrative (PSPEC) for function n

A processing narrative for function n is presented.

4.1.2 Function n flow diagram

A diagram showing the flow of information through the function and the transformation it undergoes is presented.

4.1.3 Function n interface description

A detailed description of the input and output interfaces for the function is presented.

4.1.4 Function n transforms

A detailed description for each transform (subfunction) for function n is presented. Section 4.1.4 is repeated for each of k transforms.

4.1.4.1 Transform k description (processing narrative, PSPEC)

4.1.4.2 Transform k interface description

4.1.4.3 Transform k lower level flow diagrams

4.1.4.4 Transform k interface description

4.1.5 Performance Issues

Special performance required for the subsystem is specified.

4.1.6 Design Constraints

Any design constraints that will impact the subsystem are noted.

4.2 Software Interface Description

The software interface(s)to the outside world is(are) described.

Page 21: Tamplate Pressman

4.2.1 External machine interfaces

Interfaces to other machines (computers or devices) are described.

4.2.2 External system interfaces

Interfaces to other systems, products or networks are described.

4.2.3 Human interface

An overview of any human interfaces to be designed for the software is presented.

4.3 Control flow description

The control flow for the system is presented with reference to Section 5.0 of this document.

5.0 Behavioral Model and Description

A description of the behavior of the software is presented.

5.1 Description for software behavior

A detailed description of major events and states is presented in this section.

5.1.1 Events

A listing of events (control, items) that will cause behavioral change within the system is presented.

5.1.2 States

A listing of states (modes of behavior) that will result as a consequence of events is presented.

5.2 State Transition Diagrams

Depict the overall behavior of the system.

5.3 Control specification (CSPEC)

Depict the manner in which control is managed by the software.

6.0 Restrictions, Limitations, and Constraints

Special issues which impact the specification, design, or implementation of the software are noted here.

7.0 Validation Criteria

The approach to software validation is described.

7.1 Classes of tests

The types of tests to be conducted are specified, including as much detail as is possible at this stage. Emphasis here is on black- box testing.

7.2 Expected software response

The expected results from testing are specified.

Page 22: Tamplate Pressman

7.3 Performance bounds

Special performance requirements are specified.

8.0 Appendices

Presents information that supplements the Requirements Specification

8.1 System traceability matrix

A matrix that traces stated software requirements back to the system specification.

8.2 Product Strategies

If the specification is developed for a product, a description of relevant product strategy is presented here.

8.3 Analysis metrics to be used

A description of all analysis metrics to be used during the analysis activity is noted here.

8.4 Supplementary information (as required)

Page 23: Tamplate Pressman

SOFTWARE DESIGN SPECIFICATION

1.0 Introduction

This section provides an overview of the entire design document. This document describes all data, architectural, interface and component-level design for the software.

1.1 Goals and objectives

Overall goals and software objectives are described.

1.2 Statement of scope

A description of the software is presented. Major inputs, processing functionality, and outputs are described without regard to implementation detail.

1.3 Software context

The software is placed in a business or product line context. Strategic issues relevant to context are discussed. The intent is for the reader to understand the 'big picture'.

1.4 Major constraints

Any business or product line constraints that will impact he manner in which the software is to be specified, designed, implemented or tested are noted here.

2.0 Data design

A description of all data structures including internal, global, and temporary data structures.

2.1 Internal software data structure

Data structures that are passed among components the software are described.

2.2 Global data structure

Data structured that are available to major portions of the architecture are described.

2.3 Temporary data structure

Files created for interim use are described.

2.4 Database descriptio

Database(s) created as part of the application is(are) described.

3.0 Architectural and component-level design

A description of the program architecture is presented.

3.1 Program Structure

A detailed description the program structure chosen for the application is presented.

3.1.1 Architecture diagram

A pictorial representation of the architecture is presented.

Page 24: Tamplate Pressman

3.1.2 Alternatives

A discussion of other architectural styles considered is presented. Reasons for the selection of the style presented in Section3.1.1 are provided.

3.2 Description for Component n

A detailed description of each software component contained within the architecture is presented. Section 3.2 is repeated for each of n components.

3.2.1 Processing narrative (PSPEC) for component n

A processing narrative for component n is presented.

3.2.2 Component n interface description.

A detailed description of the input and output interfaces for the component is presented.

3.2.3 Sub-Component n.m processing detail

A detailed algorithmic description for each sub-component within the component n is presented. Section 3.2.3 is repeated for each of the m sub-components of component n.

3.2.3.1 Interface descriptionA description of sub-component m inputs and outputs is presented.

3.2.3.2 Algorithmic model (e.g., PDL)The pseudocode listing for sub-component m is presented.

3.2.3.3 Restrictions/limitationsThe external environment and/or infrastructure that must exist for sub-component m to operate correctly is provided.

]3.2.3.4 Local data structuresThe data structures used within sub-component m are presented.

3.2.3.5 Performance issuesInformation on topics that may affect the run-time performance, security, or computational accuracy of this sub-component are presented.

3.2.3.6 Design constraintsAttributes of the overall software design (including data structures, OS features, I/O, and interoperable systems) that constrain the design of this sub-component are presented.

3.3 Software Interface Description

The software's interface(s) to the outside world are described.

3.3.1 External machine interfaces

Interfaces to other machines (computers or devices) are described.

3.3.2 External system interfaces

Interfaces to other systems, products, or networks are described.

3.3.3 Human interface

Page 25: Tamplate Pressman

An overview of any human interfaces to be designed for the software is presented. See Section 4.0 for additional detail.

4.0 User interface design

A description of the user interface design of the software is presented.

4.1 Description of the user interface

A detailed description of user interface including screen images or prototype is presented.

4.1.1 Screen images

Representation of the interface form the user's point of view.

4.1.2 Objects and actions

All screen objects and actions are identified.

4.2 Interface design rules

Conventions and standards used for designing/implementing the user interface are stated.

4.3 Components available

GUI components available for implementation are noted.

4.4 UIDS description

The user interface development system is described.

5.0 Restrictions, limitations, and constraints

Special design issues which impact the design or implementation of the software are noted here.

6.0 Testing Issues

Test strategy and preliminary test case specification are presented in this section.

6.1 Classes of tests

The types of tests to be conducted are specified, including as much detail as is possible at this stage. Emphasis here is on black-box and white-box testing.

6.2 Expected software response

The expected results from testing are specified.

6.3 Performance bounds

Special performance requirements are specified.

6.4 Identification of critical components

Those components that are critical and demand particular attention during testing are identified.

7.0 Appendices

Page 26: Tamplate Pressman

Presents information that supplements the design specification.

7.1 Requirements traceability matrix

A matrix that traces stated components and data structures to software requirements is developed.

7.2 Packaging and installation issues

Special considerations for software packaging and installation are presented.

7.3 Design metrics to be used

A description of all design metrics to be used during the design activity is noted here.

7.4 Supplementary information (as required)

Page 27: Tamplate Pressman

TEST SPECIFICATION

1.0 Introduction

This section provides an overview of the entire test document. This document describes both the test plan and the test procedure.

1.1 Goals and objectives

Overall goals and objectives of the test process are described.

1.2 Statement of scope

A description of the scope of software testing is developed. Functionality/features/behavior to be tested is noted. In addition any functionality/features/behavior that is not to be tested is also noted.

1.3 Major constraints

Any business, product line or technical constraints that will impact the mannerin which the software is to be tested are noted here.

2.0 Test Plan

This section describes the overall testing strategy and the project management issues that are required to properly execute effective tests.

2.1 Software (SCIís) to be tested

The software to be tested is identified by name. Exclusions are noted explicitly.

2.2 Testing strategy

The overall strategy for software testing is described.

2.2.1 Unit testing

The strategy for unit tested is described. This includes an indication of the components that will undergo unit tests or the criteria to be used to select components for unit test. Test cases are NOT included here.

2.2.2 Integration testing

The integration testing strategy is specified. This section includes a discussion of the order of integration by software function. Test cases are NOT included here.

2.2.3 Validation testing

The validation testing strategy is specified. This section includes a discussion of the order of validation by software function. Test cases are NOT included here.

2.2.4 High-order testing

The high-order testing strategy is specified. This section includes a discussion of the types of high order tests to be conducted, the responsibility for those tests. Test cases are NOT included here.

2.3 Testing resources and staffing

Specialized testing resources are described and staffing is defined. The role of any ITG is also defined.

Page 28: Tamplate Pressman

2.4 Test work products

The work products produced as a consequence of the testing strategy are identified.

2.5 Test record keeping

Mechanisms for storing and evaluating test results are specified.

2.6 Test metrics

A description of all test metrics to be used during the testing activity is noted here.

2.7 Testing tools and environment

A description of the test environment, including tools, simulators, specialized hardware, test files, and other resources is presented here.

2.8 Test schedule

A detailed schedule for unit, integration, and validation testing as well as high order tests is described.

3.0 Test Procedure

This section describes as detailed test procedure including test tactics and test cases for the software.

3.1 Software (SCIís) to be tested

The software to be tested is identified by name. Exclusions are noted explicitly.

3.2 Testing procedure

The overall procedure for software testing is described.

3.2.1 Unit test cases

The procedure for unit testing is described for each software component (that will be unit tested) is presented. This section is repeated for all components i.

3.2.1.2 Stubs and/or drivers for component i

3.2.1.3 Test cases component i

3.2.1.4 Purpose of tests for component i

3.2.1.5 Expected results for component i

3.2.2 Integration testing

The integration testing procedure is specified.

3.2.2.1 Testing procedure for integration

3.2.2.2 Stubs and drivers required

3.2.2.3 Test cases and their purpose

3.2.2.4 Expected results

Page 29: Tamplate Pressman

3.2.3 Validation testing

The validation testing procedure is specified.

3.2.3.1 Testing procedure for validation

3.2.3.3 Expected results

3.2.3.4 Pass/fail criterion for all validation tests

3.2.4 High-order testing (a.k.a. System Testing)

The high-order testing procedure is specified. For each of the high order tests specified below, the test procedure, test cases, purpose, specialized requirements and pass/fail criteria are specified. It should be noted that not all high-order test methods noted in Sections 3.2.4.n will be conducted for every project.

3.2.4.1 Recovery testing

3.2.4.2 Security testing

3.2.4.3 Stress testing

3.2.4.4 Performance testing

3.2.4.5 Alpha/beta testing

3.2.4.6 Pass/fail criterion for all validation tests

3.3 Testing resources and staffing

Specialized testing resources are described and staffing is defined. The role of any ITG is also defined.

3.4 Test work products

The work products produced as a consequence of the testing procedure are identified.

3.5 Test record keeping and test log

Mechanisms for storing and evaluating test results are specified. The test log is used to maintain a chronological record of all tests and their results.