28 March 2008

Most Requirements are just Design Decisions

The language we use both reflects and influences our thinking.

The term “requirements” has its roots on bureaucratic thinking, that supposes a static and impersonal business world where specialists would be able to uncover, extract and document the definitive specifications for software systems.

Jeff Patton in his post
“Requirements considered harmful” alerts us that most requirements are just design decisions. He shows how typical behaviours like asking and giving requirements can be dysfunctional because they justify avoiding responsibility and stop collaboration on a critical success factor for software development projects.

Recognizing that most requirements are just design decisions, gives us a better chance to design and deliver more effective software solutions if we (a) carefully treat them as design products and (b) are ready to adapt them quickly to new circumstances.

Carefully defining requirements as a product of a design process means we should (1) use a collaborative process involving all relevant stakeholders, (2) reflect about the requirements under different perspectives: market, business, users, system and (3) use the most adequate tools and language to express the requirements in a common framework comprehensible to everybody in the team.

Being ready to adapt the requirements means being agile to sense and respond to relevant environmental changes and being open to incorporate new knowledge generated by the organization. The capability to learn and innovate, quickly adapting and creating changes is critical for leadership in the marketplace. Business software should enable these changes and not prevent them.

I know there are situations where requirement changes are beyond our sphere of power and influence. However, as responsible professionals, we should not just let requirement decisions hide under processes, documents and signatures. It is healthy to foster reflection on the what and why of software requirements. As Business Analysts, we should lead this process and help our organizations expand their possibilities.

Picture by Lindsey Lissau.
Original at Flickr


  1. My organization struggles with this concept quite a bit, that is the balance between requirements and flexibility in system design. Of particular difficulty is how to capture these design decisions so we can understand them later. I would be interested in tools or techniques others use to capture design decisions through out your process.

  2. Hi, Ray

    I think this is never easy for non-trivial projects. We have a two-fold approach: (1) always link the software requirements to operational and strategic contexts and (2) reflect about the software requirements and results on our bi-weekly project review meetings with main stakeholders.

  3. Anonymous11:11 am

    A Requirement can only be defined in relation to a step in a business activity.

    Visit www.iag.biz if you need help with Requirements.

  4. There is a discussion thread directly related to this topic at RQNG

    It looks at the "thick grey line" between requirements and design. Interesting stuff and your contribution here could inform that discussion.