1 / 33

Web Design Workshop DIG 4104c

Web Design Workshop DIG 4104c. Lecture 2.5: Requirements J. Michael Moshell University of Central Florida Adapted from DIG3563. You may recognize it...!. Ferrit.com.au. Tell 'em what you're gonna tell 'em. Shingleberrysigns.com. concepts of requirements analysis

raheem
Download Presentation

Web Design Workshop DIG 4104c

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. Web Design WorkshopDIG 4104c Lecture 2.5: Requirements J. Michael Moshell University of Central Florida Adapted from DIG3563. You may recognize it...! Ferrit.com.au.

  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: * state each team's problem succinctly • * 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 • USER CENTERED DESIGN is ITERATIVE DESIGN • Stakeholder identification • User Stories and Use Cases • Requirements lists (and problems with them) • Measurable Goals and Acceptance Procedures • Mock-ups and Prototypes -5 -

  6. So, what to do about it? Lrn.usace.army.mil • * Project Description – 20 to 50 words • Stakeholder identification • User Stories and Use Cases • Requirements lists (and problems with them) • Measurable Goals and Acceptance Procedures • (Used to ask for mock-ups. Proved to be useless, • at this stage.) -6 -

  7. My Example: Conference Management Web.cs.gc.suny.edu • * A small business (owned by my wife) • Manages conference registration • Project Description: • An easy-to-use online system that will allow a conference manager • to display nametag samples from all previous conferences, so • as to quickly select a layout and inform the IT manager to • use or modify it for an upcoming conference. -7 -

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

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

  10. User Stories Cs.rochester.edul • As the IT manager, I want to know which nametag • the boss wishes me to use, and any changes she wants • me to make, as well as the name of • the upcoming conference that will use it. -10 - -10 -

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

  12. Use Cases (Written out in text) www.wikipedia.org • Conference manager: • (1) enter conference name and see badges • from all years of that conference • (2) select a badge; • (3) Write comments about it (requests for changes) • (3) transfer a badge from the registration • system to the badge display system -12 - -12 -

  13. Use Cases (Written out in text) www.wikipedia.org • IT manager: • (1) Edit the badge's layout, according to • instructions received from conference manager -13 - -13 -

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

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

  16. Another Use Case Diagram Example

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

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

  19. Use Case Diagrams • More Examples • Sometimes • the 'actors' • are not • human, • but software or hardware • As in this example ("Central computer") tigris.org -19 - -19 -

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

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

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

  23. NOT A Use Case Diagram! Why not? It contains a sequence of activities, like a flowchart. Use Case Diagrams are JUST about "who does what, with whom" ... not HOW! Buy food Eat Dinner Cook Food • Mother • Child • Child Serve Dinner -23 -

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

  25. 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. Associations, conferences, years, are all controlled vocabularies. • Conference manager will be able to extend each vocabulary item • (option) by adding new values for that 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. -25 -

  26. Measurable Goals Lrn.usace.army.mil • Examples: • 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. -26 -

  27. Mockups and Prototypes Select Association www.wikipedia.org Select Conference Pull-down Menus Select Year 2010 2009 2008 Button Show Badge

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

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

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

  31. Prepare a Project Descriptionexample: Puppiemakers.com Our website helps owners of male and female dogs find appropriate breeding partners, negotiate contracts and carry out cooperative puppy ventures for mutual benefit. The site provides recommendations for veternarians and access to appropriate breed registries. Build A Project Description for YOUR project, "for practice". (Doesn't have to be final) In a couple of minutes you'll tell the class what it is.

  32. Homework before Monday Knowyourmeme.com • Install GIT on your personal laptop • http://git-scm.com/ • PREPARE your Personal Notes/Ideas for your team's discussion on Monday; I suggest a personal "first draft" of the Requirements Document (use Rubric as a check-list)

  33. Homework before Wednesday Knowyourmeme.com • Read Study Guide 1 and 2 • * Be prepared to do what the guide calls for • If YOU are called on, and unready, it'll cost you big-time points • If you are ready,

More Related