Requirements vs. Design – Does it Really Matter?

By Richard Larson and Elizabeth Larson

This post is an abridged version of an article to be published soon.

Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don’t matter anymore. It is popular – even exciting perhaps – for BAs to think of ourselves as designers, since much of the work we do results in solutions. We don’t disagree with the trend and the main concern prompting us to write this article is to point out the importance of including the “as is” state as part of any requirements – or should we say design – effort.

Part of the impetus for the new design focus has been a strong aversion by some in the Agile community to business analysts or business analysis. Those who feel strongly tend to concentrate on the design aspects of a new product and don’t see the need for much if any actual analysis of the business or business need. (See Tony Heap’s blog its-all-design.com for an example (1). If business analysts are now just designers and we need little analysis, we are moving back to the earlier systems analyst role. This does not always serve our organization well. To say that we don’t need to worry about requirements is missing the essence of what a business analyst can and should be.

Let’s walk through some reasons why the emphasis on design over analysis is an issue. Being only or mostly interested in “design” implies that we don’t care about the “as is” state anymore, as is suggested in recent articles, blogs, and discussion groups. (See David Morris’ article in BA Times (2). Without understanding the current situation, we cannot hope to understand:

• How end-users’ jobs will change with the implementation of the new product or product increment. If we do not know the extent of the change we cannot help workers adapt to the change, which increases the risk of lack of buy-in, unhappiness, and even possible sabotage.
• Which of the issues with the “as-is” need to be addressed. If we implement new processes and systems without curing existing ills, we will lose credibility.
• No new product or solution is devoid of the current state. That means we will have requirements that must be met – not designs – to ensure the new solution contains existing functionality that works and without which the new product cannot perform adequately.
• In addition, most of us work on projects that are not entirely new products, but replacements and enhancements of existing systems or processes. These efforts need plenty of analysis of the “as is” state and its corresponding requirements to make sure the changes we bring will fit into the rest of the business operation.
• Even for brand new products, there are many business rules and decisions that apply across projects and should be taken into account for the project at hand.
• The BABOK® Guide version 3 talks about requirements being the representation of a need and design as a representation of a solution. That is a workable distinction, although it is a bit awkward to talk about “designs” at the same level as requirements. To understand the distinction better, it helps to substitute the words for the process instead of the outputs:
  • Analysis is understanding the needs and requirements and communicating them to the appropriate audience.
  • Design is how new features and functions will be incorporated into a solution, plus maintaining existing requirements that should be kept in the new solution.

The last point is perhaps our biggest concern with the new thinking. The business analysis community has fought for years to keep analysis distinct from technical design. In the end, Elizabeth and I don’t care that fashioning a solution is called design. After all, what is now being called design is nothing different from calling the output of the process “To-be” requirements.

To illustrate our point, consider Figure 1.  The example might be a typical enhancement to an existing system or process. In the traditional business analysis approach, the “as-Is” state is analyzed as a starting point to capture processes, data, and interactions that must be kept for any new solution. Those are “as-is” requirements.

The “current state to be retained” in the “Design” box below are also requirements. They could be processes, data, or user and system interfaces. The design process comes into play when determining how to integrate them with the new features being added. Those new features could equally be called “To Be” requirements as well as design.

Examples of “To Be” requirements (or design if you prefer) include many traditional BA outputs including:

• Process models showing an “As Is” as well as a new business process.
• Data models showing “To Be” data requirements and business rules relating to the relationships between entities.
• Use Case models with interaction requirements and corresponding business rules.
• Prototypes and mock-ups indicating interface requirements.
• Interfaces with other systems.

SUMMARY

In the end as long as we are talking about “logical” design and not technical or physical design, the authors agree with the current trend calling BAs designers. In actuality, BAs have always been designers because we help people conceptualize and visualize solutions that will help businesses meet goals and objectives through solutions. As long as we don’t forget the importance of “As Is” and “To Be” requirements and the part they both play in any solution, then emphasizing design over requirements becomes to us an academic argument.