English | EN Top 10 Blogs of 2015 : Skipping Functional Requirements in Projects is a Costly Mistake
Dec 18, 2015
Top 10 Blogs of 2015 : Blog no. 8 ( Originally published on 13th March 2015)
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.
About the author
