How To Handle Software Requirements Effectively

Requirements collection is the first step or probably the second step for the programs that involve carrying out VOC (Voice Of Customer) in a product/service development life cycle. Requirements are gathered based on the customer inputs and a document typically called Software Requirements Specifications(SRS) is written. Once requirements collections is felt as sufficient, the requirements are based lined and further developments happens, usually by writing the high level design and then low level design to implementation.

The problem in maintaining the requirements is that the requirements 'tend' to change over the period of time after the requirements base line. Change in the requirements leads to change in the design and then the implementation. When requirements are modified/changed often, it becomes crucial to maintain a better and the implementation. Sometimes even the scope of requirements change. In this short article I'm going to talk about how effectively we can manage the requirements so that the design and its implementation are least affected.

Have Requirements Owner

Imagine different people in the team modifying the requirements often and some members are not aware of these requirements changes. Requirements are simply not manageable if they are modified by multiple people. Have a dedicated person who is referred as 'Requirements Owner'. Yes, someone has to 'own' the requirements and any further change in the requirements must go through the requirements owner. The requirements owner will have a complete idea on what's being changed and the solid reasons/approvals for the same.

Write Requirements At Granular Level

At the time of writing requirements, write them as detailed as possible. This is very essential and makes sense to spend time. We can never bring a complete product that our customers wanted unless everyone involved in the development understands the requirements and more importantly acknowledges them. Requirements have to be understood from customer's perspective. What each requirement means for the customer has to be thoroughly understood. This can happen if we write the requirements in detail, in other words at granular level.

Avoid Assumptions While Writing Requirements

I've seen that when requirements are written, it so happens that they are written assuming that the person reading the requirements is already knowing something. Detail out every terminology that is used in the requirements. People read Wikipedia and they appreciate the content that's written over there. This is simply because, though certain information is abstract, there are hyperlinks to the terms used while explaining the matter. Wikipedia does not 'assume' anything about the readers but links all the terminologies and also gives the background/history and several links for further read. In my opinion, software requirements have to be written in this manner especially when collecting the requirements for a product/service that involves some home work.

Keep Requirements Open for Change.

This is the biggest and much deeper problem. Requirements keep changing because 'No customer explains exactly what he/she wants' in a way that a software architect can understand. Requirements are written the way how they were understood while interacting with the customers. Its really important to walk into the shoes of the customers to better understand. Do not try to understand the customer requirements, try to understand customers themselves.

Follow Agile/Scrum Framework

The best way to understand the customer requirements is to show them a demo of working software. When customers start seeing the service/product they are wanting, they start giving the feedback, they can even change their mind and ask us to change the requirements that they had initially stated. The agile methodology has been effective and many organizations are already following this and they have proven results and have gained customer trust. Have a look at how to deploy agile framework effectively.
 

Conclusion

Handling requirements is not an easy task. Never commit on the requirements that you  are not sure you can implement. Committing on every customer requirements and finally not delivering the service/product as per committed requirements will lead to losing the customers' trust. Due to the changing nature of requirements, the dynamic way of dealing with software requirements is a better option by following dynamic methodologies such as Agile/Scrum.By following these methodologies, there is no chance that we are going to miss any requirements or wrongly implement the requirements.