10 Reasons to Not Define Requirements Up Front

Requirements — we spend more time on requirements than any other single area of application development. (Note: Some poorly-managed projects spend the most time in software quality assurance. I hope yours don’t.)

Why do we spend so much time on requirements? Simply because if we don’t get the requirements right, the project is doomed. The team will either deliver the wrong thing or not deliver something needed. Both are equally bad.

How do we define the requirements?

  • Traditional Business Requirements Documents – often used in waterfall projects.
  • Use Cases – often used in projects employing object modeling.
  • User Stories – often used in agile projects following Scrum, Kanban or XP.
  • Informal Discussion – often used in unstructured projects

Regardless of the final result, there are several techniques for capturing the requirements:

  • Individual interviews
  • Group discussions
  • Existing application as an example
  • Wireframes or other mockups
  • Idea submission, review and modification

The ultimate goal of all of these approaches is gaining agreement on what the software needs to do. There has to be a common understanding of what the software receives as inputs and what it will produce as outputs. In many cases, this is tough to do at the outset as intimate knowledge of inputs and outputs often requires time for detailed design.

Just as important is how the user interacts with the software. What does the user see? What does he do? How can he find, display, edit and report the data? This can even tougher as the users often don’t know what they really want until they see something they can grasp and critique it.

Requirements Capture Is a High-Risk Endeavor

For these reasons, capturing, documenting and freezing detailed requirements at the outset of a software project is a high-risk endeavor. Yet, we continue to do it — over and over again. The next time your business users demand fully documented requirements before development begins, educate them on the following change risks.

  1. Business needs change rapidly as strategic directions are fine-tuned.
  2. Competitive announcements may force an unplanned response.
  3. Regulatory changes may require software adjustments.
  4. Personnel changes may affect expectations of the software.
  5. Changes in technology may force software updates.
  6. Adjustments to help desk and general maintenance procedures may impact the software.
  7. Marketplace changes may affect customer demands of the software.
  8. Business process changes may require a response from the software.
  9. Budget cuts could impact the project.
  10. Misunderstandings or miscommunications may need correction.

You get the idea. What are the chances that none of the above will happen before your project ends?

What’s the alternative? Keep the requirements high-level at the outset. Postpone the final details for as long as possible. Deliver the software incrementally and use the feedback received to guide future requirements. Be agile.

Updated: October 9, 2011 — 9:19 pm


  1. Hi Vin,

    What is the alternative? If you’re saying we shouldn’t define requirements up front, then what should we do? We need these requirements in order to estimate the costs and the time it takes to execute the project.

    1. The alternative is to keep the requirements to a minimal set and define them at a high level. In other words, create a small number of epics and let those be the up front requirements. As the project evolves, the detailed requirements will be defined and new epics will be identified.

      This approach actually reduces risk and speeds-up time to market.

Comments are closed.