Requirements Analysis Methods

Introduction

This page lists some introductory information about different methods of doing the required analysis of a project, so as to come up with a set of requirements that is clear, complete, and agreed-upon. To be clear, the description must be understandable by both the developers and the users and customers, which necessitates use of both diagrams and language. To be complete, the requirements definitions must describe what the software must do, what functions it provides, what user audience it must support, and how well it must work in terms of the computational performance. To be agree-upon, the requirements must prove that all the interested parties (e.g., users, sponsors, and developers) have agreed to every specific detail of the document, including whether the application is appropriate to the business need, as well as whether the software is feasible to produce within the cost and schedule constraints contained in the document.

How does this happen? This web page addresses these three premises one at a time, then presents several methods of performing the analysis process to achieve these goals.

First, Some Interesting Facts. . .

According to a 1979 report document from the General Accounting Office (GAO) of the US Government, less than 5% of the money put into nine particular software development projects resulted in software which could be used as delivered or with only minor changes. Projects worth over $5 Million failed to implement usable software. It is notable, however, that to the developers, the software "worked", but to the users the applications were "worthless".

An Illustration

Here is a scenario (from the Martin book) illustrating a common problem.

Suppose a team of programmers has developed an application which is successfully delivered and deployed. However, little design documentation is produced, there is no standard coding style used, and the code is poorly commented. In addition, let's say that no CM philosophy was used. Soon after delivery, one or more users call up a programmer (who is a member of the original development team) for a change to the application. The programmer makes a quick change to the software to implement the request. The programmer is a "shero" and she feels good about the success. However, the programmer's management has not required her to document her change to the software. Now suppose this happens several times; subsequently the programmer moves on to another project (or worse for this case, another company). Users now find that a different programmer must respond to their change requests. However, since she is not as familiar with the original application and has no idea what changes were made due to the undocumented nature of the modifications, she must be more cautious. Nevertheless, under management pressure, she makes the required modifications, and is able to get them to work. This keeps happening for a time, after which she also moves on. Now, nobody can understand the program. In fact, no one knows what the program is supposed to do any longer. Eventually it becomes too expensive to try to maintain the application, and it must be totally rebuilt or even scrapped.

Reasons For Failures. . .

• Insufficient Schedule: Users are anxious to get the working system as soon as possible.
• Insufficient/inefficient user review: Users may not understand the requirements document or how to review it. They may become trapped in review meetings which don't seem to make things any clearer.

Differences of opinion: Agreement is difficult to attain; the systems analyst needs to be adept at getting consensus among all parties involved. Politics: Decision-makers can foil the best intentions of any well-meaning analyst. The best defense against this is to determine who they are and try to keep them as involved as possible. This may be difficult in itself, as they may desire only a limited involvement. Lack of technical knowledge: It is difficult to define a feasible system when the principal people involved don't understand the limitations of the state-of-the-art in commercial hardware and software.

• Documentation deficiency: The ability to express things clearly in text is essential for every systems analyst.
• Lack of structured analysis: Without having had experience performing structured analysis, or without having read texts on the subject, it is not obvious what should be included in the application definition.

User-centric Approach. . .

The above list shows some of what a computer-knowledgeable writer needs to become a good requirements analyst; a well-defined system description approach which is quick and which involves not only the analyst, but also the users and sponsors, in all important decisions.

One principle which underlies a user-centric approach to requirements analysis is that application descriptions should be oriented toward users rather than toward developers. Results of systems analysis should be written in terms that are easily understood by the users and should clearly indicate how users will be interacting with the system.

Another principle is that functional requirements and data requirements are equally important in an application description and should be developed together. The functional requirements are statements of the services the application will provide, while the data requirements are a description of the information that the system will be required to handle.

Requirements Clarity

Verifiable requirements are stated in such a manner that different people who examine the final product will all agree whether or not the requirement is satisfied. The requirements language must not be vague; generalities in requirements fail to answer the questions about which capabilities will be in the application and which will be excluded.

On the other hand, a mammoth list of 300 pages of detail about the functional, design, and operational characteristics of the system will be "overkill". There is solid verifiability, each characteristic is precise, all characteristics are represented. However, after 20 to 30 pages of text, the user will be totally lost without some sort of coherent organization. Some of the best naps to be had at work begin with reading a 150-page requirements specification!

Clarity in the requirements specification requires the following things:

• Define all special terms
• Follow successive elaboration, using increasing levels of detail
• Display simple pictorial models
• Key all the requirements to the diagrams
• Define the requirements no lower than the first testable level
• Make sure the document is internally consistent

The definition of "successive elaboration" is to work first with the users on the broadest issues of functional and data characteristics. Make diagrams of what is agreed upon. Then, look at one small subset of the diagrams at a time and break it down to the next level of detail. Keep iterating this process until the lowest level of requirement necessary is reached.

Requirements Completeness

What material should be included to ensure a complete specification? The requirements document should:

• Tell what users need and how well this must be performed in a measurable way
• Include functional requirements
• Include database requirements
• Include performance requirements
• Tell what computer hardware and system software must be used
• Indicate whether the application will be developed in phases or not; if so, list the phases, and either group the requirements by phase, or provide a list of the requirements met by each phase

It is often best to leave the design detail determination until all the requirements have been firmly decided and agreed upon by all parties. That way, the analysis will not have to be amended or thrown away just because the requirements have evolved. Two rules that help set the boundary lines between requirements and design are: If the subject is important to the users, it should be in the requirements not in the design, and If the subject requires user input to decide what is needed, it should be considered for inclusion in the requirements, not in the design.

Requirements Agreement

Clear, complete requirements are still worthless without agreement between all of the concerned parties that they are what the users and sponsors want, and that they are attainable by the developers. Proceeding with the analysis in a top-down manner lets all the participants contribute to the decisions. Keeping management informed and participating throughout the process helps remove roadblocks when it comes time to "sign-off" on the document; since the managers will already be familiar with the concepts, they are less likely to hesitate or "stonewall" when their signatures are required for authorization. Each revision of the document itself should always be distributed with a "change sheet" which explains the differences between the current and previous versions. The analyst must remind the manager that the specification document is a "living document" which will keep evolving. This means once the "stakeholders" sign off on the document, changes to the specification become changes to the project, with the corresponding additions to time and money. As in any engineering project, changes during development are increasingly expensive the longer one waits to make them.

When writing the document, keep in mind the principle that redundancy is the enemy of consistency. Work hard to ensure that each requirement is only specified in a single place in a single document, so that if that requirement changes, there is only one place to change the text.

Agreement may be obtained by a process that:

• Develops and reviews the specification using successive elaboration
• Includes a formal sign-off page
• Has managers formally sign off any changes
• Keeps the document current with agreed-upon changes
• Eliminates redundancy as much as possible

Requirements Generation Methods

One good way to learn requirements elaboration, especially for Object Oriented system design, is by using CRC cards. CRC stands for "Class-Responsibility-Collaboration", and was originally developed in the late 1980s by Ward Cunningham and Kent Beck of the Tektronix Research Labs in Portland, Oregon. The idea is to break from using a description of bits of data and process by using a few sentences to express the purpose of a class. This is the reason for the first "C" for "class". The other "C" for "Collaboration" points to the other classes that a represented class must work with in the system. The "Responsibility" portion helps the designer visualize the classes as more than just data repositories, by including the operations they are required to implement.

According to UML Distilled, CRC cards are used "to help explore an interaction between classes, typically to show how a scenario is implemented."

Here are some links to pages from the Internet, from Cal Poly and from Trinity College, University of Dublin, Ireland. These provide a good description of the details of CRCs.

CRC cards allow the system designers to model the system operations, which in turn allows them to see what is required for the system to operate in the desired manner. From this initial set of functional operations, successive iterations of the process will produce ever-finer granularity of required functionality. When the elaboration process stops focusing on "what" and begins to get into "how", it is time to stop and write up the requirements specification.

Another way to perform the requirements elaboration is using the "use-case" analysis. In this process, the which is similar to the CRC card method, the engineers look at the system in terms of the functions that will be "seen" or "used" by the users of the system. From this, the designers can determine what the system must do to properly provide these functions. The emphasis is what the system will do, NOT how it is done. Staying focused on the "what" is the key.

The use-case model describes these functional requirements in terms of "actors" and "use cases". Actors characterize an outside user or related set of users that interact with the system. A human actor may use I/O devices to physically interact, or may initiate operations of the system by other means. A system actor may be a sensor, timer, or other device that is part of our system, or another system that interacts with ours.

As an example, consider a use case description for the COOK FOOD operation of a microwave oven:

            Name: COOK FOOD
            Summary: User puts food into microwave oven, oven cooks food
            Actors: User, Oven
            Start State: Oven is plugged in to AC power, and is in idle state
            Description of operation:
                  1.  User opens oven door
                  2.  User puts food, which is in container, into oven
                  3.  User closes oven door
                  4.  User presses desired number of minutes and seconds
                      using keypad on front of oven
                  5.  User presses START button on front of oven
                  6.  Cooking subsystem starts cooking food
                  7.  Timer subsystem displays count of remaining time to cook
                  8.  Timer elapses and informs cooking system
                  9.  Cooking subsystem stops cooking and displays done message
                 10.  Timer subsystem beeps electronic notification
                 11.  User opens oven door and removes container
                 12.  System clears the display
            Alternatives:
                 Line 1:  User presses start with door open; nothing happens
                 Line 5:  User presses start with no food in oven; nothing happens
                 Line 5:  User presses start with no time set; nothing happens
                 Line 6:  User opens door while cooking subsystem is operating; oven
                            stops cooking.  User then presses CANCEL and removes food;
                            system clears the display
                 Line 6:  User opens door while cooking subsystem is operating; oven
                            stops cooking.  User then presses START; system resumes cooking
                 Line 6:  User presses CANCEL; system stops cooking.  User opens door and
                            removes food, and system clears the display
            End State: Oven has cooked food, and has returned to idle state
      

Notice that the use case lists the steps for the operation, and that the steps are at a fairly high level. The steps tell WHAT is done, not HOW it is done. Also notice that the use case lists the start and end states of the system, the actors involved in the operation, and important alternatives within the scope of this scenario that may cause different outcomes of the process. These alternatives include both legal and illegal operations of the system.

A sample requirements specification for this use-case might include the following "shall" statements:

         1.0  Timer subsystem
         1.1  The timer subsystem shall respond to input from a keypad
         1.2  The timer subsystem shall maintain a countdown, in seconds, while food is cooking
         1.3  The timer subsystem shall notify the cooking subsystem when the time elapses
         1.4  The timer subsystem shall sound an audible alert when the time elapses

         2.0  Cooking subsystem
         2.1  The Cooking subsystem shall not operate with the door open
         2.2  The Cooking subsystem shall stop operation when the door is opened while the oven
              is in operation
         2.3  The Cooking subsystem shall stop operation when the CANCEL button is pressed while
              the oven is in operation
         2.4  The Cooking subsystem shall begin operation when the door is closed and the START
              button is pressed
         2.5  The Cooking subsystem shall stop operation when the timer subsystem provides the
              notification that the time has elapsed
         2.6  The Cooking subsystem shall provide sufficient heat to cook the food contained in
              its cabin while the oven is in operation