Skip to Content

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

Sogeti Labs
December 18, 2015

7 thoughts on “Top 10 Blogs of 2015 : Skipping Functional Requirements in Projects is a Costly Mistake

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

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

    1. 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. @Shawn Cicoria “You don’t run a project with Agile – you become agile.” So true. Many people fail to see this.

Leave a Reply

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