Requirements – Executive Summary
Fingers on the keyboard is the fastest way to get a project off track. When writing software, jumping straight into code is almost always the wrong decision. Sometimes we architect-types think we need to start whiteboarding solutions. Starting there is also the wrong decision. What’s more important than either of those is requirements? We have to identify what we intend to build.
Building software often feels like tacking in sailing. When heading into winds, you can’t make progress straight toward the end goal; you must navigate the boat back and forth to make forward progress. When we’re building software we continually make progress toward the goal, but it feels like we are constantly going back and forth.
Building software doesn’t have to be that bad. We don’t have to go back and forth, doing then redoing. But as an industry, we seem to like doing things that way. A classic measure of this is rework, which is the amount of time we spend redoing tasks we have already completed. For many software shops, this can be up to 50% of the time, which leaves only 50% of their time for existing stories.
Rework can bring to mind the dreaded coding errors (some developer writing some bad code). But, in reality, the biggest single reason we do rework is requirements – which are often the source for over 50% of all rework. Requirements matter.
So of course, we want to lock down those requirements super tight right? The problem with a super tight lockdown on requirements is that it is often at odds with the reality that business needs change throughout a project.
We have to have a balance. Ideally, we want to get a good handle of the requirements up front. But we also want to be accommodating of requirement changes. There is a delicate balance here. We want good requirements up front so we can have good plans, but we have to allow for our plans to change.
In our world, requirements are often some sort of user story (e.g., a shopper wants to buy a product). These requirements need to hit the most critical use cases for the system. Ideally, they would include all use cases for a system, but that is often very time-consuming. The level of detail here usually doesn’t require us to define every last inch of the system up front.
Not all requirements are user-centric. Often systems have non-functional requirements that need to be documented because they may impact aspects of the project. For example, a customer needs the system to be hosted in Microsoft Azure. This will dictate which technologies we will use with the system. Knowing this during a project’s early stages will help us plan accordingly.
Requirements are essential before we begin many of the activities we techies really like. Before we start creating solutions we need to slow down and make sure we know what we want to build. We must recognize the direction so we can sail towards it. Hopefully, we can keep the tacking to a minimum.
