Many years ago I worked for a large corporation and part of my job was to provide training on their requirements management product. Each course I was always asked “does the tool write the requirements for you?”  The first time I heard this question I really did not understand what the student was asking. Trying to answer the student’s question I went through a list of the tool’s capabilities such as the tool captures requirements, prioritizes, provides trace-ability, documents rationonale, captures comments, etc. Then I asked does that answer your question? The answer I received was “no.”  After some assistance from the class I realized the person was asking “does the tool write the requirements for you?” The problem was the student had no knowledge of requirements or the requirements process but was probably requested to take the course since they would be using the tool at some point.

Much has been written about the failures and successes in software systems due to problems with requirements management (i.e.: Standish Group Chaos Report). There are many different Software Lifecycle models (i.e. Waterfall, Agile, etc) that address requirements management in building software. The goal for any software system is to meet the requirements (needs) of the users. In general most software projects have the following problems. Building a system that does not meet the needs of the users (failure to meet the requirements), building a system that does too much (too many requirements), and building a system that is never completed (adding new requirements or modifying existing ones as the project continues). In these three scenarios the only positive is that the project team is employed but the company paying the bill faces increased costs, potential failure in the marketplace, and lost opportunity costs.

Even today I still see a fundemental lack of requirements knowledge. I typically observe the programmer or software team working off their “gut feeling” of what needs to be done. Even when there is a project manager involved the lack of requirements is justified as “we should probably do it but it will slow us down” or “there is no requirement that we have requirements.”  Instead a system is built based on intuition. As development progresses you hear things such as “well we can fix that later” or “we can add that in later on” or “why would someone want to do that.” I have even seen programmers that are upset that someone has not provided them with requirements because without requirements they are unsure what to build.

I think there are many reasons for the lack of requirements. Some people have no exposure to software requirements. For example there are people that start off in one career and end up at some point in a position where they are part of a software engineering effort. A good example might be someone who received a degree in computer security, then got hired in a position as a systems administrator, and then moved on to become a programmer. Second, a 2015 Stack Overflow survey of those who self identified as software developers 41.8% said they were self-taught. To me that likely means they had minimal exposure to software requirements. Third, I looked at the core requirements to earn a Bachelor’s of Science in Computer Science at one large state univeristy. The university has at least two courses that require programming in the Freshman year but does not mention requirements until the Junior year. Finally, I think the company expending the money for the software project needs to ensure that requirements are part of the process. Maybe in the future there will be software that can generate software requirements from a thorough system description but until then we may have to hope for the best in software outcomes.