The Sympriser Blog

Software Design, Technical Leadership and Business Innovation

by Rafael Peixoto de Azevedo

Most Requirements are just Design Decisions

The language we use both reflects and influences our thinking.

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

In his post “Requirements considered harmful”, Jeff Patton 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. Software development should enable these changes and not prevent them.

I know there are situations where flexibility in requirements definition is 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.

This article was originally published at Better Projects.

Back to home page