Why Business Objectives Are Not The Same as Software Requirements

If you ask any IT Manager to name the top five most critical aspects of running a successful software project, one of the items will almost certainly be good software requirements.

Going a step further, if you ask an IT Manager what is the most common challenge they face on software projects, dealing with insufficient or poor requirements will come up.

Given that it is well known that good requirements are critical to a successful project, why do requirements continue to be the most common failure point?

• Many requirements that are created at the onset of the project are written as business objectives rather than true specifications. This means they are too general to use for programming a system.
• The determination of whether requirements are “good” or “complete” is highly subjective.
• It takes a skilled resource who can speak business language and technology language to recognize requirements gaps and ask the necessary questions to fill the gaps
• Project sponsors often are not open to spending money on requirements gathering or design because it isn’t directly tied to writing code
• Deadlines are pressing and the decision makers need an estimate to support business discussions so the requirements are discussed only in enough detail to support a development team’s ability to generate an initial estimate for the project

Getting The Requirements You Need

Here are a few guidelines to consider so that you can avoid common requirement related pitfalls.

Commit To The Requirements Phase

Requirements are really where a software project starts. They set the vision for the software project and describe the building blocks that are needed to build the vision. Without requirements, you will have uncertainty, confusion, ongoing questions and people trying to fill in the blanks with their best guesses.

Although there are software development methodologies that help when your requirements are weak, namely Agile, you are leaving a lot to chance by not taking the time to think through what you want to build at the start.  Good requirements do not negate an Agile process, it simply gives you a better starting point to iterate from.

Go Deeper Than The High Level

Requirements are not goals and objectives. Goals and objectives are great and needed but are too high level if you want to start writing code.

Software requirements and specifications, on the other hand, go deeper. You will find that good software requirements itemize all your users and catalog every task the user need to perform.

Good requirements are detailed. They consider what happens when things go wrong. They also consider the tasks that the system does behind the scenes without a user, and other non-functional requirements like auditing, meeting regulatory requirements, security considerations and performance and load expectations.

Let Your Developer Ask Questions

Give your developer the opportunity to review the requirements and request more detail and clarifications where needed.  A good developer will have a LOT of questions, so this could be a trying process.

Just remember that the questions need to be answered at some point, otherwise the developer will be forced to assume, and may assume wrong. Every question you answer before you code could be saving hundreds of dollars later in the project so grin and bear it!

Get A Skilled And Experienced Resource

Although software engineers like great requirements, they have had very little formal training in requirements writing.  If you are looking for your software developer to write the requirements for you, be sure they are up to the task and have the ability to talk business and technology, while thinking through how the entire system should work and filling in any gaps.

As an alternative to a developer, consider a business analyst, a product manager or a solutions architect to create your requirements. These resources are trained to talk to key business stakeholders and subject matter experts. They can understand the business need, ask clarifying questions and document the requirements with little to no gaps in a way that developers can use and the business can comprehend.

Conclusion

Software requirements are a critical part of the software development process. Poor requirements are one of the main reasons why software projects run over budget, take longer to build than planned, or fail altogether.

Consider spending more time and effort defining your requirements up front, regardless if you are doing an Agile implementation, so that your final software product will serve your business as you intended.