Requirements Engineering

Chapter 7
Requirements Engineering

CHAPTER OVERVIEW AND COMMENTS

The intent of this chapter is to present requirements engineering tasks and basic requirements analysis concepts and principles.
Regardless of the process model used by software engineers, requirements engineering is an essential part of a successful software development project. The focus of this chapter is gathering the information needed to build the information, function, and behavioral portions of the analysis model.
Understanding the requirements of a problem is among the most difficult tasks that face a software engineer.

7.1 The Bridge to Design and Construction

In this section, requirements engineering is described as a bridge between communication and analysis modeling, design and construction.

For all new systems, the requirements engineering process should start with a feasibility study.

The input to the feasibility study is a set of preliminary business requirements, an outline description of the system and how the system is intended to support business processes.

The results of the study should be a report that recommends whether or not it is worth carrying on with the requirements engineering and system development process.
Many software engineering developers want to jump right in before they have a clear understanding of what is needed.
A feasibility study is a short, focused study that aims to answer a number of questions:

1. Does the system contribute to the overall objectives of the organization?
2. Can the system be implemented using current technology and within given cost and schedule constraints?
3. Can the system be integrated with other systems which are already in place?

“The hardest single part of a software engineering system is deciding what to build.  No part of the work so cripples resulting system if done wrong.  Not other part is more difficult to rectify later” Fred Brooks.
Requirement Engineering is a software engineering action that begins during communication activity and continues into the modeling activity.
It is essential that the software engineering team attempts to make a real effort to understand the requirements of a problem before the team attempt to solve the problem.
RE establishes a solid base for design and construction.  Without it, the resulting software has a high probability of not meeting customers’ needs.

7.2 Requirements Engineering Tasks

RE provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system.
7.2.1 Inception
How does a software engineering project get started? Is there a single event that becomes the catalyst for a new computer-based system or product, or does the need evolve over time?
There are no definitive answers to these questions.
At project inception, software engineers ask a set of questions that establish …

• basic understanding of the problem
• the people who want a solution
• the nature of the solution that is desired, and
• the effectiveness of preliminary communication and collaboration between the customer and the developer

7.2.2 Elicitation
Christel and Kang identify a number of problems that help us understand why requirements elicitation is difficult:

• Problems of scope.  The boundary of the system is ill-defined.
• Problems of understanding.  The customers/users are not completely sure of what is needed, have poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or unstable.
• Problems of volatility. The requirements change over time.

7.2.3 Elaboration

Elaboration is an analysis modeling action that is composed of a number of modeling and refinement tasks.
Elaboration is driven by the creation and refinement of user scenarios that describe how the end-user will interact with the systems.

7.2.4 Negotiation

It is not unusual for customers and users to ask for more than can be achieved given limited business resources.

The requirements engineer must reconcile these conflicts through a process of negotiation.
Customers, users, and other stakeholders, are asked to rank requirements and then discuss conflicts in priority.
Risks associated with each requirement are identified and analyzed; hence, rough “guestimates” of development efforts are made.

7.2.5 Specification

A specification can be any one (or more) of the following:

• A written document
• A set of models
• A formal mathematical
• A collection of usage scenarios (use-cases)
• A prototype

The specification is the final work product produced by the requirements engineer. 
It serves as the foundation for subsequent software engineering activities.
It describes the function and performance of a computer-based system and the constraints that will govern its development.

7.2.6 Validation

Requirements validation examines the specification to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project and the product.
The primary requirements validation mechanism is the formal technical review.
The review team that validates requirements includes software engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, conflicting requirements, or unrealistic requirements.

7.2.7 Requirements Management

Requirements Management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds.
Read book page 148 for more details.

7.3 Initiating the Requirements Engineering Process
The process of initiating engineering is the subject of this section.  The point of view described is having all stakeholders (including customers and developers) involved in the creation of the system requirements documents.
The following are steps required to initiate requirements engineering:
7.3.1 Identifying the Stakeholders
A stakeholder is anyone who benefits in a direct or indirect way from the system which is being developed. [Sommerville and Sawyer]
In the book stakeholders are: operations managers, product managers, marketing people, internal and external customers, end-users, consultants, product engineers, software engineers, support and maintenance engineers, etc.
At inception, the requirements engineer should create a list of people who will contribute input as requirements are elicited.
The initial list will grow as stakeholders are contacted because every stakeholder will be asked”Who else do you think I should talk to?”
7.3.2 Recognizing Multiple Viewpoints
Each of the stockholders will contribute to the RE process.
As information from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another.
The requirements engineer is to categorize all stakeholder information including inconsistencies and conflicting requirements in a way that will allow decision makers to choose an internally inconsistent set of requirements for the system.

7.3.3 Working toward Collaboration
Collaboration does not necessarily mean that requirements are defined by committee.  In many cases, stakeholders collaborate by providing their view of requirements, but a strong “project champion” (business manager, or a senior technologist) may make the final decision about which requirements make the final cut.
7.3.3 Asking the First Questions
The first set of context-free questions focuses on the customer and other stakeholders, overall goals, and benefits.
The first questions:

• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?

The next set of questions enables the software engineering team to gain a better understanding of the problem and allows the customer to voice his/her voice:

• How would you characterize “good” output that would be generated by a successful solution?
• What problems will this solution address?
• Can you show me the business environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?

The final set of questions focuses on the effectiveness of the communication activity itself.  Gause and Weinberg call these questions “meta questions”

• Are you the right person to answer these questions? Are your answers “official”?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

“He who asks a question is a fool for 5 minutes, he who doesn’t ask a question is a fool forever.” Chinese proverb

7.4 Eliciting Requirements
The Q&A session should be used for the first encounter only and then replaced by a requirements elicitation format that combines elements of problem solving, elaboration, and specification.
7.4.1 Collaborative Requirements Gathering
In this approach the stakeholders collaborate under the supervision of a neutral facilitator to determine the problem scope and define an initial set of requirements.
Collaborative Requirements Gathering all apply some variation on the following guidelines:

• meetings are conducted and attended by both software engineers and customers
• rules for preparation and participation are established
• an agenda is suggested
• a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting
• a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used
• the goal is to identify the problem, propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements

Read the scenario presented in the book page 153.
7.4.2 Quality Function Deployment (QFD)
In this technique the customer is asked to prioritize the requirements based on their relative value to the users of the proposed system.
QFD is a technique that translates the needs of the customer into technical requirements for software engineering.  QFD identifies three types of requirements:
Normal requirements: These requirements reflect objectives and goals stated for a product or system during meetings with the customer.
Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them.
Exciting requirements: These requirements reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.
In meeting with the customer, function deployment is used to determine the value of each function that is required for the system.  Information deployment identifies both the data objects and events that the systems must consume and produce.
Finally, task deployment examines the behavior of the system within the context of its environment. And value analysis determines the relative priority of requirements determined during each of the three deployments.
7.4.3 User Scenarios
As requirements are gathered an overall version of system functions and features begins to materialize
Developers and users create a set of scenarios that identify a thread of usage for the system to be constructed in order for the software engineering team to understand how functions and features are to be used by end-users.
7.4.3 Elicitation Work Products
For most systems, the work product includes:

• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.
• Any prototypes developed to better define requirements.

7.5 Developing Use-Cases
Use-cases are defined from an actor’s point of view.  An actor is a role that users or devices play as they interact with the software engineer.
The first case in writing a use-case is to define the set of “actors” that will be involved in the story.
Actors are the different people or devices that use the system or product within the context of the functions and behavior that is to be described.
An actor is anything that communicates with the system or product and that is external to the system itself.
Because requirements elicitation is an evolutionary activity, not all actors are identified during the 1st iteration.
Primary actors interact to achieve required system functions and derive the intended benefit from the system.
Secondary actors support the system so that primary action can do their work.
Once actors have been identified, use-cases can be developed.
A number of questions that should be answered by a use-case:

• Who is the primary actor, the secondary actor (s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What extensions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?

7.6 Building the Analysis Model

This section discusses analysis modeling. The elements of the analysis model (scenario-based, class-based, behavioral, and flow-oriented) are introduced.

The intent of the analysis model is to provide a description of the required informational, functional, and behavioral domains for a computer-based system.
The model changes dramatically as software engineers learn more about the system, and the stakeholders understand more about what they really require.

7.6.1 Elements of the Analysis Model

The specific elements of the analysis model are dictated by the analysis modeling method that is to be used.  However, a set of generic elements is common to most analysis models.

Scenario-based elements: The system is described from the user’s point of view using a scenario-based approach.
It always a good idea to get stakeholders involved.  One of the best ways to do this is to have each stakeholder write use-cases that describe how the software engineering models will be used.
Functional—processing narratives for software functions
Use-case- descriptions of the interaction between an “actor” and the system.

Class-based elements: Each usage scenario implies a set of “objects” that are manipulated as an actor interacts with the system.
These objects are categorized into classes- a collection of things that have similar attributes and common behaviors.
One way to isolate classes is to look for descriptive nouns in a use-case script.  At least some of the nouns will be candidate classes.

Behavioral elements:  The state diagram is one method for representing the behavior of a system by depicting its states and the events that cause the system to change state.
A state is any observable mode of behavior. Moreover, the state diagram indicates what actions are taken as a consequence of a particular event.

Flow-oriented elements: Information is transformed as it flows through a computer-based system.
The system accepts input in a variety of forms; applies functions to transform it; and produces output in a variety of forms.

7.7 Negotiating Requirements

The customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance, and other product or system characteristics against cost and time to market.
The intent of the negotiations is to develop a project plan that meets the needs of the customer while at the same time reflecting the real-world constraints (time, people, and budget) that have been imposed on the software engineering team.
Boehm defines a set of negotiation activities at the beginning of each software process iteration.  The following activities are defined:

• Identify the key stakeholders.  These are the people who will be involved in the negotiation.
• Determine each of the stakeholders “win conditions”. Win conditions are not always obvious.
• Negotiate; work toward a set of requirements that lead to “win-win”

7.8 Validating Requirements

The purpose of requirements validation is to make sure that the customer and developer agree on details of the software requirements (or prototype) before beginning the major design work. This implies that both the customer and developer need to be present during the validation process.
As each element of the analysis model is created, it is examined for consistency, omissions, and ambiguity.
The requirements represented by the model are prioritized by the customer and grouped within requirements packages that will be implemented as software increments and delivered to the customer.
A review of the analysis model addresses the following questions:

• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information, function and behavior of the system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.
• Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

These and other questions should be asked and answered to ensure that the requirements model is an accurate reflection of the customer’s needs and that it provides foundation for design.