Chapter 4

Requirements Engineering

Requirements Engineering It helps software engineers to better

understand the problem they will work to solve

It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants?

Types of Requirements Functional Requirements

These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations

Non-Functional Requirements These are constraints on the services or

functions offered by the system. They include timing constraints, constraints on the development process and standards

Requirements Engineering Tasks Requirements engineering provides the appropriate

mechanism for understanding what the customer wants, analyzing need, assessing feasibility, managing requirements as they are transformed into an operational system and so on

Requirements engineering is accomplished through seven functions: Inception Elicitation Elaboration Negotiation Specification Validation Management

Requirements Engineering Tasks - Inception Inception—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

Requirements Engineering Tasks - Elicitation Ask the customer, the user, and others

What the objectives for the system? What is to be accomplished? How the system fits into the needs of the

business? How the system is to be used on a day-to-day

basis?

Requirements Engineering Tasks - Elicitation A number of problems that makes the

requirements elicitation as a difficult task: Problems of scope

The boundary of the system is ill-defined Problems of understanding

The customers are not completely sure of what is needed?

Problems of volatility The requirements change over time

Requirements Engineering Tasks - Elaboration Elaboration is an analysis modeling action

that is composed of a number of modeling and refinement tasks

The end-result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem

Requirements Engineering Tasks - Negotiation It is common for different customers to propose

conflicting requirements The requirements engineer must reconcile these conflicts

through a process of negotiation Customers, users, and other stakeholders are asked to

rank requirements and discuss conflicts in priority Risks associated with each requirement are identified and

analyzed Rough “guestimates” of development effort are made and

used to assess the impact of each requirement on project cost and delivery time

Requirements Engineering Tasks - Specification A specification can be any on of the following:

A written document A set of graphical model A formal mathematical model A collection of user scenarios A prototype

The specification is the final work product produced by the requirements engineer

It serves as the foundation for subsequent software engineering activities

Requirements Engineering Tasks - Validation Requirements validation examines the specification to

ensure that all requirements have been stated unambiguously

The review team that validates requirements includes software engineers, customers, users, other stakeholders

A review mechanism that looks for errors in content or interpretation areas where clarification may be required missing information inconsistencies (a major problem when large products or

systems are engineered) conflicting or unrealistic (unachievable) requirements

Requirements Engineering Tasks – Requirements Management Requirement 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

Requirements management begins with identification. Once requirements are identified, traceability tables are developed

Requirements Engineering Tasks – Requirements Management Features traceability table

shows how requirements relate to important customer observable system features

Source traceability table identifies the source of each requirement

Dependency traceability table indicates how requirements are related to one another

Subsystem traceability table categorizes requirements by the subsystem that they govern

Interface traceability table shows how requirements relate to both internal and external

system interfaces

Initiating the Requirements Engineering Process - Inception Identify stakeholders

“who else do you think I should talk to?” Recognize multiple points of view Work toward collaboration 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?

Eliciting Requirements - Elicitation Collaborative Requirements Gathering

In order to encourage a collaborative, team-oriented approach to requirements gathering, a team of stakeholders and developers work together to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution required

Eliciting Requirements - Elicitation Guidelines for collaborative requirements gathering

meeting: Meetings are conducted and attended by both software engineer

and customers Rules for preparation and participation are established An agenda is suggested that is formal enough to cover all

important points but informal enough to encourage the free flow of ideas

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

Eliciting Requirements - Elicitation Quality Function Deployment (QFD)

Quality Function Deployment (QFD) is a technique that translates the needs of the customer into technical requirements for software

QFD concentrates on maximizing customer satisfaction from the software engineering process

QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process

Eliciting Requirements - Elicitation Quality Function Deployment Many QFD concepts are

applicable to requirements elicitation activity. They are: 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 system must

consume and produce Task deployment

examines the behavior of the system within the context of its environment

Value analysis is conducted to determine the relative priority of requirements

determined during each of the three deployments

Elicitation Work Products The work products produced as a consequence of

requirements elicitation will vary depending on the size of the system.

The work product include: A statement of need and feasibility A bounded statement of scope for the system A list of customers, users, and other stakeholders A description of the system’s technical environment A list of requirements (organized by function) A set of usage scenarios that provide insight into the

use of the system Any prototype developed to better define requirements

Developing Use-Cases The first step in writing a use-case is to define the

set of “actors” that will be involved in the system Actors are different people (or devices) that use

the system or product within the context of the function and behavior that is to be described

Actors represent the roles that people play as the system operates

An actor is anything that communicates with the system or product and that is external to the system

Developing Use-Cases Once actors have been defined, use-cases

can be developed The following questions should be

answered by a use-case: Who is the primary actor, secondary actor? What are the actor’s goals? What main tasks are performed by the actor? What information does the actor desire from

the system?

Building the Analysis Model The analysis model is to provide a description of

the required informational, functional, and behavioral domains for a computer-based system.

The model changes dynamically as software engineers learn more about the system to be built, and stakeholders understand more about what they really require

Building the Analysis Model The elements of the analysis model

Scenario-based elements The system is described from the user’s point of

view using scenario based approach Use-cases, use-case diagram, activity diagram

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 Class diagram, collaboration diagram

Building the Analysis Model Elements of analysis model (cond…)

Behavioral elements The analysis model must provide modeling

elements that depict behavior State diagram, sequence diagram

Flow-oriented elements Information is transformed as it flows through a

computer-based system Data-flow diagram

Use-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

State Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready” display msg = “please wait” display status = blinking

entry/ switch machine on do: run diagnostics do: initiate all subsystems

turn copier “on“

subsystems ready system status=“Ready”

display msg = “enter cmd” display status = steady

entry/ subsystems ready do: poll user input panel do: read user input do: interpret user input

Readingcommands

system status=“Copying” display msg= “copy count =” display message=#copies display status= steady

entry/ start copies do: manage copying do: monitor paper tray do: monitor paper flow

Making copies

start copies

system status=“Jammed” display msg= “paper jam” display message=location display status= blinking

entry/ paper jammed do: determine location do: provide corrective msg. do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper” display msg= “load paper” display status= blinking

entry/ paper empty do: lower paper tray do: monitor fill switch do: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete

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 system characteristics against cost and time

The best negotiations strive for a “win-win” result. The customer wins by getting the system that satisfies the majority of the customer’s needs, and software team wins by working to realistic and achievable budgets and deadlines

Negotiating Requirements The negotiating activities carried at the beginning

of each software process iteration are: Identification of the system or subsystem’s key

stakeholders These are the people who will be involved in the negotiation

Determination of the stakeholders’ “win conditions” Win conditions are not always obvious

Negotiate of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned Work toward a set of requirements that lead to “win-win”

Validating Requirements 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? Have all requirements been specified at the proper

level of abstraction? Is each requirement bounded and unambiguous?

Validating Requirements A review of the analysis model addresses

the following questions: (cond…) Do any requirements conflicts with other

requirements? Is each requirement testable, once

implemented? Does the requirements model properly reflect

the information, function, and behavior of the system to be built?