In my work I see software teams take unneeded risks when it comes to building interfaces. Do you recognize any of these?
- Spending tons of time on the look and feel of a user interface at the expense of other requirements
- Ignoring or deferring system-to-system interface requirements until the design phase or later
- Confusing which system "owns" the interfaces, creating delays in critical, cross-project planning
- Segregating interface requirements from analysis models
You can imagine the results. You end up with redundant, conflicting, or missing requirements, and therefore heightened risks, delays, overruns, and even project failure.
Many of these problems stem from a single cause: failing to analyze your product's interfaces before you design them. So, what's the difference between analysis and design?
Interface analysis explores, identifies, models, and specifies the user and software requirements needed to support connections between your product and external components. It is the "what" of interfaces. In contrast, interface design focuses on the "how." For most of us, figuring out the "how" is what we like to do. It's like a technical puzzle, and solving technical puzzles is what we're good at. But it's a mistake to dive into problem solving before you conduct a rigorous analysis of which problem you need to solve. More formally, before you worry about design, you need to validate that the interfaces you have in mind satisfy the business goals.
Which Is Which?
The key is to differentiate analysis results from design results. These may vary by project, methodology, and availability of resources. Here are a few examples:
Good interface analysis boils down to a few best practices. Let's take a look at those practices.
The first step in interface analysis is to understand the system's boundaries, and a best practice is to build a model. For example, a context diagram shows interfaces as arrows between the system and the external components (people, other systems, hardware). With this knowledge, a project manager and an analyst can begin discussions with the representatives or owners of the components. The goal is to reach an agreement on which interface elements should get priority and how to budget and schedule the work.
Integrate, Integrate, Integrate
Analyzing before designing helps you avoid putting all your eggs in one basket. You can do this by building models, which you should start within the first weeks of a project.
Building models with multiple views, such as dynamic, behavioral, structural (data), and control (business rule) views, gives you different perspectives that help you discover and cross-verify requirements. All these views may be integrated with interface requirements in some fashion. For example, data appearing on a customer's UI window may also be summarized in an executive report, and even sent to another application via a system-to-system interface.
When you elicit and define the system's business and temporal events, you uncover triggering interfaces as well as interfaces that are part of the system responses. (See my related column, " Events to the Rescue .") You can create stories or use cases to understand the behavioral requirements of various interfaces.
Of course, everybody loves prototypes. They give you a picture that's worth a thousand words. But most prototypes don't uncover the user requirements that lie behind the scenes, such as requirements about data and business rules. For that you need the other views.
Budgeting Benefits From Interface Analysis
Estimating project costs is often more art than science. Yet understanding the costs may help the business side more effectively prioritize the requirements. You can improve your estimates by knowing the number and types of interfaces early on. Keep in mind