Gathering Requirements

– Customers often have no IT background so either don’t know what can be done or have too high expectations

– Communications between techies and customers can be difficult

• Typical customer feedback– That’s good, but…– What about if we …– I’ll know it when I see it…– Oh. I thought it was going to…– This is not what I expected…

• So there is a need for early prototypes for customer feedback to resolve problems quickly

• Can’t be sure all requirements have been discovered so it is better to agree that enough have been discovered to at least start a prototype

• Other requirements will come to mind later, others will occur as a result of the prototype

User – Developer mismatch

• Customers don’t always know what they want

• If the customer knows what they want, the often can’t articulate it

• The developer has to appreciate that the customer is the domain expert

• Try different approached to try to eek out the customer’s requirements

• Customers think they know what they want until the developer gives them exactly what they asked for. If this is a long way down the development road, it can be expensive to put right

• Use brainstorming, storyboarding, throw away prototyping, role play etc., to try to try to ensure that both sides are in agreement

• Differentiate need from want– Why do we need it?– What does it need to do?– Want can be relegated to a wish list

• Not always clearly stated– It needs to be fast– It needs to be user friendly– It needs to be cutting edge

Use-case v Features• Some systems lend themselves to Feature Driven

Development – A word processor

• Search• Change font• Print

• Others lend themselves to Use Cases– A lift system

• User calls lift• User selects floor …

• Others - a combination of both– The FDD and Use Case development methods are tools to be

used as appropriate – to get the job done

Features• This will be different if the system is replacing an

existing manual system than if it is a new system

• For a new system– Define high level features

– Try to keep features < 50 in a new system

– Some systems better defined by features than by use cases

Example features

• <action> the <result> <by|for|of|to> a(n) <object>

• Calculate the total amount of a Sale

• Calculate the total quantity sold by a Retail Outlet for an Item Description

• Determine the most recent Cash Register Assignment for a Cashier

Categorise Features

• Features:– Add a student to a seminar waiting list. – Calculate fee for a parking pass. – Calculate the average mark on a transcript. – Display the name and address of a student on a transcript. – Drop a student from a seminar. – Enrol a student in a seminar. – List the prerequisites for a seminar. – List the seminars of a student on a transcript.

– Track number of parking passes.

Categorise Features• Categories

– Transcript– Calculate the average mark on a transcript. –  List the seminars of a student on a transcript. –  Display the name and address of a student on a transcript. –  – Enrolment– List the prerequisites for a seminar. – Enrol a student in a seminar. – Drop a student from a seminar. – Add at student to a seminar waiting list. –  – Parking Passes– Calculate fee for a parking pass. – Track number of parking passes.

Use Cases

• Good for illustrating functional requirements of systems with a lot of user interaction – user centric

• A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor

• UML provides a set of symbols

Use Case Diagram• Illustrates interaction with the system with UML

use case notation

Use Case StoryEach case is explained in sequential steps

DepositMoney (basic flow)1) The Customer inserts the bank card into the ATM and enters the

Personal Identification Number (PIN).2) The system validates the PIN and queries BankSystem to validate

the Customer’s account.3) The Customer indicates the wish to deposit cash and inserts all

banknotes for deposit.4) System checks the banknotes and notifies the overall amount of

inserted money.5) The Customer approves the amount.6) The system informs the BankingSystem to book the amount on the

Customer’s account.7) The system ejects the card.8) The Customer takes the card.9) The use case ends.

Interviewing to Elicit Requirements

• Simple, direct and very useful– avoid biases by the interviewer as don’t want

the question to influence the answer

• Ask context-free questions Who are the users?

Who wants to buy this?

• Consider tone of voice, body language, etc.

• Prepare questions before interview• Know the interviewee; avoid questions

they can’t answer• Repeat the answer back to the client for

confirmation• Be flexible…new questions will be

revealed during interview• Take good notes; elaborate on them soon

after the meeting• Use the list of questions to keep you on

track

Interviewing

Interviewing

• Questionnaires– A very poor substitute for interviews– Lack the free-form flow of information that

interviews provide– Inflexible, don’t adapt to new information– Hard to follow up on unclear responses– Sometimes unavoidable, but use as last resort– Can be used to reach a broader set of users

Elicitation meeting

• Run as a workshop• A best technique for requirements elicitation is to

meet around the table• Having key players in same room increases

requirements output and enables consensus• Facilitator (independent if possible) keeps meeting

focused and on track• Brainstorming is the most important part of the

workshop• Take about one or two days to do this if possible

Workshops

• Key workshop benefits – It’s a team building exercise– Everyone gets to provide input– Forges agreement between stakeholders & IT

team– Expose & resolve political issues within

organization– Output is system definition in terms of

features

Workshops

• Need to held throughout a project• For an iterative project, hold workshop at start of

each iteration to agree on what use-cases / features are to be implemented

• Finding a time when all key players can meet. Can’t get everyone there so identify key groups needing representation: manager, user, Software developers …

• Communicate the benefits of the workshop in terms of how it benefits each stakeholder

Workshops

• Facilitator should ideally be independent but have a thorough understanding of the problem. However, if an independent is not available, use someone from the team

• The facilitator should:– Avoid taking sides– Avoid selling a solution– Avoid defending the IT team– … – Establish & maintain professional tone– Start, keep on track & stop meeting– Establish & enforce meeting rules– Introduce goals & agenda– Guide consensus – Ensure minutes are taken or session is recorded

Brainstorming & Idea Reduction

• Key points

– Idea generation & idea reduction– Innovative ideas may spring from unrelated ideas– Various voting techniques useful for prioritising ideas– Live brainstorming is preferred– Everyone takes part

Brainstorming & Idea Reduction

• Someone’s idea leads to another person’s idea

• Results in an unpredictable mental chain reaction

• Generates lots of ideas in short time

• Can be very creative; several heads are better than 1

Brainstorming & Idea Reduction

• Two distinct phases

– Idea generation• The lively, creative part

– Idea reduction• Prioritization of ideas – the difficult bit

Brainstorming & Idea Reduction

• Brainstorming technique

– Each person gets pad of sticky notes on which to write ideas – one note for one idea

– Facilitator explains rules & objectives• No criticism or debate• No limits on imagination• No limits on cost of ideas• Expand and / or combine ideas

Brainstorming & Idea Reduction

• Starting the session

– What features do you want in system?

– What services should system provide?

– What opportunities are we missing?

– If we could have the ultimate system, what would it be like?

Brainstorming & Idea Reduction

• Don’t stop until the group runs out of ideas

• Read ideas aloud so others can generate spin-off ideas• Everyone records their ideas

– Captured in person’s own words– Avoids bottleneck caused by single note taker– Foster greater sense of participation and contribution– Don’t worry about duplicate or overlapping ideas

• All ideas collected and posted in the room– Still no criticism allowed at this point

Brainstorming & Idea Reduction

• Idea reduction– Don’t begin until brainstorming reaches a natural end

– Prune ideas• For each idea, seek consensus on whether it deserves

further consideration

• If there is disagreement, it stays on the list

Brainstorming & Idea Reduction

• Idea reduction

– Grouping ideas

• Group similar ideas together on wall (removing one may insult its author)

• Group by related idea categories – New features– Performance– Enhancements– UI / ease of use– Types of tasks– Order processing– Marketing & sales– Legal & ethical concerns

Brainstorming & Idea Reduction

• Idea reduction– Define features

• Write a short description of each retained idea to aid the prioritisation process

– Rationale

– Value delivered

– Problem solved

– Risk reduced / avoided

Brainstorming & Idea Reduction

• Idea reduction– Prioritizing ideas

• Categorize ideas by importance– Critical

» Must haves ; system won’t be useful without it– Important

» Significant impairment without it; loss of users, productivity, revenue, etc

– Useful» Nice to haves; Life would be better with it

• Score ideas– To determine an idea’s overall score, multiply critical votes by

9, important votes by 3 and useful by 1