Skip to content

Content / Knowledge

Textbook focus

Software Development VCE Units 3&4, Chapter 3, textbook pages 100-116.

Why data collection matters

The textbook explains that data used to construct an SRS is usually collected through:

  • surveys
  • interviews
  • reports
  • observations

This data helps determine:

  • the project scope
  • functional requirements
  • non-functional requirements
  • constraints
  • the end users
  • how the client is going to use the software

Key Point

It is important to choose the most relevant method of data collection for the context.

Surveys

A survey, or questionnaire, usually asks respondents to select a response from a list of alternatives or a fixed range.

Close-ended questions

Close-ended questions use fixed responses such as yes/no or a ranked scale. The textbook explains that these questions produce quantitative data and are efficient to process and analyse.

Open-ended questions

Open-ended questions ask for sentence or worded responses. These questions produce qualitative data and take more time to analyse.

Advantages of surveys

  • relatively inexpensive
  • can be delivered digitally
  • results can be collected immediately
  • can reach a large number of users

Disadvantages of surveys

  • open-ended responses can take a long time to process
  • users may not be truthful
  • users may lose interest if the survey is lengthy

Interviews

An interview is usually conducted face-to-face, sometimes in groups, and can take substantial time. The textbook explains that interviews are valuable because they allow:

  • in-depth follow-up
  • clarifying questions
  • feelings, attitudes and opinions to be explored in detail

Interviews are useful when the information is too complex to capture well in a survey.

Reports

A report is a written document that summarises findings about a system being analysed. The textbook gives examples such as:

  • error reports
  • customer complaint summaries
  • uptime reports
  • performance reports
  • monitoring reports

Advantages of reports

  • often pre-prepared
  • quick to obtain
  • inexpensive
  • data has already been collated and interpreted

Disadvantages of reports

  • interpretation may not be sound
  • the report may be biased
  • the source may not be reliable

Observations

Observation involves physically watching how a system operates or how a manual process is carried out. This is useful when replacing an existing system or when trying to understand why a problem occurs.

Advantages of observations

  • can provide an unbiased view
  • do not rely on opinion or memory
  • more than one user can be observed at the same time if they are in the same place

Disadvantages of observations

  • time-consuming
  • expensive if repeated or conducted over a long period
  • may occur at the wrong time and produce unhelpful data
  • people may act differently when they know they are being observed

Analytical tools

The textbook identifies three key tools for depicting interfaces between solutions, users and networks:

  • use case diagrams
  • context diagrams
  • data flow diagrams

These tools help interpret the data collected in the analysis stage.

Use case diagrams

A use case diagram (UCD) shows how a user interacts with a system. The textbook explains that use case diagrams:

  • provide a structured view of the functionality of a software solution
  • tell a story of how functions within a system work
  • provide a high-level view of user interaction
  • do not show internal functionality
  • do not show the sequence or order of interactions

Use case diagrams are normally completed before context diagrams or data flow diagrams.

Actors

An actor represents an entity that can interact with the software solution. Actors:

  • are described by role, not by a person's actual name
  • may be human users or external systems
  • are shown as stick figures
  • should be labelled with nouns

Use cases

Use cases describe transactions or functions that a user can complete in the system. Use cases:

  • represent system functionality
  • are shown as ellipses
  • should begin with a strong verb
  • should usually be no more than two or three words

Relationships and system boundary

The textbook explains that use case diagrams can show:

  • associations
  • generalisations
  • include relationships
  • extend relationships

Use cases are drawn inside a system boundary. Actors stay outside the system boundary. Nested system boundaries can be used to show what is in scope and what is out of scope.

Context diagrams

A context diagram, sometimes called a Level 0 data flow diagram, is a visualisation of the system as a whole that shows the data flowing into and out of the system.

The textbook explains that context diagrams:

  • are often created after use case diagrams
  • focus on system boundaries and data flow
  • do not usually show much detail

Symbols used in context diagrams

Process

Represents the whole system. In most cases, the diagram contains a single process shown as a circle.

Entity

Represents a user or external system. Entities are shown as rectangles and are labelled by role rather than by the name of a real person.

Data flow

Represents a piece or logical collection of data moving into or out of the system. Data flows are shown as solid lines with open arrowheads.

Drawing conventions

The textbook recommends:

  • placing the single process in the centre
  • balancing entities around it
  • clearly showing the direction of data movement
  • placing data labels close to the correct line

Data flow diagrams

A data flow diagram (DFD) is a graphical visualisation of the flow of information within a system. The textbook states that DFDs provide more detail than context diagrams.

Levels of DFDs

  • Context diagram = Level 0 DFD
  • Level 1 DFD = core processes within the system
  • Level 2 DFD and above = more detailed views of complex processes

If more than one level is used, the data flowing into and out of the related processes must stay consistent between levels.

Elements of a DFD

Process

In a DFD, a process represents a function rather than the whole system. Process names should:

  • be unique
  • use a strong verb phrase
  • usually be no more than two or three words

Each process must have at least one input and one output. The output data should not be identical to the input data.

Entity

Entities in a DFD represent users or external systems. They:

  • are shown as rectangles
  • are labelled by role
  • can only connect to processes

Data flow

Data flows show how data moves:

  • from entity to process
  • from process to process
  • from process to data store

Every data flow must connect to a process and should be named as a noun phrase.

Data store

A data store represents stored data such as a database, a text file or an XML file. It is shown as two parallel lines and should have at least one input and one output data flow.

Checking a DFD

The textbook recommends checking that:

  • every process has a unique strong verb name
  • every process has at least one input and one output
  • output data differs from input data
  • data flows use noun phrases
  • data stores are named appropriately
  • entities match the roles shown in the context diagram
  • overlaps are kept to a minimum