Top 10 Blogs of 2015 : Skipping Functional Requirements in Projects is a Costly Mistake

skipping requirementsTop 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.

 

Sogeti Labs

About

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

1 + 2 =


  1. Karl Z March 13, 2015 Reply

    I’m perplexed… Agile or Scrum should use User Stories (As a [role] I want [feature] so that [outcome]. for example) that are discussed by the team, at a bare minimum in the Sprint Planning Meeting. So what part of Agile or Scrum would have this scenario: “Once, there was a company that gave application mockups to its developers without providing any details about what the application was supposed to do.” I’d say that the company wasn’t using any real methodology and certainly not Agile or Scrum.

    • Greg Finzer March 18, 2015 Reply

      I would agree that the company is not actually doing Agile. It is like a Dilbert situation where the manager is calling the process Agile and it is not.

  2. Shawn Cicoria March 14, 2015 Reply

    You don’t run a project with Agile – you become agile. As for functional requirements – the user story is the requirement – or need – or value proposition. As for dissertation level Functional Requirements – well, they help only to ensure that the vendor – apparently in this case Sogeti – to defend themselves against risk. I’ve been there. Teams that are invested in their commitments and good product ownership with the right coach gets to what is really needed – not reams of worthless paper.

    On top of that these Functional requirements never address the true customer who needs to understand them – the Developer. They’re usually written for the customer to signoff on.

  3. tlandwermeyer March 16, 2015 Reply

    Even with the preparation of the functional requirements, oversights and omissions are virtually inevitable, which costs the development cycle some degree of efficiency. These gaps can be reduced by early review of the requirements by others on the team, such as QA or other SME available to critique the documents. But to skip the functional requirements altogether would be an exercise in folly. Not unlike taking a trip without a map – waste is guaranteed to ensue.

    • Greg Finzer March 18, 2015 Reply

      I prefer requirements that have concise information that both the business and developers can understand. I have seen requirements go the opposite direction; too much requirements. I once worked with a BA from the state where they measured how good their requirements were by the pound of paper. The same business rules were repeated over and over again throughout the document.

  4. Jos Punter March 21, 2015 Reply

    @Shawn Cicoria “You don’t run a project with Agile – you become agile.” So true. Many people fail to see this.

  5. Greg Hansen August 12, 2015 Reply

    Good article, thank you for sharing.