requirements elicitation n.
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements Elicitation PowerPoint Presentation
Download Presentation
Requirements Elicitation

Requirements Elicitation

9 Vues Download Presentation
Télécharger la présentation

Requirements Elicitation

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Requirements Elicitation Charles Wallace Michigan Technological University

  2. “Making work visible” • Problems: • “work” not understood by all in the same way • workers don’t always “know what they know” about work • stakeholders: people affected by the software product • typically, not one single class of stakeholder • Customers • End users • Regulatory or administrative bodies • Others affected by use of software

  3. Categories of stakeholder knowledge • organizational/explicit: encoded in official policies, procedures • activity-oriented/tacit: ad hoc, gained through experience

  4. Defining the “workplace” • activities: what are goals of individuals, groups? • what actions do they take to carry them out? • artifacts: what info is used or created during work activities? • what tools are used to work with the info? • social context: how are individuals organized? • what roles are defined (implicitly/explicitly)? • what are dependencies between roles? • ethnography: techniques for analyzing different cultures • observation of, interviews with work groups • analysis of artifacts • may involve joining the group

  5. Elicitation techniques observing work pro: get true picture of work --- no “whitewashing” con: observer’s paradox (observing affects behavior) not all work activity is visible interviewing workers pro: get inside people’s heads con: workers often rationalize behavior (lose tacit knowledge) a compromise: participatory analysis observe workers, then engage in discussion

  6. User interaction scenario • story about people and their activities • story gives a concrete, linear narrative of use • elements: setting actors goals • mental activity user actions other events • Compare to use cases • use cases typically give a more complete account of use • not linear; lots of conditional branching • scenarios typically give more context • - more background on users and their motivations

  7. Use case:Check out book Librarian scans in library card of borrower. If the card won’t scan, do Replace card and try again. Librarian scans in bar code from book. If the bar code won’t scan, the librarian types in the book number. The system marks the due date of the book two weeks later than the current date, and the small printer prints out a slip showing the due date. The librarian gives the slip to the borrower.

  8. Scenario:Cecilia checks out some magazines Cecilia is a political science student studying 20th century U.S. foreign policy. She goes to the library to collect sources on the 1962 Cuban missile crisis. She finds her sources, which are magazines from 1962, and takes them to the main counter to check them out. She gives her library card to Sam, the new librarian. Sam scans Cecilia’s card. He then looks for bar codes on the magazines. Since he’s a new employee, he doesn’t know that old magazines do not have bar codes, since there has not been enough time to label them all. He walks to the desk of Susanna, the main librarian, and asks her what to do. Susanna has him look up the call number of the magazine from the computer, and then shows him how to generate a bar code label for the magazine. Sam puts the new label on the magazine. A small printer prints out a slip showing the due date, two weeks after the current date. Sam gives the slip to Cecilia.

  9. Advantages of scenarios: • concrete but flexible descriptions • natural language understandable to all stakeholders • provoke questions and “what if” discussions • Risks of scenarios: • incompleteness • focus on typical use may hide unusual “corner cases” • time-consuming to produce and comprehend