Table of Contents
Introduction
“Not knowing the full requirements is agile“, an old boss of mine told me in the past. As soon as I heard it, I freaked out! I couldn’t believe it! I was so frustrated that I don’t know how I managed to keep my mouth shut! Lacking functional requirements is a recipe for disaster. A way straight to hell. You can’t build a system if you do not know how it works. Agile doesn’t alter the need for functional or other requirements, but it does change how you gather them. The waterfall way is to go through a long process of documents filling and revising them, till they contain all(?) the system’s requirements. The agile way to gather requirements is to specify the requirements for a small increment of the system, a minimum viable product as it is usually called, build it, then get feedback and work on the next increment. No matter the way the phrase “I don’t know” is embraced, it should never be acceptable! Without the right context anyone might understand anything!
The analysis before the (software requirement) analysis
The software development process is usually misunderstood, due to the fact that is intangible and people think that is easier to develop it compared to a car or a smartphone. Yes computer science is not an exact hard science, but this doesn’t mean that a roadmap is optional, that constraints do not exists, that everything can be changed at any time! The client must have a clear vision of their product, the market, the customers needs, ways to persuade the masses to buy it, instead of a competitive one. If the client is usually one person, things usually tend to be more straightforward, unless you have a megalomaniac entrepreneur (or “entrepreneur”). What if the client is a company? An organization? Even a group of people in the company your work for? Do they have a clear vision, or the knock your door with a huge “maybe” on their forehead?
Some potential clients have the capability to do a marketing or any other strategic research and analysis by their own. They own the resources, the people to define a new software product and discover a market to sell it. But not all of them. Those who can’t, assign, probably, this task to external consultants that this is actually their job. Sometimes even software houses run the business analysis for the client. But no matter who does the analysis and for whom, in the end, the following questions must be possible to be answered:
- Why this certain digital service or product is needed?
- What is the goal and project objective?
- Who’s going to use the new product or service?
- Where does the data for the system come from?
- What type of data we will be dealing with?
- What other systems should be integrated with your new product or service?
- What part of the business infrastructure the new system or service will be? Is it the core service, supporting instrument for employees or customers, marketing tool, etc.?
If the potential customer, or anyone responsible, can’t answer the question above, then no decent software will be built. If these questions are answered, then we can proceed to the software requirement analysis.
Software requirements analysis
There are huge volumes of books that describe the software requirement analysis techniques. But in simple terms the software analysis process is to understand in depth what needs to be developed and why. Requirements analysis can be a long and exhausting process that social skills are needed a lot. Especially if the domain is a complex one, like the medical, pharmaceutical or space domain. These domains don’t accept deviations, they don’t forgive any mistakes, and every piece of information matters a lost.
Do we need to have all the requirements well defined as soon as possible? No. But we need to define a MVP product based on adequate, well defined and solid requirements. However making any project plans like nothing is going to change in time is wrong. If one thing is constant are changes. But changes while you have answers based on the questions above is one thing, the client not knowing what they want and changing the requirements again and again is another. Always keep in mind that corrections are part of the process. Some features will be refactored, improved, rewritten for sure.
How many requirements changes are acceptable?
If I had the answer to that question I would be a millionaire. But before asking that question, make sure that the client group understand the impact of changes. Any change in the software system, means that extra money and manpower have to be invested against the deadlines. And the deadlines can’t be pushed further to the future forever.
On older formal methodologies, if something changes after the analysis phase there are processes to handle those changes. There is a lot of literature on this, but the problem actually relies on the fact that it is very bureaucratic and time-consuming. Also, people tend to react negatively to changes. We are not properly trained to handle requirements changes. For big projects, software changes make, usually, sense, but for small or medium projects tends to be an overkill if it they happen too often.
In Agile methodologies, you have a product owner that will probably create one or more stories on a board of those updates. So what? But what if those changes need one month? Or two? Is the period accepted based on the budget policies? The release to market timeline? Will four of five sprints be invested in those changes? How the Agile process will the save the day? Well it probably won’t! The goal is never to come to a point that any change in the requirements would be so much against any other business parameters. If this happens then any wrong doing happened in the past, not now that there is requirements change request.
More than meets the eye
Software requirements are never just a way to tell you how the system should work, or which are the system’s limitations. Software requirements must be taken under consideration accompanied with the financial, time and other business parameters.
The goal is to elicit a set of clear and concise needs related to what the client desires. Transform these needs into verifiable requirements. Is these requirements can’t be verified, there is no need to move any further. Several steps are necessary to understand the maturity of needs and to understand how to improve upon that maturity. It is important to identify all the stakeholders, take into account all their needs and ensure they understand any implications. The communication must be transparent and honest. Talk to as many people as possible from the client group. See the their faces, their reactions, evaluate their answers. If they dodge the questions or they try to oversell their idea, they don’t worth your time. Lack of requirements actually means lack of well planned, transparent, honest, formal communication.
If, in the end, those requirements can be verified, then they need to be even more clarified and translated into more engineering-oriented language. There are various techniques to achieve that. Some of them are listed below:
- Structured brainstorming workshops
- Interviews and questionnaires
- Technical, operational, and/or strategy documentation review
- Simulations and visualizations
- Prototyping
- Modeling
- Feedback from verification and validation processes,
- Review of the outcomes from the system analysis process (ISO/IEC 2015)
- Quality function deployment (QFD) – can be used during the needs analysis and is a technique for deploying the “voice of the customer”. It provides a fast way to translate customer needs into requirements. (Hauser and Clausing 1988)
- Use case diagrams
- Activity diagrams
- Functional flow block diagrams
Conclusions
IT projects have been around since the 1940’s. Identifying requirements has always been difficult because it requires nearly the perfect momentum of the right processes, the right people for the business problem to be solved, sometimes even before it is even defined, and an environment that is useful for making all of the parts work together. The factors driving the people are typically the most volatile and least controllable of all of the variables within the requirements process. People have a serious impact on the vagaries of requirements. All of the strengths and weaknesses that individuals and groups bring back the table will influence the ultimate requirements product. A few of the more intractable contributors to requirements variance are: Lack of experience, communication, organizational politics.
Two types of experience are the most important to this discussion. The first is whether or not participants have knowledge of domain space from a business perspective. Without that, needs will not be practically addressed. The second category is experience related to the requirements process itself. Without experience gathering, recording and managing the requirements process, it will be difficult to ensure that any information gathered is correct and that the results developed will be apt to be more costly than necessary. Human nature can act as tool to focus or redirect the process. There is a natural tendency for groups to define the solution before even defining the need. This can lead to a number of communication, and not only, issues.
In the end software requirements analysis is more a good understanding of people’s characters rather than the knowledge those people have! I have made many mistakes in the past trusting the wrong people while I had to define requirements. Nowadays I am stricter than never before in the past. It is better to be safe and away from a toxic project than sorry later.