Requirements for software of any complexity, are never complete. There are always unstated assumptions, edge cases, and ambiguities that will remain. Time does not stand still, and things change. New requirements and rules emerge in the usual business of developing software and feedback from the users.

See my post on Document to the Right Level for more about thinking about how much to document.

Different strategies are appropriate depending on circumstances to learn more and to make decisions about requirements. Develop good judgement as to when to apply a strategy.

Common Strategies

  • Make a judgement call
    • Sometimes just making a call as to how things should behave is appropriate.
  • Refer to standards
    • Standards can provide good guidance on decision making. That standard can be one that has evolved specifically for that project, or an external one.
  • Talk to stakeholders
    • Often there is a product owner who has deep knowledge of the users and the problem space. If there are cost implications in terms of time to implement, and maintainability, be sure to flag those to the stakeholders. Sometimes a less complete, or less elegant solution, will be the choice due to the costs of the more complex solution.
    • Be sure you know who the important stakeholders are that you need buy in from.
    • Learn the level of detail stakeholders want to be engaged at.
  • Refer to similar solutions
    • Competing or similar solutions may have set user expectations for how a feature should behave. This can be a good proxy to talking to actual users.
  • Talk to users
    • Finding out what your users actually need and want by talking to them is often an effective method, but can be relatively expensive. Some interpretation is needed. Users often can’t state their feedback in a way that can be directly applied to a particular question.
    • User feedback is most useful for incremental changes.
  • Test user alternatives
    • Testing alternative by putting them in front of real users is the ultimate check on the benefit and usability of alternatives.

Resources