Captions Tables Figures Appendices

Key Terms

This is a very quick overview of how to use captions, tables, figures and appendices in your report. I would always recommend that you use the auto functions in Ms Word.

  1. Caption: The label given to a table or figures (this often mirrors the title of the object)
  2. Table: If it looks like a table it is a table – an object made up of cells
  3. Figures: Not tables – charts and images
  4. Appendix: Is a space (house) which contains additional pertinent material
  5. Cross-reference: A signal to the reader to look at a specific object (figure or table)
  6. Table of Content: A list of all headings used within your report (e.g. level 1 to level 3) with page numbers
  7. List of Figures: A list of all figure captions used within your report with page numbers
  8. List of Tables: A list of all table captions used within your report with page numbers

Readability

The use of cross-referencing is about signposting your reader to supporting materials. This means that cross-referencing needs to achieve at least two outcomes, a) know what and where to look for an object and b) why they are looking at an object. For example… Figure 1, below, illustrates the flow of data around the proposed system.

The secret to good readability is recognising what to present within the text and what to move to the appendix. The best way to think about this is to consider the reading flow. If there are too many images it breaks the flow, however, if the reader is constantly flicking backwards and forwards this will break the flow too. Thus, the object (figure) needs to provide enough information (knowledge) which will allow the reader to engage with the next paragraph. If they are unsure they can choose to look at additional materials in your appendix. This is why it is critical to writing for your target audience.

Remember, if you do not cross-reference an object (i.e. figure or table) why is it in your report!

Captions and Objects

It is important to note that the caption for the table goes above and any citations go below the table (see table 1, below). Whereas figures, the caption goes below and the citation is included in the caption, see figure 1, below. If you do not provide a citation (reference) it is assumed that the object is your own work.

Using Cross Referencing

When cross-referencing an object within the immediate proximity you would use “see table 1, below”

When cross-referencing an object which is more than two pages away you would use “see table 1, pg2” or “see section 2.3, pg18” or “(see section 2.3, pg18)” or “see Appendix 2, table 1, pg45”.

Think of it like this, if you do not provide specific detail your marker will think you are hiding something and start to dig and this is never going to end well for you, the student!

Appendixes

The appendix is a container that houses information in the same way as a house contains rooms. If I want to cook food I would go to the kitchen and if I want to watch the television I would go to the living room. Thus, appendix one contain additional information about customer requirements and appendix two may contain additional information about your primary data.

All images and tables within your appendix will be captioned as figures and tables (see above). Thus cross-referencing needs to tell the reader the following ‘appendix one, figure 1, pg 23.’ By adding the word ‘appendix’ it signals to the reader that it is additional information that is pertinent but not critical to the narrative, allowing the reader to decide if they want to read it or not. The page number is included as this makes it very quick and easy to find figure 1.

Non-Linear Models (Agile)

Possible layout for non-linear models… this will be your implementation chapter.

Initial Requirements

Sprint One: Initial requirements

  • Requirements of sprint
    • What is the purpose of the sprint
      • Tell me what you will do and why
    • Make a list of items like:
      • Objectives
      • Deliverables or outcomes
      • Initial requirements or goals for this sprint
  • Implementation (create and test)
    • Testing
      • Test for feasibility and suitability
      • Test to prove it work and/ or test to refine it
      • Must provide testing evidence and display in graph where possible
  • Decision making (Scrum)
    • Consider using a SWOT Analysis (Strength, Weaknesses, Opportunities, and Threats)
    • Determine requirements for the next sprint
    • Update design diagrams and documents
    • Update list of requirements
    • Confirm which top level (report) success criteria\ objectives were achieved.

Sprint Two: Interface Specification

  • What is the purpose of the sprint
    • Tell me what you will do and why
    • Make a list of items like:
      • Objectives
      • Deliverables or outcomes
      • Initial requirements or goals for this sprint
  • Implementation (create and test)
    • Testing
      • Test for feasibility and suitability
      • Test to prove it work and/ or test to refine it
      • Must provide testing evidence for this sprint and display in graph where possible
  • Decision making (Scrum)
    • Consider using a SWOT Analysis (Strength, Weaknesses, Opportunities, and Threats)
    • Determine requirements for the next sprint
    • Update design diagrams and documents
    • Update list of requirements
    • Confirm which top level (report) success criteria\ objectives were achieved.

Sprint Three: Database Development

  • See sprint two

 

Linear Models (Waterfall)

Possible layout for linear models

Requirements

  • Identification of the problem
    • it is critical to identify the problem because……
  • System analysis (what the system needs to do)
    • highlight what system mapping you will use (UML, data flow diagram etc…)
    • highlight what data you might capture when assessing tasks
  • Feasibility assessment
    • think about the how much time the project will take
    • think about how much money it will cost to develop
    • think about how much money it will cost the company to install on their system
  • List of system requirements
    • User Requirements
    • Software Requirements
    • System Requirements
    • Feasibility

Design

  • User interfaces
    • what user interface will you need
    • who are the primary users of these interfaces
  • Design documents
    • how will you share your interface layouts with your customer
    • how will you show interface interaction with your customer
  • Technical support documents
    • what technical documents will you create and why

Testing

  • See, Testing the artefact
  • System testing
    • what system testing will you do and why
    • how will you undertake these tests
    • what protocols will you use
  • User testing
    • what users will you test and why
    • what tests will you undertake and why
    • what protocols will you use
  • User help documents
    • what help document will you provide for the interface users
    • how will they access and search these documents
  • Finalised technical support documents
    • what technical documents will you provide and why
    • how will these documents be accessed and searched

Deployment

  • Installation on to customer hardware
    • how will you test to make sure that the new software installs correctly
    • how will you test for system and interface errors
  • Maintenance (keep the software up to date and working correctly)
    • what maintenance issues will the client need to consider

Design Documents