A requirements specification must completely define the tasks that
are to be performed by the program or system, as well as any
constraints that are placed on its development or use.
Requirements are of several kinds:
- Functional: Determine how users
interact with the software and how the software should behave when
it is used correctly:
- What inputs the system should accept, and under what
conditions
- What output the system should produce,
and under what conditions
- What data the system should store that
users or other systems might retrieve
- What computations the system will perform
- Platform: the hardware, operating system,
and technology the software will use
- Process: development methodology, delivery
date, and cost
- Quality: the features of the software that provide
its value to its stakeholders.
Evaluation of software quality depends on aspects of the situation in
which it is embedded.
Evaluation of quality also depends on the level of skill and
sophistication of the user.
Three general classes of users:
- Other software developers:
- Can handle a complex interface and
occasional failures
- Worry less about the ease of learning of the software
- Technically-minded professionals:
- Are probably familiar with using software routinely
- Are most concerned with correctness
- Those who have never used software in their jobs:
- Expect naivete, with ease of learning
and robustness most important
- Expect possible hostility, especially if user
worries about software replacing him/her
Finally, evaluation of quality depends on the technological context.
For example:
- Minimal response time and resource
usage are of lesser importance today than they were when hardware
capabilities were more limited.
- As a consequence of the development of more complex software, the
importance of ease of reuse, maintenance, and verification has greatly
increased.
The values and value concepts presented here are only a
first step towards learning to judge quality.
Although it is easy to grasp the values and value concepts in terms of
their purpose and general nature, a good software engineer spends a
lifetime learning to use them effectively to judge software quality.
Judgement is difficult, first, because the ability to understand a value concept
does not automatically give you the ability to
recognize when it is
applicable.
One does not see where to apply value concepts until one has
gotten into the habit of looking out for them. For example:
- You often do not see couplings until you have seen an
alternative (often in the form of a design pattern) that avoids them
- You might not see problems with ease of use until you have see a
better user interface
Judgement is also difficult because software quality is a
network of
values with complex relationships between them.
The values network is initially just a framework for your later
understanding:
- As you acquire experience, you develop the ability
to see relationships between the concepts so that you can more
comfortably navigate within the framework.
- Your experience is also recorded within that
framework as judgements of what is important and in what contexts is it important.
An example of the complex relationships among software values
is
tradeoffs, where values come in conflict with each other.
Every engineering endeavor involves value tradeoffs, and software
engineering is no different. For example:
- Response time vs. Encapsulation:
- Many inexperienced programmers will use
global variables for a small gain in response time.
- More experienced programmers are aware of the
consequences: maintenance can get much harder.
- Timely delivery vs. Correctness:
- It takes a lot of experience to decide between
delivering a flawed product now or a better product later.
- Data security vs. Ease of use:
- For example, deciding when to time out an idle
banking session