________________________Articles| ________________________Articles |
|
Certification of Software Engineers Litigation of Software-Intensive Projects O-O-Design: ganz einfach oder sehr kompliziert? Professionalism in Software Engineering Reusing the Products of Analysis UML: A Curse or Blessing? (pdf file) Wer verträgt wieviel Abstraktion? Wohin mit den Funktionen im Objektmodell?
|
American Programmer, Volume X, No. 8; August 1997 REQUIREMENTS: MADE TO MEASUREby James Robertson and Suzanne Robertson[Copyright 1997 by James and Suzanne Robertson. All rights reserved.] Requirements, if they are to be at all useful, must be measurable. That is, they must be given quantifiable characteristics so that testers can accurately determine whether the eventual solution satisfies a requirement, and so that the client can determine if the requirement's value is worth the cost of construction. Naturally, testing must start at the beginning of a project. It is here that we must trap the requirements defects that are at the heart of project failures. History tells us that the greatest number of errors -- and the errors that are most costly to fix -- are generated at the beginning stages of development. Thus the highest-value testing we can do is early in the project. In this article, we look at how to make requirements measurable and, thus, testable.
REQUIREMENTS CREEPRequirements creep is one of the most common risks in software projects. It happens when new requirements are added to the product after the formal requirements phase without any control. New and unanticipated requirements come at the rate of about 1 percent per month. Thus for a three-year project, about one-third of the total requirements will come after the requirements phase has ended [1]. We could avoid some of the requirements creep by using a variety of techniques to flush out the conscious, unconscious, and undreamt-of requirements that might otherwise not be stated. However, some of the requirements creep involves truly new requirements that did not exist, and could not have been anticipated, during the requirements gathering activity. These new requirements are the result of evolution, and if we are to build a relevant system, we cannot ignore them. We need to measure the functionality of each one and assess the impact of including it. Naturally, if the requirement is included, then the project plan must be adjusted to cope with the change. Rather than being controlled, new requirements are often allowed to "leak" into the product -- nobody seems to know how they got there, nor where they originated. The result is that the eventual product and the original plan to build it bear very little relationship to each other. To prevent requirements creep, it is vital that the requirements be measurable and that the requirements process include a measuring and testing activity to which all requirements are subject, without exception. We call ours the quality gateway. THE QUALITY GATEWAYThe quality gateway is a quality control filter for all requirements. The basis of the gateway is simple: no matter how or where a requirement originates, it has to get through the gate to become an accepted requirement. In other words, the gateway is the single point through which every requirement must pass before you write it into the specification (see Figure 1). Each requirement is subjected to a number of tests to determine whether it is suitable for inclusion in the specification. The remainder of the article discusses the testing and measuring done by the gateway process. Relevant RequirementsRelevant requirements are those that can be shown to be part of the context and that conform to the purpose of the product. The purpose is a short, clear statement of what the product is intended to achieve; it is set at the beginning of the requirements gathering operation. One test for every requirement is to ensure that it is compatible with, or contributes to, the purpose. To test whether the requirement fits with the context, examine the flows of data to and from the system on the context diagram.
If none of the boundary data flows (the ones that connect the area of detailed study to the outside world) contribute to, or are a result of, the requirement, then either the requirement is irrelevant or the context is incomplete. Viable RequirementsViable requirements are those that the organization is capable of both building and operating once they are built. For a requirement to be viable, we must get satisfactory answers to a number of questions:
Gold PlatingGold plating refers to those requirements that add cost, but little value, to the product. Allowing individual users to tailor the fonts and screen colors is probably gold plating: it might be nice to have, but only if it is relevant to the product and we can afford the time and money to build it. The most effective test for gold plating comes from assigning a customer satisfaction rating to each requirement. Customer satisfaction is the reward that your client gives you if you successfully supply the solution to a requirement. Rate this on a scale of 1 (hardly matters) to 5 (extremely pleased if this requirement is successfully implemented). Customer dissatisfaction is the penalty that your client imposes for failure to implement the requirement. Rate this on a scale of 1 (unconcerned) to 5 (the customer is extremely unhappy that you have failed to deliver a solution for the requirement). For gold-plated requirements, the dissatisfaction scale will have a low value. For example, suppose you have a requirement that your information manager application display a Dilbert cartoon each morning. You might get a high satisfaction rating -- most people would like to have this. However, you will also get a low dissatisfaction rating -- it won't cripple the application if you don't have it. In this case, the low dissatisfaction rating indicates that this is a gold-plated requirement. REQUIREMENTS SHELLWe have found that, to be successfully measured and tested, each requirement must have a number of elements. For ease of use, we recommend that our clients use our requirements shell [2] as a container for a requirement (see Figure 2). The requirement gatherer gradually completes each part of the shell as the information becomes known. This is not intended to reduce requirements gathering to a clerical task, but to provide a convenient way of ensuring that the requirements are complete. Traceable RequirementsAssign a unique identifier to each requirement. In our requirements seminar, we suggest that this be a composite of "R" (for requirement) followed by the requirement type from our Volere template [2]. (This allows requirements to be sorted by type to check for duplication and conflict.) The type is followed by a unique number. Thus R9.246 is a functional requirement, and it happens to be the 246th requirement that you have gathered to date. The event, or use case, number is attached to the requirement to provide a pointer to its origin. Of course, a requirement may be relevant to more than one event or use case, in which case there are several event/use case numbers. The requirement should also carry references to supporting materials and anything that may be useful to understand more about this requirement. It is particularly useful to reference dependencies. These are other requirements on which this one has a change effect. Identifying the SourceThe person who originated the requirement, and that person's role, should be identified. While this is not a testable item -- you cannot measure or test a person's name -- it is useful to know where to send a requirement that has been rejected by the quality gateway. Terminology and LanguageTerminology has a detrimental effect when it is not used correctly. To be used correctly in a requirements sense, every term used in the requirement must be defined in the dictionary for the requirements specification. The definition of each term is relevant within the context of this particular project. The language must be clear and unambiguous. The suggested test is for a sample (say, 50 requirements) to be given to a panel of stakeholders. Either they agree as to the meaning of the requirement or, if they disagree, another five requirements are added to the sample. If the sample is reduced to zero, then the specification is considered to be unambiguous. If it increases, then you should consider having the specification rewritten by a competent technical writer. Fit CriteriaFit refers to whether or not a solution satisfies the original requirement, no more and no less. The fit criteria are a benchmark, or goal, that the testing activity uses to determine whether the eventual solution satisfies the requirement. You cannot successfully design a solution to the requirement if you have no way of knowing whether that solution meets the requirement. The fit criteria are a precise, quantified, testable statement of the requirement. The fit criteria are a quantified goal; they contain numbers, or measurements, that the solution has to meet. For example, we might have the following requirement description: "The product must be acceptably fast." The fit criteria for this requirement might be something like, "Ninety percent of experienced customers must spend no more than 30 seconds to make a deposit." First of all, of course, you will need a definition of "experienced." You must also be satisfied that a 90 percent pass rate is acceptable to your client, keeping in mind that you cannot expect 100 percent of people to pass any test. Finally, 30 seconds must be an acceptable time limit, with a study to back up this figure. Fit Criteria for Functional RequirementsFunctional requirements are things that the product must do. The fit criteria are the yardstick that is used to test whether or not the function has been successfully carried out. Thus if the functional requirement is to record something, then the fit criteria are that the retrieved data must conform to what should have been recorded. If the function is to calculate, then the fit criteria are that the result of the calculation conforms to the intended result. In other words, the fit criteria are that which will satisfy the originator of the function. Either the originator is capable of saying that he or she is satisfied, or the result of the action is consistent with a standard set for that kind of function. Fit Criteria for Nonfunctional RequirementsA nonfunctional requirement is a property that the product must have. The fit criteria quantify the necessary behavior or quality indicated by the nonfunctional requirement. Some nonfunctional requirements may at first seem a little hard to test. For example, "The product must be easy to learn," does not, at first glance, seem very precise. So we need to apply some quantification, such as the amount of time it takes to learn a task and produce usable results from the product. Writing fit criteria for nonfunctional requirements is a matter of finding the appropriate quantification. This is best illustrated with examples. If we have a usability requirement that says, "The product shall be usable by a member of the public who may not speak or read English," then the suggested fit criteria are something like: 45 out of 50 randomly selected non-English speakers/readers shall be able to use the product within the specified normal performance criteria plus 25 percent. Other usability fit criteria may give an amount of learning time or training time, or they may specify that a test panel can perform functions in a target time. The point is that the fit criteria provide some quantified target that, when tested, will reveal the solution's degree of conformance with the requirement. Consider the following examples:
Testing Fit CriteriaWe need to ensure that the fit criteria are a valid yardstick, for which a cost-effective test can be constructed. For example, do the fit criteria meet the intention of the product purpose? Go back to the purpose set at the beginning of the project and check. Do the fit criteria attempt to make something fast when there is no great need for speed? Do they make an unnecessary demand when the purpose can be met without this? Can the fit criteria be readily tested? While the requirements writer does not have to do the tests, he or she does provide the fit criteria that are used as the basis for designing the tests. Now we have the opportunity to involve a competent tester, someone who is qualified to decide whether a test can be designed to prove that a solution fits or does not fit the specified criteria. Are the tests cost-effective? For example, will the tests require several person-years of work? Or expensive measuring instruments? Are the fit criteria subjective? If you have said that a transaction must be complete within 15 seconds, is there a reason for specifying 15 seconds? The fit criteria must be based on surveys or empirical evidence that a 15-second completion time is needed. Each of the fit criteria must be examined both to confirm their presence and to determine that, if the product meets the fit criteria, then the product will be what your client needs and desires. CONCLUSIONWhen we make the requirements measurable, we have the basis for testing and negotiating the solutions. Whenever we discover a new requirement, we test it to ensure that it conforms with the minimum standard. That is:
We propose that you install a quality gateway as a mechanism for testing your requirements. Each requirement is checked in the gateway, and passing through the gateway is the only way that requirements can be written into the requirements specification. REFERENCES1. Jones, Capers. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, Yourdon Press, 1994. 2. Robertson, James and Suzanne. The Volere Requirements Process and Specification Template. London: The Atlantic Systems Guild, 1997. (The Requirements Specification Template is available at www.atlsysguild.com.) ADDITIONAL SOURCESDeGrace, Peter, and Leslie Hulet Stahl. Wicked Problems, Righteous Solutions. Englewood Cliffs, NJ: Prentice Hall, Yourdon Press, 1990. Pardee, William. To Satisfy and Delight Your Customer. New York: Dorset House, 1996. Weinberg, Jerry. Quality Software Management. Vol. 4, Anticipating Change. New York: Dorset House, 1997. James Robertson has written numerous seminars and papers that are well respected as sources of new software development ideas. As well as teaching his popular seminars, he now works at helping companies adapt modern software development techniques to fit specific projects and transfer new technologies to the software developers within the organization. Suzanne Robertson is successfully researching and consulting on patterns and the specification and reuse of requirements. The product of this research is Volere, a complete requirements process and template for assessing requirements quality and specifying business requirements. Ms. Robertson is a member of IEEE and the Australian Computer Society, on the committee for the annual Object Technology conference, and roving ambassador for the British Computer Society's Reuse Group. Mr. and Ms. Robertson have adapted one of their large-scale projects to become the case study for their ground-breaking book Complete Systems Analysis: The Workbook, the Textbook, the Answers (Dorset House, 1994), a two-volume text and case study that teaches the core skills necessary for systems analysis. The authors can be reached at The Atlantic Systems Guild, 11 St. Mary's Terrace, London W2 1SU, UK (+44 171 262 3395; e-mail: james@systemsguild.com, suzanne@systemsguild.com; Web: www.asystemsguild.com). © Copyright 1997 Cutter Information Corp. All rights reserved. No part of this document may be reproduced in any manner without express written permission from Cutter Information Corp.
|
