It all starts with a requirements document
Whether it’s for Waterfall or Agile, a requirements document is where the development process begins. Sometimes, a client will come to us with a detailed brief; other times, it can be as little as a single sentence. It’s my job to work with them to break down even the most abstract ideas, then identify and record important information about their project, like:
- Who the stakeholders are – and who has final signoff
- Functional requirements (what the new software needs to do)
- Non-functional requirements (how the new software needs to achieve its function)
- The scope of the project – and what’s beyond the scope
- Risk analysis, and a list of other systems this project will impact
- What types of testing we’ll need, such as security checks or cross-browser compatibility tests
- The release schedule and change plan
- Potential wireframes
The scope of requirements can vary wildly, from a whole new app – such as a support ticketing capability – down to adding a single input field to a search function, or adding an extra button to a contact page.
That means every set of requirements will include different levels of detail. They’re living documents too, so they’ll often change a lot during the development, release, and iteration cycle. However, that’s not an excuse for lax requirements – everyone still needs a clear goal to work towards, even if some of the particulars are likely to shift.
Another important thing to consider about requirements documents is that they’re not there to suggest solutions or approaches. As business analysts, we don’t want to lead developers down any specific path; requirements should give them everything they need to plot their own route to the final product.
When it’s done, I pass the requirements document on to our developers – and that’s where the other half of my job starts.