Chapter 5

Understanding Requirements
Requirements Engineering


Tasks and techniques that lead to an understanding of requirements

Begins during the communication activity to modeling activity

Builds a bridge to design and construction
Requirements Engineering


Provides appropriate mechanism for:

Understanding what customer wants

Analyzing need

Assessing feasibility

Negotiating a reasonable solution

Specifying the solution unambiguously

Validating the specification

Managing requirements as they transformed into an operational system
Requirements Engineering


Seven distinct task:

Inception (permulaan)

Elicitation (pancingan)

Elaboration (perluasan)

Negotiation (perundingan)

Specification (perincian)

Validation

Management
Inception - Permulaan


Establish basic understanding:

The problem (Pahami masalah)

People who want a solution

The nature of solution that is desired

Solusi seperti apa yang diinginkan

Effectiveness of preliminary communication

Efektivitas persiapan komunikasi

Collaboration between the other stakeholders and software team

Kolaborasi customer/ stakeholders dengan tim developer
Elicitation


Ask the customer, users, others about:

Objectives for the system product are

Tujuan sistem yang akan dibuat

What is to be accomplished

Apa yang mau diselesaikan / dicapai

How the system fits onto the needs of the business

Bagaimana sistem bisa sesuai dengan kebutuhan bisnisnya

How the system is to be used on a day-to-day basis

Bagaimana sistem akan digunakan sehari hari
Elicitation - Problem


Problems of understanding

Customer/users are not completely sure of what is needed

Have a poor understanding of the capabilities and limitation
of their computing environment

Don't have full understanding of the problem domain

Omit information that is believed to be “obvious”

Specify requirements that conflict with the needs of other
customer/users

Specify requirements that are ambiguous
Elicitation - Problem


Problem of volatility

The requirements change over time
Elaboration


Developing refined requirements model that identifies various aspects of
software function, behavior and information

Creation and refinement of user scenarios

Describe how user will interact with ystem

Each user scenario is parsed to extract analysis classes

Define attributes of each analysis class

Identify relationships and collaboration between classes
Negotiation


Customers, users, and other stakeholders are asked to rank requirements

Discuss conflict in priority

Requirements are eliminated, combined, modified
Specification


Different things to different people

Written document

Set of graphical models

A formal mathematical model

Collection of usage scenarios

A prototype

Combination of these
Validation


Examines the specification to ensure that all software requirements have
been stated unambiguously

All inconsistencies, omissions, errors have been detected and corrected
Establishing The Groundwork


Identifying stakeholders

Anyone who benefits in a direct/indirect way from the system which is being
developed

Recognizing multiple viewpoints

Different stakeholders, different viewpoints

Working toward collaboration

Identify areas of commonality & areas of conflict
Establishing The Groundwork


Asking the first questions

Context-free questions focuses on the customer & other stakeholders, the overall
project goals & benefits

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


Collaborative requirements gathering

Meeting attended by software engineers & stakeholders

Quality function deployment

Translates the needs of the customer onto technical requirements
for software

Normal requirements
 Stated during meetings

Expected requirements
 Implicit, may be so fundamental

Exciting requirements
 Beyond the customers expectation
Eliciting Requirements

Usage scenarios

How these functions and features will be used by different classes of end users

Elicitation work products

Statement of need and feasibility

Scope for the system

List of customers, user, & other stakeholders

Description of the technical environment

List of requirements & domain constraints

Usage scenarios

Prototype to better define requirements
Developing Use Case


How an end user interacts with the system under a specific set of
circumstances

Depicts software from the user's point of view
Building The Requirements Model


Elements of the requirements model

Scenario based

Class based

Behavioral

Flow oriented

Analysis pattern

Suggest solutions within the application domain that can be reused when modeling
many applications
Negotiating Requirements


The best negotiations strive for a win-win result

Stakeholders win by getting the system that satisfies the majority of their needs

Software team win by working to realistic and achievable budgets and deadlines
Validating Requirements


Reqs are consistent with system's overall objectives

All reqs been specified at the proper level of abstraction?

Is req is really necessary or add-on?

Any conflict?

Achievable?

Testable?