Lecture Requirement engineering Chapter 3 Software elicitation

Lecture Requirement engineering Chapter 3 Software elicitation. This chapter presents the following content What is requirement elicitation? Participants in elicitation, risks of requirements elicitation, requirements elicitation techniques.

What is Requirement Elicitation?

Participants in elicitation

Risks of requirements elicitation

Requirements elicitation techniques

The most common causes of poor

quality, cost overruns and late delivery of software: Incorrect, incomplete, or

misunderstood requirement

Requirements elicitation is “the process

of discovering the requirements for a

system by communicating with

customers, system users and others who have a stake in the system development”

Gather requirement from various sources: identify requirement providers: stakeholders

Analyse the gathered information, looking

for implications, inconsistencies or

Requirement elicitation involves many people

Customer/Client: Person who pays for the software development Ultimately, has the final word on what will be the product

Software engineer: Expert who knows the

technology and process -> produce the requirements specifications

The potential users: of the current system or future systems  indicate which functions to maintain or improve

Articulation problems:

The user can’t express their needs

The users may not aware of their needs or not

understand how the technology may be able to

Different personality types and different value

systems among people

Knowledge and cognitive limitations

The users and developers don’t have enough

domain or technical knowledge

The users and developers don’t remember exactly what was said  may misinterpret that

information late

Try to simplify the propblem or ignore parts of

problem  distort the problem

State the problem in terms of favored solution

Human behavior issues:

Requirement elicitations is a social process 

human behavior issues are involved

Conficts and ambiguities in the roles of

stakeholders  lead to gap in requirements

Fear the new system will necessitate the changes

in behavior of individuals and group  withhold information

Technical issues

The problems are becoming increasingly complex

Requirements change over time

There are many sources of requirements

Asking

Observing and inferring

Discussing and formulating

Negotiating

Studying and identifying problems

Discovering through creative process

Interview

Brainstorming

JAD

Prototype

The most commonly used requirements

gathering technique

Three main objectives:

Record information to be used as input to

requirements analysis and modeling

Discover information from interviewee accurately and efficiently

Reassure interviewee that his/her understanding

of the topic has been explored, listened to, and

valued

Process consists of three important steps:

 Planning and preparation

 Conducting the interview

 Postinterview follow-up

Planning and preparation

Set goals and objectives for the interview

Select interviewees

Create an interview schedule

Designing Interview Questions

 Closed-Ended Questions

 Opened-Ended Questions

 Probing Questions

Conducting the interview

Make the interviewee comfortable and confident

Be polite and respectful!

Take careful notes

Don’ t afraid to ask

Postinterview follow-up

 Prepare an interview report that

describes the information from the

interview

 Send the interview report to the

interviewee with a request to read it and inform the analyst of clarifications

or updates

Problem solving stages includes:

Two main activities:

The Storm : Generating as many ideas as possible (quantity, not quality) – wild is good!

Idea Selection : Filtering out of ideas

(combine, clarify, prioritize, improve …) to keep the best one(s) – may require some voting strategy

Planning the Session

Define the problem

Identify participants

Create groups out of the participants (just 3-4 members/group) Each group should consist of people from diverse and relevant backgrounds

Conducting the Session

After the Brainstorming Session

Give a reward or recognize the participant

follow-up and monitor the solution to closure

An information gathering technique that allows the project team, users, and

management to work together to

identify requirements for the system

JAD is a structured process

10 to 20 users meet together under the

direction of facilitator skilled in JAD

techniques

Pre-session Planning

Evaluate project

 Identify contentious issues and scope of JAD

session

Select JAD participants

Create preliminary agenda

Determine deliverables for the working

session

Enable participants to prepare for the session

Pre-work Planning

Gather information

Clear schedules for the working session

Refine session agenda

Finalize pre-session assignments

Prepare material for session (flip-charts, presentations, marker )

Set-up stage

Session leader welcomes participants,

presents task to be discussed, establishes rules and what is on/off topic…

Generate common understanding

Achieve agreement on decisions

Create the deliverables

Identify open issues and questions

Follow-up

Resolve open issues and questions

Evaluate the JAD process

Follow-up on action items

Re-evaluate project

Discuss "lessons learned"

Finalize deliverables

Facilitator - JAD expert

Good with people skills, enthusiastic, sets tone of meeting

Set the meeting agenda and guide the discussion

Do not join in the discussion as a participant - do not provide ideas or opinions on the topics under discussion to remain neutral during the session

Must be an expert in both group process

techniques and systems analysis and design

techniques

A new form of JAD called electronic JAD

or e-JAD

Each participant uses special software on

a networked computer to send

anonymous ideas and opinions to

everyone else

All participants can contribute at the

same time, without fear of reprisal from people with differing opinions

A software requirements prototype is a model or partial implementation of a

software system

Helps developers, users, and customers

better understand system requirements

Helps clarify and complete requirements

Helps find new functionalities, discuss

usability, and establish priorities

Prototyping is effective in resolving

uncertainties early in the development process

Focus prototype development on these uncertain parts

Encourages user participation and mutual understanding

Prototypes that focus on user-interface tends

to lose the focus of demonstrating/exploring functionality

Prototypes can bring customers’ expectations about the degree of completion unrealistically

up

Do not end-up considering a throwaway

prototype as part of the production system

Always clearly state the purpose of each prototype before building it