Requirements Elicitation CSCI 5801: Software Engineering

Requirement Elicitation

Working with customers/users to determine requirements – Interviews – Observation – Other methods

Why Is This Difficult? Developers must create system in unfamiliar domain Clients Understand domain (or at least their own part) Not experts in software development ideas or terminology Developers Understand programming and software development Not experts in domain or in its users ???

Why Is This Difficult? Users not good at specifying processes – Assume implicit knowledge – Skip steps in process “Fred registers for 31302, which is Dr. Sullins’ graduate project course” – is the CRN, but have not told developer about difference between CRNs and course numbers – Fred must also specify number of hours for project courses, but client has forgotten to mention this

Customer Interviews Asking clients/users what system must do – Most imprecise method Wrong approach: “Describe in detail what system should do” Better approach: General to specific – Get general list of desired features – Get more detail about each – Ask questions to clarify as needed

Kickoff Meeting Initial meeting between customers/developers – Free-form discussion Main goals: – User gives basic features required for system – User can give background about problems/needs Developers can also make suggestions about features – User describes context in which system will operate Creating new system? Updating existing system? – Identify main stakeholders

Followup Meetings Much more structured meeting Developers look at previous interviews, determine unanswered questions Prepare specific questions for meeting – Can involve simple prototypes Customers provide specific answers which developers record – Can be done via if questions simple/clear enough

Often Cyclical Process Kickoff meeting Analysis and Validation Further questions Structured interview

Scenario Refinement Asking “what if” type questions about scenario “Fred wants to register for the MW 10:00 section of CSIS He logs onto BANNER and tries to add it, but is told that it is closed. BANNER provides a list of open sections, which include one at MW 2:00. Fred is ok with that time, so he registers for that section.” – What if no other sections open? – What if Fred does not like any other times? – What if time conflicts with other classes? – What if section closes before Fred finishes? – …

Task Analysis Decomposition of tasks into subtasks, gathering more detail about each Register for course Choose courseSelect sectionAdd section Find required courses Find courses offered this semester Choose section based on time Find open sections

Understanding Requirements Find out why customer gives requirements – Better understanding of system – Help customer find better alternatives possible “The system will need to be able to show a list of all courses for students to use.” “Why do they need it? What are they looking for in particular?” “They look for courses that meet requirements, at times that work for them.” “Could we provide a search mechanism also? One that lets them narrow this big list by requirements met or times offered?”

Understanding Requirements Customers may also only have vague understanding of requirements Elicitation can help them develop understanding! “Students have to log in with their name and password before adding classes” “What if two students have the same name?” “Good point. Let’s use their student ID instead.” “What if they forget their password?” “I’m not sure. Let me think about that...” “Who else should I talk to?”

Customer Interviews Basic guidelines: Allow plenty of time Prepare before you meet with the client Understand their viewpoint (type of stakeholder) Keep full notes for future reference If you do not understand, ask for clarification Small group meetings are often most effective

Ethnography Major problems with interviews: Interviewee may not explicitly state all steps in process to be incorporated in software What people say is not always what they do “Prerequisites must always be followed.” Prerequisites are overridden when appropriate.

Ethnography Alternative: observe users perform tasks – Will observe all steps – Will observe what actually happens Passive: Observe (and possibly record) task Active: Ask questions at each stage – Why did you do that? – What else could you have done?

Problems with Ethnography Only works when creating system to duplicate existing processes – Online registration process may not duplicate paper process May not observe all important parts of process – Some exceptions may occur infrequently Example: transfer students – Not all parts of process may be observable Can only observe how courses entered, not how chosen

Problems with Ethnography May not be convenient to observe process – Registration only happens 3 times a year Users may not like being observed Users may act differently when observed – More likely to “follow book”

Form Analysis Much redesign involves converting paper forms to computer/on line forms Use to understand crucial parts of process – What input are needed? – What reports are produced? Good basis for user interface design – Common usability requirement: keep system as familiar as possible to users.

Form Analysis What could you learn from this form?

Written Sources Instruction manuals, employee handbooks, etc. – Required sequence of steps – What must be done before each step – What to do if problems – Must make sure they are up to date and actually followed!