Queensland University of Technology   Brisbane Australia Skip bannerSkip to content A university for the real world - Information Technology Services
QUT Home TILS Home
Staff Directory Contact us
ITS Home About ITS Assistance Services Governance

Systems Development Framework - Documentation

Governance
Project Management
IT Service Management
Web Governance Linked to another ITS website.
Systems Development
  When to use this Framework
  Types of development life cycles
  "Not so soft" projects
  SDF Phases
  Project Documentation
  Summary Table and templates
  Appendices
  Checklists
  Additional resources
Quality Management
- - - - -
Change Management
Continuous Improvement Program
- - - - -
Policies & Standards
Commitees, Groups and Working Parties
Forms
- - - - -

[Print-friendly version]

General documentation produced through the various phases should contain certain key elements;

  • headers should include the project/sub-project name, AMP project reference number (where AMP funded) or internal reference number


  • footers should include filename, date of document (not date printed field) and page numbering including total number of pages.


  • Document cover and title pages should include the document version number and person and/or section author.

This framework refers to a number of different types of documents and reports. Some of these are included in the PMF as templates. Others may vary depending upon the nature of the specific development project . Specific technical and design documents such as data dictionaries, process flow diagrams, etc. are fairly basic in concept but may vary considerably depending upon the particular development tool or technology being used and consequently are not provided here. Individual sections within QUT should have specific examples of the most appropriate technical documentation for their areas.

The amount of information and level of detail included in various system development documents depends upon the size and complexity of the project. A business requirements specification could, at a minimum, consist of just a few pages with a couple of screen dumps and a user guide may consist of no more than a few screens of online help particularly for many simple web based applications. On the other side are the large system packages such as Callista, Concept and Oracle Financials which have hundreds of pages of technical documentation, installation guides, reference manuals and procedures manuals.

In all cases care should be taken that adequate documentation and procedures are prepared to ensure:

  • that all project participants are clearly aware of and understand
    • what the system is required to do,
    • the nature of the specific architectural, design and development activities required,
    • their particular role within the project
  • that clients and team members can be confident that all required functionality is comprehensively tested
  • that staff involved in ongoing support and maintenance such as client system areas, system developers, desktop support staff, central systems, operations, and helpdesk staff are aware of how the system should function, any expected performance measures, how to resolve any problems that arise, and easily identify how to perform any required enhancements or modifications.
  • end-user clients know what the system does, how to use it, and where to go to or who to contact for any problems.