Requirements Document

Template

• Requirements document (DOCX) (last updated February 10, 2012)

Created by

• Business Analyst

Reviewed by

• Project Manager
• Subject Matter Expert
• Project Lead

Approved by

• There may be a formal approval by Sponsor

Requirement

• Required for any IS project 

Additional tools

• Affinity chart for data synthesis
• Prioritization techniques
• Process & data modelling tools
• Use cases

Guidelines

• Requirements can stem from market demands, business needs, customer requests, technological advances, legal/regulatory changes and social needs
• Detailed requirements remove uncertainty as to how the system will accomplish the task
• Proper requirements are:
  • Cohesive (specifies only one thing at a time)
  • Complete (self-contained, defining all situations that can be encountered and the appropriate response for each)
  • Consistent (should not contradict other requirements and should not be repeated elsewhere
  • Correct (mistakes in a requirement definition will result in a defective solution)
  • Feasible (must be possible given system and project constraints)
  • Mandatory (although requirements can have relative priority, they must all be “required”)
  • Modifiable (if a change to a requirement is necessary, it should be expressed such that it is traceable)
  • Unambiguous (avoid words like “more”, “less”, “fast”, “slow”)
  • Testable (should be possible to design a test to determine if requirement has been met)
• Types of requirements include:
  • Business requirements (high level, measurable statements of goals, objectives or needs of the University)
  • Stakeholder requirements (statements of the needs or particular stakeholder or class of stakeholders)
  • Solution requirements (describe characteristics of a solution)
    • Functional requirements (describe behaviour and information the solution will manage)
    • Non-functional requirements (describe environmental conditions under which the solution must remain effective or qualities system must have – speed, security, availability, etc)
  • Transition requirements (capabilities to facilitate transition from current state to the desired future state – data conversion, skill gaps, training, etc)
• Business rules are the foundation for most requirements (policies, guidelines, legislation, etc)
• Documenting requirements can be very complex. It may be appropriate to use a variety of tools such as Use cases, Flow diagrams, etc.