Sommerville-Software-Engineering-10ed

564 Chapter 19 ■ Systems engineering
Concept formulation
Problem understanding
System proposal development
Feasibility study
System structure development
Figure 19.7 Conceptual
design activities
System vision document
I don’t like the term Concept of Operations partly because of its military connotations
and partly because I think that a conceptual design document is not just about
system operation. It should also present the system engineer’s understanding of why
the system is being developed, an explanation of why the design proposals are appropriate,
and, sometimes, an initial organization for the system. As Fairley says, “It
should be organized to tell a story,” that is, written so that people without a technical
background can understand the proposals that are being made.
Figure 19.7 shows activities that may be part of the conceptual design process.
Conceptual design should always be a team process that involves people from different
backgrounds. I was part of the conceptual design team for the digital learning
environment, introduced in Chapter 1. For the digital learning environment, the
design team included teachers, education researchers, software engineers, system
administrators, and system managers.
Concept formulation is the first stage of the process where you try to refine an
initial statement of needs and work out what type of system would be best to meet
the needs of system stakeholders. Initially, we were tasked with proposing an
intranet for information sharing across schools that was easier to use than the current
system. However, after discussions with teachers, we discovered that this was
not really what was required. The existing system was awkward to use, but people
had found workarounds. What was really required was a flexible digital learning
environment that could be adapted by adding subject and age-specific tools and
content that are freely available on the Internet.
We discovered this because the concept formulation activity overlapped with the
activity of problem understanding. To understand a problem, you need to discuss
with users and other stakeholders how they do their work. You need to find out what
is important to them, what are the barriers that stop them from doing what they want
to do, and their ideas of what changes are required. You need to be open-minded (it
is their problem, not yours) and to be prepared to change your ideas when the reality
does not match your initial vision.