Skip to content

Content / Knowledge

Textbook focus

Software Development VCE Units 3&4, Chapter 3, textbook pages 102-108.

Solution requirements

The textbook describes solution requirements as what the client needs from the solution; in other words, what the system must do. These are divided into:

  • functional requirements
  • non-functional requirements

Functional requirements

Functional requirements are directly related to what the solution will do. The textbook gives examples such as:

  • calculations
  • data processing
  • opening, reading and writing to files
  • data manipulation
  • other specific functionality required within the system

Functional requirements are usually written in terms of:

  • the inputs required
  • the sequence of operations performed
  • the outputs after processing

Examples given in the textbook include:

  • save customer data to a file
  • calculate discount values on products
  • set an alarm to go off at a particular time
  • load a set of jobs into a timetable

Non-functional requirements

Non-functional requirements are requirements the user or client would like the solution to have that do not change what the solution does. The textbook refers to these as quality requirements.

Important

Non-functional requirements must be measurable so they can be tested.

The textbook organises non-functional requirements into five areas.

Usability

Usability is about how easy a system is to learn and use. It is often described in terms of efficiency and effectiveness. The textbook highlights:

  • clarity of the user interface
  • intuitiveness of the functions
  • user satisfaction

Example from the textbook: users should be able to use all basic functions after one hour of training.

Reliability

Reliability is about how much the software can be depended on to function as designed, and for how long. It is linked to being fit for purpose over time and resistant to failure.

Example from the textbook: the system should have a 99.9% uptime over any 12-month period.

Portability

Portability is about how easily the software can be used in different operating environments. This can include:

  • moving from one system to another
  • reinstalling on a new system
  • working across multiple operating systems
  • working across multiple platforms or languages

Robustness

Robustness is about how well the software responds to errors when it is being used. It is closely linked to error handling and validation.

Example from the textbook: the system should reject invalid data entered by a user.

Maintainability

Maintainability is about how easy the software is to look after once it is in use. This includes:

  • fixing errors
  • improving efficiency and reliability
  • installing on new systems
  • adding new functionality

Example from the textbook: fewer than 10 hours should be spent per quarter on maintaining the system.

Scope

The scope defines the boundaries of the software solution. The textbook explains that the scope describes:

  • what the project will do
  • what the project will not do

Clear scope is important because a project without limits will never be finished and disputes will arise about what was or was not included.

The textbook also explains that scope:

  • defines the boundaries of the project
  • includes technological, resource and time limitations
  • helps manage expectations
  • helps prevent scope creep

When thinking about scope, the textbook suggests that each cycle of the problem-solving methodology can produce a version of the software with its own unique scope.

Constraints

Constraints shape the final product and influence what can realistically be included. The textbook groups constraints into:

  • economic
  • legal
  • social
  • technical

Economic constraints

Economic constraints are financial limitations. They influence:

  • budget
  • scale and ambition
  • team size
  • technology choices
  • prioritisation of features

For VCE Software Development, the textbook specifically names:

  • Copyright Act 1968
  • Privacy Act 1988
  • Privacy and Data Protection Act 2014

Legal constraints matter because failure to meet legal requirements can lead to penalties, legal action and damage to reputation.

Social constraints

Social constraints are shaped by:

  • societal norms
  • cultural practices
  • ethical considerations
  • stakeholder expectations

The textbook links these to inclusivity, accessibility, cultural sensitivity and public acceptance.

Technical constraints

The textbook includes technical factors such as:

  • hardware limitations
  • software dependencies
  • programming languages and development tools
  • system integration
  • scalability and maintainability
  • performance requirements
  • security requirements
  • user interface and user experience factors
  • network and connectivity
  • resource availability

Software requirements specification (SRS)

The textbook defines an SRS as a single document containing the outcomes of the analysis stage of the problem-solving methodology. It is created after data collection and before the design stage.

An SRS must outline:

  • constraints
  • scope
  • functional requirements
  • non-functional requirements

It may also include:

  • appendices with extra information needed to interpret the requirements
  • technical environment details
  • performance parameters such as response time, processing time, maintenance requirements, resource demands, security arrangements and backup arrangements
  • relevant diagrams, such as use cases, context diagrams and DFDs

Key Point

A well-written SRS becomes the basis for design specifications and for evaluating the success of the final product.

The textbook explains that a well-written SRS ensures:

  • the problem, need or opportunity is understood
  • the issues have been identified and documented systematically
  • the completed SRS becomes the basis for design specifications
  • the criteria identified in the SRS are used to evaluate the final product
  • the final evaluation verifies that the software performs as expected

Creating an SRS

The textbook sets out a clear structure for this document.

Required document features

  • a cover page with the project name, author or authors, contact details and version
  • a table of contents on the first page after the cover page
  • numbered headings and subheadings
  • page numbers

Typical contents

  • technical environment
  • functional requirements
  • non-functional requirements
  • constraints
  • scope

Appendices

Any extra documentation should be placed in appendices. The textbook gives examples such as:

  • reports
  • interview evidence
  • observation evidence

Presentation

Because an SRS is a professional document, the textbook states that consistency in fonts, font sizes and font colours is important.

Important

The textbook notes that an SRS can act as a contract between a client and a developer and helps prevent scope creep.