How to write a multi-point requirement for a requirements document?

Question

I am a realtively new BA and I am having trouble finding the best way to write out a requirement that has multiple points.

We are trying to build a dashboard, and I am getting conflicting opinions on how the required elements of the dashboard should be written in the document.

For example should it be written like the following with everything in bullet form within a single requirement:

1. The dashboard shall display:
   • Client first and last name
   • Client Address
   • Current account Market Value
   • etc.

or break each requirement into its own numbered requirement row with a prefacing sentence

5.0 The following shall be displayed on the dashboard.
5.1 Client first and last name
5.2 Client Address
5.3 Current account Market Value
5.4 etc.

or break each requirement into its own number requirement and be repetitive in each requirement

5.0 The dashboard shall display client first and last name
5.1 The dashboard shall display client Address
5.2 The dashboard shall display current account Market Value
5.3 etc.

Answer 1

The point behind numbering items is usually traceability. If you have a numbered item you can reference it easily in test cases and defects. In my opinion, numbering items in requirements specifications is A Good Thing.

In your case, you need to think a little about whether these are Business Requirments Specifications or Functional Requirements Specifications - The issue here is the detail you need to go down to, with the FRS being at a lower level of detail than the BRS.

Assuming this is a FRS I would:

• Start a section called DashBoard Specification (or similar)
• Start a subsection called Required Display Fields (or similar)
• Either include a table containing all the fields to display or Start sub-sub-sections, one for each display field.

Whether you use a tabulated list or document subsections is largely up to you or the style preferred in your organisation, but you need to ensure that the correct level of detail is present and a table could be good for this as you will likely need to include such things as:

• Field label
• Label Font
• Data source
• Presentation style (i.e graph, pie chart, text etc.)
• ...and indeed any number of local field level specifications that are important to you

The specification should be to a level of detail that a) allows the developers to develop what is required and b) allows the testers to write test cases that prove the requirements are present (and for this, table rows should be numbered as the test cases will likely match a field specification and so needs to reference a specific row in the specification table).

Since this is also a visual element, you will probably need to have a section including some kind of visual/layout design that has been approved or requested by the users- that way the developers will know how to lay the dashboard out and the testers will know what it is supposed to look like.