Understanding user requirements (or a client’s) is critical when developing a software proposal. And, often it’s a single point of failure.
With most IT and software projects, there is sign off before the actual coding or implementation begins. And, this holds true, whether it’s a project that an IT services company develops, or a product that the internal development team works on. Either way, a requirement document is paramount for software development.
Before, I go further, a few clarifications:
- With executing a project for a client, the requirements documentation helps define the scope of a project, and also software requirements specifications (SRS)
- In the case of a product, these requirements manifest as the functional (and at times technical requirements) that appear as line items/tasks in a sprint
What is an SRS, and why is there a need for requirement definition?
The SRS is a software requirements specification document, that provides a description of the application/software to be developed. It details out the functional and non-functional (read: technical) requirements, along with use cases. When executing a project for a client, the SRS often becomes the basis of the contract/agreement between the the parties.
Delivering right, without over engineering
Much like the self-operating napkin, some times, teams get carried away when developing a feature or implementing a functionality. Take for example, a client of ours that wanted a website built. One small feature on the website was to be the ability for visitors to see what content was popular. And, it was to be achieved with minimal development effort (it was a marketing activity, and the budgets were on the lower side).
The initial approach (and probably the right one, from the long term perspective), was to create social logins, add a five star widget, and store ratings per user in the database. With a view to keep efforts on the lower side, we decided to strip down the functionality to include only a Facebook login, and a like button for indicating popularity of the content. Doing so helped save a few days of effort, along with the design and testing overheads.
This is, but, one very small example. Entire projects have been undone by not defining the bounds and scope of what has to be developed. And, it’s how well you define requirements, that allows development teams to detail an SRS effectively.