REQUIREMENTS ELICITATION FOR SOFTWARE | Software Engineering

 REQUIREMENTS ELICITATION FOR SOFTWARE

Before requirements can be analyzed model or specified they must be gathered through an

elicitation process.

• There are basic four elicitation process such

a. Initiating the Process

b. FAST

c. QFD

d. Use-cases

1.Initiating the process:

• It is the most commonly used requirement elicitation technique, which uses meeting or

interview to gather the requirements.

• During the first meeting between analyst and customer where neither of them know what to

say but at the same time both want to be a success.

• The analyst starts by asking context-free questions i.e. a set of questions to get basic

understanding of problems or definition of software 

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 analyst to gain a better understanding of the problem.

• They are as follows:

 How would you characterize "good" output that would be generated by a

successful solution?

 What problem(s) will this solution address?

 Can you show me (or describe) the environment in which the solution will be

used?

• The final set of questions focuses on the effectiveness of the meeting called meta-questions.

It can contain following types of 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?

• These questions will help to and initiate the communication that is essential to successful

analysis.

• The Question & Answer session should be used for the first encounter only and then replaced

by a meeting.

2.Facilitated Application Specification Technique (FAST):

• FAST is a team-oriented approach to requirement gathering, which is applied at early stages

of analysis and specification.

• This approach encourages the creation of a joint team of customers and developers.

• The goal is

 Customers and developers work together and identify the problem,

 Propose elements of the solution,

 Negotiate different approaches and

 Specify a preliminary set of solution requirements.

• Basic guidelines for FAST are as follows:

 A meeting is conducted at a neutral site and attended by both software engineers and

customers.

 Rules for preparation and participation are established.

 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.

 Initial meetings between the developer and customer occur and basic questions and

answers help to get an idea of problem and its solution.

 Out of these initial meetings, the developer and customer write a one- or two-page

"product request."

 Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria

(e.g.,speed, accuracy) are also developed.

 As the FAST meeting begins, the first topic of discussion is the need and justification for

the new product—everyone should agree on it.

 After agreement each participant present list of discussion.

o The list can be pinned on wall or on electronic bulletin board for review prior

to meeting.

 After this the team is divided into smaller sub-teams; each works to develop mini-

specifications for one or more entries on each of the lists.

 Each sub-team then presents each of its mini-specs to all FAST attendees for

discussion.

 After the mini-specs are completed, each FAST attendee makes a list of validation

criteria for the product/system and presents his or her list to the team.

 A final agreement list of validation criteria is then created.

 Finally, one or more participants (or outsiders) are assigned the task of writing the

complete draft specification using all input from the FAST meeting.

3.Quality Function Deployment (QFD)

• (QFD) is a quality management technique that translates the needs of the customer into

technical requirements for software.

• It was originally developed in Japan, and first used at the Kobe Shipyard of Mitsubishi

Heavy Industries, Ltd ,in the early 1970s

• It focuses on what is valuable to the customer and then install these values throughout the

engineering process.

QFD identifies three types of requirements:

1. Normal Requirement:

 The objectives and goals that are stated for a product or system during meetings with the

customer. If these requirements are present, the customer is satisfied.

Example : graphical displays, system functions and level of performance

2. Expected Requirements:

 These requirements are implicit to the product or system and may be very fundamental

for the customer.

 It does not explicitly state them.

 Their absence will result in a significant dissatisfaction.

 Example of excepted requirements are :

 Ease of human/machine interaction,

 overall operational, correctness and reliability

 ease of s/w installation

3. Exciting Requirements:

 These features go beyond the customer’s expectations and prove very satisfying when

present.

 Example: word processing software has a number of page layout capabilities that are quite

pleasing and unexpected.

• QFD uses customer interviews and observation, surveys, and examination of historical data

as raw data for the requirements gathering activity.

• These data are then translated into a table of requirements—called the customer voice

table—that is reviewed with the customer.

4.Use cases:

• As requirements are gathered as part of informal meetings, FAST, or QFD, the software

engineer (analyst) can create a set of scenarios that identify a thread of usage for the system to

be constructed. The scenarios, often called use cases, provide a description of how the system

will be used.

• It is the graphical representation of the system.

• A use case is a software and system engineering term that describes how a user uses a system

to accomplish a particular goal.

• A use case acts as a software modeling technique that defines the features to be implemented

and the resolution of any errors that may be encountered.

• Use cases define interactions between external actors and the system to attain particular goals.

• There are three basic elements that make up a use case:

 Actors: Actors are the type of users that interact with the system.

 System: Use cases capture functional requirements that specify the intended

behavior of the system.

Goals: Use cases are typically initiated by a user to fulfill goals describing the

activities and variants involved in attaining the goal.

• Use cases are modeled using unified modeling language (UML) and are represented by

ovals containing the names of the use case.

• Actors are represented using lines with the name of the actor written below the line. To

represent an actor's participation in a system, a line is drawn between the actor and the use

case. Boxes around the use case represent the system boundary.

USE CASE SYMBOL

Example: The following is a sample use case diagram representing the School login system.

There are three use cases (Loing, Reset Password and Forgot Password) and actor which are

Students, Teacher, Parents, Staff and admin.

• The Reset password and Forgot Password use cases are extended from Login use case. So

they have extends relationship.

• Another important point is to identify the system boundary which is shown in the picture.

The actors(Students, Teacher, Parents, Staff and admin) lies outside the system as it is an

external user of the system.

• The purposes of use case diagrams are as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.

 Identify external and internal factors influencing the system.

 Show the interacting among the requirements are actors.