Software Requirements Basics

Functional requirements

While ordering software, it is very likely that the customer will not know all of the technical aspects of it. It is the vendor's responsibility to explain and advise on the technical choices concerning a certain functionality during the functional requirements collection process.

Absurd abusing

The customer should not end up in a situation when the “user login” functionality was ordered, but nobody thought about “password reset” functionality. It’s software developer’s – as the technical expert – duty to forecast cases like that, and notify the customer about them. The customer can be equipped with any Agile methodology (like SCRUM) that allows him to add missing functions in future iterations. It is a natural process, unless the budget is already exceeded.

Written form

Project requirements delivered by a customer and revised later together with the vendor should always be kept in a written form. The requirements should be available to all people involved in the software's development. It helps keeping transparency of the project and establishing one, rightful source of information.

Final requirements should be confirmed both by the customer and the vendor

Last requirements revision before final acceptation

I always advise the customer to take the latest requirements document and consult it with a 3rd party company or an independent consultant. Such consultation will provide the customer with another expert’s point of view and confirm/decline the quality of functionalities and the system requirements. Usually, the additional costs are much smaller in comparison to possible architectural costs later.