How to Develop a First-class Requirements Template – Part 2

In Part 1 of our guide to how to develop a first-class requirements template we recommended a few thoughts, techniques and recommended additions to your current requirement template. Today, in Part 2, we will recommend a few more of these additions which will ensure that requirements are correctly understood by all and no time (and money) is wasted in miscommunication.

Links 

Links are a description of the relationships between the current requirement and other items, e.g. requirements. A requirement often has a relation to other requirements or test cases even to a bug report. The reader may simply need to read a different requirement to understand the current one. It is very important that all dependencies are crystal clear right from the offset, for obvious reason.

System Version or sprint

Make a note of the specific sprint or version of the future system in which a given requirements will be introduced.

Why is this a good idea? Apart from allowing work to proceed in an orderly and planned fashion, this cuts the risk of redundant development work being carried out.

Subsystem/functional area 

Essentially, this is the part or section of the system affected by the requirement. Knowing which subsystem a requirement affects is especially useful when planning iterations, because it makes it easy to sort or filter out all requirements which pertain to a particular part of the system.

Rules

Rules can be business rules, policies, or regulations. You should briefly describe the rule in the requirement, but leave longer descriptions to other documents. Simply refer to them in the requirement in order to avoid drowning your reader in detail.

It is convenient to add rules as attachments to requirements. Incidentally, this is one of the highest used features of ReQtest.

Comments 

Provide other information that may be useful to the reader but is not shown in any of the other fields.

For example, an idea, thought or observation might be jotted down here and then explained face to face in a meeting when requirements are discussed.

Change log 

The change log needs to be updated every single time a requirement changes. It will often contain the name of the person who changed the requirement, as well as the date and reason for the change. Every requirement should have a change log. It’s not uncommon to note the changes in the requirements document’s history, but the history section is often too brief.

It’s important to keep detailed track of changes in requirements because test cases will be created based on them so if a requirement changes, the test case conditions might need to change as well.

Of course, it’s much easier to keep the change log up to date if you use a requirements management tool such as ReQtest since tools often create the change log automatically. ReQtest certainly does!

So, what have I learned about my requirements template?

Writing high quality requirements will become much easier if you have a good requirements template that includes some of the important headings described above and in Part 1 of this guide.

Of course, you can’t get by just by having a good template; you do need skills and proper techniques for gathering requirements based on stakeholder needs, as well as techniques for reviewing the requirements.

To get started with your requirements template, choose one or more of the headings recommended here. They’re all advantageous in one way or another, but resist the temptation to cram them all into your template, or you’ll never get requirements management off the ground. Having a lot of headings does reduce the risk of authors neglecting to enter details, but having too many headings will cause the process to get bogged down and make requirements more difficult to produce and use, which is most certainly not what you want!

Of course ReQtest comes with a standard set of headings for requirements and you can easily add, modify and remove fields to create the optimum template. To learn how to do all of that, watch this video on our site. The video shows how to configure fields and content for a bug report, but it works in exactly the same way requirement fields work.