1.3 Characteristics of a software system
Having considered the basic terms ‘system’ and ‘software’, we can move on to the notion of a software system. There are two important questions that we want to address.
- What characteristics should we be looking for in a software system so that we can develop one that meets the needs of all its users?
- What attributes should a software system have in order to be of high quality?
We develop a software system in response to an identified need. For the purpose of this course, we assume a software system is to solve a customer’s problem – this is not always the case as software can be developed without a specific customer, in the hope that someone will buy or use it in the future. The contract between customer and developer, as provider, includes the requirements specification, which identifies what the software should do and the environment in which it must work. We expect a software system to be useful, as otherwise it cannot meet the needs of its users.
To its users, the user interface represents the software system. No matter what functionality is contained in the software, it cannot be used to its full potential if that interface is difficult to use. We expect a software system to be usable – otherwise the user is hindered in their use of the software to carry out tasks.
We expect a software system to be reliable, in that errors are minimised, as otherwise its users will not be able to perform those tasks that need its support.
While developers are busy constructing a software system, it is probable that the users’ needs will change. In addition new requirements are likely to be identified once a software system becomes operational. It is also possible that the developer may miss a requirement during the specification process. We expect a software system to be flexible, because it is important to be able to change it easily as time goes by. In addition, a flexible software system makes it easy to correct errors.
In order to operate in its target environment, any design solution to a requirements specification must be turned into machine-readable code. No matter how useful or usable a software system might be, we expect it to be available in the target environment, offering continually available services in the customer’s environment.
The contract between the customer and the developer will also include delivery dates and costs. Whatever process is used, the developer is expected to meet such contractual constraints. We could also say that the developer’s working practices affect the availability of a software system, including its initial delivery and any subsequent changes. From the customer’s point of view, the software system must be affordable to buy and maintain.
From the developer’s point of view, there must be a way of keeping control of a project. Labour resources are the most significant component of a developer’s contract, and often become the two-edged sword that leads to the success or failure of a software development project.
Software development is concerned with the activities that lead to a useful software system – techniques that will help you to define a requirements specification and then produce a design solution to the problem contained in the specification.
Activity 3 Good software systems
- a.What is the defining quality of a good software system, and what are its main characteristics?
- b.How might greater flexibility make a software system more affordable over its whole life?
- c.Give two reasons why a delivered software system might not meet its users’ needs.
- a.A good software system is one that meets its users’ needs. We can characterise a good software system as useful, usable, reliable, flexible, available and affordable.
- b.Users’ needs will change over time. The time taken to implement the changes in requirements in a flexible system is less than for less flexible software. As labour costs are the most significant component of software costs, flexible software is more affordable.
- c.Software systems are usually out of date even as they are being developed because:
- some needs are often missed during requirements capture
- users’ needs change with time.