Introduction

Software requirements understanding and management is a critical step in the software development process. It is the focal point of understanding the needs and objectives of the customer and their expectations for the software system. However, requirements understanding is a communication process and by definition is very difficult.

There are two main reasons for the difficult nature of requirements understanding. The first and obvious reason is the imprecise nature of human language. Statements by the users are not necessarily what they intend and a dialog must ensue to ensure a clear understanding between the customer and the development team. The second reason is termed "requirements uncertainty" by Watts Humphreys. A system's requirements may not be clearly understood by the customer until after the customer actually uses the system.1 In other words, the customer may not yet know what it wants the system to perform.

Due to the unclear requests by customers, requirements understanding and management must be addressed formally to obtain as precise a set of system requirements as possible. A formal requirements definition and agreement process should be followed. The process' purpose is to enhance communication between the customer and the system development team beyond simple conversation. There needs to be 'guided communication' that ensures clarity and precision about the expected behavior of the system under development.

Management of the requirements definition process requires certain procedures be set up and followed to make sure the communication between the parties is precise and documented. The basic procedure follows four steps. First, identify and analyze the requirements. Second, refine the definitions of the requirements by repeated rounds of communication with the customer. Third, reach agreement with the customer about the requirements and formalize the mutual understanding with a contract. Finally, set up the development infrastructure to monitor the requirements as they flow through the design and implementation of the software as it is developed.

The Process

Step 1 is the identification and analysis of the customer's requirements. Many techniques have been developed over the past 40 years to help define requirements. One technique that has permeated the software development community is known as the Use-Case method. It was first published by Ivar Jacobson in the early 1990s as part of the object-oriented analysis and design movement.2 One part of his development process is the Use-Case Model which coincides with the Requirements Baseline in the traditional project management method.

The use-case is very useful in identifying requirements. It is a formal communication tool that aides the customer and the development team. It guides both parties through a description of the system as it will be used by the customer. A set of use-cases describe the outer scope of the system. An individual use-case will show how the customer will interact with the system for one particular function or purpose.

The main advantages of the use-case tool are threefold. First, it describes the systems from the point-of-view of the user. It allows the customer to use their own language to describe the system and does not include technical terms that could be injected if the developer wrote the requirements. Second, it helps focus the development team on the user's perspective. This ensures the development team sees the system from the point of the customer. Third, it helps the customer to clarify their requests for system behavior and diminishes the "requirements uncertainty" mentioned earlier.

Many books have been written on use-cases, one such book, Writing Effective Use Cases, is located elsewhere in the nodegel. I wrote a book review for it in 2002. The review was published in the newsletter of the Object-Technology User Group (OTUG), a software based group active on the St. Thomas University campus.

I have utilized Use-Case analysis extensively over the last 10 years. When implementing the CMM to bring my department up to Level 2 Repeatable. I used the use-case technique to describe the services my department provides as-if it were a black-box system with an application programming interface (API) my department's customer's could access.

Step 2 is the refinement of the requirements by repeated rounds of communication between the customer and the development team. Both parties will review the use-cases and derive requirements from those descriptions. They should focus their attention on vague terms or general statements that could be interpreted in more than one way. A well written requirement will have three characteristics: (a) state a single purpose; (b) state a time frame or specify a concluding condition; and (c) specify an action or activity.

The customer and the development team will pull out of the use-cases individual requirements. The requirements will be of four types. The first is a Sourced requirement. This is one that is explicitly stated by the customer. The second is a Parsed requirement which is one or more requirements that have been extracted from a complex, multiple-requirement statement. The third is the Interpreted requirement. As its label implies, this type of requirement is a refinement of a vaguely worded phrase or term. In Step 2, many requirements will be of this category. The fourth category is called Derived. A derived requirement is generated based on previously stated requirements. It follows logically from other information about the system. It is implied but up to this point was not explicitly stated. An example of a derived requirement is the unstated assumption that accounting software should contain the functions of addition and subtraction as intrinsic to the nature of the software.

Step 3 is arriving at an agreement with the customer about the system requirements and formalizing the agreement with a contract. The set of requirements is complete and each requirement is clearly phrased. Now the process is one of reviewing the set of requirements to determine their feasibility. The questions to be answered are (a) Is the requirement needed? (b) Is the requirement verifiable? and (c) Is the requirement attainable within the constraints of technology, cost, or time?

When mutual understanding is reached between the parties, then it should be formalized in two documents. The first is the requirements baseline, alternatively called a Use-Case Model. It is the set of requirements the customer requests and for which it agrees to pay. At the same time it is the set of features the development team agrees they can provide by the conclusion of the project. The second document is the contract formalizing this business agreement.

Step 4 is the conclusion of the requirements management process. It wraps up the process by placing the requirements baseline into a formal configuration management control system and sets procedures for formal requirements change. The former process provides an objective method for assigning requirements to the design and being able to trace design and implementation details back to specific requirements in the baseline. The latter process helps defend and protect the scope of the project from ad hoc user changes.

Summary

Software requirements understanding and management is a critical element of the software development process. It is essential to understand the customer's needs and translate those needs into requirements that can be fulfilled by the software. Requirements management involves a four-step process and utilized the use-case analysis tool to help the customer and the development team understand the requirements from the user's perspective.



Footnotes:

  1. Humphreys, page 315.
  2. Jacobson, page 127.

References:

  • Humphreys, Watts, A Discipline for Software Engineering, Reading, MA: Addison-Wesley, 1995.
  • Jacobson, Ivar, Object-Oriented Software Engineering A Use Case Driven Approach (revised), Wokingham, England: Addison-Wesley, 1993.

Log in or register to write something here or to contact authors.