In a 2011 study (Critical success factors for software projects: A comparative study), requirements were deemed crucial for the success of software engineering projects.
Academic Journals - Scientific Research and Essays - critical success factors for software… - Although there have been studies completed on the critical success factors of software projects, these studies all have…
The study identified 43 studies published between 1990 and 2010 listing the critical success factors for software projects. Requirements and the ones where requirements play a crucial piece are listed below, with their ranking defined by how often they were mentioned:
1. Clear requirements and specifications (60.5%)
2. Clear objectives and goals (55.8%)
3. Realistic schedule (53.5%)
6. User/client involvement (46.5%)
8. Realistic budget (44.2%)
10. Frozen requirement/Requirement stability (39.5%)
So, as we can see, directly or indirectly, knowing what we are trying to support is crucial.
Requirements bridge the problem and the solution
I hear it a lot: Focus on the requirements before the solution. However, many people take that the requirements are the first thing to be understood. It’s not.
The requirements are precisely what they mean. A set of characteristics the software must have to solve a problem. Therefore, we need to understand the problem first, which requires understanding how the business work.
To define the solution, we need to understand the requirements. To define the requirements, we need to understand the problem.
Understanding involves agreement
What we want is to make building software simple. That means we need to define how we are building it (X-axis) and what we are building (Y-axis).
I want to explore this topic using an epistemological approach. So I’ll present you the Toulmin model of argumentation:
A requirement can be seen as an argument because it claims to support a specific business process, solving a problem. In the example above, we could write the requirement in many forms based on the initial claim statement. E.g.:
“The system should not allow a researcher to plan a research using animals for testing.”
If we ask why the immediate answer could be: “Because animals die in the process (from the data) and that testing on animals is cheaper than the alternatives (from the backing).”
So, a solution would be to create alternatives cheaper than animal testing, right? Or improve on the existing ones.
Since it could reduce the final price of cosmetics, wouldn’t it be a better solution? It would make cosmetic products available to a broader public and benefit medical treatments that are not lifesaving.
But let’s say we didn’t ask anything and proceeded to implement the ban from the initial claim. We would cause a big problem in potential lifesaving medical treatments because we didn’t care to learn about the business.
Understanding the business is crucial to understand the requirements.
By asking why the requirements are the way they are, by understanding the business, we can AGREE with the requirements, not just ACCEPT them, which will help us define the best technology, processes, etc., to determine the simplest/best solution we can.
In this analogy with Toulmin’s model, the rebuttal is when business people (business analysts, product owners/managers, etc.) sometimes feel that engineers are pushing back, while we are just trying to get more contextual information about how the business works. It’s only after understanding the business that we can identify restrictions, edge cases, exceptions, business rules, in general, to get to a final claim (refined/detailed requirement).
The armory case
A few years ago, I took over as a requirements engineer and architect on an ongoing project running extremely late.
The software would be used in the police armory to automate the registration of which officers were checking out weapons and other equipment.
When I took over, one of my first actions was to ask who the requirement providers were. That’s when I found out that it was the clients (administrative workers at the police), and the actual users had never seen the software.
So, I took it over to them on a laptop to experience it firsthand. They would select which equipment, one by one, they were giving to the officer, who was the officer (who would authenticate with their fingerprint), and confirm. The whole process would take about 5 minutes.
That’s when I asked: are there peak times when you have many officers here waiting for their gear? The answer was: yes, sometimes 150 of them at once.
Well, 150 officers X 5 minutes each = 12h 30min. That was how long the line would be if just one officer was operating the system (and guess what? most of the time, there was just one).
This would happen when they all had to go out together, for instance, to provide coverage for an event. In these cases, all of them would get the same gear.
We went back and designed packages of gear to be assigned to the officers. The packages were normally pre-assembled before the event, and accounting for this in the system reduced the processing time to 1 minute only. Now, 150 officers would take 2h 30min to be processed. The previous process requiring them to write down and sign on a notebook took about 2 minutes.
Understanding the business is crucial to agree with the requirements and provide a proper solution.
If you had any experience building solutions around requirements that did not inform the business problem being solved, sound off in the comments!
If you like this post, please share it (you can use the buttons in the end of this post). It will help me a lot and keep me motivated to write more. Also, subscribe to get notified of new posts when they come out.