Why software requirements development matters

In the cloud or in the data center, few organizations realize just how critical the step of developing requirements is to the ultimate success of a major software purchase. At the start of a software selection process, most people have only a very high-level idea of their needs. It is the act of looking at potential products and seeing what they do that helps them flesh out those needs in greater detail.

Those requirements are the foundation upon which success is built. Just like a building, if the foundations are inadequate, anything constructed on top of them will ultimately suffer serious problems or an outright failure. Developing requirements in enough detail takes time, effort and a robust process. If an organization is unwilling to spend the time and money to do that upfront, the project is doomed from the start.

Discovering requirements

The first step is to gather enough requirements in sufficient detail. It is important to realize that any requirements not found at this stage will be found during implementation. If they can’t be satisfied out of the box, the implementation consultants will attempt to meet them by configuring the software. If that is not possible, they will look at add-on modules, third-party products, writing code or business process re-engineering. All of this takes time.

When too many new requirements are discovered, implementation schedules slip and costs go through the roof. When time constraints mean requirements are not satisfied, there are pains like business disruption, unhappy users, and unrealized savings.

The key to solving the requirements problem is understanding that, for any given type of software, every organization has essentially the same requirements. The difference between organizations is expressed in how important the individual requirements are to them. The source of the requirements does not matter; what does matter is that they are captured. Knowing this frees you up to use requirements from any source. You usually start by asking users, but in practice we have found that few users have much idea of requirements beyond their pain points. You can also scour the Internet for RFPs or purchase libraries of requirements.

Examining potential products and rewriting their features as requirements (called reverse engineering requirements) is how unknown requirements are discovered. For example, a client in the civil engineering space was selecting project management software. Their eyes were opened when they saw how well several products worked with smartphones, and how much time this would save their project managers in the field. It was just something to which they had never given much thought.

As you build out the master list of requirements, pay attention to the quality of those requirements (i.e. how well they are written). Well written requirements are unambiguous, and have examples that provide context. Poorly written requirements waste time and lead to inconsistent results.

Evaluating importance

Once a comprehensive list of requirements has been assembled, the next step is to evaluate them for importance to the organization. This step is where the various teams consider each requirement that is relevant to them and decide to whom it is important, how important it is and why it is important. This information is captured on each requirement. When the team members see their names and comments written on the requirements, they feel the organization is listening to them, and this builds tremendous buy-in to the project, especially with the lower ranks in the organization.

While this buy-in is a significant contributor to the ultimate success of the project, it is the act of deciding how important requirements are to the teams that helps them fully understand their needs. In going through this exercise, several Finance executives have said to me that they found this very valuable because it forced them to think through issues they otherwise would not have considered. A thorough requirements analysis is the critical step that helps the organization fully understand what they need. Of course, for this to be effective the requirements must be comprehensive, and cover all usage areas in sufficient detail.

Why developing requirements is so important for major software purchases

Developing a comprehensive requirements profile allows you to select the best fit software for the organization’s particular needs. Even more important, the act of taking the various teams through the requirements rating process allows the organization as a whole to understand what they really need and why they need it. It is this understanding that is critical to the success of the new software. Those people who take shortcuts with this foundational step take unnecessary risks for their organization and their careers.