10 Tips for Better Requirements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Eliciting, elucidating, organizing, and prioritizing requirements for IT application design can be difficult. People are willing enough to express their wishes for the application, but what they say is usually incomplete, sometimes rambling, and often inconsistent. My book Designing the Requirements: Building Applications That the User Wants and Needs contains a comprehensive discussion of how to develop a solid set of requirements. For this article, I've selected 10 of my top tips to help you on the right path:
- Understand the ultimate objectives.
- Look at both a data view and an activities view.
- Understand how the application supports business processes.
- Understand who is affected by the application.
- Work transparently and engage a wide range of views.
- Remember that it's easier to criticize than to design.
- Make sure that you understand existing applications and business practices.
- Don't forget security.
- Understand time and money constraints.
- Analyze the requirements.
The following sections discuss each tip.
Tip 1: Understand the ultimate objectives.
Imagine that you've been asked to explain to the board what an application does for your organization. Your explanation must take no longer than one minute. IT applications come in many varieties, but the vast majority are helping, not doing; they assist people in their regular business activities but don't actually perform those activities for them. In other words, the application is part of a greater whole. If you're describing this kind of application to the board, the key point they want to hear is how the application will improve business operations. What will the new application do to change existing business activities? If the answer is nothing, because the application just analyzes data, the board will want to know how the application will help users gain new insights that lead to better business results. How do you move from "This is a pretty diagram" to improving business behavior?
When you've explained the application's purpose and the reasoning behind it, the board will want to know whether you've considered other ways to achieve the same objectives. There usually are other ways, so what's special about the chosen approach that made you select it?
Objectives for large complicated projects are often very simple. For instance, a government might decide that it can provide better health services by developing an application that helps hospitals and health clinics to share health records. You can see the advantages—knowledge of complicating conditions such as allergies, saving time by not having to take health histories, and quicker diagnoses. But the ramifications of expense, privacy, and how to standardize data formats are immense.
There is a big step from high-level primary objectives to all the requirements that need to be implemented by an IT application. Don't become lost in the details. Always keep the primary objectives in your sights.
Tip 2: Look at both a data view and an activities view.
Existing ways of expressing requirements—for instance, use cases and storyboards—tend to focus on what we expect the application's users to do. It's an "activities" view. But often the role of applications in business—and in many other areas—is simply to store data and make it available. So another way to look at an application is from a "data" view. A data view comes from investigating questions such as where the data comes from, who needs it, its purpose, and how to ensure that the data is accurate.
To develop a data view, it helps to think about the relationships between data and external objects or people. Some data, such as customer details, records information from the outside world, such as the customer's name and address. There is always a possibility that data is inaccurate; for instance, a customer may have changed email addresses without telling you. You must know what data in the database is inherently unreliable, and design accordingly.
Tip 3: Understand how the application supports business processes.
Business processes are often drawn in diagrams with a rectangle for each activity, a rhombus for each decision point, and lines representing paths. Such designs are great for showing how all activities work together to achieve the outcome, but less helpful for pointing out how IT applications support the process.
An activity can be entirely automated at one extreme and the work of several people at the other. Often an IT application records that an activity has started and when that activity has finished. A line between activities sometimes indicates a delay (for instance, when work is passed to a different team), but at other times no delay—especially the line between an activity and a decision.
You need to know what data is generated by each activity, as well as how data is created by one activity and picked up by another (reemphasizing my earlier point about understanding the data view).
Tip 4: Understand who is affected by the application.
Think of an activity in a business process; for example, delivering an order. Some people are actually performing physical work: loading a truck, driving to a customer's location, unloading goods, and so on. Other people manage the workers. Together, these managers and the workers are some of the obvious users of a delivery-management application.
But applications must also cater to people working in "follow-on" activities; for instance, the delivery process itself relies on data generated by the warehousing picking-and-packing activities. Finally, some people might want to look at the data analytically and ask questions such as whether the company needs a fleet of bigger trucks. You need to design not only for the direct users of the application, but also for the indirect users of the application.
Tip 5: Work transparently and engage a wide range of views.
Tip 4 raises another question: Are you talking to all the people who are affected by the application? In some cases, obviously not—for instance, you can't talk to all the customers of an online banking application; sometimes you have to rely on their representatives. But even when potential users are readily available, it's easier to talk to just a few of them. Sometimes you might be encouraged to talk to just a few, such as when a business manager wants to use the application to push through a change that's not universally accepted.
Try to resist such temptations. Everyone who is affected by the design should be informed about it and have an opportunity to give input. Not only will this approach lead to a better application, but it will prepare the way for having the application accepted by the whole organization. To some extent, rolling out a new application is a sales exercise; sometimes you have to convince people that the application is worth using.
Tip 6: Remember that it's easier to criticize than to design.
Even if you're talking to the right people, sometimes when you ask for input they won't know what to say. People often find it difficult to "think up" requirements; when they do, they often have a design at the back of their minds and they're not telling you about it.
The solution is to present a design early and let everyone tear it to bits. This strategy achieves two goals:
- It makes competing visions for the application visible, because multiple stakeholders will tell you to change the design—usually in mutually incompatible ways. Thus, you can resolve conflict early and set proper expectations.
- Because critical faculties are often more finely tuned than creative faculties, stakeholders will quickly tell you what's missing.
Tip 7: Make sure that you understand existing applications and business practices.
When you talk to stakeholders about a new application, they're likely to assume that everything in existing applications will be carried forward. They'll tell you about new features they want, but forget to tell you about existing features on which they depend constantly. You must understand fully all affected existing applications and how the stakeholders use these applications. (In the process, you'll probably find out that some features of the existing application aren't used at all.)
Tip 8: Don't forget security.
A common assumption among IT developers is that security is a technical subject best left to geeks. Clearly, the requirements should identify the different user groups for the application and define what data they can see and what functions they can use. Unfortunately, this step is often done sloppily, which is a shame because thinking about each user group's needs is an important check for ensuring that the application design works well for all users.
In addition to meeting user access needs, security should be considered early in the design process because you need to document a threat model for the application. The threat model tells the security designers what kind of threats you fear and the costs of a security failure. In particular, security designers need to know whether you expect external threats, or the danger is from within the organization. The threat model is important because it helps the security team to develop a solution that is commensurate with the potential threats.
The threat model also might lead you to question other aspects of your design. For instance, perhaps you listed disclosure of personal data as a threat. In the process of documenting the threat model, you might find that the rest of the design happily allows many different user groups to access personal data. Perhaps you need to find another solution.
Tip 9: Understand time and money constraints.
From the perspective of senior management, one of the major bugbears of IT application development is that designers seem unable to factor in time and money constraints. This is true partly because IT application developers are not good at estimating development time and costs (though we won't get into that discussion here).
Often, management would like something developed faster, with fewer features. A key fact to know is this: Assuming that development takes x months, what's the maximum value of x after which development is not worthwhile? Costs involve a similar question. When you're establishing the requirements, you need to include these indications of time and cost boundaries. The application developers may say that these numbers are impossible (hopefully earlier, rather than later). As a general principle, you should never sacrifice quality, but if time or cost constraints are too tight, you can look for ways of reducing the number or complexity of features, staging the features over multiple releases, or redesigning the business approach.
Tip 10: Analyze the requirements.
The requirements for an IT application are part of a design for new business practices. You should analyze this design for completeness, consistency, and meeting the objectives of the application. For instance:
- Completeness check: All data records must be created somewhere and used somewhere.
- Consistency check: Data records are created before they're used, and the application holds the data users need to do their jobs.
- Meeting the objectives: The application does what you told the board it's meant to do.
Final Thoughts
All these points are discussed in more detail in Designing the Requirements: Building Applications That the User Wants and Needs. My fundamental message with both these tips and the book is this: Instead of passively "gathering" requirements for IT applications, we need to design business solutions supported by IT.