Managing Software Requirements[c] A Use Case Approach

   

1 Introduction

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

1.1 Purpose of the Supplementary 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 document and any systems or subsystems to which it applies.

1.3 Definitions, Acronyms, and Abbreviations

Provide the definitions of all 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 ), date, 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 document.

2 Functionality

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

3 Usability

This section includes those requirements that affect usability. Examples follow. (See Chapter 22 for additional guidance on usability requirements.)

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

  • Specify measurable task times for typical tasks .

  • 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. Examples follow below.

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

  • Mean time between failures (MTBF): This is usually specified in hours but could also be specified in terms of days, months, or years .

  • Mean time to repair (MTTR): How long is the system allowed to be out 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 meant 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 characteristics of the system are outlined in this section, including specific quantitative parameters. Where applicable, reference the related use cases by name . Examples of performance requirements include the following:

  • Response time for a transaction (average, maximum)

  • Precision (resolution) and accuracy (by some known standard) required 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 Supportability

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

7 Design Constraints

This section includes any design 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 developmental 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 following:

  • 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 interfaces 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 interfaces to be supported by the software, including logical structure, physical addresses, expected behavior, and so on.

10.3 Software Interfaces

Define software interfaces to other components of the software system such as operating systems, databases, and so on. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this specification but with which this software application must interact.

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 licensing 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 user data, and so on.

12 Legal, Copyright, and Other Notices

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

13 Applicable Standards

This section includes by reference any applicable standards and the specific sections of any such standards that 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 describes any applicable requirements for internationalization (the ability to support multiple user language environments) and localization (requirements to provide or support GUI dialogs, displays and report formats, entry of user data, and so on) in the user's native language or local dialect .

15 Physical Deliverables

This section defines any specific physical deliverables (CDs, manuals, and so on) produced to support deployment and operation of the system.

16 Installation and Deployment

This section describes any special requirements for system configuration or preparation, third-party components, installation or conversion utilities, and any other requirements for successful implementation and deployment.

   
Related

Категории