Requirements Document


Created by

Reviewed by

Approved by

  • There may be a formal approval by Sponsor


  • Required for any IS project 

Additional tools


  • 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.