VCE Software Development - U3O2 - Analysis and Design Hangman

The 114 key terms

1Need or opportunity

A problem worth solving or a gap worth exploring, forming the starting point for developing a digital solution

2stakeholder

Any person or group who uses, is affected by, or has an interest in a digital solution, such as users, the client, developers and people affected indirectly.

3productivity and efficiency

A reason to build software: do more work in less time or effort by automating manual tasks, cutting errors and rework, and speeding up processing.

4reducing costs

A reason to build software: it lowers an organisation's running costs by saving staff time, paper, errors and equipment, so the development cost is repaid over time.

5gap in the market

A need that no existing product meets well, so an individual or business builds new software to serve a target market and take advantage of competitor weaknesses.

6organisational objective

A stated goal an organisation wants to achieve, such as growth, compliance or a new service, which a software project is undertaken to help meet.

7software development brief

A short document that records a problem, need or opportunity so the client and developer agree on what the project is about. It is the written starting point for the project.

8Problem, need or opportunity outline

The part of a brief that clearly and briefly describes the current situation, the need or opportunity, and why a solution is wanted.

9proposed users

The people a brief names as expected to use the software, with their skills and needs, so the design can suit them.

10programming languages to be used

A brief feature naming the language(s) the solution will be built in, with a reason, such as suiting the platform, the developer's skills or the libraries available.

11feasibility

A judgement of whether a project can realistically be completed given its time, cost, skills and technology (technical, economic and time feasibility).

12originality

How a proposed solution is new or different from existing software, such as unique features, while avoiding copying the work of others.

13task breakdown

Splitting a whole project into small tasks, each with a clear outcome, a time estimate and an order (dependencies), so you can track progress as the work gets done.

14Gantt chart

A project management tool that shows tasks and their timeframes as horizontal bars along a timeline

15Sequencing

Putting tasks in the order they must happen on a Gantt chart. Tasks that depend on others start after them, while independent tasks can run in parallel (at the same time).

16time allocation

The estimate of how long each task will take, shown on a Gantt chart as the length of its bar. Bars are measured in days or weeks and together set the total project length.

17dependency

A link between two tasks where one cannot start or finish until the other is complete. The first is the predecessor, the next is the successor. Shown on a Gantt chart by an arrow.

18milestone

A marked checkpoint in a project plan, such as a finished prototype, showing a major piece of work is complete by its deadline. Used to check progress.

19critical path

The longest chain of dependent tasks in a project. It sets the shortest possible finish time, and any delay to a task on it delays the whole project. Tasks off it have float.

20project log

A record of each work session: the date, what was done, any problems and the next step. It shows actual progress against the plan and evidences why the plan changed.

22Data collection method

A structured technique, such as an interview, survey, or observation, used to gather information about user needs before designing a solution

23interview

A data collection method where you ask a person open questions about an issue and record their views, giving qualitative data. It is rich in detail but a small sample may not represent everyone.

24observing

Watching a user do a task to see where they get stuck, without helping or interrupting. You write down what you see instead of just asking them what they think.

25survey

A survey collects data by asking everyone the same clear questions, such as closed or open questions on an online form, so the answers can be counted and compared.

26secondary data

Data already collected by someone else, such as error logs, sales or incident reports. Analysts study it to find problems and needs, after checking it is current and reliable.

27thematic analysis

Sorting similar interview and survey responses into themes, then counting how often each appears, so the most common problems and wishes become the user needs.

28The solution must

Starts a functional requirement: one thing a digital solution must do. It says what the solution does, not how, and covers one action. Example: The solution must show the score.

29Non-functional requirement

A quality describing how well a system performs, such as speed, security, or reliability, rather than what it does

30measurable non-functional requirement

A quality of a solution, such as speed, security or usability, written with a testable target, like a page loads in under 2 seconds, so you can check whether it is met.

31constraint

A limit on how a solution can be made, such as time, cost, skills, devices or software. A constraint is not a feature; it limits what you can build.

32economic constraint

A limit on money that restricts a solution, such as a fixed development budget, software licence fees, or the ongoing costs of hardware, hosting and staff.

33legal constraint

A law or regulation a solution must obey, such as privacy law, copyright and licensing rules, or industry regulations. It limits what the software can do and how it handles data.

34social constraint

A limit on a solution from the needs, values or abilities of the people affected, such as accessibility, cultural expectations and user acceptance.

35Technical constraint

A limit set by technology, such as the hardware, operating system, network or existing software, that a solution must work within.

36scope

The boundary of what a solution will and will not include. Features inside the boundary are in scope. Features left out, or saved for later, are out of scope.

37version boundary

A line that sets which features go in the current release and which wait for a later version. It also marks where the solution ends and other systems begin.

38requirements list

A list that sorts what a solution must do (requirements) from the limits it must work within (constraints), for one problem. Each item should be clear and testable.

39analytical tools

Diagrams like context, data flow and use case diagrams that show how users, data and systems relate, so the existing system is understood before a solution is designed.

40context diagram

A Level 0 diagram that shows the whole system as one process in the centre, with external entities around it outside the system boundary.

41data flow

A labelled arrow on a context diagram showing data passing between an entity and the system. The arrowhead shows direction (input or output) and the label names the data.

43Level 1 DFD process

A numbered, named step (e.g. 1.0 Validate Order) in a Level 1 DFD. It uses a verb phrase and shows one main task from the context diagram's single system.

44Data store

On a Level 1 DFD, a data store is where data is held (e.g. a file or database). Entities sit outside the system and send or receive data. Both must match the context diagram.

46Level 1 DFD

Breaks a system into processes, data stores, entities and labelled flows found in a scenario, then checks the rules, e.g. every process has an input and an output and no flow is missing.

47Use case diagram

A diagram showing actors (stick figures) outside a system boundary box, linked by lines to the use cases inside the box that they can do with the system.

48use case

A goal an actor achieves with the system. It is drawn as an oval named with a verb phrase (e.g. Borrow Book) and joined to its actor by an association line.

49<<include>> vs <<extend>>

<<include>>: a use case always uses another (arrow points to the included one). <<extend>>: optionally adds behaviour (arrow points from the extending case to the base).

51Depicting an existing system

Using analytical tools like context and data flow diagrams to show how the current system works, so bottlenecks and problems are exposed for the new solution to fix.

52Software requirements specification (SRS)

A formal document recording what software must do, so client and developer agree, and used as the basis for design, testing and reference during development.

53SRS content

The parts of an SRS that state the functional and non-functional requirements, the constraints on the solution, and its scope (what is and is not included).

54technical environment

The SRS section describing the users (their skills and needs) and the hardware, operating system, software and network the solution will run in.

55SRS analytical tools

An SRS includes context, data flow and use case diagrams to show how an existing system works, and these diagrams link to the requirements.

56Copyright Act 1968 (Cwlth)

Australian legislation that automatically protects original creative works, like software and images, from being copied or used without permission

57Ownership and control of data

Who has the right to hold, change, share and delete data about a person or topic. An organisation may hold the data, but the person it describes should keep some control.

58Privacy Act 1988

Commonwealth legislation that sets rules for how organisations must collect, use, and store people's personal information.

59Australian Privacy Principle 1

Requires organisations to be open and transparent about managing personal information, with a clear, available, up-to-date policy.

60APP 3

Australian Privacy Principle 3: only collect personal information that is reasonably necessary for your functions, and collect it lawfully and fairly. Take extra care with sensitive information.

61Australian Privacy Principle 6

Requires organisations to only use or disclose personal information for the purpose it was originally collected for, unless consent or an exception applies.

62APP 8

Before sending personal information overseas, such as to a cloud server, an organisation must take reasonable steps to make sure the overseas recipient will also protect it.

63APP 9

An organisation must not adopt a government identifier (e.g. Medicare or tax file number) as its own ID for a person. It should use its own customer ID, with limited exceptions.

64Australian Privacy Principle 11

Requires organisations to protect personal information from misuse, loss, and unauthorised access, and to destroy it when no longer needed.

65Privacy and Data Protection Act 2014

Victorian legislation that sets rules for how the Victorian public sector must collect and securely protect personal information.

66IPP 1

Information Privacy Principle 1 (Vic): only collect personal information that is necessary for your functions, collect it lawfully and fairly, and tell people why you are collecting it.

67Information Privacy Principle 2

Requires personal information to be used or shared only for the purpose it was originally collected for, unless consent or an exception applies.

68Information Privacy Principle 4

Requires organisations to take reasonable steps to protect personal information from misuse, loss, unauthorised access, and unwanted modification.

69Information Privacy Principle 5

Requires organisations to be open and transparent about managing personal information, with a clear, available, up-to-date policy.

70IPP 7

Limits an organisation from assigning or sharing a unique identifier for a person unless it is necessary for its functions, with limited exceptions.

71IPP 9 transborder data flows

IPP 9 lets an organisation send personal information outside Victoria only if the recipient is bound by similar privacy protection, or the person consents.

72IPP 10: sensitive information

Victorian privacy principle: sensitive information (health, ethnic origin, beliefs) can only be collected with the person's consent or when the law allows it.

73APP critique

Check a system against one APP at a time: say what it does, judge if it meets that principle using evidence from the policy or audit, then suggest an improvement.

74Version history

A tool in a shared folder that records who changed a file and when, so you can view earlier versions and restore one. Clear names with dates or version numbers help too, like Plan_v2_2025-03-14.

75version control

A system that records every change to project files, so developers can see who changed what, work in parallel on branches, and roll back to an earlier version.

76Backup strategy

A plan for how and when backups are taken and stored, such as scheduling regular backups and keeping copies in multiple locations.

77full backup

A backup that copies all selected files every time it runs. Restoring is simple, but it uses lots of storage and takes longer than other backup types.

78incremental backup

A backup that copies only files changed since the last backup of any type. It is small and fast, but a restore needs the full backup plus every increment.

79differential backup

Copies all files changed since the last full backup. It grows each day, and a restore needs the full backup plus only the latest differential.

80full vs incremental vs differential

They differ in size, time and restore steps: full copies all data, incremental saves changes since the last backup, differential saves changes since the last full backup.

81permission

A rule that lets an account read, write or execute a file or resource. Read only views it, write can change or delete it, and execute runs it as a program.

82disposal

Permanently destroying files and storage media no longer needed (e.g. secure deletion, shredding old drives) so data cannot be recovered, once any retention period ends.

83Ideation technique

A structured method used to generate a wide range of possible solutions to a problem before one is selected for development

84brainstorming

Listing as many ideas as possible quickly, with no early criticism and quantity first, then reviewing the ideas afterwards and grouping them to find the best ones.

85mind map

A diagram with a central topic in the middle and branches and sub-branches that link related ideas, used to generate and organise ideas during design.

86mood board

A collage of colours, images, fonts and styles that shows the look and feel wanted for a design, helping a team agree on a visual direction before building the interface.

87screen sketch

A simple drawing of a screen. It has an outline, then a box or shape for each button, text box or label, drawn where it will go. You draw one sketch for each screen.

88annotation

A short note on a design that says what an element does or what happens when it is used, like a label on a button or an arrow showing which screen opens next.

89design criteria

Checkable standards, such as easy to read, easy to navigate or meets the requirements, that an interface is designed to meet and then judged against.

90decision matrix

A table that scores each design idea against each criterion, then totals the scores (weighting key criteria) so the best design can be chosen using evidence.

91Evaluation criteria

Measurable standards used to judge how well a finished solution meets its original requirements and purpose

92efficiency

How well a solution uses resources such as time, processing, memory, storage and user effort to do its job. An efficient solution is fast, light on memory and storage, and saves the user time.

93Effectiveness

How well a solution does what it was meant to do, giving correct, complete and usable results that meet the requirements and suit its purpose.

94data dictionary

A table listing each data element with its name, data type, size or format, description and validation rule, so everyone uses the data the same way when coding and testing.

95studentAge, integer, 2 digits, age in years, 15, 11 to 19

One data dictionary row for a data item: name, data type, format or size, description, example value and validation rule. Written from a requirement or IPO chart.

96Mock-up

A static visual representation of a solution's interface, showing layout and design before development begins

97object description

A design table for a class that lists its name, its attributes with data types, and its methods with their parameters and purpose.

99IPO chart

A three-column table listing a solution's inputs (data entered), the processes applied to that data, and the outputs it produces, such as a total or report.

100pseudocode

A way of writing algorithms using plain English and common symbols without the rules of any specific programming language, used to plan logic before coding begins

101end if

A closing keyword in VCAA pseudocode that ends an if block; every nested construct uses end followed by its matching keyword: end if, end while, end for

102IPO to pseudocode

Turn each IPO input into an INPUT statement, each process into assignments or IF selection, and each output into a PRINT statement, in that order.

103user experience (UX)

How easy, efficient and pleasant a system feels to use from start to finish, not just how it looks. Good UX avoids frustration points, while UI is only the look.

104affordance

When the look of a control signals how it can be used, such as a raised button that looks pressable or a slider handle that looks draggable. Clear visual cues make actions obvious.

105interoperability

The ability of software to work with other systems, devices and file formats and exchange data with them, for example by using standard formats like CSV or PDF across platforms.

106Authentication vs authorisation

Authentication checks who you are, like logging in. Authorisation decides what you can do once you are known, like which files you can open. Authentication always comes first.

107multi-factor authentication

A login step that asks for a second proof of identity, like a phone code or app prompt, as well as your password. A stolen password alone is not enough.

108security measures

Controls such as passwords, access control, encryption and backups that protect personal information in a dataset from misuse, loss or unauthorised access.

109usability

How easily, quickly and accurately users can learn and use software to achieve their goals, including ease of learning, efficiency of use, and error prevention and recovery.

110accessibility feature

A design choice that lets people with different abilities use a system, such as alt text for images, captions for video, keyboard-only controls or colour-blind safe colours.

111UX characteristics

Affordance, interoperability, security and usability. Designers review a solution against each one and balance trade-offs, such as stronger security making a system harder to use.

112alignment

A UI design principle that lines up elements along common edges or centres, such as a left edge or grid, so the layout looks tidy and is easy to scan.

113balance

The even spread of visual weight across a screen so no side feels too heavy. It can be symmetrical (mirrored) or asymmetrical (different elements that still feel equal in weight).

114contrast

The difference in colour, size or brightness that makes key elements and text stand out from their background so they are easy to read and notice.

115space

The empty area around and between interface elements, used to group related items, separate unrelated ones and keep a layout uncluttered and easy to read.

116text formatting

Using font, size, weight and colour consistently so text is easy to read and shows importance, such as larger bold headings above smaller body text.

117feedback

A response from the interface that tells the user what happened, like a confirmation message, or an error message that says what went wrong and how to fix it.

118user flow

The path of screens a user follows to finish a task, like logging in or buying a ticket. Navigation controls such as back and home buttons help them move along it in as few steps as possible.

119Annotated design review

Checking a mock-up against each UI principle in turn (alignment, balance, contrast, space, text), annotating the improvements needed, then revising the design.