The process by which most enterprise software is developed is fatally flawed. There are flaws in any software development process, but in the past 13 years I’ve seen one approach produce more bad software and blow more budgets than any other: r
equirements-driven software development. Thankfully, I’ve also had the opportunity to see the success of an alternative type of process, a process in which user experience design drives what gets developed. This type of process helps teams deliver good software on time and within their budgets.
The Problem With Requirements
Requirements are not inherently bad. On the contrary, it would be impossible to produce good software without gathering requirements and using them to guide development. The real problem is the emphasis that is placed upon them. In enterprise software development, requirements are regarded as a source of truth and a measure of success. Instead, they communicate user and business needs ineffectively and serve as an excuse for mediocrity. Here is the process I see far too often:
Up until user acceptance testing (UAT), everything seems fine to the project team. Once users see what was developed, however, it all hits the fan. If the team is lucky, users might hate it but it will do what it’s supposed to do and it will get launched. Even then, user dissatisfaction will force replacement or changes earlier in the life cycle than would otherwise be needed. More often, however, there are major issues that users discover simply by attempting to do their normal work with the system. These issues stem from missed components of their critical tasks or poor communication and misunderstanding around them.
Technically, these systems meet the requirements as they were specified. However, a system like this will simply not work, and the critical problems identified in UAT will need to be fixed before the system can be released. Where does that happen? In the next phase. This delays the development of new features. In the end, it ends up making the system either more expensive and much later or less functional than it needs to be.
Fortunately, it doesn’t have to be this way.
Use Experience Design Methods to Validate Requirements
Requirements-driven software development fails mainly due to communication issues. Huge spreadsheets of detailed requirements, by themselves, are simply not an effective way to convey what an interactive system needs to do and how users need it to work. What does work, however, is validating those requirements buy cialis online with an interactive prototype.
For all our mental and linguistic prowess, we human beings are remarkably bad at communicating our needs, understanding what other human beings are
trying to say, and visualizing complex systems in our heads. All three of these factors combine to make the typical requirements review meeting a futile exercise. If the team takes the small amount of effort required to visualize those requirements in the form of an interactive prototype (the number of tools that let you accomplish this is staggering), they can bridge these three cognitive gaps and quickly reach a common understanding. Seeing a complex system visualized quickly reveals communication and interpretation errors along with missed requirements and unmet user needs. What you get is a process like this:
Sure, it’s better. But there’s still more we can do.
Use Experience Design Methods to Elicit Requirements
What works even better is using that prototype to elicit the requirements in the first place. But first, you have to split up how requirements are gathered and do it iteratively. It looks like this:
When you understand what the business wants to accomplish with a system and who will be using it, you can gather high-level business requirements while another team member conducts user research. I differentiate high-level requirements from detailed requirements based on granularity:
Users need to learn a patient’s demographic information during Task X in order to move on to Task Y.
The system must display patient demographic information on the Validate Coverage page.
The system must integrate with System X to support Task A.
Populate the Demographics section of the Validate Coverage page with data from the System X table [PT_DEMOG]
A high-level requirement is somewhere between a feature and a detailed requirement. It describes something critical to making the system functional but leaves out the detail. The detail comes from designing the system, prototyping it, and getting feedback on it from end users. For example, the existence of an independent “Validate Coverage” page is not something that is implied in the high-level requirement. It could have been a separate page, a pop-up window, a table on another page, or anything else.
There is a school of thought that says details like this don’t belong in requirements at all. Frankly, I agree. The point of this philosophy is
to isolate the need from the solution so the solution can be developed such that all needs are balanced with one another. But because people have so much trouble articulating their needs, it’s hard to identify them all without giving them something to react to. Besides, people have even more difficulty articulating how their needs must be met. The sad reality I’ve seen too often in enterprise software development is that requirements are the source of truth. If it’s not in the requirements, it doesn’t get into the UI specification, and it doesn’t get developed. This is especially true when there is no one on the team with specific design expertise.
Those who subscribe to this philosophy are often hesitant to show anything to end-users before things have been finalized. They don’t want people getting attached to a design that might not make it to implementation, which is understandable. There are two components to
overcoming this problem. First, set the expectation before users see anything that what they see will definitely change. Second, when the design is about to be finalized, update the prototype and test it with these same end users. Let them know that this will happen when you show them the first prototype.
A high-level requirement articulates a need that feeds the design process. For example, let’s say the high-level requirements and user research suggest the need for the “Validate Coverage” page mentioned above. A designer prototypes the page and tests it with users, which allows the team both to validate that it the page is useful and to identify some missing information crucial to the process: users need patient demographic information when they are validating coverage. The designer revises the prototype and presents it again, validating the new design.
In this example, the prototype helped the team validate the design before the coding started. In addition, it uncovered additional informational needs for this task, making the design an input to the detailed requirements. By starting design early, the team managed to paint a picture of what the system might actually do, and get important feedback that made the requirements better.
What are your enterprise software design horror stories? What solutions have you come up with to get through them?
Cartoon faces courtesy of the Memebase Rage Builder and the internet, relentless meme machine that it is.