« Supporting Frameworks for Successful Program Management - Contingency Management
Managing Testing Resources: Five Suggestions for the Project Manager - Lay Out Criteria for Important Milestones, and Stick to Them »

Documenting Requirements - A Sample Requirements Specification

April 14, 2008 | Author: admin | Filed under: Scope Management, Project Scope Management, Requirements Management

Documenting Requirements - A Sample Requirements Specification (#24 in the Hut A Project Management Primer)
By Nick Jenkins

The most common method is to break down the requirements in an outline fashion as used in a document or manual.

For example:

  1. Current product status – all parties highlighted the need for a clear and public indicator of the current status of a product
  2. Dates - dates for each major milestone were also recognised as necessary. Although some of these dates will remain in the public domain others will be available only to “private” users. Private users will have the ability to publicise dates as they see fit.
    The dates specified are:

    1. Development sign off
    2. Testing sign off…

Even more structure can be put into the document by splitting up requirements categories, for example:

  1. Functional Requirements
    1. Product list – the system should produce a list of products available or under development
    2. Current product status – all parties highlighted the need for a clear and public indicator of the current status of a product. There should be a simple flag which indicates at-a-glance whether the product is ready for release.
    3. Dates – for each product, dates for each major milestone must be shown. Although some of these dates will remain in the public domain others will be available only to “private” users. Private users should have the ability to publicise dates as they see fit.
      The relevant dates are listed below:

      1. Design sign off
      2. Development sign off
      3. Testing sign off
      4. etc…
  2. Non-Functional Requirements
    1. Performance – the system must be updated daily and information available to all international users within 1min of the information being posted by head office.
    2. Usability – usability of the system was seen as very important to adoption of the system. The system must be simple and easy to use and must follow the standard UI style as laid out in the company design handbook.
    3. Security – access to schedule information must be controlled on a per-user basis. Access to the information should not be available to any external customers or companies.

It is best to be as specific as possible but remember the 10th commandment and be flexible. If your project doesn’t warrant this level of detail then don’t include it; or you will spend all your time writing documentation. Find a happy medium between detail and effort that suits you and your organisation’s needs.

Next in the Hut A Project Management Primer:

Traceability

Previously in the Hut A Project Management Primer:

Documenting Requirements - Diagrammatic Methods

Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Monday, April 14th, 2008 and is filed under Scope Management, Project Scope Management, Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

[…] Documenting Requirements - A Sample Requirements Specification […]

PM Hut » Documenting Requirements - Diagrammatic Methods wrote on April 14, 2008 - 3:51 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories