APPENDIX D

Managing Software Requi= rements; Second Edition - A Use Case Approach - Appendix D – Supplementary Specification Template

Note: The publisher has gra= nted permission for readers of the book to use this electronic template in their= projects. The following permission must be included in any electronic reproduction:

Leffingwell/Widrig, MANAGING SOFTWA= RE REQUIREMENTS 2E, C 2003 Pearson
Education, Inc. Reproduced by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley. ALL RIGHTS RESERVED.

Supplemen= tary Specification Template

The supplementary specification con= tains three major classes of software requirements. First, it contains those functional requirements that are n= ot expressed in the use cases. Second, it contains nonfunctional requirements, those requirements that describe attributes of the system and of the systems environment, including items su= ch as usability, reliability, and performance requirements, as well as legal, regulatory, and documentation requirements. Finally, the supplementary specification contains any design constraints imposed on the system or the development process used to develop the system. This document is updated as needed and is shared among = team members and other involved personnel. The document template in this appendi= x is intended to be used as a starting point and may be customized according to = your organization’s needs.

Company Name

Project Name
Supplementary Specification

Revision History

= Date	= Revision	= Description	= Author
mm/dd/yy	1= .0	I= nitial version	A= uthor name
<= o:p>	<= o:p>	<= o:p>	=
<= o:p>	<= o:p>	<= o:p>	=
<= o:p>	<= o:p>	<= o:p>	=

&nbs= p;

Table of Contents

1 &nbs= p; Introduction

This section should provide an overview of the supplementary specification and should contain the following subsections.

1.1 Purpose of the Suppleme= ntary Specification

The document collects and organizes all the requirements of the system that are not contained within = the use-case model. These include functional requirements, nonfunctional requirements, and design constraints.

1.2 Scope

State the scope of the docum= ent and any systems or subsystems to which it applies.

1.3 Definitions, Acr= onyms, and Abbreviations

Provide the definitions of a= ll terms, acronyms, and abbreviations required to properly interpret the supplementary specification. This information may be provided by reference = to a project glossary.

1.4 References

This subsection should

· = Provide a list of all documents referenced elsewhere in the supplementary specification

· = Identify each document by title, report number (if applicable), dat= e, and publishing organization

· = Specify the sources from which the references can be obtained =

This information may be provided by reference to an appendix or to another docum= ent.

2 = Functionality

This section describes the functional requirements of the system for those requirements that are expre= ssed in declarative, natural language style or via other, more formal methods. F= or some applications, this may constitute the bulk of the requirements, and thought should be given to the organization of this section. This section m= ay be organized by feature, by subsystem or by other strategies as appropriate= .

3 = Usability

This section includes those requirements that affect usability. Examples follow below.

· = Specify the required training time for normal users and power users= to become productive at particular operations.

· = Specify measurable task times for typical tasks.<= /span>

· = Specify requirements to conform to common usability standards, for example, IBM’s CUA standards or Microsoft’s GUI standards.=

4 Reliability=

This section includes those requirements that affect reliability and availability of the system. Exampl= es follow below.

· = Availability: Specify the percentage of time the system is expected= to be available, hours of use, maintenance access, degraded mode operations, a= nd so on.

· = Mean time between failures (MTBF): This is usually specified in hou= rs but could also be specified in terms of days, months, or years.<= /span>

· = Mean time to repair (MTTR): How long is the system allowed to be ou= t of operation after it has failed?

· = Maximum bugs or defect rate: This is usually expressed in terms of bugs/KLOC (thousands of lines of code) or bugs/function-point.

· = Bugs or defect rate: This is categorized in terms of minor, significant, and critical bugs. The requirement(s) must define what is mean= t by a critical bug (for example, complete loss of data or complete inability to= use certain parts of the functionality of the system).=

5 Performance=

The performance characteristi= cs of the system are outlined in this section, including specific quantitative parameters. Where applicable, reference the related use cases by name. Exam= ples of performance requirements include the following:

· = Response time for a transaction (average, maximum)

· = Precision (resolution) and accuracy (by some known standard) requir= ed in the systems output

· = Throughput (for example, transactions per second)=

· = Capacity (for example, the number of customers or transactions the system can accommodate)

· = Degradation modes (the acceptable mode of operation when the system= has been degraded in some manner)

· = Resource utilization for memory, disk, communications, and so on

6 Supportabil= ity

This section includes any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class l= ibraries, maintenance access, maintenance utilities, and so on.

7 Design Constraints

This section includes any des= ign constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of develo= pmental tools, specific architectural constraints, mandated use of purchased components, class libraries, and so on.

8 User Documentation and Help System Requirements

This section describes the requirements for documentation for the system. Examples include the followi= ng:

· = Getting started guides

· = User guides

· = Online help

· = Administration guide

· = User glossary

· = Read me files and release notes

· = Labeling and packing requirements

9 Purchased Components

This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.

10= Interfaces

This section defines the inte= rfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, and so on to enable development and verification of the software against the interface requirements.

10.1 User Interfaces

Describe the user interfaces= to be implemented by the software.

10.2 Hardware Interfaces

Define any hardware interfac= es to be supported by the software, including logical structure, physical address= es, expected behavior, and so on.

10.3 Software Interfaces

Define software interfaces to other components of the software system such as operating systems, database= s, and so on. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the sc= ope of this specification but with which this software application must interac= t.

10.4 Communications Interfaces

Describe any communications interfaces to other systems or devices such as local area networks, local or remote devices, and so on.

11 Licensing and Security Requirements

This section includes any lic= ensing requirements or usage enforcement restrictions to be implemented in the software, as well as any sublicensing requirements for any OEM components or other licensed applications required for system operation.

This section may also define requirements for security and accessibility, encryption of source code or u= ser data, and so on.

12 Legal, Copyright, and Other Notices

This section includes any nec= essary legal disclaimers, including warranties, copyright notices, patent notices, trademark, or logo compliance requirements.

13 Applicable Standards

This section includes by refe= rence any applicable standards and the specific sections of any such standards th= at apply to the system being built. For example, this could include legal, quality, and regulatory standards or industry standards for usability or interoperability.

14 Internationalization and Localization

This section describ= es any applicable requirements for internationalization (the ability to support multiple user language environments) and localization (requirements to prov= ide or support GUI dialogs, displays and report formats, entry of user data, an= d so on) in the user’s native language or local dialect.=

15 &nb= sp; Physical Deliverables

This section defines any spec= ific physical deliverables (CDs, manuals, and so on) produced to support deploym= ent and operation of the system.

16&n= bsp; Installation and Deployment

This section describes any sp= ecial requirements for system configuration or preparation, third-party component= s, installation or conversion utilities, and any other requirements for succes= sful implementation and deployment.

&nb= sp;