1 / 21

Requirements Elicitation

Requirements Elicitation. CSCI 5801: Software Engineering. Requirement Elicitation. 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

libra
Télécharger la présentation

Requirements Elicitation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Elicitation CSCI 5801: Software Engineering

  2. Requirement Elicitation

  3. Requirement Elicitation • Working with customers/users to determine requirements • Interviews • Observation • Other methods

  4. 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 ???

  5. 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” • 31320 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

  6. 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

  7. 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

  8. 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 email if questions simple/clear enough

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

  10. Scenario Refinement • Asking “what if” type questions about scenario “Fred wants to register for the MW 10:00 section of CSIS 2610. 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? • …

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

  12. 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?”

  13. 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?”

  14. 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

  15. 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.

  16. 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?

  17. 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 infrequentlyExample: transfer students • Not all parts of process may be observableCan only observe how courses entered, not how chosen

  18. 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”

  19. 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.

  20. Form Analysis What could you learn from this form?

  21. 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!

More Related