Skipping Functional Requirements in Projects is a Costly Mistake

Running a project with Agile or Scrum methodologies does not mean that it’s ‘OK’ to skip functional requirements. Once, there was a company that gave application mockups to its developers without providing any details about what the application was supposed to do. It was left to the developers to guess what actions the application should perform, based on the mockups. As expected, this led to a lot of iterations and unnecessary exchanges between the business and the developer. Days (of work) were wasted, as the changing functional requirements were communicated verbally to the developer. When the application was ready to be tested, the requirements changed again, because there were former business users in the QA department.

Essentially, application requirements should consist of mockups (also known as wireframes), business rules, a functional description of what each button/link does, and a list of the fields with their types and lengths. Requirements should be completed and signed off by the business before development begins. It is best if requirements are completed in related screens, so that the architect gets a broad view of things and is able to guide the developers accordingly.

I am not proposing Waterfall, where all the requirements of the entire application are addressed up front, while the developers wait. Ideally, this is what needs to happen: The business analysts would have their own iterative requirements cycle, coming before the iterative development cycle. In my opinion, there should be one business analyst for every four or five developers. If there is fewer analysts, it creates a bottleneck.

The goal of having good functional requirements, which are signed off by the business, is to reduce scope creep and changes. This in turn will help reduce costs. Also, developers are typically the most expensive resources (after the managers) in an IT department. Therefore, it’s wise to make the best use of their time and skills.

Would you be able to build a car with just a picture and no specifications? I suppose not. So, neither should you attempt to build any software that way.

This article was previously published in SogetiLabs Blog

Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community. More on Greg.