4.2 Steps in the Facade Iteration

Following are the steps to completing the Facade iteration:

1. Create a problem statement.

2. Identify and review existing documentation and intellectual capital.

3. Get the executive sponsor's unique viewpoint.

4. Review business process definitions.

5. Identify the users, the user group management, the stakeholders, the customers being served by the user group, and the owners of the data.

6. Interview the stakeholders.

7. Create a stakeholders' list.

8. Find the actors.

9. Create the use case survey (a list of Facade use cases).

10. Start the nonfunctional requirements survey.

11. Start the business rules catalog.

12. Create a risk analysis.

13. Create a statement of work.

14. Begin experimenting with user interface metaphors.

15. Begin user interface storyboards.

16. Get informal approval from the executive sponsor.

4.2.1 Create the Mission, Vision, Values

The executive sponsor leads the effort to create the mission, vision, and values for the application and distributes it widely to generate support and awareness. This document essentially becomes the marching orders for the application development team, including the requirements analysts. For an example of mission, vision, and values, refer to Chapter 3.

4.2.2 Identify and Review Existing Documentation and Intellectual Capital

To familiarize yourself with the history of this effort, read every memo, deliverable , proposal, and e-mail message you can get your hands on. If there is too much for one person to read, use a team approach. Each person takes a stack of paper or electronic documents and wades through it, reporting the interesting findings to the group. Here are the questions you're trying to answer:

• What elements of the proposed system were ruled out previously and by whom? Who introduced those items in the first place?

• Who are the people who want this system built? Who doesn't want it built?

• Have any commercial off-the-shelf (COTS) packages been considered ? Which ones?

• Is this project visible to upper management? Who?

• How long has this idea been kicked around? What were its previous incarnations?

The benefit of completing this step is that you create a reuse strategy at the first level: requirements. If someone has already done part of this work, it is worthwhile to try reusing it. Of course, reuse always comes with some overhead, so you must judge whether it is worth it. Often, it is. Major stumbling blocks are revealed, and fortuitous shortcuts will become clear.

Let's take a closer look at each of these questions.

4.2.2.1 What Elements of the Proposed System Were Ruled Out Previously and by Whom?

You're not searching for great detail here, only the subsystem name and general functionality that was killed before this effort started. Usually there is a long "fuzzy front end" (McConnell 1996) during which not much gets done but people mull the possibility of developing such a system. What was ruled out during this time?

4.2.2.2 Who Are the People Who Want This System Built? Who Doesn't Want It Built?

This question may be more important than the first one. Find out the enemies of this system and their motivations. If possible, arrange to meet with them, or at least people in the organization who know something about them. At this point, don't try to convince them that they're wrong. Just gather data. They may have valid suggestions, and implementing them might result in only a small change to the requirements that would be easy to include at this early point. The motives of these naysayers may be political, and it will require your tact, charm , and negotiation skills to work with them. If you're a consultant or a low-ranking IT team member, this is a difficult step because the upper-level IT managers may not understand why this kind of discussion is important. However, you should still see how far you can go. Consider it practice in office politics for when you're in management. Remember that numerous systems have died for political and not technical reasons.

4.2.2.3 Have Any Packages Been Considered? Which Ones?

It is important to ferret out this information. There may have been some investigation into whether any COTS packages could fulfill the requirements for this system. It is also likely that those COTS packages have evolved since the investigation. Check into it. During design, you can evaluate the suitability of these products.

4.2.2.4 This Project Visible to Upper Management? Who?

High project visibility is both a curse and a gift. The curse is often that everyone wants his or her trademark on the visible project and wants to be associated with ituntil it begins to look as if there are problems. However, project visibility is a greater gift than a curse. When resources are required, it helps tremendously because no one wants to stand in the way of an initiative that has support and visibility at high levels of management. Quite simply, the higher the visibility in the organization, the better.

4.2.2.5 How Long Has This Idea Been Kicked Around? What Were Its Previous Incarnations?

Find out what you can in this area, but don't go into great detail. Because elements of these previous incarnations will show up in your requirements, it pays to at least speak the language: "Oh, that sounds like it comes from the ORMS idea a few years ago." It's likely that this system has been attempted once or twice before and then stopped .

Too Much Information

Following this process, the team will inevitably complain that there is too much information to cope with intelligently. Our advice is that the team allows this to happen and tries to find a way to deal with the overabundance of information. It is quite likely that a small team of business analysts will not be able to read through all the background documents. However, humans are incredibly adaptive to challenges like this and our brains are able to quickly sort the wheat from the chaff until "enough" of the primary messages are clear.

4.2.3 Get the Executive Sponsor's Unique Viewpoint

It can be hard to get time from your executive sponsor. She is rushing from one high-flying meeting to another, and she has already started organizing her next big launch. As far as she's concerned , you should be self-sufficient. Yet your success rides on getting the exact definition of the problem from her. Get at least a sliver of her time, whatever it takes. Try this as your opening line: "Our team has our own answers to these questions, but we want to make sure we're right." Then ask her these questions.

• What is the problem being solved ?

• Why is a system required?

• Why is a computer system required?

• Who will be affected by the system implementation? How?

There is another very important question to ask the executive sponsor. "How can we make sure this application helps fulfill our corporate mission, vision, and values?" The application your team is building must have "traceability" back to the goals of the business as a whole. This is true whether your organization is a private or public corporation, non-profit or government department. The organization is tasked with accomplishing some goal, and each and every task under the umbrella of the organization must be aligned with that goal. Make sure you ask the sponsor, or whoever else can help with the answer.

These questions are best addressed in a face-to-face meeting or telephone call. E-mail will not work. This must be interactive. Certain things the sponsor says will spur other questions, and you should ask them. It is important to try to catch every nuance, every uncomfortable moment, every glance at her shoes. Body language, silences, and tone of voice will warn you of the dangers to come. Remember, if she's not happy with the result, you've failed. Period.

4.2.3.1 What Is the Problem Being Solved?

This should be a problem statement, perhaps four or five sentences at the most. It should describe the business reason for the system. Usually, business systems are developed to help the organization stay competitive in the marketplace , to provide better customer service, to automate certain functions, to comply with government legislation, or to meet any other of a variety of environmental demands. State the factor that is pushing the need for this system, and state what is likely to occur if it is not developed. If there is a drop-dead date that has relevance to the problem statement, include it.

4.2.3.2 Why Is a System Required?

What is the worst thing that would happen if this problem were not resolved? How much money would the new process save (or make) the company? What is a reasonable payback time? This question addresses only the business process and not necessarily a computer system. That's next.

4.2.3.3 Why Is a Computer System Required?

Why can't this task be done manually? If the business process has been proven, why can't it be a manual process? This is a difficult question. If the executive sponsor starts to think about it, she may decide that an electronic system isn't needed at all, and that means you will have to find another project to work on! As project managers, we tend to jump too quickly into a self-fulfilling prophecy : We want to make a project happen whether or not it is meant to happen. If you take a hard, objective look at whether this system really should be built now, you might save countless heartaches later.

If you and the executive sponsor end up talking each other out of a computer system to attack this problem, the executive sponsor may see you as someone who has just saved her budget millions of dollars, and she may be more likely to come to you again with requests , knowing that you'll take an objective view. Play the devil 's advocate with the sponsor. Pretend that you need to be convinced of the need for this process to be automated. It's what's best for the business.

4.2.3.4 Who Will Be Affected by the System Implementation? How?

Identify all the groups that will be affected by this implementation. Determine the relative benefits or obstacles they will experience from this system. Judge this over a period of time. For example, the data entry clerks might be disadvantaged by the system at first but then realize its benefits after two months. This technique is called other people's views , or OPV (de Bono 1994). Don't limit the list to those directly affected; include the indirect effects as well. This step will give you valuable information later as you calculate costs versus benefits.

Other People's Views: The Selling Property Application

At the beginning of a project to design a real estate application, the following people and groups were identified as those who would be affected by the application.

All stakeholders want a system that is easy to use, doesn't cost much, handles transactions quickly, and stays out of the way, allowing productivity.

Buyers want to buy a property that fits their exact needs and want some advice on shaping their own needs.

Sellers want to sell property quickly and as close to their target price as possible.

Agents want to earn maximum fees in minimal time and want to feel a sense of accomplishment from helping people exchange money and property.

The owner of the agency wants the application to increase the agency's profits, wants the application to be delivered quickly, and wants control of and information about the status of the development.

Regulatory agencies , although they have no financial stake in the system, have power over the results. Think about the government tax agencies, industry regulators, stock exchange regulators, and so on.

Designers and developers want requirements that show the needs of the users accurately, want no design assumptions embedded in requirements, and want to build an application that is state-of-the-art.

4.2.4 Review the Business Process Definitions

If there is business process documentation relevant to the application you are building, review it before you proceed. Business processes can be documented as flowcharts, activity diagrams, or even use cases.

We discuss the traceability between the business process definitions and the system use cases in Chapter 7.

4.2.5 Identify the Users, Customers, and Related Groups

Get an up-to-date organization chart for the user group that includes management and all participants . Try to find out where the informal power lies. If you can also get last year's organization chart, so much the better. Seeing the way things have been reorganized will help you understand where the organization is trying to go and how a system could help it get there.

If possible, talk to a sampling of the users. Take some of them out for lunch . Include not only the managers but also a decent sampling across the board. These are get-to-know-you sessions and not requirements gatheringyet. That comes later.

By customers , we mean the real, honest-to-goodness customers outside the organization, not internal customers. Building a system for a grocery chain? Identify the people who would benefit: the clerks, the shoppers, the pharmacists. How about a manufacturing firm? Identify the wholesalers and the final customers, assuming that your system will change how they view the firm.

The "Internal Customer" Problem

A recent movement promotes the idea of treating everyone in the organization as your customer. The IT shop treats the accountants as its customers, the accountants treat manufacturing as their customer, and so forth. Here's the issue with internal customers. Let's say you work for an internal IT shop that's building a sales tracking system, and you consider your internal customer to be the sales department. Your internal customers will tell you exactly what they want so that they can sell more stuff, properly credit their commissions, and widen their markets. That's part of why you're building this system. But there's more. The actual customers will want a sales tracking system that increases their level of customer service, allows them to cancel orders late in the order process, and is flexible enough to handle their specialized requests. They may also offer some insights into what the future may hold for this company in terms of the changing marketplace. Christopher Alexander, an insightful building architect who has greatly influenced the computer industry, said at the 1996 OOPSLA conference in San Jose that computer analysts and programmers treat themselves as "guns for hire" in their organizations. They say, "Just tell us what to build, and we'll build it"without asking about the larger circumstances. By including the external customers in the process of requirements gathering, we broaden our purview to include the health and wealth of the entire business, and perhaps society, in the development of an application. We believe that it is the obligation of computer analysts and programmers everywhere to delve deeply to determine the true requirements of the systems they build.

4.2.6 Interview the Stakeholders

You can do this task in several ways. You can conduct individual interviews with the users, user management, and a sampling of their customers. You can hold a concentrated joint requirements planning session, during which all interested parties get together in a hotel conference room and work through all the issues until a semblance of requirements emerges. The differences in these approaches change the speed, but not the content, of your iterations. You will most likely emerge from the JRP with a set of Filled use cases, which will need to be consolidated with the Focused iterations before they are completely usable. This means that to avoid wasting the participants' time you may need to walk into the JRP with a set of Facade use cases. With individual interviews, on the other hand, the interview notes will come together as input to your Facade use cases. Remember Ellen Gottesdiener's book on requirements workshops as a useful tool (Gottesdiener 2002).

4.2.7 Create a Stakeholders List

Once you've identified the stakeholders and had some discussion with them, create a simple list of them. Stakeholders will come from inside the organization you're providing a solution for. They will also come from outside that organization. Outside stakeholders may include customers, suppliers, partner companies, resellers , investors, and people in other departments (if it's a departmental application). Remember, a stakeholder is someone who has a direct "stake" in the success of the system. A rule of thumb to use is to think about whether someone in this category would be willing to spend a week of their time (given reasonable notice) to make sure this application goes well. If yes, they are a potential stakeholder.

4.2.8 Find the Actors

Actors are the people and applications that interact with this application. Ask the executive sponsor who she thinks the actors are, and ask each stakeholder.

Your definition of the actors may be fuzzy at this point, and that is OK. Define them as they arise and push concerns about duplication and definition into later iterations. At this point, consider every stakeholder as a potential actor.

4.2.9 Create the Use Case Survey (A List of Facade Use Cases)

The output of this step is a list of sketchy use cases that outlines the scope of the proposed system. The level of detail is crucial because too much detail here will hurt the iterative nature of this process. It is important to identify the need for the use case, describe in two or three sentences what is involved, and move on.

We're creating use cases that treat the system as if it were a bread-making machine. You put the ingredients into the machine, and after a while you take out a loaf of bread. The focus is on the ingredients going in and the product coming out. What goes on inside the bread-making machine is not our concern, and certainly not part of requirements.

Facade use cases show the basic, essential, high-level interactions that this application must support (Constantine 1999).

Use cases focus on the ingredients that go in and the result that comes out.

When you're creating use cases, do

• Name the use case in user terminology.

• Write a two- or three- sentence description of what the use case accomplishes.

• Use role names and not user titles.

• Group input or output information without specifying field-by-field details, which can come in later iterations.

Don't

• Skip use cases, because the goal is to create "shell" use cases for each of the main user interactions expected for this system (placeholders, remember?).

• Start with CRUD (create-read-update-delete) table-based use cases (leave them until you have identified use cases that satisfy business requirements).

Table 4.1 shows a use case survey. Consider each line on this survey a Facade use case.

Table 4.1. Use Case Survey

Use Case Number

Use Case Name

Initiating Actor

Description

Completeness

Maturity

Use Case Complexity

Architectural Priority

Business Priority

Dependency

Source

Comments

Actor names and use case names can be quite informal and may not be completely consistent in Facade. They can be cleaned up later.

4.2.10 Collect and Document Nonfunctional Requirements

There are three steps to identifying and documenting nonfunctional requirements in this iteration:

1. Identify the requirement in the notes from previous interviews.

2. Validate the requirement with additional interviews with the associated stakeholders.

3. Document the requirement : Capture an understanding of the requirement, its effects, and the system and business degradation that would result if the requirement were not satisfied.

In the Filled and Focused iterations, you refine your nonfunctional requirements and create a stereotype to relate nonfunctional requirements to the use cases. Stereotypes are first explored in Chapter 2, in which we describe how this feature of the UML can be employed to associate related information to a number of use cases. For this iteration, we only capture and document these requirements.

4.2.10.1 Identify Nonfunctional Requirements

The best time to identify nonfunctional requirements (see Table 4.2) is while you are exploring the functional requirements. Whenever you identify a candidate nonfunctional requirement, document it. Do not wait to attempt to do this as a single task later. Your group of users is an excellent source for identifying nonfunctional requirements. When you interview stakeholders while building the use cases, use this opportunity to gather the nonfunctional requirements, too.

Table 4.2. Definitions of Nonfunctional Requirements

Nonfunctional Requirement	Definition
Archival	Length of time data needs to be retained within the application; level of difficulty to retrieve archived data (special request to operator, and so on)
Auditability	Ability for this application to show what has happened to it, who did it, and when (audit trail, transaction changes, before/after pictures, and so on); includes requirements for effective dating
Authentication	Security requirement to ensure "you are who you say you are"
Authorization	Security requirement to ensure that users can access only certain functions within the application (by use case, subsystem, Web page, business rule, field-level, and so on)
Availability	24x7 support and 99.999% uptime or better (this would be a very aggressive availability requirement)
Compatibility	Adherence to industry standards for inputs/outputs (XML, ebXML, BPML, and so on)
Configurability	Ability for the end users to change aspects of the software's configuration easily (through usable user interfaces)
Data integrity	Tolerance for loss, corruption, or duplication of data
Extensibility	Ability to easily incorporate add-on modules ( components ) of functionality to the application in production
Installability	Ease of system installation on all necessary platforms
Integratability	Ability for this application to easily fit in as part of a larger system (for example, ERP component and others)
Interoperability	APIs (application programming interfaces) required to allow other applications to talk to our application easily. This is unique from compatibility because interoperability is concerned only with the structure and ease of use of the APIs, not the industry standard protocols.
Leverageability/reuse	Ability to leverage common components across multiple products
Localization	Support for multiple languages (German, Chinese, and so on) on entry/query screens, in data fields; on reports ; multi-byte character requirements (such as Kanji and others); also units-of-measure; currencies
Maintainability	Amount of effort required to maintain (and enhance) application in production
Multiple environment support	Need to run multiple environments on a single server (development, system test, user test, and so on)this could mean that the application components can never "hold and lock" vital operating system ports or resources, like a CD-ROM drive or port 8080 to the Internet
Operability	Ease of everyday operation; amount of qualification and training required for operators to oversee and troubleshoot the application
Performance	Constraints in batch (overnight window) and online
Personalization	Ability for individual users to personalize their view of the application (My Yahoo! Style)
Portability	Ability to easily move the application to different hardware platforms, operating systems, database management systems, network protocols, etc.
Privacy	Ability to hide transactions from internal company employees (transactions encrypted so even database administrators [DBAs] and network architects cannot see them)
Reliability	Confidence in the accuracy of transactions processed in the application
Robustness	Ability to handle error and boundary conditions while running (internet connection goes down, power outage , hardware failure/replacement, and so on)
Scalability	Ability to handle a wide variety of system configuration sizes and requirements
Security	General security requirements (encryption levels over the Internet, hackerproofing, viruses, and so on)
Upgradeability	Ability to easily/quickly upgrade from a previous version of this application to a newer version on servers and clients (upgrade scripts versus manual upgrades)
Usability/achievability	Level of training required for users to achieve their goals with the application. Usability requirements need to be treated as seriously as any other architectural issue (performance, availability, and so on). Many applications fail because they are hard to use and nonintuitive.

Ask the users about response time needs, and ask them what annoys them about the way the system works now. The answers will give you valuable leads for nonfunctional requirements. If there is a legacy system, it can be another good source for nonfunctional requirements. Ask users what they liked and disliked about it. Be careful not to confuse business-related gripes with those that provide nonfunctional requirements. For example, "The existing system only allows us to capture three lines of miscellaneous information about a customer." Increasing this length constraint can be documented as a normal requirement. The flow of events would contain the statement "Enter the miscellaneous information provided by the customer (no length constraint)."

These nonfunctional requirements, and many others like them, contribute to the usefulness of a system. For a number of reasons, however, it is common for these topics never to come up during requirements discussions. They are important nevertheless.

TIP:

One way to deal with nonfunctional requirements is to rate their relative importance, numbering them 1 through n .

When confronted with a list of nonfunctional requirements, businesspeople always have the same response: "We'd like them all high priority, thanks!" Even businesspeople who understand that use cases must be prioritized and delivered in stages seem to think that computer applications are magically able to fulfill every nonfunctional requirement without any additional work. As you probably know, just the opposite is true. Nonfunctional requirements, contributing to architectural requirements, often cost more than the implementation of the use cases! A strict performance requirement of, say subsecond response time for 10,000 concurrent users could require such massive architecture that the cost would dwarf what was required to build a few Java programs to implement the use cases.

When businesspeople think about availability, for instance, they assume that having the application up "all the time" is no problem. Essentially, they initially are assuming "infinite availability." Our response when businesspeople make this assumption is to mention that infinite availability will cost an infinite amount. Usually, that is not the price they had in mind. This goes for every nonfunctional requirement. Businesspeople are adept negotiators , once they can understand some general cost parameters around each nonfunctional requirement level, they are happy to trade up and down until there is a solution they can live with. Don't let their initial assumptions drive you into an architectural nightmare.

It is quite likely that there will be multiple nonfunctional requirements in each category. Number the individual nonfunctionals and use the categories merely to add information to the entries.

4.2.10.2 Validate the Requirements

At this point, it helps to recap the functional and nonfunctional requirements and walk through them to test whether they make sense as a group.

4.2.10.3 Document Nonfunctional Requirements

Figure 4.1 presents a template for documenting the nonfunctional requirements.

Figure 4.1. Technical Requirements Template

Describe the requirement, include the exceptions that are special cases of the requirement, and name the use cases that it applies to. Some nonfunctional requirements, overall system constraints, apply to many use cases. It is not necessary to list all of them; instead, write, "Most data entry use cases." This approach spares you from having to write the same requirement for many use cases and makes it easier to alter. You can be more specific later.

Be careful to avoid including assumptions in the nonfunctional requirements. For example, a technical requirement might be expressed as "Back up nightly to tape storage."

The requirement is to prevent data loss, and it describes the frequency of this task. The mention of a tape solution, however, is either an architectural assumption or a technical constraint. Ask the user which it is. If it is a technical constraint, you have identified an additional nonfunctional requirement. If it is not, you risk adding an invalid assumption to your requirements.

Avoid documenting platitudes such as "Each window must have a method of closing it as part of the interface." Such statements do not add value to your use cases, but they may be appropriate rules in the user interface standards document.

Table 4.3 lists nonfunctional requirements for one use case example.

Table 4.3. Manage Property Nonfunctional Requirements

Requirement	Exceptions	Applies to Use Cases
When an offer is changed, this information must be available to all users simultaneously .	None	Making and responding to offers
Other users, and anyone outside the system, must not be able to see details of any transactions being posted.	Authorized system administrators may view the details of any transaction.	All

Nonfunctional Versus System Maintenance Requirements

Are system maintenance requirements different from nonfunctional requirements?

Yes. If you can model a requirement by writing a narrative description of the interaction between actor and system, then it is a functional requirement. Use cases can document any functional requirement, whether it involves maintaining a system or supporting a business process. Therefore, you should not document administrative functions as part of the nonfunctional requirements. A system administrator is another actor, and use cases are an appropriate vehicle to document the administrator's interactions. Write these use cases just as you would any other.

For example, many data- intensive applications use lookup tables to constrain the data. The requirement that the system administrator needs access and can change these tables is a functional requirement. This requirement could be documented in a use case titled Edit List of States with the actor system administrator .

Remember to investigate and document maintenance requirements. Because they are not core to the business, they are sometimes neglected.

TIP:

When you're looking for nonfunctional requirements, refer to standards documents, where some technical constraints and requirements have probably been documented. Many organizations create and maintain standards documents to describe solutions to recurring problems. They can include everything from GUI standards to the software and hardware that is normally used. You should review these documents and become familiar with their contents. When you discover an already defined nonfunctional requirement, simply determine that it relates to your use case and state that it follows the established standard. This fits our principle of documenting only in one place whenever possible.

4.2.11 Start the Business Rules Catalog

Business rules (see Chapter 3) govern how the organization conducts its business, so they likely apply to several or all use cases.

Look for business rules that constrain the construction of use cases for this application. Try to produce at least a few rules in this early iteration, but there is no need to create a comprehensive catalog yet. See Table 4.4 for an example.

Table 4.4. Business Rules Example

Rule ID	Name	Description	Category	Static/ Dynamic	Source
001	Provide discounts for referrals.	If a current customer provides a referral to the company and the referral makes a purchase, the person referring the business receives a $20 discount off future costume purchases.	Inference	Dynamic	Interview with owner 5/7/2000
002	Referral discounts must be used quickly.	If a referral discount has been granted to a customer, that discount must be used on a costume within 1 year unless the customer contacts the company to request an extension.	Structural fact	Dynamic	Interview with owner 5/7/2000

4.2.12 Create a Risk Analysis

Create a risk analysis document in this iteration as a repository for the risks that surface as you proceed through discussions with the users. Chapter 3 describes the format and role of the risk analysis.

4.2.13 Create a Statement of Work

Create a statement of work as a contract to fulfill during this development effort. This document outlines a set of scope boundaries that you and the user groups agree to. Chapter 3 describes the format and role of the statement of work.

4.2.14 Begin Experimenting with User Interface Metaphors

Early in the Facade iteration is the time to begin trying different user interface metaphors for applications that have a substantial amount of human interface. A metaphor is something that the user interface will represent, some tangible organizing mechanism. Some examples of metaphors:

• A neighborhood (Talk City, Geocities)

• A retail store (Amazon.com, Outpost)

• An auction house (eBay)

• A conference room or stadium (eRoom, WebEx)

• A personal calendar and address book (Palm Pilot, Pocket PC)

Metaphors help the users to intuitively move around the functions without having to be trained keystroke-by-keystroke to know where to go. If you have the name of a new contact you've made, you know that you should go to the place marked "Address Book" and then look for something that says "Add" or "New."

However, metaphors can fall apart too. Here's how Alan Cooper (1995), a user interface guru, describes the failed General Magic MagiCap user interface in his book About Face: The Essentials of User Interface Design :

I'm sure it was a lot of fun to design. I'll bet it is a real pain to use. Once you have learned that the substantial-looking building with the big AT&T on its faade is the phone company, you must forever live with going in and out of that building to call people. This most-modern, information-age software drags all the limitations of the mechanical age into the future and forces us to live with them yet again. Is this progress? (page 62)

Interface design is best left to the experts. Hire or contract with a "usabililty analyst" who has knowledge of how to craft user interfaces in a way that is intuitive for people. A lot of people talk about "usability studies" instead of "usability design." A usability study implies that someone will come in after the fact and examine what the technical designers have done, critique it, and be on their way. To us, this seems backwards . Good usability design from the start can create huge savings in user training and can also be the "make or break" between the application being accepted by its users or not. Yes, usability costs money, but if you can find the right usability person (or team) you will receive a very high return-on-investment.

4.2.15 Begin User Interface Storyboards

User interface design usually means creation of storyboards. Storyboards, borrowed from the television advertising world, are large cardboard wall charts with smaller pictures pasted on depicting each "scene." In a television ad, the storyboard may have one scene of the person waking up with the cough, one scene where the spouse is offering his comments, another where the magic cough remedy is consumed, and a last scene where everyone is sleeping happily.

The same pattern applies to user interface (UI) storyboards, which show how a user may navigate through the Web pages or screens to accomplish a goal. These UI storyboards will match the definitions of use case paths, but since the use cases aren't much more than names and descriptions at this point, the storyboards are still just graphic depictions of data entry, reporting, and other functions. It still makes sense to begin the storyboarding effort in the Facade iteration, since there will be a lot of discussion about colors, metaphors, and field placement yet to come.

Again, this is work for a professional. There are specialists who create Web sites and applications, usually called graphic designers or user interface specialists. Make sure that the people you use for this task have some basic knowledge of usability, or there will be problems between the usability analyst and the graphic designer.

4.2.16 Get Informal Approval from the Executive Sponsor

It is doubtful that you'll get your executive sponsor's attention long enough to leaf through a set of partially finished (Facade) use cases at this point. Instead, summarize what you believe are the sticking points: areas that are unclear, fraught with danger, or contentious. Bring these up with your sponsor and create an action item for each one as necessary. This is really all you need to do for this step.