1dsbw 2011/2012 q1

Requirements Engineering → Requirements Model

Analysis → Analysis Model (Specification)‏

External Design of the Web Presentation Layer

→ Interaction Model (UX Model)‏

Unit 4: From Requirements to the UX Model

2dsbw 2011/2012 q1

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.

Requirements Engineering and Analysis

3dsbw 2011/2012 q1

Vision Document (Revised)‏

Requirements Document

Functional Requirements

Non-functional Requirements

User eXperience (UX) document

Requirements Model: Artifacts

4dsbw 2011/2012 q1

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

Vision Document

5dsbw 2011/2012 q1

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)”

Requirements

6dsbw 2011/2012 q1

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)”

Non-functional requirements

7dsbw 2011/2012 q1

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?

Requirements: Defining User Categories

8dsbw 2011/2012 q1

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.

Gathering Requirements from Stakeholders

9dsbw 2011/2012 q1

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

UX Document [Conallen]

10dsbw 2011/2012 q1

Definition of page layouts and content positioning

UX Document (cont.)‏

11dsbw 2011/2012 q1

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

Analysis Model: Artifacts

12dsbw 2011/2012 q1

E-Tailer Example: User Categories

customer

guest registered

customer

customer

service staff

new existing

13dsbw 2011/2012 q1

E-Tailer Example: Use Case Diagram

E-Tailer

Checkout

Customer

BrowseCatalog

Check order status

Shiporder

Processpayment

<<extend>>

<<include>><<include>>

MerchantAccount System

ShippingDepartment

14dsbw 2011/2012 q1

E-Tailer: Conceptual Model

ID : String

name: : String

...

CategoryID : String

name: : String

price : float

...

Product

date : Date

/total : float

Sale

quantity : Integer

Sale Item

**

1 *

custName : String

address : String

...

Finished{incomplete}

ID : String

name: String

...

Catalog

1 *

15dsbw 2011/2012 q1

E-Tailer: System Sequence Diagram for

the Browse Catalog Use Case

: Customer : System

Navigate to home page

Select catalog

Select category

Select product

Display company page

Display top-level categories

Display products

Display product detail

The customer begins by navigating to the e-retail company application

The system responds with the company's home page.

The customer selects the product catalog.The system responds with a list of the top-level categories of the catalog.The customer selects a category.

The system displays a list of products in this category.

The customer selects a product.

The system responds with a detailed product description.

16dsbw 2011/2012 q1

WebApp Engineering Design Pyramid

Component design

Architecture design

Navigation design

Content design

Aesthetic design

Interface

design

user

technology

17dsbw 2011/2012 q1

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.

WebApp Engineering Workflows

18dsbw 2011/2012 q1

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

WebApp Engineering Workflows

19dsbw 2011/2012 q1

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.

User eXperience Model (UX Model) [Conallen]

20dsbw 2011/2012 q1

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

Screen Description

21dsbw 2011/2012 q1

UX Model Stereotypes

22dsbw 2011/2012 q1

E-Tailer: Home Page Screen

«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

Home Page

23dsbw 2011/2012 q1

E-Tailer: Storyboard sequence for the

Browse Catalog Use Case

The customer navigates to the e-retail

company application on the Internet.

The system responds with the

company's home page.

The customer selects the product

catalog.

The system responds with a list of the

top-level categories of the catalog.

The customer selects a category.

The system displays a list of all

products in this category.

The customer selects a product.

The system responds with a detailed

product description.

<<screen>>: Home Page

: Customer

: Category

<<screen>> <<screen>>

: Product

<<screen>>

: Catalog

navigate()

navigate()‏

catalog()‏

select category()‏

select product()‏navigate()

navigate()‏

24dsbw 2011/2012 q1

E-Tailer: Screens and Navigational paths for the

Browse Catalog Use Case

25dsbw 2011/2012 q1

E-Tailer: Storyboard Sequence for the

Checkout Use Case

Error in the payment data

26dsbw 2011/2012 q1

E-Tailer: Screens and Navigational Paths for the

Checkout Use Case

27dsbw 2011/2012 q1

E-Tailer: Cart Updating

28dsbw 2011/2012 q1

E-Tailer: Navigational Map

29dsbw 2011/2012 q1

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.

Interface Design: Principles (1/2)‏

30dsbw 2011/2012 q1

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/

Interface Design: Principles (2/2)‏

31dsbw 2011/2012 q1

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

References