Inc. S iliware Standard re n arc … · occurring in the first place is even more desirable....
4
by Robert M. Poston S Programming Environments, Inc. 68 Monmouth Road S_iliware Standard _ _Oakhurst, NJ 07755 re n a rc s~~~~~~~~~~~~Compmail +: r.poston Preventing software requirements specification errors with IEEE 830 A fter a software development sched- ule has been established, we often find it does not include enough time to complete all necessary work. At that point we begin to make compromises. In making the com- promises we usually throw out everything in favor of the schedule. Under pressure from a schedule, managers will often issue hasty directions. "Don't document now. We'll document later." "We don't have time for a review. Just go with what you've got." "We don't have time to learn a standard technique or a new tool on this project." In a future article we will look at why software development schedules are often unrealistic in the first place. But for now, we want to look at ways to come closer to meeting the schedules to which we are al- ready committed by using IEEE 830 and some simple rules. The panic compromises of documenting later, skipping reviews, and using nonstandard techniques or tools will usually shift errors from the immediate phase into the testing phase where they are more costly to correct. Errors in requirements. A typical soft- ware development cycle is illustrated in Figure 1. We can see from this illustration that over 40 percent of the software devel- opment effort is spent in testing. If we are trying to meet a tight schedule, we want to reduce the time spent in testing, which in- cludes failure identification, fault isolation, and fault removal-the biggest piece of the pie in Figure 1. (If your schedule does not include 40 percent or more of total develop- ment time for testing, your effort is signifi- cantly different from currently reported norms.) Another factor pushing us toward reduc- ing test time is the cost to eliminate an error 100 80 Relative cost to fix a failure 60 40 20 - Plan & Z' Requirements Design in the different life-cycle phases as shown in Figure 2. We see it is much less expensive to eliminate errors early. The errors that give us the most trouble in testing usually orig- inate in the requirements and design phases, so they are there early on for us to find as shown in Figure 3. An ounce of prevention is worth a pound of cure. A number of well-known authors have presented various techniques for find- ing software errors early in the development cycle. Finding errors early is obviously ad- vantageous, but preventing errors from Code & Integration unit test test System test Operation Figure 2. Fault removal cost. Composite data from: * B. Boehm, Software Engineering Economics * E. Miller & P. Howden, Software Testing and Validation Techniques 60 50 40 Percent of all development 30 faults 20 10 0 Life cycle phases A total of 55% of the faults appear during requirements and functional design i M =Design faults = Introduced E_ = =Logic faults 0=Observed E_ =Syntax faults O 0 .A Requirements & functional design Technical and program design Construction and system test Acceptance Testing & operations Figure 1. Software development cost. Figure 3. Fault removal cost (derived from Alberts 1976). January 1985 Reference- B. Boehm, "Verifying and Val- idating Software Requirements and Design - Specifications," IEEE Software, Jan 1984. . rE.- ~ I 83
Transcript of Inc. S iliware Standard re n arc … · occurring in the first place is even more desirable....
by Robert M. PostonS Programming Environments, Inc.68 Monmouth Road
S_iliware Standard __Oakhurst, NJ 07755ren arc s~~~~~~~~~~~~Compmail+: r.poston
Preventing software requirements specification errorswith IEEE 830A fter a software development sched-
ule has been established, we often findit does not include enough time to completeall necessary work. At that point we beginto make compromises. In making the com-promises we usually throw out everything infavor of the schedule. Under pressure froma schedule, managers will often issue hastydirections. "Don't document now. We'lldocument later." "We don't have time fora review. Just go with what you've got.""We don't have time to learn a standardtechnique or a new tool on this project."
In a future article we will look at whysoftware development schedules are oftenunrealistic in the first place. But for now,we want to look at ways to come closer tomeeting the schedules to which we are al-ready committed by using IEEE 830 andsome simple rules. The panic compromisesof documenting later, skipping reviews,and using nonstandard techniques or toolswill usually shift errors from the immediatephase into the testing phase where they aremore costly to correct.
Errors in requirements. A typical soft-ware development cycle is illustrated in
Figure 1. We can see from this illustrationthat over 40 percent of the software devel-opment effort is spent in testing. If we aretrying to meet a tight schedule, we want toreduce the time spent in testing, which in-cludes failure identification, fault isolation,and fault removal-the biggest piece of thepie in Figure 1. (If your schedule does notinclude 40 percent or more of total develop-ment time for testing, your effort is signifi-cantly different from currently reportednorms.)
Another factor pushing us toward reduc-ing test time is the cost to eliminate an error
100
80
Relativecost tofix a
failure
60
40
20
- Plan &Z' Requirements Design
in the different life-cycle phases as shown inFigure 2. We see it is much less expensive toeliminate errors early. The errors that giveus the most trouble in testing usually orig-inate in the requirements and design phases,so they are there early on for us to find asshown in Figure 3.
An ounce of prevention is worth a poundof cure. A number of well-known authorshave presented various techniques for find-ing software errors early in the developmentcycle. Finding errors early is obviously ad-vantageous, but preventing errors from
Code & Integrationunit test test
Systemtest
Operation
Figure 2. Fault removal cost.
Composite data from:* B. Boehm, SoftwareEngineering Economics* E. Miller & P. Howden,Software Testing andValidation Techniques
60
50
40Percent of alldevelopment 30
faults 20
10
0Lifecyclephases
A total of 55% of the faults appear duringrequirements and functional design
i M =Design faults = Introduced
E_ = =Logic faults 0=ObservedE_ =Syntax faults O
0.ARequirements& functional
design
Technicaland program
design
Constructionand system
test
AcceptanceTesting &operations
Figure 1. Software development cost. Figure 3. Fault removal cost (derived from Alberts 1976).
January 1985
Reference- B. Boehm, "Verifying and Val-idating Software Requirements and Design
- Specifications," IEEE Software, Jan 1984. .
rE.-~ I
83
occurring in the first place is even moredesirable. Here, we will focus on preventingerrors in the earliest life cycle phase, therequirements phase.
Requirements phase activities. In the re-quirements phase a number of differentactivities are underway concurrently. Theproject management team is creating a soft-ware development plan. The project (quali-ty) assurance team is devising a projectsoftware quality assurance plan. Theconfiguration management team is produc-ing a project configuration managementplan. These three activities are supportfunctions. They set the framework in which
Characteristics of a good SRS. A good SRS is(1) unambiguous,(2) complete,(3) verifiable,(4) consistent,(5) modifiable,(6) traceable, and(7) usable during the operation and main-
tenance phase.
Unambiguous. An SRS is unambiguous if-and only if-every requirement stated thereinhas only one interpretation.
(1) As a minimum, this requires that eachcharacteristic of the final product be de-scribed using a single unique term.
(2) In cases where a term used in a par-ticular context could have multiple meanings,the term must be included in a glossarywhere its meaning is made more specific.
Complete. An SRS is complete if it possessesthe following qualities:
(1) Inclusion of all significant require-ments, whether relating to functionality, per-formance, design constraints, attributes, orexternal interfaces.
(2) Definition of the responses of the soft-ware to all realizable classes of input data inall realizable classes of situations. Note that itis important to specify the responses to validand invalid input values.
(3) Conformity to any SRS standard thatapplies to it. If a particular section of thestandard is not applicable, the SRS shouldinclude the section number and an explana-tion of why it is not applicable.
(4) Full labeling and referencing of allfigures, tables, and diagrams in the SRS anddefinition of all terms and units of measure.
Use of TBDs. Any SRS that uses the phrase," to be determined," is not a complete SRS.
the evaluation and development teams canbuild the software product.The evaluation team is creating a verifi-
cation, validation, and system testing plan.The evaluation team also is performing theverification and validation on the itemsproduced in the requirements phase.The development team activities in the
requirements phase center on understand-ing the need the prodLuct will satisfy,establishing the feasibility of available,alternative solutions, and specifying the re-quirements for the selected alternatives.The errors we want to prevent are createdprimarily in development, so it is useful topay particular attention to the developmentactivities.
Verifiable. An SRS is verifiable if and only ifevery requirement stated therein is verifi-able. A requirement is verifiable if and only ifthere exists some finite cost-effective pro-cess with which a person or machine cancheck that the software product meets the re-quirement.
(1) Examples of nonverifiable requirementsinclude statements such as "The productshould work well," or "The product shouldhave a good human interface.'' These re-quirements cannot be verified because it isimpossible to define the terms good or well.
(2) An example of a verifiable statement is,"The output of the program shall be givenwithin 20 seconds of event X, 60 percent ofthe time; and shall be given within 30seconds of event X, 100 percent of thetime.'' This statement can be verified be-cause it uses concrete terms and measurablequantities.
(3) If a method cannot be devised to deter-mine whether the software meets a particular re-quirement, then that requirement should beremoved or revised.
(4) If a requirement is not expressible in veri-fiable terms at the time the SRS is prepared,then a point in the development cycle (review,test plan issue, etc.) should be identified atwhich the requirement must be put into a verifi-able form.
C"rsistent. An SRS is consistent if and only if noset of individual requirements described in itconflict. There are three types of likely conflictsin an SRS.
(1) Two or more requirements might describethe same real world object but use differentterms for that object. For example, a program'srequest for a user input might be called a promptin one requirement and a cue in another.
(2) The specified characteristics of real worldobjects might conflict. For example, the format
Most often, the need for a new softwareproduct is identified by a customer or amarketing representative. When this hap-pens, the development cycle and therequirements phase are kicked off.The first step in the requirements phase is
to analyze the need pointed out by thecustomer or marketer. This activity may becalled problem analysis, system analysis, orneeds assessment. Whatever it is called, itamounts to a thorough examination of theneed or problem.The second step in the requirements
phase is to look at ways to fulfill the need orto solve the problem. This activity often iscalled a feasibility study, and it identifies
of an output report might be described in one re-quirement as tabular but in another as textual.
(3) There might be a logical or temporal con-flict between two specified actions. For exam-ple,
(a) One requirement might specify that theprogram will add two inputs and anotherspecify that the program will multiply them; or
(b) One requirement might state that Amust always follow B, while another requiresthat A and B occur simultaneously.
Modifiable. An SRS is modifiable if its structureand style are such that any necessary changesto the requirements can be made easily, com-pletely, and consistently. Modifiability generallyrequires an SRS to
(1) have a coherent and easy-to-use organi-zation, with a table of contents, an index, andexplicit cross-referencing; and
(2) not be redundant; that is, the same re-quirement should not appear in more than oneplace in the SRS. Redundancy itself is not an er-ror, but it can easily lead to errors.
Traceable. An SRS is traceable if the origin ofeach of its requirements is clear and if it facili-tates the referencing of each requirement infuture development or enhancement documen-tation. Two types of traceability are recom-mended:
(1) Backward traceability (that is, to previousstages of development) depends upon each re-quirement explicitly referencing its source inprevious documents.
(2) Forward traceability (that is, to all doc-uments spawned by the SRS) depends uponeach requirement in the SRS having a uniquename or reference number.
Usable during the operation and maintenancephase. The SRS must address the needs of theoperation and maintenance phase, including theeventual replacement of the software.
Figure 4. Characteristics of a good SRS derived from IEEE 830.
IEEE SOFTWARE84
the selected method of satisfying the needor solving the problem.
If the feasibility study indicates that a
software product is the best answer, a soft-ware requirements specification will be gen-
erated. A requirements specification is a
detailed description of what a product mustdo. In this final step of the requirementsphase, IEEE 830 comes into play.IEEE 830 is a description of what makes
a good software requirements specifica-tion. It offers the format, content, andqualities of an understandable specifica-tion. By employing 830, a software devel-opment team can prevent errors in at leasttwo ways.
Misinterpretations among developers are
much less likely to occur when 830 is beingused, because developers will be adhering to
standard definitions of terms in writing re-quirements and plugging information into aprescribed format.IEEE 830 also provides a list of the char-
acteristics of a good software requirementsspecification. The reciprocals of the char-acteristics on the list may be consideredmost probable errors. If a developer knowsthe most probable errors that occur in a
specification, he can avoid making them inthe first place. The characteristics on the listand their definitions are shown in Figure 4.Let's look closely at one characteristic.
Listed as a desireable characteristic is anunambiguous requirement. The most prob-able error, then, is an ambiguous require-ment. An ambiguous requirement is onethat can be interpreted in more than oneway. For example, "The character string
will be terminated by a delimiter." Thereader of such a requirement does not knowif the delimiter is the last character in thestring, or a simple count of the characters inthe string, or if some special character willbe designated the delimiter. IEEE 830 pro-vides formal definitions of the characteris-tics and examples of bad requirements ormost probable errors as well as examples ofgood requirements. IEEE 830 steers us clearof poor workmanship and guides us towardgood professional practice.
There are holes in 830. For example, inproviding prototype outlines, 830 does notspecify explicitly how to fill in the sections.The prototype outlines shown in Figure 5indicate what paragraph should be presentbut do not tell us how to specify the infor-mation that goes into the paragraphs. So we
4. Appendixes/5. Index
Figure 5. Prototype SRS outlines.
January 1985
Prototype SRS outline.Table of Contents 2. General Description1. Introduction 2.1 Product Perspective
1.1 Purpose 2.2 Product Functions1.2 Scope 2.3 User Characteristics1.3 Definitions, Acronyms, and Abbreviations 2.4 General Constraints1.4 References 2.5 Assumptions and Dependencies1.5 Overview 3. Specific Requirements
Prototype outline 1 for SRS Section 3.3. Speeific Requirements
3.1 Functional Requirements3.1.1 Functional Requirement 1
3.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Processing3.1.1.4 Outputs
3.1.2 Functional Requirement 2
3.1 .n Functional Requirement n3.2 External Interface Requirements
3.2.1 User Interfaces3.2.2 Hardware Interfaces3.2.3 Software Interfaces3.2.4 Communications Interfaces
3.3 Performance Requirements3.4 Design Constraints
3.4.1 Standards Compliance3.4.2 Hardware Limitations
3.5 Attributes3.5.1 Security3.5.2 Maintainability
3.6 Other Requirements3.6.1 Database3.6.2 Operations3.6.3 Site Adaptation
Prototype outline 2 for SRS Section 3.3. Specific Requirements
3.1 Functional Requirements3.1.1 Functional Requirement 1
3.1.1.1 Specification3.1.1.1.1 Introduction3.1.1.1.2 Inputs3.1.1.1.3 Processing3.1.1.1.4 Outputs
3.1.1.2 External Interfaces3.1.1.2.1 User Interfaces3.1.1.2.2 Hardware Interfaces3.1.1.2.3 Software Interfaces3.1.1.2.4 Communication Interfaces
3.1.2 Functional Requirement 2
3.1 .n Functional Requirement n3.2 Performance Requirements3.3 Design Constraints3.4 Attributes
3.4.1 Security3.4.2 Maintainability
3.5 Other Requirements3.5.1 Database3.5.2 Operations3.5.3 Site Adaptation
85
Rule 1. Use IEEE 830 for* a standard format,* a completeness check, and* a checklist of good requirement
characteristics.Reason: To establish consistency betwe(
documents.
Rule 2. Use models for* functional relationships,* data flow,* data structure, and* performance.Reason: To express complete
requirements.
Rule 3. Limit the structure of paragraphs to Reason: To improve consistency and toa list of individual sentences. reduce ambiguity.
Reason: To increase the traceability andmodifiability of each requirement; and to in-crease the ability to check for completeness. Rule 6. Limit the verbs and objects to terms
that are common to the end user of theproduct (that is, nonprogrammer terms).
Rule 4. Limit the structure of each sentence Reason: To increase user understandingto a simple sentence that is, noncompound of the requirements.verbs or objects.
Reason: To increase the verifiability(testability) of each requirement. Rule 7. Limit the verbs and objects to
Rule 5. Limit the verbs and objects in thesentences to a small set with a singlespecified definition for each word.
actions and items tnat are visiole exiernai tothe product.
Reason: To reduce the amount of designdata that goes into the requirements; and toincrease the testability of the product.
Figure 6. Rules of order for specifying software requirements.
see that 830 is not a panacea, but it doestake a significant step toward establishing areference for professional practice, and itcan help us prevent errors.Some rules to help us specify the neces-
sary information in accordance with the 830list of good requirements characteristics are
provided in Figure 6. These rules are impor-tant. They do for requirements specifica-tions exactly what the structured program-ming constructs do for programming. Theyreduce the probability of errors.
In the United States, at least four or-ganizations are presently applying IEEE
830. To date, we at the Standards Depart-ment have received mostly favorable com-ments about these efforts. We are now ac-tively seeking "war stories" dealing withIEEE 830 as well as with all other IEEEstandards. Please contact Bob Poston ifyou have any experiences to share.
(
I Tis publication reports on recentresults and progress in distributed com-puting systems, covering the topics ofalgorithms, operating systems, lan-guages, and the traditional roles playedby PCU's, memory, and communica-tions structures. 590 pp.
Order #534PROCEEDINGS: The FourthInternational Conference on
Distributing Computing SystemsMay 1984
Nonmembers-$60.00Members-$30.00
Handling Charges Extra
Order from IEEE Computer SocietyOrder Dept., PO Box 80452,Worldway Postal Center, Los
Angeles, CA 90080 USA(714) 821-8380 I/
Classified AdsRATES: $4.50 per line, $45 minimum charge (upto ten lines). Average six typeset words per line,nine lines per column inch. Add $4 for box num-ber. Send copy at least six weeks prior to monthof publication to: Jonne Marriott, ClassifiedAdvertising, IEEE SOFTWARE Magazine, 10662Los Vaqueros Circle, Los Alamitos, CA 90720.
In order to conform to the Age Discriminationin Employment Act and to discourage age dis-crimination, IEEE SOFTWARE may reject anyadvertisement containing any of these phrasesor similar ones: ". recent college grads. .
...1-4 years maximum experience...,...up to 5 years experience...," or "...10years maximum experience." IEEE SOFT-WARE reserves the right to append to anyadvertisement, without specific notice to theadvertiser, "Experience ranges are suggestedminimum requirements, not maximums." IEEESOFTWARE assumes that, since advertisershave been notified of this policy in advance,they agree that any experience requirements,whether stated as ranges or otherwise, will beconstrued by the reader as minimum require-ments only.
WANG INSTITUTE OFGRADUATE STUDIES
School of Information TechnologySoftware Engineering Faculty
Wang Institute provides a unique educationalenvironment that combines the best features ofacademe and industry. Faculty members teachone graduate course per semester, interact
closely with small numbers of graduate studentswho have industrial experience, supervise pro-duction quality software projects, and pursuetheir individual research interests.Positions are available for full-time faculty mem-bers and one-year visitors who have experiencein using and teaching the technical andmanagerial principles of software engineering.Faculty members receive industrial-level salar-ies and are provided with sufficient equipmentand support staff to achieve their professionalgoals. Each faculty member is expected to main-tain a reasonable balance between research insoftware engineering and exposition of thatmaterial in the classroom. Teaching ability andan interest in graduate-level education are es-sential.The campus of the School of Information Tech-nology is located near the Boston high-tech anduniversity areas which provide rich environ-ments of academic, cultural, and professionalactivities. Instructional computing facilities atWang Institute include a VAX 111750 (VMS), aVAX 11/780 (UNIX), a Prime 750, a Wang VS100,Apollo DOMAINs, and IBM, Apple, Wang, andHewlett-Packard personal/professional com-puters. A growing collection of software tools forsoftware engineering is maintained by the staffof the Wang Institute Software Environmentproject.Applicants should submit the names of threereferences and a resume that indicates profes-sional specialty areas, teaching experience, andexperience in the practice of software develop-ment and/or software management to: Richard E.Fairley, Faculty Chair, Wang Institute of Gradu-ate Studies, Tyng Road, Tyngsboro, Massachu-setts 01879.
IEEE SOFTWARE
I
I
\1-
86
