Requirements

Early in the report, make it clear what the requirements were for your project. This forms part of the background work that would have been conducted early in the work. This section outlines some issues that should be considered when reporting the requirements.

Describing the requirements

The easiest way to describe the requirements is to provide a list, with each requirement having a number. Figure 1: Example of a set of requirements shows an example for a system that records assessment dates for modules in the department; this is related to the example Project Outline that was discussed earlier in the term. This extract only represents a few requirements from what a longer list for the whole application.

An example list of requirements, organised in a list.

Figure 1: Example of a set of requirements

List as many requirements as are necessary for your project. The requirements could alternatively be listed as a set of sections and sub-sections. As an example, Figure 2: Example of reporting the requirements as a set of sections shows the above requirements as sections.

An example list of requirements structured into separate sections.

Figure 2: Example of reporting the requirements as a set of sections

Either approach is acceptable. If there are only short descriptions for each requirement, the list as in Figure 1 might be better. If there are longer descriptions for each (or most) requirements, then the use of sections, such as Figure 2, may be better.

The identifiers FR-1, FR-2, etc., are a choice made for this document. The identifiers for a requirement can have a different format. The important thing is that each requirement and sub-requirement can be identified specifically. That will enable easier discussion about how a particular requirement has been implemented during the project.

Note

The example figures are displayed with borders around them. That is only done for effect in this document to highlight them as figures for illustration. It is not necessary to surround any list of requirements in the same way.

Requirements may be discussed differently depending on the approach that has been used for the project. For example, if using FDD, then feature sets should have been developed and if using a variation of XP, then it is likely that stories have been defined. Identify a way to talk about those issues so that they can be discussed in the report.

Use Case Diagrams

UML Use-Case diagrams can be a useful way to describe requirements. These can be particularly useful when there are multiple types of users, where each type of user accesses a subset of the overall requirements. The diagram type can also be useful even if there is only one type of users.

If using this type of diagram, remember that in addition to the diagram, there should be some descriptions. Those descriptions should explain the purpose of the different use-cases and any links between them.

Research questions

If the project has a research question or a few research questions, clearly identify what they are. You will discuss the design method used to develop experiments to answer those questions. Also, discuss the software that has been developed in that work. In discussing the software, do describe the requirements that were identified for the work.