Requirements are not a thing of the past.
As a Snr Programmer, I have to wonder why so many projects are started without any real consideration to Business and Technical requirements. What I don’t wonder at, is the number of these projects that fail because of this very reason.
I suspect that many think that if they are using Agile project management, that requirements are not needed and are part of the past, but they cannot be further from the truth if they try.
As such, I’m going to go through what Requirements are and why they are needed. This is for those of you who don’t even know what I’m talking about, as well as those of you who make minor attempts at requirement gathering.
Business Requirements
For those of you of a technical frame of mind, you might look at this title and shudder, but its really the start and sort of the most important part of the requirements gathering.
Business Requirements detail the place in the world where your app or system will be placed and the requirements for it to be put in that place. You need to keep technical specs out of this.
Lets start with an example project. You want an App that will create meal plans for those following a selected diet. What are the business requirements for this.
Well firstly, we need VERY precise details on the diet. A vague idea of how the diet works is not good enough. If its based on calories, then you need to have formulas that calculate calories, and others for dealing with nutritional facts. These are are elements of your business. If you don’t have these marked out in detail, how can any project properly work. It’s not something you can decide on later.
Next you need to have content, or a pathway for content to be created. In this case it will be meals with their nutritional facts. Such a system is about working out what content is to be delivered to the client in what order. Thus content or a plan to get the content is a MUST. Its not an after thought.
Next you need to have formats for how your meal plans will be laid out. This is not a system requirement, its a business one. Its not down to a coder to decide how many meals and snacks a person can have a day. This is part of your business.
Marketing Content. For your business to work, you need branding and content that supports your branding. FAQ’s descriptions, images and logos, colour schemes. None of this is part of the technical specs. Its clearly the business side. It is however one area I see a lot of projects failing on.
Acceptable Accuracy values. A part of any business dealing with data will be the accuracy of the data provided. If you are using LLM (GenAI), what would be an acceptable failure rate. Generally LLM’s don’t have a high accuracy rate, and there.
User Requirements
These will be a set of requirements that will be expected to me met for from the Users Point of view. For example, being able to answer a set of questions about themselves that will be stored to calculate their nutritional intakes.
The Ability to Change meals in a plan that are not acceptable to them.
The Ability to have a shopping list created so they can use this to buy ingredients.
To have an interface with a choice of languages.
To be able to register via Google or Facebook.
To make payments via Paypal or card
Technical Requirements
The business and User requirements will define a shape for the application to be built, but not how the application will be built.
The Technical requirements will define the technical stack to be used, server sizes needed, databases, database models, Frameworks used etc.
Items such as response times will be part of the User and Business requirements and the technical requirements will be expected to meet these.
This is why Technical requirements are the last Items to be defined. Deciding on a technical stack and server before the projects starts is silly. You need to have a firm grip on what is to be expected of the system before you can set the technical requirements.
Do not get me wrong, selecting components of a tech stack based on the availability of coders is a good idea, but only as long as it meets the User and Business requirements. If it doesn’t, then a rethink is needed.
In Many of today’s projects, technical requirements are placed first. This leads to increased budgets and a steep increase in the chance of the project failing. You might also want to consider the costs involved with the people in each section. For example, leaving the creation of content, branding, images etc down to programmers, is expensive and will result in a less than perfect result.
Conclusion
All it takes is some time researching your proposed project and working out a lot of the fine details before you start bringing in the coders. This may seem obvious, but its just not done!! A lot of people just want to see code and pages, not reports on how it will work. They don’t like the hard work and hard questions that are asked about their project. Just watch Dragons Den and see the looks on the people walking away and you get the idea.
I really suggest you do this. I am trained and experienced in requirements gathering and if you want, you can hire me here.