Your SlideShare is downloading. ×
Unit 04: From Requirements to the UX Model
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Unit 04: From Requirements to the UX Model

671
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
671
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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 2011/2012 q1 1
  • 2. Requirements Engineering and Analysis 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 2011/2012 q1 2
  • 3. Requirements Model: Artifacts Vision Document (Revised)‫‏‬ Requirements Document  Functional Requirements  Non-functional Requirements User eXperience (UX) documentdsbw 2011/2012 q1 3
  • 4. 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 constraintsdsbw 2011/2012 q1 4
  • 5. 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 2011/2012 q1 5
  • 6. 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 2011/2012 q1 6
  • 7. 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 2011/2012 q1 7
  • 8. Gathering Requirements from Stakeholders Traditional focus groups  Trained moderators meet with small groups of representative 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 build. Scenario-building  Selected users are asked to create informal use cases that describe specific interactions with the WebApp.dsbw 2011/2012 q1 8
  • 9. 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 requirementsdsbw 2011/2012 q1 9
  • 10. UX Document (cont.)‫‏‬  Definition of page layouts and content positioningdsbw 2011/2012 q1 10
  • 11. 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 diagramsdsbw 2011/2012 q1 11
  • 12. E-Tailer Example: User Categories customer guest registered customer customer service staff new existingdsbw 2011/2012 q1 12
  • 13. E-Tailer Example: Use Case Diagram E-Tailer Browse Catalog Customer <<extend>> Check Check order status out <<include>> <<include>> Process Ship payment order Merchant Shipping Account System Departmentdsbw 2011/2012 q1 13
  • 14. E-Tailer: Conceptual Model Product Catalog Category ID : String ID : String ID : String name: String : name: String name: String : 1 * 1 * price : float ... ... ... * Sale Item * quantity : Integer Finished Sale custName : String {incomplete} address : String date : Date ... /total : floatdsbw 2011/2012 q1 14
  • 15. 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 The system responds with the Display company page companys home page. The customer selects the product Select catalog 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 Display product detail product description.dsbw 2011/2012 q1 15
  • 16. WebApp Engineering Design Pyramid user Interface design Aesthetic design Content design Navigation design Architecture design Component design technologydsbw 2011/2012 q1 16
  • 17. 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 2011/2012 q1 17
  • 18. 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 designdsbw 2011/2012 q1 18
  • 19. 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 2011/2012 q1 19
  • 20. Screen Description A screens 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 screendsbw 2011/2012 q1 20
  • 21. UX Model Stereotypesdsbw 2011/2012 q1 21
  • 22. 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 quotedsbw 2011/2012 q1 22
  • 23. E-Tailer: Storyboard sequence for the Browse Catalog Use Case : Customer <<screen>> <<screen>> <<screen>> <<screen>> : Home Page : Catalog : Category : ProductThe customer navigates to the e-retail navigate()‫‏‬company application on the Internet.The system responds with thecompanys home page. catalog()‫‏‬ navigate()The customer selects the productcatalog.The system responds with a list of thetop-level categories of the catalog. select category()‫‏‬ navigate()‫‏‬The customer selects a category.The system displays a list of allproducts in this category. select product()‫‏‬ navigate()The customer selects a product.The system responds with a detailedproduct description.dsbw 2011/2012 q1 23
  • 24. E-Tailer: Screens and Navigational paths for the Browse Catalog Use Casedsbw 2011/2012 q1 24
  • 25. E-Tailer: Storyboard Sequence for the Checkout Use Case Error in the payment datadsbw 2011/2012 q1 25
  • 26. E-Tailer: Screens and Navigational Paths for the Checkout Use Casedsbw 2011/2012 q1 26
  • 27. E-Tailer: Cart Updatingdsbw 2011/2012 q1 27
  • 28. E-Tailer: Navigational Mapdsbw 2011/2012 q1 28
  • 29. 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 2011/2012 q1 29
  • 30. 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 2011/2012 q1 30
  • 31. 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-10dsbw 2011/2012 q1 31