《Software Requirements Analysis and Specification》读书笔记

Software Requirements Analysis and Specification

IEEE defines a requirement as “(1)A condition of capability needed by a user to solve a problem or achieve anobjective; (2) A condition or a capability that must be met or possessed by asystem ... to satisfy a contract, standard, specification, or other formallyimposed document”

Approaches like agile require only high-levelrequirements to be specified in written form—detailed requirements areelicited through interaction with the customer in the iteration the requirementis to be implemented and directly reflected in software.

Other approaches prefer that the requirements are specifiedprecisely. In such situations, the goal of the requirements activity is toproduce the Software Requirements Specification (SRS) that describes what theproposed software should do without describing how the software will do it.

3.1 Value of a Good SRS

– An SRS establishes the basis for agreement between theclient and the supplier on what the software product will do.

– An SRS provides a reference for validation of the finalproduct.

– A high-quality SRS is a prerequisite to high-qualitysoftware.

– A high-quality SRS reduces the development cost.

3.2 Requirement Process

The requirements process typically consists of three basictasks: problem or requirement analysis, requirements specification, and requirementsvalidation.

3.3.1 Desirable Characteristics of an SRS

1. Correct

2. Complete

3. Unambiguous

4. Verifiable

5. Consistent

6. Ranked for importance and/or stability

Some believe that completeness in all details may notbe desirable. The pursuit of completeness can lead to specifying details andassumptions that may be commonly understood. (For example, specifying in detailwhat a common operation like add a record means.) And specifying these detailscan result in a large requirements document, which has its own problemsincluding making validation harder. On the other hand, if too few details aregiven, the chances of developer’s understanding being different fromothers’ increases, which can lead to defects in thesoftware. For completeness, a reasonable goal is to have “sufficient detail” for the project at hand.

Together the performance and interface requirementsand design constraints can be called nonfunctional requirements.

3.3.2 Components of an SRS

– Functionality

– Performance

– Design constraints imposed on an implementation

– External interfaces

There are two types of performance requirements:static and dynamic.

Static requirements are those that do not imposeconstraint on the execution characteristics of the system.

Dynamic requirements specify constraints on theexecution behavior of the system.

Design constraints. Such factors include standardsthat must be followed, resource limits, operating environment, reliability andsecurity requirements, and policies that may have an impact on the design ofthe system.

An SRS should identify and specify all suchconstraints.

Some examples of these are:

Standards Compliance

Hardware Limitations

Reliability and Fault Tolerance

Security

In the external interface specification part, all theinteractions of the software with people, hardware, and other software shouldbe clearly specified.

3.3.3 Structure of a Requirements Document

The general structure of an SRS:

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 General Constraints

2.5 Assumptions and Dependencies

3. Specific Requirements

3. Detailed Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communication Interfaces

3.2. Functional Requirements

3.2.1 Mode 1

3.2.1.1 Functional Requirement 1.1

:

3.2.1.n Functional Requirement 1.n

:

3.2.m Mode m

3.2.m.1 Functional Requirement m.1

:

3.2.m.n Functional Requirement m.n

3.3 Performance Requirements

3.4 Design Constraints

3.5 Attributes

3.6 Other Requirements

3.4 Functional Specification with Use Cases

3.5 Other Approaches for Analysis

3.6 Validation

Due to the nature of the requirements specificationphase, there is a lot of room for misunderstanding and committing errors, andit is quite possible that the requirements specification does not accuratelyrepresent the client’s needs.

The most common errors that occur can be classified infour types: omission, inconsistency, incorrect fact, and ambiguity.

Requirements review is a review by a group of peopleto find errors and point out other matters of concern in the requirementsspecifications of a system.

Requirements reviews are probably the most effectivemeans for detecting requirement errors.

3.7 Summary

– The main goal of the requirements process is to producethe software requirements specification (SRS) which accurately captures theclient’s requirements and which forms the basis of softwaredevelopment and validation.

– There are three basic activities in the requirementsprocess—problem analysis, specification, andvalidation. The goal of analysis is to understand the different aspects of theproblem, its context, and how it fits within the client’s organization. In requirements specification the understood problemis specified or written, producing the SRS. Requirements validation is done toensure that the requirements specified in the SRS are indeed what are desired.

– The key desirable characteristics of an SRS are:correctness, completeness, consistency, unambiguousness, verifiability, andranked for importance.

– A good SRS should specify all the functions the softwareneeds to support, performance requirements of the system, the designconstraints that exist, and all the external interfaces.

– Use cases are a popular approach for specifyingfunctional requirements.

– Each use case specifies the interaction of the systemwith the primary actor, who initiates the use case for achieving some goal.

– A use case has a precondition, a normal scenario, aswell as many exceptional scenarios, thereby providing the complete behavior ofthe system.

– For developing use cases, first the actors and goalshould be identified, then the main success scenarios, then the failureconditions, and finally the failure handling.

– With data flow diagrams, a system is analyzed from thepoint of view of how data flows through the system. A DFD consists of processesand data flows through the processes.

– Omission, incorrect fact, inconsistency, and ambiguityare the most common errors in an SRS. For validation, the most commonly usedmethod is doing a structured group review of the requirements.

最后

以上就是现代汉堡为你收集整理的《Software Requirements Analysis and Specification》读书笔记的全部内容，希望文章能够帮你解决《Software Requirements Analysis and Specification》读书笔记所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。