Figure 5-1. We Are Here -- The Concept Phase
| Requirements | | |
5.1. What
Are Requirements?
5.2. Categorization
of
Requirements
5.2.1.
Software
Environment
Requirements
5.2.2.
Hardware
Environment
Requirements
5.2.3.
Compatibility
Requirements
5.2.4.
Performance
Requirements
5.2.5.
Functional
Requirements
5.2.6.
User
Interface
Requirements
5.2.7.
Software
Interface
Requirements
5.2.8.
Documentation
Requirements
5.2.9.
Release
Requirements
5.3. Characteristics
of Good Requirements
5.4.
Requirements
Issues vs. Design
Issues
5.5. Initial
Requirements
5.5.1.
An
Outline
5.5.1.1.
Cover
Page
5.5.1.2.
Problem
Statement
5.5.1.3.
Table
of
Contents
5.5.1.4.
Introduction
5.5.1.5.
Requirements
5.5.2.
Initial
Requirements
Checklist
5.5.3.
Example
Initial Requirements
5.6.
Summary
5.7.
Humor
-- Languages You've Never Heard
Of
5.8. References
Throughout this class we will continue to refer to a simple waterfall
software life cycle diagram to review where we are. The diagram can be thought
of as a road map that allows us to maintain an overall perspective of the
project. The first of these "road maps" is shown in Figure Figure 5-1.
While we are generally following more of a two-cycle spiral model, this simple
model helps us to easily see what that task is during each phase of our
projects.
We are, of course, at the beginning of our projects. Our teams and projects have been selected, and it is time to start the Concept Phase of our projects. As indicated in the diagram, the Concept Phase takes as input the project proposal received from the sponsor, and, through the process of requirements analysis produces a requirements specification. A requirements specification is a document that is intended to describe explicitly what the software is to do from the user's perspective, not how it is supposed to work from the implementor's perspective. That will come later. The requirements specification is essentially a contract between the developer of the software and the person or organization requesting its development.
This chapter will first give an overview of requirements issues. These requirements issues will then be categorized and described in more detail. Within each category, examples will be presented. Criteria for requirements evaluation are provided, and distinction is made between requirements issues and design issues. Finally, the initial requirements paper, its content, and an example are discussed.
We can't build software if we don't know what software we are trying to build. Our first task is to gather requirements for the software we are to produce. These requirements define in detail the constraints on the software to be implemented. We are striving to narrow the focus from "some software" to "software that does a specific set of things within a specific set of constraints." Since the organization requesting the software is usually different from the organization that will actually produce the software, we are trying to reduce the margin of error between what the customer wants and what the implementor produces. We do not want to leave room for misinterpretation of requirements. Conversely, we do not want to overconstrain the problem. We want to give the implementor as much freedom as is consistent with getting a solution to the problem. This will allow the implementor to choose the "best" solution from the set of all possible solutions.
A useful analogy is that of comparing software development to the tasks involved in construction, e.g. in building a house. An architect gathers requirements from the customer that define the attributes of the house to be designed, and presumably, to be built. You, as the software architect, gather requirements from the customer that define the attributes of the software to be designed. It is not adequate for a client to tell an architect "build a house," unless the client is willing to live with whatever the architect's interpretation of "house" is (contemporary or Victorian? $500,000 budget or $100,000 budget? 1 bedroom or 6?). Similarly, it is not adequate for a client to tell a software architect to "build a text editor," unless the client is willing to live with whatever the implementor's interpretation of "text editor" is (for Windows NT or web-based or for both? keyboard or mouse based? extensible or fixed?).
The architect would have many questions for the person who has asked for a house design. How many bedrooms? What style? Where will it be built? What size garage? And many, many more. These questions would be asked in an attempt to generate the requirements. Examples of the requirements gathered for a house design might include
Requirements should be stated as precisely as possible. Some of the above are stated reasonably well. "Four bedrooms" for instance is relatively precise -- not three, not five ... four. Many of the above would require more elaboration. For example, "large kitchen" -- how large is "large"? The architect's idea of large may be 100 square feet; the customer's idea of large may be 300 square feet. Much more detail than that given in this small list would have to be provided; however, you can see that we are starting to narrow the focus from "house" to a house with the specific attributes desired by the customer. But notice that the requirements do not specify how the house is to be designed or built; they only specify the properties that the resulting house should possess.
The same ideas of requirements analysis apply to gathering requirements for software. The attributes and constraints of the software to be developed must be determined, just as they must be determined when building a house. These attributes and constraints for software must also be specified as precisely as possible. For example, "the compiler should be able to compile many lines per second" is not a very useful requirement, since different people may, and probably will, have different ideas of how many lines are "many." "The compiler should be able to compile 300-500 lines per second" is much more precise and leaves less room for misinterpretation.
For manageability, requirements are broken down into a number of categories.
It may sometimes be unclear whether a particular requirement falls into one category or another; however, the important issue is not the "proper" categorization of the requirements, but rather that all necessary requirements are addressed. Each of these categories is briefly discussed below.
Software environment requirements specify the software environment in which the new software is expected to run. These requirements specify other software that is not a part of this project, but with which this software must work. This category can be extended to include the software development environment under which the project should be developed. Specific versions of the software may be required and should be indicated as necessary. Areas of concern include
- development environment
- Is there a requirement that the software be written in a specific language or languages? Which versions or dialects? Should certain development tools be used? Integrated development environments? Graphical user interface builders? Source code control systems?
- operating systems
- On what operating system(s) should the software run? Which versions?
- libraries
- Should the software make use of specific libraries, e.g. graphics, math, database, user interface, etc.?
- applications
- Should the software make use of specific applications, e.g. editors, databases, spreadsheets, etc.?
- data
- Is there specific data to be used by the software?
- portability
- What level of portability is required to other software environments? Source level? Object level? Isolation of dependencies?
Examples of software environment requirements include:
An important distinction needs to be made here that often causes confusion. These requirements specify the software environment that the new software must run in. They do not specify the software environment that the new software requires to run. In other words, we are specifying constraints that the environment is placing on the new software, not constraints that the new software is placing on the environment.
Just as software environment requirements specify the software environment in which the new software is expected to run, hardware environment requirements specify the details of the hardware environment in which the software is expected to run. As in the case of the software environment, requirements should indicate specific revision levels, version numbers and model numbers as necessary. Here are some hardware issues that are often of interest with respect to the software being developed.
- processor
- On what processors/CPU boards should the software run? Which version? How much main memory is available for use by the software? Are there any restrictions on its use? How big will the virtual address space be? How much of it is practical to use?
- mass storage
- What mass storage systems will be available? Floppy disk? Tape? Hard disk? CD-ROM? Video disc? What are their capacities? Their average access times? Their transfer rates?
- user interface hardware
- What hardware will be available for interfacing with the user? Mouse? How many buttons? What resolution? Keyboard? What type? Light pen? Tablet? Touchscreen? Microphone? Speech recognition? Bitmapped display? What resolution? Color? CRT? Hardcopy terminal? Printer/plotter? Color? Sound generation facilities?
- hardware accelerators
- What hardware accelerators will be available to the software? Floating point? Array processors? Graphics engines? Routing engines?
- other peripherals
- What other peripherals will be available? Communications processors? Modems? Network interfaces? Graphics devices?
- portability
- What level of portability to other hardware is required? Source level? Object level? Isolation of hardware dependencies?
Examples of hardware environment requirements include:
Compatibility requirements describe the ways in which the software must be compatible with (or may not be compatible with) other systems, both hardware and software.
- other systems
- How is the software compatible with other systems? Is it able to use data created by other software? Does it produce data in a form usable by other software?
- hardware modifications
- What modifications might be required of existing hardware systems to make them compatible with the new software?
- software modifications
- What modifications might be required of other software systems to make them compatible with the new software?
- incompatibilities
- What are the known incompatibilities that will be allowed to exist?
- obsoleted systems
- Will any systems be obsoleted by this new software?
- necessary conversions
- Will conversions be required (or even possible) to, for example, make data produced by an older system usable by the new system and vice versa?
Examples of compatibility requirements include:
Performance requirements deal with speed, capacity, and reliability of the new software. Software that is functionally correct, but is too slow, for example, may be useless. Software controlling surgical instruments that has a 1% chance of incorrect behavior is probably unacceptable.
- speed
- What response times are acceptable? Are there minimum and maximum response times allowable? Is there a minimum startup time for an application? Can probabilities or ranges be assigned to these values?
- capacity
- What is the throughput of the software? How many megabytes per second should be processed? What quantity of data should the software be able to handle? What are the parameters of input data? Number of lines? Length of lines? Amount of data? Are there constraints on resource usage?
- reliability
- How reliable should the software be? What should be the MTBF (mean time between failure)? What amount of down time is acceptable? What level of robustness is required? In the presence of input errors? In the presence of hardware errors? Are there unusual security issues? Should access to information be controlled? Should redundant copies of information be maintained?
Examples of performance requirements include:
The functional requirements are the heart of the requirements for the software. They specify the services provided by the software -- what the product does in detail. One should be careful during requirements to specify only what the software is to do -- not how it is to do it, unless it is required that the software be implemented in a particular way. This is usually not the case; the requirements should indicate a problem to be solved; the solution to the problem should be left to the designers.
There are many ways to state functional requirements. Some combination of the following may be appropriate for your project -- narratives, block diagrams, screen faces, prototype menus and forms, grammars, regular expressions, command/operator sets, state tables, formal equations. Examples are often useful and help to clarify the requirements.
Often, it is not practical (or even desirable) to state all requirements explicitly, since this may overconstrain the problem. It is perfectly reasonable to leave some issues to be resolved by the implementor. However, it should be made clear when this is the case.
Requirements are often not absolute; they vary in degree of importance or priority. Some will be in the category of "the software must ...". Others will be in the category of "it would be nice, but not necessary, if the software ...". Many requirements will lie somewhere in between these extremes. By indicating the relative importance of requirements, one can avoid overconstraining the problem, but still get useful features. The designer may relax relatively unimportant requirements in favor of meeting the more important ones. Also, the relaxation of lesser requirements might lead to a better design, more efficient operation, or a simpler user interface.
Examples of functional requirements include:
User interface requirements specify how the user is to interact with the system. Who are the users of the system? What are their levels of ability? What is the format for input from and output to the user? How are exceptional conditions to be handled? How should the user be notified of diagnostic/error/status messages? What options can the user specify? What commands can the user execute? What menus and forms should be used?
Examples of user interface requirements include:
Software interface requirements indicate how the software is to interact with other software. What files are to be taken as input and produced as output? What are their formats? Is the software to communicate with other processes via interprocess communication? What protocols will be used? Is the software to communicate with other software through shared memory? What conventions are followed? Is the software to communicate with other software through mass storage, e.g. removable media such as tape or floppy disk? What is the format of data on these media?
Examples of software interface requirements include:
Documentation requirements indicate what documentation will be required as part of the software development. Man pages? User reference manual? Tutorial manual? Developer manual? Online help? Are there documentation standards or guidelines that must be followed? What tools may be used to produce the documentation? Who are the intended audiences?
Examples of documentation requirements include:
Release requirements state the set of deliverables required for the project. The deliverables usually include the source and binary files and documentation. Any requirements as to methods of building and installation of the software should be stated. The media on which the software will be delivered as well as the form for online and hardcopy listings and documentation should be given.
Examples of release requirements include:
It is very important that all requirements can be verified. It must be possible to determine whether the resulting software meets the requirement or not. If there is no way to do that, then it is not a requirement. Thus, the following statements are not really requirements, since they cannot be measured:
Pfleeger [Pfleeger 91] describes seven ways in which requirements should be evaluated:
It is sometimes difficult to separate requirements issues from design issues. This can be particularly difficult for many of us, since in classes we are almost always given a set of requirements (a homework assignment, for instance), and we immediately begin to focus on solving the problem, i.e. we immediately focus on design and implementation. At this stage of the project, we need to be careful to focus only on requirements, and not get caught up in trying to come up with a design. We'll have time for that later.
For example, are the following requirements issues, or are they design issues?
Most people would probably say the first statement was a requirements issue and the second was a design issue, while there may be considerable disagreement on the third. However, it is generally not possible to examine a statement in isolation and deduce whether it is a requirement or a design issue. The first statement could be a design issue, if there were no requirement specified as to spreadsheet size, leaving it to design to determine the practical limits. The second statement could be a requirement, if for some reason the customer wanted that technique to be used. The third statement, of course, could be either a requirements issue or a design issue. If the customer wants the product implemented in C++ no matter what, it is a requirement. If the customer wants the product implemented in the best language for the task (which might be C++), then it is a design issue.
At first, it may indeed appear to be quite difficult to determine if something is a requirement or a design issue. However, it is actually quite simple. If the software is required to meet a constraint, then that constraint is a requirement. If the software is not required to meet a constraint, then that constraint is not a requirement. This may sound a little silly and perhaps somewhat circular, but it is the only way to determine if something is a requirement or not.
Finally, it should be emphasized that the requirements describe requirements on the software to be developed, not needs of the software to be developed. The requirements should describe the constraints the software must meet to be successful, not requirements that the software may need to fulfill its purpose. For example, the software may be required to be written in C++ and have an X Windows graphical user interface. A logical choice for doing this might be the Interviews C++-based X Windows toolkit. However, the use of Interviews would not be stated as a (in this case, software) requirement, since the customer does not require that this particular toolkit be used.
We will be producing two requirements documents in this class. The first document will be an initial set of requirements for our software, while the second will be a more detailed specification of the requirements. The initial requirements paper is intended to be a somewhat less formal document, lying somewhere between an actual specification and a "back of the envelope" requirements analysis. The goal is to produce a relatively quick, but thorough, set of requirements for our system, from which we are able to begin to develop some high-level architecture. We will revisit requirements later to develop them further. Note that, while the document is intended to be produced rather quickly, that does not imply that it should be a rough draft or be poorly written.
The initial requirements paper should include a cover page, a problem statement, a table of contents, and an introduction to the project and the paper, as well as the description of the requirements.
The cover page should include information about the project and the paper. This includes
This section should be a brief, informal statement of the problem to be solved. The problem statement should be similar to the project descriptions you used when you were choosing your project. If the project has changed slightly, update the description.
The Table of Contents should include section headings and page numbers. Two or three levels are usually sufficient.
The Introduction should give a general description of the sponsor and of the software to be developed. It should indicate its purpose, principal features and facilities, and its relation to other products, both software and hardware. It should include a figure that shows this relationship. It should introduce the paper, describing its purpose, content, and organization.
This section should be an organized listing of the requirements. A reasonable way to organize this section is along the lines of the categories of requirements presented above. Some categories may apply to your project; others may not. You may choose to organize your requirements differently. You should not be overly concerned with the proper categorization of the requirements; you should be more concerned with getting all of the requirements written down in an understandable form.
Here is a checklist of items to consider when writing your requirements specification. It is, by no means, complete. However, before you turn in your initial requirements, you should go through the checklist and make sure that every applicable item is covered in your paper.
An example set of initial requirements for our hypothetical GEEK project is provided below. You may use it as a template for your document if you wish, but you are, by no means, required to format or organize it in the same way, as long as you make certain your document is complete.
This discussion covers many of the issues with which you will have to be concerned when generating the requirements for your project. It is certainly not complete; it is certain that each project will have requirements that are not mentioned here. However, these notes, along with the GEEK example, should give you a start towards determining the requirements issues that are relevant to your particular project.
Requirements will need to be generated through communication with your sponsor. This can at times be difficult, and also at times be somewhat awkward. In fact, Pressman [Pressman 92] compares these initial requirements meetings to a first date where neither person knows what to say; both are concerned that what they do say will be misinterpreted; both are wondering where it might lead; both want to get it over with; but at the same time, both want it to be a success.
Here are some facts about some little known languages you may (or may not) find useful at some point in your career. Fortunately (for him or her), the author of this work is unknown.
Basic, Fortran, Cobol . . . These programming languages are well-known and (more or less) well-loved throughout the computer industry. There are numerous other languages, however, that are less well-known yet still have ardent devotees. In fact, these little-known languages generally have the most fanatic admirers. For those who wish to know more about these obscure languages -- and why they are obscure -- the following catalog is presented.
- SIMPLE
- SIMPLE is an acronym for Sheer Idiot's Mono-purpose Programming Linguistic Environment. This language, developed at the Hanover College for Technological Misfits, was designed to make it impossible to write code with errors in it. The statements are therefore confined to BEGIN, END, and STOP. No matter how you arrange the statements, you can't make a syntax error.
Programs written in SIMPLE do nothing useful. Thus they achieve the results of programs written in other languages without the tedious, frustrating process of testing and debugging.
- SLOBOL
- SLOBOL is best known for the speed, or lack of it, of its compiler. Although many compilers allow you to take a coffee break while they compile, SLOBOL compilers allow you to take a trip to Bolivia to pick up the coffee. Forty-three programmers are known to have died of boredom sitting at their terminal while waiting for a SLOBOL program to compile.
- VALGOL
- (With special thanks to Dan and Betsy "Moon Unit" Pfau.) From its modest beginnings in southern California's San Fernando Valley, VALGOL is enjoying a dramatic surge of popularity across the industry.
VALGOL commands include REALLY, LIKE, WELL, and Y$KNOW. Variables are assigned with the =LIKE and =TOTALLY operators. Other operators include the "CALIFORNIA BOOLEANS": FERSURE and NOWAY. Repetitions of code are handled in FOR-SURE loops. Here is a sample VALGOL program:VALGOL is characterized by its unfriendly error messages. For example, when the user makes a syntax error, the interpreter displays the message, GAG ME WITH A SPOON!14 LIKE, Y$KNOW (I MEAN) START %% IF PI A =LIKE BITCHEN AND 01 B =LIKE TUBULAR AND 9 C =LIKE GRODY**MAX 4K (FERSURE)**2 18 THEN 4I FOR I=LIKE 1 TO OH MAYBE 100 86 DO WAH + (DITTY**2) 9 BARF(I) =TOTALLY GROSS(OUT) -17 SURE 1F LIKE BAG THIS PROGRAM ? REALLY $$ LIKE TOTALLY (Y*KNOW)
- LAIDBACK
- Historically, VALGOL is a derivative of LAIDBACK, which was developed at the (now defunct) Marin County Center for T'ai Chi, Mellowness, and Computer Programming, as an alternative to the more intense atmosphere in nearby Silicon Valley.
The center was ideal for programmers who liked to soak in hot tubs while they worked. Unfortunately, few programmers could survive there for long, since the center outlawed pizza and RC Cola in favor of bean curd and Perrier.
Many mourn the demise of LAIDBACK because of its reputation as a gentle and nonthreatening language. For example, LAIDBACK responded to syntax errors with the message, SORRY MAN, I CAN'T DEAL WITH THAT.
- SARTRE
- Named after the late existential philosopher. SARTRE is an extremely unstructured language. Statements in SARTRE have no purpose; they just are there. Thus, SARTRE programs are left to define their own functions. SARTRE programmers tend to be boring and depressed and are no fun at parties.
- FIFTH
- FIFTH is a precision mathematical language in which the data types refer to quantity. The data types range from CC, OUNCE, SHOT, and JIGGER to FIFTH (hence the name of the language), LITER, MAGNUM, and BLOTTO. Commands refer to ingredients such as CHABLIS, CHARDONNAY, CABERNET, GIN, VERMOUTH, VODKA, SCOTCH, and WHATEVERSAROUND.
The many versions of the FIFTH language reflect the sophistication and financial status of its users. Commands in the ELITE dialect include VSOP and LAFITE, while commands in the GUTTER dialect include HOOTCH and RIPPLE. The latter is a favorite of frustrated FORTH programmers who end up using the language.
- C-
- This language was named for the grade received by its creator when he submitted it as a class project in a graduate programming class. C- is best described as a "low-level" programming language. In fact, the language generally requires more C- statements than machine-code statements to execute a given task. In this respect, it is very similar to COBOL.
- LITHP
- This otherwise unremarkable language is distinguished by the absence of an "s" in its character set. Programmers and users must substitute "TH." LITHP is thaid to be utheful in prothething lithtths.
- DOGO
- Developed at the Massachusetts Institute of Obedience Training. DOGO heralds a new era of computer-literate pets. DOGO commands include SIT, STAY, HEEL, and ROLL OVER. An innovative feature of DOGO is "PUPPY GRAPHICS," in which a small cocker spaniel leaves a deposit as he travels across the screen.