O'Reilly logo

Essentials of Software Engineering, 3rd Edition by Barbara Bernal, Orlando Karam, Frank Tsui

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

1.1 A Simple Problem
In this chapter we will analyze the tasks involved in writing a relatively simple program.
This will serve as a contrast to what is involved in developing a large system, which is
described in Chapter 2.
Assume that you have been given the following problem: “Given a collection of lines
of text (strings) stored in a file, sort them in alphabetical order, and write them to another
file.” This is probably one of the simplest problems you will be involved with. You have
probably done similar assignments for some of your introduction to programming
classes.
1.2 Decisions, Decisions
A problem statement such as the one above does not completely specify the problem.
You need to clarify the requirements in order to produce a program that better satisfies
the real problem. You need to understand all the program requirements and the
design constraints imposed by the client on the design, and you
need to make important technical decisions. A complete problem
statement would include the requirements, which state and
qualify what the program does, and the design constraints, which
depict the ways in which you can design and implement it.
The most important thing to realize is that the word require-
ments is not used as it is in colloquial English. In many business
transactions, a requirement is something that absolutely must
happen. However, in software engineering many items are nego-
tiable. Given that every requirement will have a cost, the clients
may decide that they do not really need it after they understand
the related cost. Requirements are often grouped into those that are “needed” and those
that are “nice to have.”
It is also useful to distinguish between functional requirements—what the program
does—and nonfunctional requirements—the manner in which the program must
behave. In a way, a function is similar to that of a direct and indirect object in grammar.
Thus the functional requirements for our problem will describe what it does: sort a file
(with all the detail required); the nonfunctional requirements will describe items such
as performance, usability, and maintainability. Functional requirements tend to have
a Boolean measurement where the requirement is either satisfied or not satisfied, but
nonfunctional requirements tend to apply to things measured on a linear scale where
the measurements can vary much more. Performance and maintainability requirements,
as examples, may be measured in degrees of satisfaction.
Nonfunctional requirements are informally referred as the “ilities,” because the words
describing most of them will end in “-ility.” Some of the typical characteristics defined
as nonfunctional requirements are performance, modifiability, usability, configurability,
reliability, availability, security, and scalability.
Besides requirements, you will also be given design constraints, such as the choice of
programming language, platforms the system runs on, and other systems it interfaces
Program requirements Statements that
define and qualify what the program needs
to do.
Design constraints Statements that con-
strain the ways in which the software can be
designed and implemented.
Functional requirements What a program
needs to do.
Nonfunctional requirements The manner
in which the functional requirements need
to be achieved.
2 Chapter 1 Writing a Program
91998_CH01_Tsui.indd 2 1/10/13 6:19:01 AM

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required