4.1 Objectives

The first iteration in the requirements lifecycle is the Facade iteration. Its purpose is to create placeholders for each major interaction you expect the actors to have with the application.

A Facade use case contains only the minimum information needed as a placeholder, including a name and short description of the interaction. It also identifies the initiating actor and other actors. Executing this iteration is difficult because you may not yet have a concept of the application. For this reason, the team will do its best work if the environment encourages openness and creativity.

The Facade Iteration

As you develop a definition of the proposed system, you can call on the following sources for ideas and opinions :

• Users

• Project team

• Industry experts

• IT management

• User management

• Owners of the data

4.1.1 Users

The users have the major influence on the definition of proposed system interactions. They are the focus of the new system, and their input and buy-in are critical.

However, as anyone knows who has been through requirements definition even once, the users cannot tell you the whole story. They are not equipped to define fully what the new system should do. Why? First, the new system is probably not being created merely to automate an existing system. Many new business processes, perhaps not yet built, will dictate the system interactions. In addition, the users often know their domain so well that they assume that most of what they do is terribly obvious. Alternatively, they've been put into their current role recently as a result of organizational restructuring, and they haven't had time to become familiar with their environment. One department in an oil and gas company for which we worked had a 110 percent annual staff attrition rate, so relying solely on the users was not possible for that development effort. In any case, the requirements-gathering team has its work cut out for it.

There's another issue. If you don't have a subject matter expert (SME) on your project team who knows this domain as well as a user, your team will not have the opportunity to "read between the lines" of what the users tell you. You need to make these kinds of inferences to identify better, faster, cheaper processes and to recognize the vital pieces of the puzzle that the users have left out ”omissions that will come back to bite you in three months' time. SMEs are often ex-users themselves , or they may be IT people who have specialized in an industry and have a number of system implementations under their belts.

4.1.2 Project Team

The project team, too, has input into how the user-system interactions should occur. After all, the team is responsible for the work! The project team should have a focus on setting standards for interaction, maintaining scope, making inferences from user input, and documenting, storing, and indexing the requirements. The major guiding force behind these interactions should be the users and the SMEs on your project team. The task of the rest of the team is to transmute these models into use cases. The users provide the information on how they do things now and what they would like to see changed, and the SMEs help to shape the system into more refined, elegant, and profitable processes.

4.1.3 Industry Experts

The challenge of the project team members is to take user-centric information offered by computer industry experts and luminaries and to determine whether it applies to this situation. Industry experts can provide only rules of thumb, and rules are meant to be broken. Determine your position on the industry "advice-of-the-day," and if you decide to deviate from it be prepared to defend your position. Whatever you do, don't simply follow the experts blindly. Unless you believe in your direction, your project won't work.

4.1.4 IT Management Group

The IT management group always has opinions on how the interactions of the system should be described. If you are a member of the in-house IT group, you must balance these opinions with the user needs and wants. If you are an outside consultant the same balancing act is required, but sometimes it is easier being a third party. The IT group can provide valuable input regarding systems that have been developed previously, interfaces between user departments, previous incarnations of this functionality, and other contextual information.

As with user input, you should be cautious in weighing IT viewpoints. IT staff (yes, this means us!) have a strong tendency to push requirements gathering into something that is technology-centered. Technology-centric solutions have no place in this early activity of system development. It is dangerous to commit an application to a specific technology or to focus more on the technical implementation than the needs of the users. This practice leads to systems that fit neatly into technology niches but are lacking in functionality or may even deliver functions that are not required. It's easy to fall into the technology trap, especially for someone who is steeped in technical know-how. At this stage, there should be no discussion of technical solutions, only a focus on business solutions. Technical solutions enter into the picture during systems analysis and design, which are the next activities of the lifecycle.

Requirements analysts need to wear blinders to avoid thinking about the various technology options.

User-Centric Versus Technology-Centric Solutions

User-centric solutions focus on what the user needs. All requirements that drive the development of use cases come from actual business needs of the users. This principle applies to the entire development cycle and not just requirements gathering.

Technology-centric solutions focus on using the "technology of the hour " for whatever business problem might pop up. Applying a technical solution ”whether a new programming language, operating system, architecture, partitioning scheme, or methodology ”becomes an end in itself rather than a tool. It is sometimes a fine distinction, but it is possible to tell the difference.

We're not saying you shouldn't try out new technology to solve business problems, but when you find yourself adding features the user didn't request simply because your new tool supports them, you've crossed the line into a technology-centric approach. By the same token, when you are trying to convince the users that they should not want a feature because your favorite tool doesn't support it, you are being technology-centric. When you start making up business problems so that you can use your new techno-toy, you are also being technology-centric.

Our best advice : Start user-centric and never lose that focus. The time to start deciding how to "make it happen" is during design. If there are critical requirements that can't be fulfilled, decide then to take them out.

4.1.5 User Management Personnel

User management personnel are involved in the major decisions for the application's life or death, so it is important to try to involve them early and often. They need to know of major changes in the project's scope and should be kept up-to-date on major decisions that are made throughout the life of the project ”for example, whether to use distributed updates or centralized updates.

4.1.6 Owners of the Data

The users of the proposed application may not be the owners of the data ”that is, the people who are responsible for the integrity of the data in the database. From a technical standpoint, of course, the database administrators are responsible for data integrity. But from a user perspective, there may be an administrative group, such as an audit or finance group, that is responsible for seeing that the data is accurate and current. Whoever they are, they will also want input into the requirements and should be involved as much as possible.