Designing a System

4 October 2006

Beyond the Technology

• What will be implemented – external view– “glossy” brochure– Use cases and user types

• Translation to a software design– Web interface– Data objects– STRUTS diagram– Domain model and interface

• How it will be implemented– Project plan: when and who

Design Phase

• Concept

• User Types

• Use Cases

Marketing

• What are you going to accomplish?

• What problem are you solving?– How is it currently done?– How are you going to do it better?

• NO TECHNICAL DETAIL

• Last year’s examples– CampaignScaper– HeelBid

Design Phase

• Concept

• User Types

• Use Cases

How Do You Describe a User

• As a Person– Knowledge and experience– Age and gender– Physical handicaps– Characteristics of tasks and jobs– Psychological characteristics

• By his or her role in the system– Functions– Privileges

Methodologies

• For this project– Three or four sentences describing your

assumptions about the user type and their role in your system

• For more complex systems– Personas

User Requirements - Persona

• A description of a fictitious user representing a distinct user group– User groups are based on unique goals, from the goal model– Each persona represents a unique set of goals for design

• Personas help direct the design– Allow designers to focus on people’s needs and differences– Skills, motivations, emotions, behaviors

– Design teams often post photos and descriptions in their work areas

– Use each persona as though it were a real person

– “What would Jackie do if …”

Persona excerpt from hotel reservation systemPersona: Robert

“Everything had best run like clockwork.” – Robert

Robert – Director of Field Operations Company: Stewart Auto Glass Citizen of Great Britain 45 years old Degrees: BS Industrial Engineering Personal concerns: being responsible and do everything with integrity Corporate concerns: transforming Stewart Auto Glass into a premier auto industry supplier Robert is responsible for all field operations, including glass installation at fourteen auto manufacturer’s plants as well as the over 350 nationwide auto-glass retail outlets owned by Stewart Auto Glass. Robert loves the highly active work environment and the demands of the job. He thrives on rapid-fire situation management, in which he demonstrates his quick analytic ability and decisive management style. Robert travels frequently and expects the same degree of precision, reliability, and integrity from the travel industry as he expects from himself and his own organization. He is a discerning and demanding business traveler. He and his wife are avid golfers and he sometimes combines pleasure with his business duties, but always after all business has been successfully completed. He shoots in the high 70’s, making a point of being very good at whatever he chooses to undertake, in business as well as his personal life.

Story excerpt Scenarios / stories that clearly communicate and demonstrate the users’ requirements Business Traveler: Robert makes a hotel reservation Robert needs to be in Boston for a two-day business meeting. Robert travels frequently, typically several times a month, but he's still conscientious about finding discounted flights and cars whenever possible. He won't bend on the hotel though, even if a discount is available. He likes his comfort, and will pay for it. Robert has traveled to the same seven cities for about four years, and has developed a routine. He has a favorite airline and hotels in each city. He always stays at high-end hotels, usually in rooms with in-room business facilities. He usually rents a car but will take a taxi if the weather is going to be bad. Robert typically prefers to make his own reservations via the Web - he’s a stickler for having everything go exactly as planned, and he doesn’t quite trust that a travel agent will be as exacting as he is. Robert finds a few free minutes at the office, so he accesses the ExpressTravel Web site, which is the one he usually uses. For some reason, the Web site is down, so he goes to the UTravel Web site. He doesn't like this Web site as much and has only used it once before, but, at this point, he has no option. He needs to get his reservations made. On the home page he takes advantage of the “create your own trip” window and types in his departure and arrival city, dates of travel and preferred departure and return times. Robert clicks the small icon of the calendar to check the exact dates of his trip. He is asked to specify if he has a preferred airline, class of travel, a preferred time of day, number of travelers, and number of connections preferred. After typing in all of this information, he clicks the Search button. He's frustrated because the next page tells him there are several matches for Chicago, IL airports and he needs to specify the correct airport. He clicks on ORD then he clicks on the "Search Now" lin

Design Phase

• Concept

• User Types

• Use Cases

Use Cases• A statement of the functionality users

expect and need, organized by functional units

Functional units to be designed Creation, removal, update, purchase,

browse, … Relationships between user roles and use cases

User activities, decisions, and objects involved

Measures and targets that satisfy task-level success criteria

Methodologies

• For this project– Text definitions– Examples from last year

• CampaignScaper• HeelBid

• For more complex systems– UML

Sample Use Case: UML notation

Traveler

Find a suitable hotel

Make a booking

Make a payment

View additional materials

«user goal»Room OK

«user goal»Hotel OK

«user goal»Payment method OK

+ «optional» payment : payment type = personal credit card

«system_imposed goal»Payment approved

+ «mandatory» room is paid for : payment acceptance = yes

«user goal»Booking confirmation received

+ «mandatory» confirmation : conf. type = printout

«user goal»Room is booked

«include»

«extend»«extend»

Use cases are often inter-related extend is an optional association include is a mandatory association

• Each use case is a logical function to be designed • The collection of all use cases defines the system

Use Case

Into Development Mode

• Interface Design – Building a Web Site

• Building a System

• Dividing the Work

• Managing the Process

About Site Design(from Yale site guidelines)

• In architecture as in all other operative arts, the end must direct the operation.

— Sir Henry Wotton, The Elements of Architecture

• Although people will notice the graphic design of your Web pages right away, the overall organization of the site will have the greatest impact on their experience.

• The fundamental organizing principle in Web site design is meeting users' needs. Ask yourself what your audience wants, and center your site design on their needs.

The UI IcebergThe UI Iceberg

VisualsVisuals

InteractionInteractionTechniquesTechniques

Object ModelObject Model

Feel30%

Look10%

The things you use60%

Toolkits and Style Guides help with look and feel, the tip of the usability iceberg.

Real usability gains come from system and application objects perceived by users.

Principles of Good Screen Design(Galitz)

• Consistency

• Starting in the upper left corner

• Simple navigation

• Hierarchy for importance

• Pleasing visuals

• Captions

Development OverviewDevelopment Overview

DiscoveryD

esign

Implementation

Users

Check in

Greet Register

Create keyConfirm roomCheck reservations

TaskAnalysis

DialogWindow

Container

Implementor's Model

Model of Users’ Objects

Hotel Guest

Reservation

Domain Classes

• Object-oriented paradigm, not implementation

• Domain = application specific• Classes defined in natural language

– Used to explain the architecture and design

• Classes derived from the requirements– Need not match the implementation– Likely design in small project

Defining Domain Classes

• Begin with Use Cases• Identify nouns

– External agents are not domain classes– Are these key classes for the application?– Are there others?

• Identify attributes and functionality for each class• Validate

– Walkthrough use cases– Try changes and extensions

• Look for– Missing attributes or functions– Changes that reach everywhere

Into Development Mode

• Interface Design – Building a Web Site

• Building a System

• Dividing the Work

• Managing the Process

With Teams of Two

• Pair Programming– High quality– No coordination problems– Need to coordinate work times

• Vertical Towers– Both people get full experience– Both people need to learn all parts– Parts may be inconsistent– May not find all reusable components

• Horizontal Slices– Each person only needs to become expert in parts– Do not get the work in both parts– Need to assure pieces work together

Pair Programming

• Two people working at a single computer• Built-in backup and inspections• Collaboration builds better code• Different models: mechanics

– One drives, the other talks– Keyboard slides between the two

• Different models: logical– One tactical, the other strategic– Both think about the full spectrum but bring different

perspectives

Into Development Mode

• Interface Design – Building a Web Site

• Dividing the Work

• Managing the Process

Technical Risks

• New features• New technology• Developer learning

curve• Changes that may

affect old code• Dependencies• Complexity

• Bug history• Late changes• Rushed work• Tired programmers• Slipped in “pet”

features• Unbudgeted items

Knowing How You’re Doing

• If you don’t have a plan, you don’t know if you’re on schedule

• Weekly checkpoints

• If you’re behind?

– Work harder

– Adapt assignments

– Reduce scope