Home > Uncategorized > Requirements Document formatting tips

Requirements Document formatting tips

This post has formatting tips for your BTR490 Requirements Document that’s due on Friday.


The following information does not replace the template format that you have been using this summer.

Instead, it provides tips that will help you submit a better-quality and more useful document.

For each section in the template, some point-form tips are provided.


General comments

  • Take care with the document’s format
  • Font consistency – the “Normal” style must use the same font throughout the document (but of course, you can use italics and bold where appropriate)
  • Each major section must begin on a new page
  • Pay attention to spelling (i.e. do a spell check!)
  • Pay attention to grammar, composition, clarity, and so on

Cover/title page

Suggested format, nicely spaced, sized, and formatted:


Client Name

(optionally, a Contact Name)

System Name

Team Number

Team Member Names


Table of contents

  • On a separate page
  • Titled (e.g. “Table of contents”)
  • Take advantage of Word’s built-in capabilities for table of contents


  • Include some descriptive text
  • The intention is to quickly orient the reader
  • And to provide some context


  • Include some introductory text that describes the project’s overall scope (i.e. what is it trying to achieve)
  • In other words, set the context before jumping into the (repetitive) use case blocks
  • Include (in this scope introduction) a full/overall use case diagram

For each use case…

  • Follow the template’s format for a use case specification
  • Each use case must have a (suggested) table of information, showing
  1. the use case name,
  2. its (team member name) author, and
  3. the date that the use case was most recently revised/updated
  • Optionally, include a use case diagram (for this specific use case), only if it helps to clarify
  • Optionally, include a domain class diagram (for this specific use case), only if it helps to clarify
  • Clearly identify the use case name, and then briefly describe it; optionally you can number/identify each use case (e.g. UC01, UC02, etc.)
  • Section 1 must list business rules that are specific to the use case; optionally you can number/identify each business rule (e.g. BR01, BR02, etc.)
  • Section 2 will have one or more scenario descriptions, showing
  1. scenario number/ID and name,
  2. preconditions, and
  3. a table of one or more actor-system-data steps
  • Section 3 must list the classes (and their attributes) covered by the use case

Domain class diagram – include one for the whole system

Stakeholders will include descriptive information on any or all of the following, plus some others…

  • Client, as an organization
  • A department (business unit) of the client
  • The client contact person
  • The public, and/or its customers
  • Business partners or suppliers to the client (etc.)

Business rules

  • List of all business rules
  • Includes general/overall rules
  • Also includes each of the business rules that appeared in the Scope > Use Cases section (above)
  • It would be helpful/useful to cross-reference each business rule with the use case(s) it applies to (suggestion – use a three-column table; business rule number/ID, business rule name, use case(s))


  • As in the template


  • As in the template


  • As in the template


  • As in the template
  • Remember that you must submit paper for documents that need signatures (contract and project initiation document)


Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: