Software requirements

Requirements keep software development on track and heading towards the right destination.

They are the record of stakeholder wants/needs/expectations to be achieved by the project and should be accurately documented in sufficient detail for the built solution to be validated, after the fact and with the least chance of confusion.

Requirements can represent high-level business outcomes, end user functionality, technical constraints, regulatory and compliance needs. Often requirements interrelate and exist within a hierarchy of sorts, eg. lower technical requirements underpinning the functional requirements.

A good business analyst will be more than capable of gathering the stakeholder needs, validating them as necessary, before documenting the requirements sufficiently for the technical and assurance teams to work off.

None of this process should be seen as unnecessarily fixed and rigid, as stakeholders change their minds and requirements evolve over time as the project progresses. Writing stuff down isn’t waterfall.

Requirements can also be captured at different times and at different levels of detail, depending on factors like maturity of team, delivery method, type of technical development etc.

The business analyst can oversee all proposed changes, expertly assessing their feasibility and impact, and helping the stakeholders make informed decisions.

I’m really passionate about getting the early stages of a project off to a good start, having previously worked as a developer for many years and being on the receiving end of rubbish, incorrect or simply no requirements at all.