Close this search box.

Thinking about requirements


Poor or ambiguous requirements are often blamed as a key factor in software development. However writing any requirements is difficult, let alone good ones. What can we do to reduce this particular risk to our projects?
If you have to create requirements and are unsure of what makes a good Engineering requirement then thinking in terms in terms of questioning techniques (who/what/where/when/why/how etc.) is a useful approach to use. Subsequently using the “5 Whys” technique to delve into areas of ambiguity is also a handy tool to help add clarity.
Here are some ideas around the kind of things to consider when framing a requirement:

  • What is the problem to be addressed?
  • Why are we doing this? Is there a business case to support this/add more background information?
  • What do you want to achieve?
  • What do you consider minimal viable thing to achieve?
  • Who are the stakeholders for this feature?
  • Who cares? Why do different people care?
  • Who is impacted or has a vested interest? Who is the end user? (Low level IT guys, higher level manager, both?)
  • Are there other non-obvious personas/stakeholders (1E support, Consultants/Partners)?
  • Will there be any additional artifacts required other than working code?
  • How It Works documents, updated Help content, training materials/sessions, Upgrade/Install/Sizing guides/Best Practise documents?
  • Where and When?
  • What kind of environments is this expected to work in (Windows/*Nix, Large/Small, Multi forest etc.)?
  • Are there to be any restrictions on who should be able to employ/configure/trigger the solution?
  • How often does the USER need to take action to solve their problem currently? Is this a frequent/infrequent tasks? Do we know usual timelines?
  • What level of flexibility is minimally required and then desired? Will the user be able to configure?
  • Have the needs of all stakeholders been achieved? What would be necessary for this to happen?
  • What are specific targets in terms of non functional aspects/behavior?
  • What “size” of solution needs to be targeted? How many seats/users/devices etc? What level of detail/granularity is required? Do we need to support HA/Clustering etc?
  • What security considerations are required? Access, level of access rights, cloud/on-premise etc.
  • Is UX/UI important?
  • Is accessibility a concern?
  • Is ease of deployment an issue?


  • Dictating the implementation details.
  • Assuming that existing solutions are best template for implementation.
  • Thinking in terms of a “spot” solution within a product.

So if you are creating a requirement or change request, and your submission does not answer the above or similar questions, then how do you expect an engineer to give you what you want?
Questioning what you are asking for and reviewing the answers may just remove a little of the confusion.


The FORRESTER WAVE™: End-User Experience Management, Q3 2022

The FORRESTER WAVE™: End-User Experience Management, Q3 2022