Requirements are the result of information. The business analyst gathers information, analyzes the information and produces the requirements. In order to have ‘complete requirements’ you must have all the information relevant to the problem and solution, in the correct form, confirmed to be accurate, and without ambiguity or contradiction. This is ostensibly possible.
The problem is that you can never know that you have 'complete information' except in hindsight. In 46 years in the IT business I would venture to say that only once or twice in that time could we say that we had complete information (and therefore complete requirements) when we started coding (very small projects). Most of the time we were in the late stages of testing and still getting new information (and requirements). New information came up when the users actually saw the product. And there were many times when the product was delivered and it was only when the users used the functions or features in their day to day activities that we got the real information we needed (usually resulting in a subsequent release).
We have to accept the premise that complete information may not ever be available.
There is no blame here. No one is purposefully withholding information.. No one is providing purposefully false or contradictory information. Despite many developers (and business analysts) protestations to the contrary, users really do know what they want and may even be able to express it in an understandable fashion It’s just that after they see what we are developing their minds are changed by new information and viewpoints and ideas. There are simply things that we do not know and many times we don't know that we do not know. And then, suddenly, we do. We discover new information in new circumstances and that new information many times renders old information useless or suspect. We call these ‘changes’, and we call those who give us the ‘changes’ something worse. For some reason IT has always expected the business to know exactly what they want and then not waver from that request, despite new information that arises during development.
The Information Gap
In software development and to a large degree in projects in general, we have devised many ways of mitigating the problems caused by the information gap. The agile approaches assume that we will learn as we go. Agile approaches advocate incremental delivery with a new ‘piece’ of the solution delivered every two weeks or so. This provides a continual flow of new information in the form of feedback.
Even in a linear management or waterfall software development approach we have tended to add prototyping to our processes so that the business people could see what they were going to get. And we could get more information in the form of feedback, information we could not possibly have obtained prior to that point. People respond better to a straw man than to a vague concept.
A linear or waterfall approach suggests that if we spend more time up front we can get a very large percent of that information, reducing the need for change, disappointment or outright failure. The agile approach assumes that we cannot get all the information up front or perhaps ever, so why try? Since much of the information is obtained after the product is at least somewhat operational, let's get it working and adjust from there.
Both approaches may work, but management and the project team have to be prepared - appropriate budget, personnel, schedule - for whichever approach is used.
If you are looking for all the information to be present before design or code and you follow an agile approach you will be very frustrated with all the changes and the obvious lack of information that was obtained at the beginning. If you expect to get the information as you go in an agile manner and you follow waterfall, you will be very frustrated with the time spent initially gathering information that you are sure will change anyway.
The Requirements Document is a plan
Requirements are like plans. You could consider the requirements document as the plan for solving the problem or developing the product. (Requirements documents have been referred to as ‘blueprints’ by software development gurus for decades). As much as it makes sense to plan a project, it makes sense to have a plan of the product, as embodied in a set of requirements. However, the famous saying from Helmut von Moltke the Elder: “no plan survives contact with the enemy” applies to requirements as well: “no set of requirements survives contact with the developers (or the users, your choice)”. Similar advice about planning that can be applied to requirements comes from Dwight Eisenhower: “plans are nothing, planning is everything.” Applied to requirements the quote might read: “requirements are nothing, gathering the information and defining the requirements is everything”. In other words, it is the process of defining the requirements that is important and valuable to the project and the organization, not the requirements document itself.
In that case, why bother Documenting?
So, if we cannot really know when we have acquired the complete information and produced the complete requirements, when do we stop? And if the value is in the process rather than the document, what is the purpose of the document?
I am not suggesting that we do not produce hard copy of the requirements in some form: written user stories, feature lists, business requirements documents, or items on a product backlog. There is value in documenting the requirements. However, the document cannot be our primary goal. Solving the business problem is.
The goal of the requirements document, as with any document, is to prove that the process has been completed. A requirements document shows that the requirements process has been accomplished, up to that point. User stories are the result of information gathering and analysis of the features and functions required for a particular solution. In the case of user stories, one might suggest that the requirements process is just starting as the team then discusses and dissect the user story into smaller user stories perhaps and then requirements which may or may not be written down. The same attitude applies to the requirements document: As Alan Davis says, Requirements are “the control point for evolution of the system”, and the requirements evolve as well.
One Irreverent Solution
Since the requirements document is theoretically a complete, correct and accurate representation of the solution, you could always turn the requirements document in after the system goes into production. In contracts we did back in the 90s, we guaranteed that the software we delivered would exactly match the requirements, or the customer would not have to pay. We met that obligation by submitting the requirements when we submitted the completed and approved software. The customers accepted that the requirements document should reflect the installed software and what was delivered at the end might not look anything like what people had in mind at the beginning. So we evolved the requirements as we evolved the system. When we delivered the system, we did in fact deliver a complete set of requirements that matched that system. and we knew for a fact that we were done.
We can’t do that
Steve, it sounds like you are suggesting that we just start writing the software and define the requirements as we go along?
No. It was the requirements document we delivered at the end, not the requirements. In most cases there was a proposal involved or a business case. We wrote all the software support systems for an insurance company in Evanston, IL based on our proposal and an initial overview, and of course our knowledge of the industry in general. The same held true to a degree for a janitorial supply company and for the billing system for a telecom. However, we wrote the system for a prosthetics maker which was a business that was completely new to us, and another system for a company that imported and exported rags. (I didn’t even know there was a thriving business in such things) In these cases, we did business analysis work: we asked questions until we understood the business or at least the problem domain, assembled the information, confirmed our understanding of what was being done and what was needed, and then laid out the solution at a conceptual level. From there the requirements evolved with the system development and were delivered, completed, at the end of the project.
Now, I am not suggesting that you change your approach to requirements and system development. Proposing to your management that you deliver the Business Requirements Document along with the finished system might not win you any political points, if you are not laughed out of the room or placed on forced mental health leave. However, you can start your requirements process with the attitude that you will not have “complete” information about your problem and solution (and therefore ‘complete’ requirements) until the solution is implemented. You can assume additional information will continue to come in while the team is developing the solution and adjust your mindset and your project and software development process to accommodate this fact.
I can see no end in Sight
But how do we know we are done? The normal process is to say we are done when the fixed and approved set of requirements have been turned into code or otherwise implemented and are ready for production. If the requirements are not fixed at some point, when is the project done?
In agile, the answer generally is “never”, but more realistically “whenever”. That “whenever” means, “whenever the money runs out or is reallocated to a higher priority project” or “whenever the product owner (customer) decides that the project is over”. As a business analyst you can determine completeness based on your experience, intuition, and more pedestrian factors, such as a time limit or deadline. You determine ‘completeness’ when you have 'enough' information to concoct a viable solution. Basically the fundamental question that determines that the document is done is, “do these requirements define a complete solution to the problem?”
And when the project is complete, you can say that, except for the changes to be added in the next release (or next sprint), the requirements are complete based on the information you have at this time. Up until that point, you can never really know what you don’t know.
Don't forget to leave your comments below.