1 / 32

Information Management

Information Management. DIG 3563 – Lecture 3: Requirements J. Michael Moshell University of Central Florida. Ferrit.com.au. Imagery is fromWikimedia except where marked with *. Tell 'em what you're gonna tell 'em. Shingleberrysigns.com. concepts of requirements analysis

shadi
Télécharger la présentation

Information Management

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. Information Management DIG 3563 – Lecture 3: Requirements J. Michael Moshell University of Central Florida Ferrit.com.au. Imagery is fromWikimedia except where marked with *.

  2. Tell 'em what you're gonna tell 'em Shingleberrysigns.com • concepts of requirements analysis • Problems with requirements analysis • A rubric and check-list • JMM applies the rubric to a problem • Your team applies the rubric to a practice problem • THEN WE: * brainstorm a list of REAL problems • * each team chooses one • * your team is USER for another team • * you will draft & present reqs for them -2 -

  3. Classical Requirements Analysis Aynsof.com • The 'waterfall model' of software development: • A one-way flow of activities: • - figure out the requirements • - design the software • - build the software • - test it • - deliver it to the client • - fix bugs and maintain the software • What's wrong with that model? -3 -

  4. Problems with the Waterfall Aynsof.com • What's wrong with that model? • Customers don't really know what they need • Requirements change as • - customers learn from prototypes • - customers' activities and needs change • Constraints change as the true costs emerge • Result: "Design" and "Build" are not really separate processes! -4 -

  5. So, what to do about it? Lrn.usace.army.mil • We still have to start with requirements • But we will revisit them and revise them • during the building process • AND manage the chaos ….here we go: • Stakeholder identification • User Stories and Use Cases • Requirements lists (and problems with them) • Measurable Goals and Acceptance Procedures • Mock-ups and Prototypes -5 -

  6. My Example: Conference Management Web.cs.gc.suny.edu • * A small business (owned by my wife) • Manages conference registration • (including one at the Shanghai Conference Center, above) • Needs to be able to look at previous name-tags • and select one (or more) to emulate for a new conference. -6 -

  7. Stakeholder Identification Truelegends.coml • "Who cares?". More formally - • Who is going to use this system? • Who is going to have to take care of it? • Who is going to be affected by it? • Who will benefit, directly or indirectly? • Who will lose, directly or indirectly? • Who is affected in some indefinite way? -7 -

  8. User Stories Cs.rochester.edul • Short enough to write on a 3" x 5" card. • As a <role>, I want <goal/desire>. • Example: • As a conference manager, I want to be able to look • At the nametags from previous conferences so • We can reuse the designs or get ideas from them. -8 - -8 -

  9. What is a Use Case? • It is a single KIND of interaction with a system • We define Use Cases to help design User Interfaces • The Use Case does NOT explain. It just identifies – • The actor or actors • The activity • and, in limited, cases, extensionsof the activity. • UC is the first step in Analyzing the User Story -9 -

  10. Use Cases www.wikipedia.org • Conference manager: • (1) enter conference name and see badges • from all years of that conference • (2) select a badge and inform IT manager of its selection • IT manager: transfer a badge from the registration • system to the badge display system, along with its • metadata (e. g. association, conference, year). -10 - -10 -

  11. Use Case Diagrams • Explain WHO does WHAT and with WHOM. • (Does not explain HOW it is done.) Cs.rochester.edul Badge Display System See Badges Select Badge • Conference • Manager Registration System • IT • Manager Transfer Badge -11 - -11 -

  12. Use Case Diagrams • .. Are part of a system called UML • (Unified Modeling Language) • We will use elements of UML in the course, • But will not formally study the "whole thing" – It's large and complicated. • It is used for designing software systems of • all sorts. -12 - -12 -

  13. Another Use Case Diagram Example

  14. Where are the Details? • Specify them in your Requirements List • ((Be clear about what you require your system to do, • because you’ll have to IMPLEMENT IT!)) -14 -

  15. Use Case Diagrams • Explain WHO does WHAT and with WHOM. • (Does not explain HOW it is done.) Buy Gas Buy Lotto Ticket • Customer • Clerk Count Inventory -15 - -15 -

  16. Use Case Diagrams • More Examples atlas.kennesaw.edu -16 - -16 -

  17. Use Case Diagrams • More Examples tigris.org -17 - -17 -

  18. Use Case Diagrams More Examples visual-paradigm.com -18 - -18 -

  19. Use Case Diagrams • More • Examples • Note • SUBSET • relations • between • user types. • We don’t • need to do this, in our course. visual-paradigm.com -19 - -19 -

  20. Use Case Diagrams • Examples with • the <extend> • and • <include> • relationships. • You will NOT • need these in • this course. <extend> <include> www.modernanalyst.com -20 - -20 -

  21. NOT A Use Case Diagram! It's a WB* it contains a sequence of activities (WB* see your lecture notes) Buy food Eat Dinner Cook Food • Mother • Child • Child Serve Dinner -21 -

  22. Requirements Lists Lrn.usace.army.mil • * Dangerous, if they are taken as a "contract" • - because of a false sense of mutual understanding • ("We agree on the words, but not on what they mean.") • Lots of effort may go into meeting a requirement which is • then discarded. • * Useful, if they can be amended as the process continues. -22 -

  23. Requirements Lists • Example: • System will have a GUI with pull-down menus that list • associations, conferences and years. One, two or three • of these items may be specified. A little window will • show thumbnails of all the badges matching the choices. • 2. Metadata: associations, conferences, years, are all controlled • vocabularies. • Conference manager will be able to extend each vocab item. • 3. Manager will be able to communicate the specifics of • the selected badge to the IT manager, together with • a note of any needed changes, for use in a new conference, • by clicking on a button. -23 -

  24. Measurable Goals Lrn.usace.army.mil • Example: • Manager will be able to find any name badge for any • conference we ever managed, within 20 seconds of • beginning the search. • System will not consume more than 2* the amount of • disk storage required to store GIF images of badges. -24 -

  25. Mockups and Prototypes Badge Display System ACM POPL 2011 Select Association www.wikipedia.org Select Conference Pull-down Menus Select Year 2010 2009 2008 Button Show Badge

  26. Iterating the Process • I showed the prototype to the user • She said "I want to see multiple badges at once, side-by-side for comparison. • I prepared a modified mockup.

  27. Mockups and Prototypes Badge Display System ACM POPL 2011 Select Association www.wikipedia.org Close Select Conference ACM POPL 2011 ACM POPL 2011 Pull-down Menus Select Year 2010 2009 2008 Close ACM POPL 2011 Close Button ACM POPL 2011 Add Badge Close Close All

  28. Iterating the Process • She said "I don't want to have to add badges one- by-one. Can I just select "All badges from the Cat Fancier's Association?"  I added a "wild card" to each pulldown menu. Etc, etc.

  29. Iterating the Process • I showed the next prototype to the user • She said "Cool. Now, how do I tell the IT manager about a new conference? + As part of that, how do I add to a controlled vocabulary, e. g. by adding an association?  My next step would be to create a new use case, requirement list, measurable goal, mockup. Then we build some small prototypes that actually WORK, Show them to the user, get further feedback.

  30. A Practice Project (In class) • Online Pokemon Card Exchange, OR • Online Used Boyfriend/Girlfriend Exchange • I will bring the one-page Grading Rubric up on the screen • You will use it to remind you of the steps, • Prepare a Requirements Analysis (on paper or laptop) • In 20 minutes we sample groups – You can SHINE or FAIL Smh.com.au -30 -

  31. Brainstorming Projects Knowyourmeme.com • 1. Class will generate a list of 12 projects • 2. Discuss within your group • 3. Select your Semester Project (Duplication is OK) Requirements Analysis, Part 1: • 4. Group N: analyze Requirements for M+1 • Next week in class: present to Group N+1 (written form + discussion).

  32. Presenting Requirements Knowyourmeme.com After you receive your partner-group's Requirements Analysis, You will perform your own. (Modify theirs/borrow from it, or Throw it out, if necessary.) In a few weeks, all groups will present your Requirements to the class.

More Related