We need to gather the requirements….
What does this mean in relation to a software development project?
Essentially, the idea is to look at what is currently being done, known as the ‘As Is’ and the vision of where the system needs to be, the ‘To Be’.
The area in the middle is going to be filled with the requirements, the needs to fix the existing issues or areas for improvement.
Of course, if this is something new, the ‚As Is’ will be a blank canvas.
The requirements for the system which is to be developed should support the business, people and the processes. In IT, we may consider Incident or Request Fulfilment. For HR, we can look to New Hires, Managing Leave etc..
One of the issues of ‘gathering the requirements’ is that they can sometimes be elusive. A stakeholder can want something, but might not be able to define what it actually is, or how it looks.
Other common problems include –
- The expressions are ambiguous
- Statements are imprecise or too general
- There is a confliction between two or more stakeholders
Perhaps one of the biggest problems is ‘Missing Requirements’. These are usually missing in the sense that they haven’t been considered. Not that someone has accidentally misplaced them 😊
Overall, this means the task of defining the requirements and shaping them into the project deliverables can be tough.
What do Good Requirements Look Like?
- Precise – It’s clear exactly what is meant
- Not open to interpretation
- Complete – All the connected information is present
- The questions ‘what next’ or ‘what if’ is vital to understand the full scope when electing the need
- Atomic – Aim for – 1 actor, 1 task, 1 time
- If and/or has been used, perhaps there are different requirements that should be split
- Traceable – You have information relating to who gave the requirement and why
The Tools Available
An analyst can use many techniques and approaches to collect the requirements –
- 1 on 1 interviews
Once the stakeholders have provided their input. Everything must be understood or ‘analysed’ and then validated back to confirm understanding.
These steps are just as important and will help refine the deliverables for the project.
During each phase, the key must be listening and really building an understanding. Ask questions until there is no doubt.
Not a Waste of Time and Money
An important point is the cost of analysis at the start of the project will nearly always be less expensive than replacing or repairing issues at the end of a project.
However, there seems to be a stigma related to this topic. Often Businesses want to rush through this process.
They don’t see it as value added and almost never want to invest time and resources in the process until a scope has been defined and budgets have been set. In effect, when it’s too late!
A Lasting Note
What do most people refer to when they’re reviewing a project retrospectively? Perhaps –
- The failure of benefits not being delivered
- How the system didn’t meet the real need of the business
Generally, people won’t refer back to ‘The cost of gathering and defining requirements’ as the standout subject.
Of course, the other end of the spectrum is also undesirable. You don’t want a project never to start because you’re constantly analysing and tweaking every detail.
The requirements gathering and definition process should be built into the project.
Plan it carefully, just as you would with any other aspect; such as budget, delivery dates and project resources.