Transcript Slide 1
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 Story Each 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. Interviewing • 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 • 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