Requirements Elicitation for Software

<< Requirements Management, Requirements analysis

The Software Requirements Specification >>

Software Project Management (CS615)

LECTURE # 14

2. Software Development Fundamentals

Technical Fundamentals

2.11

Requirements Management

⇒ Requirements Analysis

Evaluation and Synthesis

Upon evaluating current problems and desired information (input

and output), the analyst begins to synthesize one or more solutions.

To begin, the data objects processing functions and behavior of the

system are defined in detail. Once this information has been

established, basic architectures for implementation are considered.

A client/server approach would seem to be appropriate, but does

the software to support this architecture fall within the scope

outlined in the Software Plan? A database management system

would seem to be required, but is user/customer's need for

associativity justified? The process of evaluation and synthesis

continues until both analyst and customer feel confident that

software can be adequately specified for subsequent development

steps.

Throughout evaluation and solution synthesis, the analyst's

primary focus is on "what, not "how." What data does the system

produce and consume what functions the system must perform.

What behaviors do the system exhibit, what interfaces, are defined

and what constraints apply?

Models

During the evaluation and solution synthesis activity, the analyst

creates models of the system in an effort to better understand data

and control flow, functional processing, operational behavior, and

information content. The model serves as a foundation for software

design and as the basis for the creation of specifications for the

Software.

Specification

Software Project Management (CS615)

During the evaluation and solution synthesis activity, the analyst

creates models of the system in an effort to better understand data

and control flow, functional processing, operational behavior, and

information content. The model serves as a foundation for software

design and as the basis for the creation of specifications for the

Software. The customer may be unsure of precisely what is

required. The developer may be unsure that a specific approach

will properly accomplish function and performance. For these, and

many other reasons, an alternative approach to requirements

analysis, called Prototyping, may be conducted.

Concerns for Review

The customer may be unsure of precisely what is required. The

developer may be unsure that a specific approach will properly

accomplish function and performance. For these, and many other

reasons, an alternative approach to requirements analysis, called

Prototyping, may be conducted.

For example, an inventory control system is required for a major

supplier of auto parts. The analyst finds that problems with the

current manual system include:

(1) Inability to obtain the status of a component rapidly,

(2) Two- or three-day turn- around to update a card file,

(3) Multiple reorders to the same vendor because there is no way to

associate vendors with components, and so forth.

Once problems have been identified, the analyst determines what

information is to be produced by the new system and what data

will be provided to the system. For instance, customer desires a

daily report that indicates what parts have been taken from

inventory and how many similar parts remain. The customer

indicates that inventory clerks will log the identification number of

each part as it leaves the inventory area.

Upon evaluating current problems and desired information (input

and output), the analyst begins to synthesize one or more solutions.

To begin, the data objects, processing functions, and behavior of

the system are defined in detail. Once this information has been

established, basic architectures for implementation are considered.

A client/server approach would seem to be appropriate, but does

the software to support this architecture fall within the scope

outlined in the Software Plan? A database management system

would seem to be required, but is the user/customer's need for

Software Project Management (CS615)

associativity justified? The process of evaluation and synthesis

continues until both analyst and customer feel confident that

software can be adequately specified for subsequent development

steps.

⇒ Requirements Elicitation for Software

Before requirements can be analyzed, modeled, or specified they must be

gathered through an elicitation process. A customer has a problem that

may be amenable to a computer-based solution. A developer responds to

the customer's request for help.

Communication has begun. But, as we have already noted, the road from

communication to understanding is often full of potholes.

1. Initiating the Process

The most commonly used requirements elicitation technique is to

conduct a meeting or interview. The first meeting between a

software engineer (the analyst) and the customer can be likened to

the awkwardness of a first date between two adolescents. Neither

person knows what to say or ask; both are worried that what they

do say will be misinterpreted; both are thinking about where it

might lead (both likely have radically different expectations here);

both want to get the thing over with, but at the same time, both

want it to be a success. Yet, communication must be initiated.

Gause and Weinberg [GAU89] suggest that the analyst start by

asking context-free questions. That is, a set of questions that will

lead to a basic understanding of the problem, the people who want

a solution, the nature of the solution that is desired, and the

effectiveness of the first encounter itself. The first set of context-

free, questions focuses on the customer, the overall goals, and the

benefits. For example; the analyst might ask:

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?

These questions help to identify all stakeholders who will have

interest in the software to be built. In addition, the questions

identify the measurable benefit of a successful implementation and

possible alternatives to custom software development.

Software Project Management (CS615)

The next set of questions enables the analyst to gain a better

understanding of the problem and the customer to voice his or her

perceptions about a solution:

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?

Will special performance issues or constraints affect the way

the solution is approached?

The final set of questions focuses on the effectiveness of the

meeting. Gause and Weinberg call these meta-questions and

propose the following (abbreviated) list:

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?

These questions (and others) will help to "break the ice" and

initiate the communication that is essential to successful analysis.

But a question and answer meeting format is not an approach that

has been overwhelmingly successful. In fact, the Q&A session

should be used for the first encounter only and then replaced by a

meeting format that combines elements of problem solving,

negotiation, and specification.

2. Facilitated Application Specification Techniques

Too often, customers and software engineers have an unconscious

"us and them" mind-set. Rather than working as a team to identify

and refine requirements, each constituency defines its own

"territory" and communicates through a series of memos, formal

position papers, documents, and question and answer sessions.

History has shown that this approach doesn't work very well.

Misunderstandings abound, important information is omitted, and

a successful working relationship is never established.

It is with these problems in mind that a number of independent

investigators have developed a team-oriented approach to

requirements gathering that is applied during early stages of

Software Project Management (CS615)

analysis and specification. Called

facilitated

application

specification techniques "(FAST).

This approach encourages the creation of a joint team of customers

and developers who work together to:

Identify the problem

Propose elements of the solution

Negotiate different approaches and specify a preliminary set of

solution requirements.

FAST has been used predominantly by the information systems

community, but the technique offers potential for improved

communication in applications of all kinds.

Many different approaches to FAST have been proposed. Each

makes use of a slightly different scenario, but all apply some

variation on the following basic guidelines:

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

software engineers 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 in an atmosphere that is conducive to

the accomplishment of the goal.

To better understand the flow of events as they occur in a typical

FAST meeting, we present a brief scenario that outlines the

sequence of events that lead up to the meeting, occur during the

meeting, and follow the meeting.

Initial meetings between the developer and customer occur and

basic questions and answers help to establish the scope of the

problem and the overall perception of a solution. Out of these

initial meetings, the developer and customer write a one- or two-

page "product request." A meeting place, time, and date for FAST

are selected and a facilitator is chosen. Attendees from both the

100

Software Project Management (CS615)

development and customer/user organizations are invited to attend.

The product request is distributed to all attendees before the

meeting date.

3. Quality Function Deployment

A quality management technique that translates needs of customers

into technical requirements of software.

Normal Requirement: meeting objectives & goals stated for a

product or system during meeting

Expected Requirement: Implicit to products / system and may

be so fundamental that customer does not explicitly state them

Exciting Requirement: Features beyond customer's expectation

and prove to be very satisfying when present

4. Use Cases

As requirements are gathered as part of:

Informal meeting

FAST or QFD

SW Engineer can create a set of scenario that identify a thread of

usage for system to be constructed; providing a description of how

system will be used.

5. Analysis Principles

A variety of modeling notations are developed by investigators.

Each analysis method has a unique point of view. However all

analysis methods are related by a set of operational principles like:

The information domain of a problem must be represented and

understood.

The functions that the software is to perform must be defined.

The behavior of the software (as a sequence of external events)

must be represented.

The models that depict information function and behavior must

be partitioned in a manner that uncovers details in a layered (or

hierarchical) fashion.

101

Software Project Management (CS615)

The analysis process should move from essential information

toward implementation detail.

6. Software Prototyping

Analysis should be conducted regardless of the SW engineering

paradigm. (Various approaches apply)

In some cases it is possible to apply operational analysis principles

and derive a model of SW from which a design can be developed.

In other situation Requirement Elicitation (FAST, QFD etc) is

conducted and a model is built, called Prototype.

102

Table of Contents: