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-FinzerGreg 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.

Acerca de Sogeti España

Como parte del Grupo Capgemini, Sogeti opera en más de 100 localizaciones a nivel mundial. Trabajando estrechamente con clientes y socios para aprovechar al máximo las oportunidades de la tecnología, Sogeti combina agilidad y velocidad de implementación para diseñar soluciones innovadoras enfocadas al futuro en Digital Assurance & Testing, Cloud y Ciberseguridad, y todo ello, impulsado por IA y automatización. Con su enfoque práctico y su pasión por la tecnología, Sogeti ayuda a las organizaciones a implementar su transformación digital a gran velocidad. Si quieres conocer nuestro "Value in the making", visítanos en

0 comments on “Skipping Functional Requirements in Projects is a Costly Mistake

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: