Skip to content

a. What You Need To Know

Characteristics of a software solution

Before any code is written, a software solution needs to be clearly described. A solution is much easier to build successfully when everyone understands:

  • what the solution must do
  • what quality it needs to have
  • what limits apply to the project
  • what is included and what is excluded

The three big ideas here are:

  • scope
  • functional requirements
  • non-functional requirements

Scope

The scope sets the boundaries of the solution. It makes clear what the project will include and what it will not include.

A good scope helps prevent confusion later because it stops people making different assumptions about the finished product.

In scope

These are the features, outputs and qualities that the solution is expected to include.

Out of scope

These are features or ideas that have been deliberately left out, often because of time, money or technical limitations.

Key Point

Scope is about boundaries. If a feature is not in scope, it should not suddenly appear halfway through development unless the project is formally changed.

Scope creep

Scope creep happens when more and more requirements are added during development. This can make a project harder to finish on time and can force rushed or poor-quality decisions.

Functional requirements

Functional requirements describe what the solution must do.

These usually relate to:

  • input
  • processing
  • storage
  • output
  • specific actions or behaviours in the system

Examples of functional requirements include:

  • save customer data
  • calculate a discount
  • display a result
  • load records from a file
  • reject invalid data

Functional requirements are often easiest to describe by thinking in terms of:

  • the inputs needed
  • the steps or operations performed
  • the outputs produced

Student Tip

If a requirement describes an action the system performs, it is probably functional.

Non-functional requirements

Non-functional requirements describe the qualities the solution should have rather than the actions it performs.

They do not change what the solution does, but they do affect how well it works.

Common categories include:

  • usability
  • reliability
  • portability
  • robustness
  • maintainability

Usability

Usability is about how easy the solution is to learn and use. A usable interface is clear, efficient and intuitive for the intended users.

Reliability

Reliability is about whether the solution can be depended upon to keep working as expected over time.

Portability

Portability is about whether the solution can operate in different environments or on different platforms.

Robustness

Robustness is about how well the solution handles errors and unexpected situations.

Maintainability

Maintainability is about how easy the software is to fix, modify or improve after it has been developed.

Common Error

Do not confuse functional and non-functional requirements. "Calculates wages" is functional. "Must be easy for office staff to learn" is non-functional.

Constraints

Constraints are the factors that limit what can realistically be built.

Even if a feature sounds useful, it may not be possible because the project has restrictions.

Common constraints include:

  • economic constraints such as budget and time
  • technical constraints such as hardware, software or storage limits
  • social and usability constraints linked to users and context
  • legal constraints linked to privacy, copyright or data handling

Why constraints matter

Constraints force choices. They can affect:

  • how ambitious the solution can be
  • which features are included
  • which tools are used
  • how polished the final product can become

Design tools

Design tools help you plan the solution before you build it. This reduces wasted time because problems can be identified before code is written.

Mock-ups

A mock-up is a sketch of how an interface will look. It is useful when your solution has screens, controls, labels, buttons or other interface elements.

A good mock-up helps another person understand:

  • what appears on the screen
  • where controls are placed
  • what the user will interact with

Pseudocode

Pseudocode is a language-independent way of describing an algorithm. It focuses on logic rather than exact programming syntax.

Pseudocode is useful because:

  • it is faster to write than full source code
  • it can be adapted to different languages later
  • it lets you focus on the sequence of logic

Flowcharts

Flowcharts show the flow of instructions visually. They are helpful for following sequences, decisions and loops.

IPO charts

IPO stands for Input-Process-Output. An IPO chart helps you separate:

  • the data entering the system
  • the processing done to that data
  • the output produced

Key Point

Design tools are not decoration. They help you think through the logic, interface and behaviour of the solution before development starts.

What this means for your folio

For each programming task, you should be able to:

  • identify the scope
  • separate functional and non-functional requirements
  • recognise important constraints
  • choose a design tool that matches the task

In short, do not jump straight into coding. Read the brief, work out the boundaries, and represent the solution clearly first.