Example LOR

Setting up a List of Requirements (LoR)

To organize a list of requirements for a (design) project can be a challenge. Setting it up as a plain text list often is not sufficient. You need some extra’s like numbering it for easy reference, dividing it into categories, add priorities (e.g. using the MoSCoW method) and justification.

To organize this in a compact table, Excel or Google Sheets can be helpful. So that’s why I offer this template.

Download a template here.

Example:

(with fake requirements)

The justification column can have a very brief elaboration on why the requirement should be there, or where it is based on. But often a bit more explanation is needed or even a full analysis. Then simply put a reference there to a paragraph in your analysis (document).

Closer look:

Tips

A list of requirements should be formulated SMART:

Specific – (clear/to-the-point) target a specific area (for improvement)

Measurable – quantify or at least suggest an indicator of progress.

Assignable – specify who will do it.

Realistic – state what results can realistically be achieved, given available resources.

Time-related – specify when the result(s) can be achieved.

Which parts are essential? These will be requirements; others: wish. Or further detail this using MoSCoW method (must/should/could have, or wishes) or weighing factors.

Try to group or categorize requirements. eg: technical (dimensions/working-principles/how-to-make), use (ease of use)/design, regulations/law, safety, and requirements that (will) solve your problem (eg. in case of a re-design).

Also add a (reference to) justification and test-methods, eg. refer to paragraphs in your analysis that further substantiate the requirement. These can be added as separate columns too.

You do not have to literally repeat requirements mentioned in an assignment description, or requirements which are obvious: often an assignment description contains general requirements, which you as a designer must convert to more specific ones.

Generic requirements might be applied on specific products, eg. an interactive product with a Userinterface should adhere to Nielssens heuristics, …

More information: