• Save
[DSBW Spring 2009] Unit 04: From Requirements to the UX Model
Upcoming SlideShare
Loading in...5

[DSBW Spring 2009] Unit 04: From Requirements to the UX Model






Total Views
Slideshare-icon Views on SlideShare
Embed Views



2 Embeds 34

http://pbasari.wordpress.com 30
http://www.slideshare.net 4



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    [DSBW Spring 2009] Unit 04: From Requirements to the UX Model [DSBW Spring 2009] Unit 04: From Requirements to the UX Model Presentation Transcript

    • Unit 4: From Requirements to the UX Model Requirements Engineering → Requirements Model Analysis → Analysis Model (Specification) External Design of the Web Presentation Layer → Interaction Model (UX Model) dsbw 2008/2009 2q 1
    • Requirements Engineering and Analysis of WebApps  In principle, all that you have learned in Software Engineering courses on these topics are also applicable to Web Application engineering.  We are going to recall some general concepts,  with special attention to those aspects more concerned with WebApp Engineering. dsbw 2008/2009 2q 2
    • Requirements Model: Artifacts  Vision Document (Revised)  Requirements Document Functional Requirements  Non-functional Requirements   User eXperience (UX) document dsbw 2008/2009 2q 3
    • Vision Document  The Vision Document is an overview of the entire project and is the source for the rationale that drives all the decisions made throughout the development process.  The vision document contains several key elements:  Description of the problem  List of the stakeholders involved in the project and their views of the system  Outline of the project scope  Outline of the software solution: high-level features and key design constraints dsbw 2008/2009 2q 4
    • Requirements  A requirement is a statement that defines a goal or a constraint that the system must satisfy and  needs to be understood by the development team and validated by the stakeholder and user community.  has clearly determined pass/fail criteria that can be verified by the testing team.  must have its priority set in relation to other requirements.  Functional requirements “The system should be able to compute international shipping charges  for all products available for sale (high priority)” dsbw 2008/2009 2q 5
    • Non-functional requirements  Usability/Accessibility “The user should not fill more than three forms in any use case  (medium)” “The system interface shall not use HTML frames (low)”   Performance “Web pages should not take longer than 5 seconds to load in the  browser with a broadband connection (high)”  Robustness/reliability “The system should enable access to data on weekly backup tapes  within a 2-hour window (high)”  Security “Personal data should be transferred through secure protocols (high)”  dsbw 2008/2009 2q 6
    • Requirements: Defining User Categories  What is the user’s overall objective when using the WebApp?  What is the user’s background and sophistication relative to the content and functionality of the WebApp?  How will the user arrive at the WebApp?  What generic WebApp characteristics does the user like/dislike? dsbw 2008/2009 2q 7
    • Gathering Requirements from Stakeholders  Traditional focus groups  Trained moderators meet with small groups of representative end- users.  Electronic focus groups  Moderated electronic discussions conducted with groups of representative end-users and stakeholders.  Iterative surveys  Series of brief surveys, addressed to representative users and requesting answers to specific questions about the WebApp  Exploratory surveys  Web-based surveys tied to one or more WebApps that have users who are similar to the ones that will use the WebApp to be developed.  Scenario-building  Selected users are asked to create informal use cases that describe specific interactions with the WebApp. dsbw 2008/2009 2q 8
    • UX Document [Conallen]  Its purpose is to guide the team developing the user interface :  Definition of the general user interface metaphors: menus, tabs, carts  Naming conventions for menus and titles  Detailed specifications for fonts, sizes, colors, and artwork requirements dsbw 2008/2009 2q 9
    • UX Document (cont.)  Definition of page layouts and content positioning dsbw 2008/2009 2q 10
    • Analysis Model: Artifacts  Use Case Model  User Categories  Use Case Diagrams  Content Model Content “objects”: text, graphics, pictures, video, audio, etc.   Conceptual Model Class Diagram  Textual Integrity Constraints   System Behavior Model System’s sequence diagrams  System’s operation contracts   State Model  State diagrams dsbw 2008/2009 2q 11
    • E-Tailer Example: User Categories customer guest registered customer customer service staff new existing dsbw 2008/2009 2q 12
    • E-Tailer Example: Use Case Diagram E-Tailer Browse Catalog Customer <<extend>> Check Check out order status <<include>> <<include>> Process Ship payment order Shipping Merchant Department Account System dsbw 2008/2009 2q 13
    • E-Tailer: Conceptual Model Product Category Catalog ID : String ID : String ID : String name: String : name: String : name: String price : float * 1 * 1 ... ... ... Sale Item * quantity : Integer * Finished Sale custName : String {incomplete} date : Date address : String /total : float ... dsbw 2008/2009 2q 14
    • E-Tailer: System Sequence Diagram for the Browse Catalog Use Case : Customer : System The customer begins by navigating Navigate to home page to the e-retail company application Display company page The system responds with the company's home page. Select catalog The customer selects the product catalog. The system responds with a list of Display top-level categories the top-level categories of the catalog. The customer selects a category. Select category The system displays a list of Display products products in this category. The customer selects a product. Select product The system responds with a detailed product description. Display product detail dsbw 2008/2009 2q 15
    • WebApp Engineering Design Pyramid user Interface design Aesthetic design Content design Navigation design Architecture design Component design technology dsbw 2008/2009 2q 16
    • WebApp Engineering Workflows  Interface design:  Describes the structure and organization of the WebApp pages  Layout, menus, tabs, links, content, context information, search, etc.  Aesthetic design:  Look and feel of the WebApp (Refinement and/or redefinition of the UX Document)  Content design:  Content structure and organization in pages  Navigation design:  Definition of the navigational flows among pages that implement the different use cases. dsbw 2008/2009 2q 17
    • WebApp Engineering Workflows  Architecture design:  Definition of the overall hypermedia structure for the WebApp  Component design:  In simple WebApps (static) Which html files are needed and how they are organized  Web server configuration   In complex WebApps: System’s Physical Architecture  Internal design of the Web presentation layer  Business logic layer design  Persistence model design  dsbw 2008/2009 2q 18
    • User eXperience Model (UX Model) [Conallen]  Corresponds to the Content design (partially), Navigation design and Architecture design layers of the “pyramid”  L’UX Model describes how the (dynamic) content will be structured and organized in different screens and how the user will navigate among those screens to execute the WebApp use cases.  Artifacts of the UX Model: Screens   Storyboard sequences  Navigational paths and maps  A screen is something that is presented to the user, which contains the standard user interface infrastructure, such as menus and controls, as well as business-relevant content. dsbw 2008/2009 2q 19
    • Screen Description  A screen's properties and its behavior with the user define the screen. These include :  Name and description  Structure  Content: Static content  Dynamic content   Business logic content  Managed content: Banner ads, help and informational messages, press releases, company and application FAQs, white papers  Input fields and controls that accept user input  Description of user interactions with the screen dsbw 2008/2009 2q 20
    • UX Model Stereotypes dsbw 2008/2009 2q 21
    • E-Tailer: Home Page Screen Home Page «business logic» Featured product ID «business logic» Featured product name «business logic» Featured product price «business logic» Featured product short description «business logic» Featured product thumbnail «managed» Copyright statement «managed» Customer quote dsbw 2008/2009 2q 22
    • E-Tailer: Storyboard sequence for the Browse Catalog Use Case <<screen>> <<screen>> <<screen>> : Customer <<screen>> : Home Page : Catalog : Category : Product The customer navigates to the e-retail navigate() company application on the Internet. The system responds with the company's home page. catalog() navigate() The customer selects the product catalog. The system responds with a list of the top-level categories of the catalog. select category() navigate() The customer selects a category. The system displays a list of all products in this category. select product() navigate() The customer selects a product. The system responds with a detailed product description. dsbw 2008/2009 2q 23
    • E-Tailer: Screens and Navigational paths for the Browse Catalog Use Case dsbw 2008/2009 2q 24
    • E-Tailer: Storyboard Sequence for the Checkout Use Case Error in the payment data dsbw 2008/2009 2q 25
    • E-Tailer: Screens and Navigational Paths for the Checkout Use Case dsbw 2008/2009 2q 26
    • E-Tailer: Cart Updating dsbw 2008/2009 2q 27
    • E-Tailer: Navigational Map dsbw 2008/2009 2q 28
    • Interface Design: Principles (1/2)  Anticipation: The WebApp should anticipate the user’s next move.  Communication: The interface should communicate the status of any activity initiated by the user  Consistency in the use of navigation controls, menus, icons, and aesthetics  Controlled autonomy: The interface should facilitate user movement throughout the WebApp, but it should do so in a manner that enforces navigation conventions that have been established for the application.  Efficiency: The design of the WebApp and its interface should optimize the user’s work efficiency, not the efficiency of the Web engineer who designs and builds it or the client-server environment that executes it.  Focus: The WebApp interface (and the content it presents) should stay focused on the user task(s) at hand. dsbw 2008/2009 2q 29
    • Interface Design: Principles (2/2)  Fitt’s Law: “The time to acquire a target is a function of the distance to and size of the target.”  Learnability: A WebApp interface should be designed to minimize learning time, and once learned, to minimize relearning required when the WebApp is revisited.  Maintain work product integrity: A work product (e.g., a form completed by the user, a user specified list) must be automatically saved so that it will not be lost if an error occurs.  Readability: All information presented through the interface should be readable.  Track state: When appropriate, the state of the user interaction should be tracked and stored so that a user can logoff and return later to pick up where she left off.  Web Design Patterns: www.welie.com/patterns/ dsbw 2008/2009 2q 30
    • References  R. G. Pressman, D. Lowe: Web Engineering. A Practitioner’s Approach. McGraw Hill, 2008. Chapters 4, 7-9  CONALLEN, Jim Building Web Applications with UML, 2on Edition, Addison-Wesley, 2002. Chapters 8-10 dsbw 2008/2009 2q 31