check listThe Requirements

Before we get started on this section, you might like to check out this Dilbert strip!

In a commercial software development setting, a document called the requirements specification is written by the analyst as a formal response to the brief. This details, in precise and formal language, exactly what needs to be designed and built based on the information in the brief.

The purpose of this document is to resolve any potential ambiguities and misunderstandings that may exist in the brief itself. It makes clear to the client exactly what will actually be delivered by the developer. This would usually be agreed and signed by both parties and then forms the basis of the legal contract between the developer and the client.

The requirements will also provide input to the design of the tests. A comprehensive test plan should ensure that all of the points detailed in the requirements are, in fact, met by the final system.

Functional & Non-Function Requirements

Broadly, requirements can be divided into two different types:

Functional requirements specify how the system must behave - what features it must have. For web site, this would include the information that it must present, the details of user interaction and site security and so forth.

Non-functional requirements are everything else. That would include project time scales, usability and accessibility factors, relaibility, performance and so on. Some authors divide non-functional requirements into several subcategories to help organize this stage of the design. One common set of catagories is the FURPS+ system:

IBM has a good page describing FURPS+ here. Although this is mainly from a software systems perspective, the general description of the form of requirements is relevant.

Before you can complete the requirements, you will need to have done a thorough analysis of the brief, making sure that any questions that arise are resolved with the client. As we saw in the previous section, this should give you a clear idea of what the client is expecting that you can then codify in the requirements.

Example Requirements for the OEO

Continuing with the Overtly Educational Orchestra example, and assuming some answers to the questions raised, we might arrive at the following set of requirements:

Functional Requirements

  1. There will be a page detailing the services offered by the OEO
  2. There will be a contacts page with the following options:
    1. Email form
    2. Link to Facebook page
  3. There will be a page containing videos of workshops
    1. The videos will be hosted on YouTube and embedded into the OEO site
  4. There will be a page listing available CD recordings
    1. This will link to a bandcamp page
  5. There will be a page with interactive musical games (see Additional Notes 1, below)
  6. There will be a blog page where members of the orchestra can post brief articles
    1. There will be a comments function in the blog
    2. All comments will be moderated before being posted to the blog
    3. The submission of a comment will raise a notification email sent to the site admin
  7. There will be member login to the site to update the blog and moderate comments
    1. These logins will be restricted to orchestra members
    2. Which member has posted or moderated will be recorded by the system
  8. There will be a registration feature on the site for other users
    1. A user must register before they can submit a comment
    2. Users must supply an email address which will be validated before the account is created
    3. The validation will be a standard challenge/response email
  9. Each member of the orchestra will have a profile page (see Additional Notes 2, below)
  10. Navigation should not use heirarchical submenus.

Non-Functional Requirements

  1. An initial version of the site must be ready within 2 months (note: you should substitute an actual date for this requirement)
    1. This preliminary version must cover points 1 & 2 from the FR
    2. It may cover additional points
    3. Where additional coverage is possible, it should begin with profile pages for the main orchestra members (see Additional Notes 2 & 3, below)
  2. The final complete site should be developed and alpha tested within 6 months (again, you should substitute an actual date for this requirement)
  3. Acceptance testing should be completed within 1 month of hand over
  4. The design of the site should be easy for children to use (see FR 10)
  5. The visual appearance of the site should be informal and fun

Additional Notes

  1. The developers will work with members of the OEO to formulate the interactive musical games
    1. The development of these games will constitute a separate contract to the rest of the site
    2. The games will be developed initially for the web platform
    3. Subsequent development may port the games to mobile platforms, with an initial emphasis on Android
  2. It is the responsibility of the OEO to obtain and organize the content for the profile pages described in FR9
  3. It is the responsibility of the OEO to prioritize the orchestra members for addition to the profile pages

Things to Note

One of the key things about a requirements list, such as the example above, is the use of numbering to make sure each point can be clearly identified.

Note the use of a heirarchical numbering scheme to ensure that the details of a given point can be expanded with further information.

The different kinds of requirements are clearly separated into their own sections and supporting notes are included to clarify some points.

Note also the use of cross-referencing between the various points and sections.

Finally, for a real requirements specification, actual dates should be used, not the relative spans given in NFR1 & NFR2. Note that a span may be used where it is specified relative to apreviously established fixed date (see NFR3).

...Return to the Design Overview