• 33.1 Introduction
• 33.2 Why do this?
• 33.3 Different kinds of projects
• 33.4 Investigating purpose
• 33.4.1 Who are stakeholders?
• 33.4.2 Who is each stakeholder?
• 33.4.3 What does a customer or stakeholder want?
• 33.4.4 Customer objectives
• 33.4.5 Funder and organization business objectives
• 33.4.6 Regulatory objectives
• 33.4.7 Third party objectives
• 33.4.8 Safety objectives
• 33.4.9 Security objectives
• 33.4.10 Synthesis
• 33.4.11 Results
• 33.4.12 Techniques and tools
• 33.4.13 The project team
• 33.5 Competition
• 33.6 Defining scope
• 33.7 Artifacts
• 33.8 Validating purpose
• 33.9 Review milestone
• 33.10 Change of purpose
• 33.11 Using purpose

33.1 Introduction

A system’s purpose is the set of things that it should achieve for different stakeholders (Chapter 9). The purpose is a record of the reasons for investing resources and time into making the system. The purpose gives direction for all the work developing a concept and design for the system. A system is acceptable if it meets its purpose; anything in the system that does not contribute to the purpose is waste.

Developing the system purpose is part of the reference life cycle, as discussed in Section 28.3.

The development of every system and every component should begin with establishing its purpose. Understanding purpose is the first step to working out the specifications for a system or component. Trying to develop a concept or specification without working out purpose usually leads to developing the wrong thing. In Section 9.2, I laid out why it is important to work out purpose first.

The purpose for an entire system is likely to be complex, and it will take time and effort to find out the purpose. The understanding of the purpose for a system—or a complex component of it—is likely to evolve as time goes by, because people won’t realize everything they want all at once. The full understanding usually comes iteratively, as stakeholders review system concepts and discover something they missed.

Some components have simple purposes. The purpose for a bolt, for example, is just to connect some physical components and transfer force between them. Knowing what those components are, what they are made of, the environment the assembly will be in, and what forces the bolt must handle are most of the purpose. This kind of purpose does not need a drawn-out investigation or a complex record. It does still need to be established and written down, however.

The input to developing purpose is usually vague and unorganized. It includes general ideas for a system and who might be interested. It proceeds through discussions with potential customers and background research on them. It can include market research when a system might be built to sell to as yet unidentified customers. It can also include documents from a potential customer, such as a request for proposals (RFP).

The output of purpose development is a set of documents and other records. The primary outputs are a statement of who the system stakeholders are and what they need or want. The output also includes the unedited, uninterpreted records of what customers or stakeholders have said, so that the final record of purpose can be checked against the original information. Maintaining a record of how the team has learned to interpret what a customer said also helps check the final result.

The purpose is different from a specification or requirements. The purpose is a collection of statements of needs and wants. It will become the source for requirements, but the purpose is more high-level than requirements and does not try to have the same precision. The purpose is usually imprecise where specifications are precise and verifiable. Requirements specify everything necessary about a system or component, while purpose is limited and does not reflect decisions about system or component structure.

The general approach to developing the purpose is as follows:

• Work out who will be using the system or component—who the stakeholders are.
• Investigate their needs, recording their direct input for future reference.
• Document those needs in an organized way.
• Have the stakeholders review the relevant parts of the documented needs to ensure it accurately captures what they mean.
• Iterate until all the stakeholders are satisfied and the documented purpose is clear enough to proceed to developing a concept for a solution.

Parts of this process will repeat as concept, specification, and design proceed. When parts of the purpose change, people need a clear indication of the difference between the old and new purpose so that they can determine what needs to be changed in concept, specification, or design to meet those changes.

33.2 Why do this?

I have been told on more than one project: “We can’t afford to do this up-front stuff. We need to move fast and get something working.”

My first response has been along the lines of: “Moving fast to get where?” The second response is: “You clearly have some idea of what you want to build. What is that idea that you already know?”

There are five reasons to take the time at the beginning of a project to work out the system purpose.

1. How often do people actually know what a customer needs before doing homework?
2. The beginning of the project is the time to build relationships with stakeholders.
3. Does the team actually have one shared idea of what the system should do? Or do they have multiple different ones?
4. Get the purpose wrong, and it sticks. If a system gets developed that customers don’t like, they won’t forget it—even if it is improved later.
5. There will likely be competition from other systems. What is needed so that this system is the more attractive to customers?

There are occasional exceptions to each of these, but they are not common for complex systems.

The Pontiac Aztek SUV offers an example. It was an automobile marketed by General Motors from 2001-2005 (model years). It was designed to appeal to customers in a new market segment for smaller SUVs, and the company put effort into making it new and exciting. It was a failure for GM: it sold poorly and never met break-even sales. It was often described as one of the ugliest cars ever produced.

The company went ahead and produced the vehicle. It has been reported that the team worked hard to develop the model faster than had been typical of the company at that point. By some accounts, the project’s execution went smoothly and met its milestones. Nonetheless, all the effort was in vain.

The Aztek project shows all three reasons for spending time working out purpose. The project believed they knew what people wanted better than the customers they surveyed did, and they were wrong. The company failed to build relationships with potential customers who were telling them that the car was not attractive. And once the car was available, the public stigma was so great that even the changes they made in subsequent years and marketing efforts did not help sales.

This example is far from unique. I discussed other projects that did not fully work out the system purpose in Sections 4.1, 4.3, and 4.4.

There is one case where the principle of establishing a customer’s purpose for a system does not apply: when building a new kind of system for which there is not yet a customer. For example, a technical demonstration system is used to learn about the technical problems of a potential system design approach before committing to making a product using that approach. The Boeing 367-80 (the “Dash 80”) in the early 1950s is a good example [Thompson87]. It tested a design that evolved (separately) into the 707 passenger aircraft and the KC-135 military tanker aircraft—but neither of those aircraft were exactly the Dash 80. The Dash 80 tested new wing and engine pod designs, thrust reversers, landing gear, and more. The Dash 80 also gave flight demonstrations to airlines that showed that the aircraft was up to the task of carrying passengers economically.

Technology demonstration project still have stakeholders, even if they do not result in a system that will be used directly by customers. Funders are still providing resources to build the system, and they expect a return on that investment, such as learning enough that the organization can build a “real” version as a product. Regulators may have a stake in how the system operates. The project may have to make a case to the funder or others in order to get the investment for the work. In Chapter 26, I discussed making the case for a project.

33.3 Different kinds of projects

The purpose is all about knowing what the customer and other stakeholders want. But who is the customer? How does one learn what they want? There are multiple answers to these questions, and how one learns about purpose depends on those answers.

I divide projects into three general groups:

• Customer-driven, where there is a specific customer or set of customers who want the system. One can learn what this customer wants by talking to them. This is typical of internal customers, or customers who have an ongoing contractual relationship with the development organization.
• RFP-driven, where there is a specific customer. This customer is following an acquisition process where they provide a request for proposals (RFP), and the team must respond with a proposal for developing the system. The customer is often constrained in how they can communicate about their needs in order to be fair to all proposers. This is typical of government contracting.
• Visionary, when there is not a specific customer yet, and possibly not even a defined market for the system. This is typical of commercial products that will be marketed to many customers once it is created. Developing the purpose includes working out the market segment or set of potential customers for the system.

33.4 Investigating purpose

The process of coming to understand the purpose for a system has a few steps. These do not proceed neatly linearly; they overlap and repeat. The purpose of the process is to identify who all the stakeholders involved in the system, and come to an accurate and complete understanding of what each of them needs. The process of understanding each stakeholder itself has multiple steps. After one works out what each stakeholder needs for themselves, the last step is to synthesize a common purpose out of all of the stakeholders’ needs.

The task of understanding a stakeholder’s needs will only generate useful results if the results are accurate. This means that the team is careful to separate what the stakeholder actually says from what the team thinks they will be saying. It means that the team does not fill in gaps in what the stakeholder says—they may ask the stakeholder to fill it in, but the team does not supply the information. Most of all, the team works to avoid confirmation bias; they treat their understanding as it evolves as a hypothesis and devises ways to check whether the hypothesis is correct or not.

There will be the temptation to get too specific and try to make specifications while investigating purpose. Don’t do that; at this point in a project, the task is just to record what the system should solve. This information will get combined with a concept and more investigation with stakeholders to make specifications. Some customer needs will be rejected as not something this project should address. The needs from multiple stakeholders will be reconciled. All this happens before getting into details of concept or specification.

33.4.1 Who are stakeholders?

The first step in working out the purpose for a system or a component is to identify who the stakeholders are. A person or an organization can be considered a stakeholder if they can say “no” to the project or to the system and stop its progress, or if they are providing resources to the project to build the system.

I discussed stakeholders in Section 16.2. That section provides a general list of stakeholders and their potential as a starting point for working out the stakeholders for a particular project. That list includes the customer, the team, the organization, funders, and regulators as example stakeholder roles.

It is helpful to record the list of stakeholders, not just think them through. It is also helpful to record who or where to get information about each stakeholder. For a customer, this might be the list of contacts who are available to answer questions. For the organization running the project, this might include pointers to organization policy documents.

In the beginning, some stakeholders are theoretical. A project developing a visionary product (as defined above) does not have specific customers to talk with. Instead, the initial task is to identify market segments that might have potential customers, and work out how to learn about those segments. A project might not have funding at the beginning. The first step is then to identify potential approaches to getting funding, and how to learn about each one. This might be anything from obtaining venture funding to getting small business innovation contracts (SBIR in the US) to getting budget from the hosting organization.

Some stakeholders are not obvious and not in the lists I have presented so far. For example, in many cases there are groups or individuals who have influence over a decision to approve funding for a project. They may not be named officially in a funder’s decision process but they have de facto influence. These people are also stakeholders and their needs must be considered in order to get funding approved.

33.4.2 Who is each stakeholder?

Getting to know a stakeholder and how they work are the second part of working out purpose. This is the time to both learn about who they are and to develop a working relationship with their team. Stakeholders are not all alike: each venture funding organization has its own culture, decision processes, and objectives. Each potential customer has a different objective and works in different ways, even if those differences are sometimes subtle.

A systems project aims to satisfy stakeholder needs. A project team works out how to communicate with the stakeholder in order to learn about their needs. They also learn how to communicate so they can make the case to the stakeholder how the needs are met and potentially get their approval. The team also communicates with the stakeholder when there are problems that affect meeting stakeholder needs.

There are several kinds of information that a team might want to learn about a stakeholder, and especially a customer.

• Who will the team work with? What are their roles within the stakeholder, and what decisions do they make?
• How do those people prefer to communicate? Do they like in-person meetings? Email and messaging communication? Are they limited in the kinds of communication they can accept? (This is common in government procurement.)
• What is the stakeholder’s culture like? How do they work with each other? Do they work cooperatively with each other, or do they compete with each other? How will this affect how the project team interacts with the stakeholder?
• Are there factions within the stakeholder that should be taken into account?
• How do they make decisions in general? Do they have a defined procedure for decisions relating to this project? What is that procedure?
• What are their organizational capabilities and experience? Have they worked with systems or projects like this before, or is this something new they are learning about? If they are a potential customer, do they have the capability to use a system like what the project might deliver?

This information can come from many different sources. Some of it may be spelled out by the stakeholder in a contract, a request for proposals, or in regulation. Some of it can be asked about. Much of the subtlety, however, has to be learned by observation and perhaps by talking informally with others who know the stakeholder.

The information about each stakeholder can be recorded in a prose document. Some organizations may have customer relationship management tools that will help capture some of the information about a customer.

33.4.3 What does a customer or stakeholder want?

The next step is to work out what each stakeholder wants or needs. I will present the rest of this section in terms of a customer, but this applies equally to any kind of stakeholder.

Some stakeholders have objectives to be met, such as a customer wanting a business function performed or a funder wanting a return on investment. Some stakeholders impose constraints, such as a regulator imposing safety rules or the organization limiting the amount of resource that can be allocated to developing the system.

Working with a stakeholder is full of pitfalls. The most serious is that the team will interpret what the stakeholder is saying in a way that the stakeholder does not actually mean. The team can bring their own interpretations to understanding what the stakeholder says; the result can be a system purpose or design that doesn’t meet the stakeholder’s actual needs.

The intent is to learn from the customer or other stakeholder. This is a time when the team must be careful not to be creative: they must exercise care to keep what they interpret or respond separate from what the customer is saying. The team’s interpretation comes later, and only once a solid basis of fact has been established.

The end result should be as complete and accurate understanding of the customer’s needs as is possible. Complete means that everything important about what the customer wants or needs has been included. Accurate means that the record contains only what the customer wants, and nothing else—no reading between the lines, no extrapolation, no filling in gaps. Knowing where the gaps are is important information that the team needs as they develop a concept and specification for the system.

Stakeholder speak in terms they are used to, and not the language of systems. Someone must be able to translate between the customer and the system-building team. A stakeholder should not be expected to do that; they are responsible for doing their work. Some stakeholders may have some people on their team who have systems experience, and they can be a helpful part of the process—but no systems-building team should expect that their team will have someone like that available. I have seen systems projects handle translation two ways: by having a few team members learn about a stakeholder’s business, or by bringing in people who already have experience in that business and systems-building.

There are many ways to elicit information from the stakeholder. I will discuss those later in this chapter.

Some of this information can be gathered from research materials. A customer that has issued an RFP should have documented most of their needs. Regulatory requirements can—theoretically—be understood by reading the appropriate regulations. A funder may have documented their expectations in a funding agreement.

The general process for learning stakeholder needs goes through three rough phases. In practice the process does not proceed smoothly from one phase to another; rather, it involves lots of looping back and moving forward on one topic before another is worked out.

The first general phase is to listen to what the stakeholder says they need or want. What problem do they want to solve? What capability do they want to gain? Why do they want to do this? The project team can prompt this discussion by asking a few open-ended questions: “Can you tell me about your business? What are the difficulties you are having or improvements you would like to make?” At the initial stage, before it is certain that the team understands the stakeholder, it is inappropriate to ask about specifics. The systems team must not presume that they know what the stakeholder wants until they have done the work to ensure that they do indeed understand the stakeholder.

During this phase, the team does little or no prompting. They should ask questions to clarify some point they aren’t sure they understand, and periodically read back what they think the stakeholder has said to confirm that they have heard it correctly. The point is to come to understand how the stakeholder sees their needs, including learning where the stakeholder—especially a customer—has not thought things through yet.

Throughout, the project team working with the stakeholder is recording what they hear. To the greatest degree possible, this record should be made using the stakeholder’s own language. This means that the project team may need to learn the language that the stakeholder uses and the assumptions they make, or include someone who can translate. The stakeholder should see the team making an effort to keep a record of what they learn; this conveys to the stakeholder that the team is taking them seriously. It also means that as team members cycle in and out of the project, the new people can learn about the stakeholder from the records and they do not have to ask the stakeholder to repeat over and over things that they have already said.

After the team has gained some understanding, it can be time to ask the stakeholder to expand on things they have said. An initial explanation often leaves gaps unexplored; this is the time for filling in gaps in what the stakeholder has reported and getting some depth of understanding. This is a time to prompt the stakeholder about assumptions they may not have articulated (and may not even normally think about). This is also a time to learn about industry norms that they operate within, which customers often take for granted and forget to explain to others.

Adding depth to the understanding includes things like who major system users would be and what they would do with it (informal use cases). This includes learning the motivations why a customer values those functions. It also includes learning about the context for a system: what environment it operates in and what other systems it will interact with.

Filling in gaps means finding functions or system aspects that the customer has not been thinking about. One may have some relevant experience that may suggest there are more topics to be checked. This is the time to ask questions like “I understand from what you’ve said that X and Y. Is there some Z that connects them?” Or “I’ve worked on some similar projects that have an issue with X. Does something like that apply to what you’re doing?”

Learning about how the customer expects the system to be used can expose some of those gaps; for example, if a customer expects that users will access a computer system, there might be a gap in how the users will log in, how they will be authenticated, and how their access might be controlled—security-related capabilities. The project team might prompt some of these discussions by asking an open-ended question like “what security risks do you seen in user access?” Other gaps can be exposed when tracing through how some use case might work; the customer might mention that the system then sends a record of something to some other system—prompting a discussion of what that external interface is.

The third step gets into more detail, especially about unusual situations. Customers often focus on the good cases and don’t think about what happens when a user does something they shouldn’t, or when there is an emergency, or when something fails. They often don’t think about how the system might need to be evolved, and what responsibilities they may have when the system is retired. One person I talked to advised looking for all the “it will never happen” scenarios—and that “the odds of them occurring are directly proportional to the fervor with which they user swears they won’t.”

The project team will likely prompt much of the discussion in this third step, because it is about filling in information that a customer does not think about much.

Obviously, this process is a gradual process of starting with only what the customer says and gradually prompting them and asking them more and more questions to get a fuller understanding of what they need. Questions late in the process will occasionally reveal major new functions or use cases that are important, even if they weren’t at the top of the customer’s attention. When these are discovered, the project team needs to go backward in the process to learn more about this newly-discovered aspect of the system, see how it changes their understanding of what has already been discussed, and eventually get into details about the new aspect and about how it affects other parts of the system.

At the end of the process, the team should have confidence that they understand the customer correctly. This requires validating their understanding with the customer. This should be done continuously: regularly asking questions to confirm understanding, for example. The team should also ask the customer to confirm the completed record to ensure that the customer agrees that it is complete.

33.4.4 Customer objectives

The customer objectives record what a customer (specific or hypothetical) wants out of the system. They serve as a proxy for the customer throughout system development, rather than having every developer talk directly to the customer to check their specification or design.

It is important to separate the customer objectives from other objectives. I have seen projects include business objectives, like profitability, in the list of “customer” objectives. I have also seen teams include internal technical objectives like being able to reuse parts of existing designs. Doing so creates confusion: is an entry in the list of customer objectives actually something the customer wants, or is it something that the customer doesn’t care about? There will come times in the development process when hard decisions must be made about some part of the system design. At those moments, the team must be clear about what is actually a customer need and what is an internal need. If a customer need can’t be met reasonably, the team needs to talk to the customer to resolve the issue. If an internal business or technical objective is proving hard to meet, the decision should be handled internally and the customer should not be involved—they don’t care or know about the issue.

For some customers, working in terms of use cases will be familiar. While documenting use cases is helpful, it cannot capture all of the information from the customer in their original language. Resist the temptation to document the objectives as formal use cases unless the customer is providing information that way. Formalization comes in the system concept, which derives from the system purpose.

33.4.5 Funder and organization business objectives

Funders (Section 16.2.4) and organizations (Section 16.2.3) provide the resources for a project. Each of them have reasons they are willing to make an investment in the project, and so the project must in return address those reasons.

A funder provides resources to the organization that runs the project. The funder then expects some kind of return on this investment. That return can be financial or intangible, but they will only invest if they have confidence that they will obtain the expected return. The confidence in turn comes from the plans and strategies that the organization provides to make the case for investment.

An organization that is devoting resources to build a system must be able to obtain those resources. At the minimum, the organization must be able to hire and pay the people who design and build the system; it must be able to pay for the tools and prototypes it uses; it must be able to pay people to gather customer objectives and work with regulators and all the hundred other tasks involved.

Most organizations are also building an ongoing business, not just coming together long enough to build one system and then disbanding. Sustaining a business requires obtaining funding, getting sufficient return on the work the organization does in order to fund continuing work, and building capabilities that allow the organization to keep building or maintaining systems into the future.

All these imply that an organization needs to have a business strategy, which leads to business objectives. The organization may have a strategy of developing a product line that serves a wide variety of customers. This might translate into an objective to build a simple initial system product that is able to generate X revenue, and that can be extended over time to address the needs of more customers.

Many organizations develop these objectives at the executive level but do not feed the information downward explicitly to the team who must design a system. This is a problem because the design team knows that such objectives exist but don’t necessarily know exactly what they are, and thus can’t make accurate design judgments. We have seen, over and over, questions in a design team like “should we design this board with extra capability now, or design the minimal board and replace it later?” These have often led to arguments because the design team did not have the information needed to make a choice between a higher up-front investment cost for extra capability or incurring cost later in a redesigned board.

There are many different kinds of business objectives to document.

Some objectives are easily quantifiable:

• The budget available for developing the system
• Deadlines for delivering the system and intermediate decision milestones

There are general business case objectives:

• The expected profitability of the system over time
  • The profitability of system development, if appropriate, or whether the development is purely an expense
  • How long it should take to recover development expenses
  • How profit or return on investment should evolve over time
• How the scale of the system should evolve over time
• How the size of the addressable market should evolve over time

Finally there are business strategy objectives:

• Is this project intended to build a single iteration of the system for a single customer? Or is it intended to be the base for ongoing development of an incrementally improving system?
• Is this project intended to produce other things of value besides the system itself, such as developing in-house capabilities in some area, or building technology or designs that can be reused (at low expense) in future projects?

These business objectives change continuously. When there is a proposal to change the objectives, the team must follow a disciplined process to determine what the effects of the change might be. This involves tracking down how the change will affect technical requirements and designs, which in turn affects whether the changes will affect the system’s ability to satisfy customer, regulatory, safety, or security needs. Changes to the design will also affect development cost and the time required to bring the system to operation. Sometimes a change to business objectives will make sense: changing the rate at which the system should scale up after the initial operational version may not affect the development time much but will increase customer satisfaction. Other times a change will have negative consequences: setting the goals for the size of the addressable market too high too early may require a higher development budget and longer development time than is available. Making a well-informed decision about these changes is only possible if the team can determine what the effects of a potential change in business objectives are.

33.4.6 Regulatory objectives

Many kinds of systems are subject to regulation. Some systems require licensing or certification, to prove that they meet regulations; others only need to be able to show compliance on demand.

These regulations pose constraints on the design of the system. Some are simple: aircraft emergency exits must be marked in particular locations. Some are complex: the crew of an aircraft must be able to properly determine what is happening with an aircraft even when there are complex failure situations—which involves human factors as well as the design of aircraft sensing systems.

A system will not be able to be put into operation unless it can meet these regulations. This means that the regulations must be incorporated into the design, just as the functional desires of the customer must be. One cannot do this unless one knows what the regulatory constraints are, and so one must search out and document all the regulations that apply.

The regulatory objectives documentation should at minimum list the source regulatory documents that apply to the system. Before design validation is complete, the information in the regulatory objectives document must translate into a detailed collection of requirements against which the system can be checked.

It is often necessary to involve either experts in the regulation of a particular industry or the regulatory agencies themselves to properly gather all of the regulations that apply.

33.4.7 Third party objectives

No systems operate in isolation. Instead, they operate within the context of a larger system of people, businesses, and organizations. This might include:

• Other systems that the customer already operates.
• Services that the system will interact with directly, such as for maintenance or communications.
• Services that the system will interact with indirectly, such as finance organizations that provide operating capital for the customer’s day-to-day operations.
• Services or organizations that maintain the environment in which the system operates, such as a data center, an airport, or roads.
• Part or component suppliers that provide components that will be used inside the system.

These systems and organizations are stakeholders, whose needs or objectives must be understood and addressed in the system.

The interactions and dependencies within this larger system create constraints on how the system being designed must function. It is important to identify each of these third party stakeholders, document how the system will interact with them, and then document the more specific objectives that are involved in working with them.

This information should be collected into one or more documents that record, first, the structure of the larger system and its interfaces with the system being designed; and second, the sources of constraints or objectives for each interface.

Information about the ecosystem in which the system will operate is likely to change frequently over the course of developing a system, especially for visionary projects. This means that it is important to update information about these objectives, and when it changes, flow those changes down into the system design.

33.4.8 Safety objectives

Safety is the condition that a system, when operated in the intended way, does not produce too many events that cause harm. There are four parts to this statement:

1. The operational system (its design and implementation);
2. The way it is intended to be operated (the intended functions and environment);
3. Produce too many events; and
4. Events that cause harm.

In the end, a system must be shown to be safe by showing that the rate at which it causes harm is below a threshold. The process of designing a system to be safe is well known to be a difficult task, and there are many books and standards that try to give guidance on how to do so. As the system is designed, it must be evaluated to show the likely rates at which harmful events will occur.

This is a complex topic, and later chapters address the design and analysis of safe systems.

The ways in which a system needs to be safe derive from customer, organization, and regulatory needs. Safety is not a stakeholder itself; rather, safety needs come from those stakeholders. A customer may care about harms to its workers or property; a regulator may care about environmental and social harms. An organization may care about its reputation for building safe systems. The definitions of what makes a system safe or not, thus, come out of stakeholder needs.

Defining safety objectives is the first step in designing a safe system. This involves defining what kinds of harms are to be measured, along with the acceptable rates at which they occur. There is no possible way to justify that a system is “safe” or “unsafe” without defining the harms they refer to. Safety objectives, as part of the system purpose, inform the development of the system concept and later its specification and design.

A harm is some undesired outcome of a system’s operation. A well-designed system avoids or minimizes these outcomes. There are many synonyms for this: a loss, an injury, a hurt, or damage.

There are many different kinds of harms, and each system will have its own set that matter. Examples include:

• Injury or death of people;
• Damage to property or goods;
• Wastes of time;
• Loss of value or money; or
• Disclosure of secrets.

Each project must define and document its own high-level safety objectives in terms of the harms and the acceptable rates of those harms occurring.

Some industries have conventional definitions of harm and rates. The automotive industry has adopted a scale of zero to three for “severity” in the ISO 26262 standard [ISO26262], focused entirely on injury to persons. Severity 0 is no injuries, 1 is light to moderate injuries, 2 is severe injuries with survival probable, and 3 is severe or fatal injuries. The aviation industry has defined a five-level scheme in the ARP 4754 standard [ARP4754], ranging from minor (slight increase in crew workload or minor passenger inconvenience) through hazardous (serious or fatal injuries among passengers) and catastrophic (many deaths, loss of aircraft).

These two standards differ in two respects. They consider different ranges of harm: ISO 26262 has any severe or fatal injury as its highest category, while ARP 4754 considers the distinction between fatal injury and mass fatality. They also consider different kinds of harms: ISO 26262 only considers injury to persons, while ARP 4754 considers effects on the crew’s ability to control the aircraft and damage to the aircraft.

These point to deficiencies in the standards, and to the reason why a project should define its own safety objectives carefully. There are many harmful incidents that these standards do not address, such as damage to property. Consider an incident involving a truck that damages an overpass, but does not injure anyone directly. The cost of repairing or replacing the bridge can run to several millions of dollars; the economic impact on the community of not being able to use the bridge can be equally high. In addition, depending on the industry, the range of severity in these standards can also be too limited: they do not account for harms that spread beyond the people and vehicles immediately involved in an incident. The use of aircraft as missiles in the 9/11 attacks showed how an aircraft safety incident can result in mass casualties or worse.

In addition to defining the harms that system design will consider, the safety objectives set targets for how often those harms can occur. Sometimes a potential harm can be designed out, so that there is no chance of it happening. Most of the time harms can only be minimized, not eliminated: an aircraft can only avoid falling if it never flies, and a boat can only avoid sinking if it is never put in the water.

Instead, the safety objectives will need to define how often each harm is allowed to occur. This is typically defined as some maximum amount per unit of time or activity.

Guidance issued for commuter aircraft [FAA11], for example, gives a maximum allowed rate of incidents per flight hour for commuter-class aircraft:

Some organizations may choose to say that the system they build should allow zero safety incidents above a certain level. This is possible only if the system can be guaranteed never to perform operations that could induce such serious events. For example, an aircraft can be guaranteed never to cause catastrophic harm, involving multiple fatalities—but only if the aircraft has a maximum weight of a few tens of kilograms, a low maximum speed before it disintegrates in the air, can only carry a single person, and so on. No transport aircraft (more than 19 seats or maximum takeoff weight greater than 19,000 lbs) that actually flies can ever have a zero rate of catastrophic harm, if only because of its kinetic energy while flying. Similarly, many weapons systems can never have a zero rate of mass casualty harms simply because of the energy they carry. In most cases, as the conventional wisdom goes, the only way to get a system to have a zero rate of harm is not to build the system.

An engineering team needs defined and measurable harms and rates in order to design and build a safe system. The team will often have to make trade-offs between one safety objective and another, or between safety and something else. They will need to judge how much effort to put into meeting some safety aspect of the system, and prioritize effort among multiple possible tasks. However the objectives are defined, the team must be able to determine whether they have reached a solution that is good enough to meet the objectives. They must be able to agree on what is needed, and build component behaviors or structures that, when integrated with others, result in a safe system.

Defining precise safety objectives early in a project is required for building a safe system. I have observed many projects that made aspirational statements about “safety being a first priority”. In every single instance where the definition stopped at that statement, the team designed an obviously unsafe system—often because, in the absence of an objective standard, each person took steps they thought would be safe but in aggregate the design missed even basic scenarios that resulted in hazards. Further, the absence of an objective meant that no one could perform an objective analysis of a design to determine whether it was good enough.

33.4.9 Security objectives

Security objectives are closely related to safety objectives: both are concerned with naming harms that the system should avoid, and both derive from other stakeholder needs.

Security objectives differ from safety objectives in three ways. First, several kinds of harm are typically considered “security” concerns rather than “safety”, such as disclosure of confidential information or unauthorized system use. Second, security typically deals with harms that are not well characterized by rates of occurrence: events that are so catastrophic or unrecoverable that they should not occur even once. Finally, security often deals with harms that can be caused by malicious, intentional actions.[1] Security objectives are generally not characterized by rates of harm because the the hazards do not occur regularly or randomly; they occur when a malicious actor creates a hazardous situation.

As with safety objectives, security objectives are defined in terms of harms to be avoided. These harms generally include all the harms identified in the safety objectives, as well as things like information disclosure, interruption of business, financial loss, or theft of goods.

Unlike with safety objectives, the security objectives also include the list of threat actors. These are the people, organizations, or systems that can choose to initiate an attack on the system. Each threat actor will have their own motivation: a criminal organization for financial gain, a nation state to disable defense-relevant capabilities. The likelihood of some harm happening, the amount of resources to apply to avoiding that harm, and the ways to avoid the harm depend on the actor and their motivations or incentives for causing a problem.

The system must then be designed to address the different harms that different threat actors might pose. The resulting design can be analyzed to determine whether the threats are sufficiently addressed. The built system can be tested to verify that key defensive features are working as intended.

The definition of “sufficiently addressed” remains subjective. Some security analysis techniques have rationales for assigning weights to different threats. For those analyses, ensuring that all high- and medium-priority threats have been mitigated might be sufficient.

There are many standards related to security, and depending on the industry and geographic region compliance with some standards may be mandatory. These may define security objectives that a system must meet for regulatory or business acceptance. This information should be documented in the regulatory objectives, and information about threat actors or harms should flow from the regulatory objectives into the security objectives.

33.4.10 Synthesis

Previous steps investigated what each stakeholder needs individually. In the end, the project must satisfy all of the stakeholders.

The next step, then, is to create a synthesis of all of the stakeholder needs. In simple cases, this is just merging the different needs together: the customer needs X and Y, the funder needs Z, and so on. The difficult cases are when there might be conflicts between different stakeholder needs.

Consider two examples. In one case, the customer wants a product within 24 months at a given price. However, the product will require regulatory approval, and the approval process takes at minimum 12 months if nothing goes wrong. These two stakeholder requirements could conflict if the approvals aren’t completed within 24 months or if the cost of getting approval becomes too expensive. In another case, the funder requires a minimum return on investment to fund other projects in the future. The customer is price-sensitive and is only willing to pay up to some maximum amount. These could conflict if the cost of the project’s development and deployment is high enough that it doesn’t leave enough profit for the funder.

Note that neither of these examples are certain conflicts. They represent serious risks to project success, but they do not indicate that the project cannot succeed. These potential conflicts are added to the list of risks for the project (Chapter 66). These will need to be analyzed during concept development (Chapter 34).

Sometimes there will be clear conflicts between stakeholder needs. A customer may want a capability that is not allowed by regulators. An organization may want to impose constraints that mean customer needs cannot be met (e.g. Sections 4.1 and 4.4). When the team finds these kinds of conflicts, they can either negotiate with the various stakeholders in hopes that one or more of them will relax their needs, or the team can determine that the project is not feasible and stop the work. The decision to stop the project is part of the stakeholder review and agreement milestone (Section 33.9). The worst outcome is not to find out about conflicts until lots of time and resources have been spent.

33.4.11 Results

The outcomes of investigating a system’s purpose are records of what each stakeholder needs, along with checks of whether those results are complete and consistent. Some form of these records will be checked by stakeholders as part of validation (Section 33.8) and a review of purpose (Section 33.9).

Again, it is important to limit the exercise to determining needs and purpose. The work should not expand into developing a concept or specifications—yet.

I have found it useful to maintain two separate kinds of records. The first is an unabridged, untranslated record of what each stakeholder has said—regardless of source. The second is a purpose statement for the stakeholder, an organized form of their needs. The information in the organized form should be specific and actionable, and measurable where possible. These records should use the stakeholder’s own language and frame of reference.

I have structured the record of a stakeholders needs in different ways. It should be simple. A bulleted outline of problems to solve, functions needed, and needed attributes like reliability or security can work, along with a few diagrams to explain them.

The stakeholder will review and validate the purpose statement. This is the basis for them approving the team’s understanding of purpose or not.

The project team will develop other information along the way. This consists of things like use cases, definitions of broad functional needs or partial potential system concepts, and records of gaps or inconsistencies in the stakeholder needs. All this information is developed by the project team for their use; it is derived from what stakeholders say, but it is not a record of the stakeholder needs. (The team must take care never to confuse this interpretation of stakeholder needs with the actual stakeholder needs.) This information can be in any form useful to the project.

33.4.12 Techniques and tools

There are several tools that a project team can use to help the process of learning what stakeholders want. I often expect to spend many hours or days discussing with a customer to understand their needs, at least for complex systems. Other stakeholders may not require as much time.

Some stakeholders may not be able or allowed to discuss interactively and one must deal with written information. I have seen this most often with government stakeholders. When a public entity is requesting competitive proposals, they are often limited to interacting in writing and to sharing any questions and feedback with all potential proposers. Regulators are obliged to follow the text of their regulations, and in trying to explain them they can potentially convey wrong impressions. They often lack the people and time to answer many questions anyway.

When discussing with a stakeholder, the first tool is to keep a record of what they say. This can be in notes, audio recording, or video depending on the circumstances. (I find that notes are useful in addition to any recording.) It should be very clear to the customer that the team is making a record; this conveys a message that the team is paying attention. However, the team should check with the stakeholder about how they will build a record to address any confidentiality concerns that they might have.

Active listening is a set of the techniques that helps understand what a stakeholder needs. There are many resources available to explain it in detail. The purpose of the techniques are to put the focus entirely on what the stakeholder knows, listen with the intent of understanding them, and to convey implicitly that one cares about what they know more than about finding a solution at the start.

The main ideas are:

• Ask the stakeholder to explain their business or their need. Ask open-ended questions that prompt them to explain this broadly, and to indicate interest in what they have to communicate.
• Ask questions when needed to clarify understanding of what they are saying. Taking one’s ego out of the conversation helps; I have many times used phrases like “I’m learning about this; I’m not familiar with X. Can you educate me?” Expressions like this can seem a little stilted, but they convey that the intent is to learn from them.
• Don’t interrupt the stakeholder except to clarify things. Let them direct the topics that are presented, at least early on in the process. There is a lot to be learned from how they discuss their needs: how organized or disorganized they are, what they see as important, and how they see topics connected.
• Ask questions that test and confirm your understanding of what they are saying. I often try to read back or echo key concepts in paraphrase. “I think you’re saying Y; do I have that right?”

At the beginning of learning about a stakeholder, the listening is focused on hearing from them. As the process goes on, project team members will begin to ask more questions and gradually direct discussions to specific topics, filling in gaps in understanding. Even as the team ask more questions, though, they must keep the focus on learning from the stakeholder, and not putting words in the stakeholder’s mouth.

Asking open-ended questions is another useful tool. By asking a question that indicates interest in a subject, but not giving potential answers, allows for the possibility of learning something unexpected. If the stakeholder has need B, and a team member asks a question like “for topic X, are you thinking of A?”, then the stakeholder might just answer “no” and the team will not learn of B. Or worse, the question may lead the stakeholder to start thinking in terms of A when they really did mean B. It is better to ask a question like “what are you thinking about for topic X?” and let them answer as they will. Only ask “are you thinking about A” when you are confirming that they have said “A”.

Getting information from multiple people within a stakeholder’s organization has two benefits. It can provide different perspectives on some need, providing more information about needs. One person might consider something more important than another person does; the first person will likely emphasize that need more than the other person. The other benefit is that it can expose differences of opinion or inconsistencies within the stakeholder. These differences can cause problems for the team down the line, when a stakeholder must approve part of the system. The team can record these disagreements and work to ensure they are resolved before they become a problem.

Shadowing part of a stakeholder’s operation can be a productive way to understand operational needs. (It is not particularly useful, for example, with a funder.) By following along as a customer’s staff goes about their business, the project team gets a different perspective than they would talking about things in a meeting room. They will see little details that the customer staff might not think about because they take those details for granted. Early in my career, I was asked to work out how to automate some city government finance operations. Processing utility bill payments was one of those functions. It was not until I sat by the person who received envelopes from the post, opened and processed each one, and recorded the necessary information did I actually understand the manual steps involved and the importance of the physical environment—desk, shelves, sorting baskets—that they relied on to do the job. The result was to conclude that further automation was not useful for that task at the time, so I could put my energy into other functions.

I have found that acting out scenarios is a powerful way to engage stakeholder imaginations about potentially complex operational needs in a system. In discussing UAV traffic management with a government organization, we were having difficulty discussing malicious behaviors that UAV operators could exhibit. When I then tasked two of the people in the meeting to act out good and bad scenarios, they immediately understood the problem I was trying to raise. After that we had a productive discussion about the problems that a traffic management system might need to address.

Behind the scenes, the project team can build models of what the stakeholders are saying in order to organize the information they have found, such as definitions of system users, use case models, and activity models record who will interact with the system, and for what. Definitions of interactions between a system and the outside world record information that will inform system scope. Lists of functional needs, perhaps organized into groups or hierarchies, help for finding where there may be topics that the stakeholder has not addressed or where there are contradictions. All these models derive from the raw information received from the stakeholder, and the team must ensure that the models only contain information that has been expressed by a stakeholder.

These models are for the project team’s use, and generally not for the stakeholder to see. The models will be expressed using language or notations that the team understands, but the stakeholder likely does not. The team uses these models to prompt confirmation questions, find gaps, and identify contradictions. These models likely include information from multiple stakeholders, and some of that information should not be shared between stakeholders.

Most important, the models are not the reality of stakeholder needs; they are an interpretation. The models are hypotheses about the stakeholders, and as hypotheses they must be investigated to confirm or deny their accuracy.

It is possible and often tempting to put too much energy into developing such models. While discovering stakeholder needs, all this work is tentative; there is some probability that there will be a surprise coming along soon that will invalidate some of the hypotheses encoded in the models. The team should put only enough effort into these analyses to further understanding the stakeholder. These models will be improved during the next phase, when the team works on system concepts. The effort involved in elaborating use cases and finding solutions should be deferred until concept development and later in design.

Because the intent of working out a system’s purpose is to have an accurate and complete understanding of stakeholder needs, one takes deliberate steps to check the accuracy of what one thinks one has learned—that is, to validate the understanding.

33.4.13 The project team

The team members who work on discovering project purpose need a few different skills.

They will be interacting with the stakeholders. The team members need social skills to build rapport with the stakeholders. They need skills in communicating and listening.

The project team translates between a stakeholder’s point of view and language to the team’s language. The team needs someone who can understand both groups’ ways of expressing information. This can come by team members learning the stakeholder’s language, or by ensuring the team has someone with experience in both. Sometimes bringing in a consultant meets the need.

The team also documents its understanding of the stakeholder needs. This involves skills of organizing the information in ways useful to the team. I have found it helpful for the team working with a stakeholder to include people with engineering experience as well as people with marketing experience. (I discussed one example in Section 4.2.)

Finally, the team produces documents of its results. The team should include someone who can write text or presentations that are concise and clear.

For complex systems, all these skills are rarely found in one person. It is often more effective to assemble a small group—perhaps two to four team members—to work with the stakeholder.

33.5 Competition

Virtually every systems project will be in some kind of competition—whether for a customer contract, for sales of a developed system, or for acceptance of a new technology over an existing approach. A team can develop a good concept or a good system, but then fail to get that system used.

Knowing about competition applies to every project, not just those which must generate a competitive proposal. A customer-driven project must still satisfy its customer; the customer will be aware that they have choices about what investments to make in new systems or upgrades. A visionary project may have direct competitors who may try to build similar systems—but visionary projects also have competition from the way problems are already being solved, as a customer can always choose not to by any new system and stick with what they already have.

Understanding competition provides constraints on the system and offers ideas about possible objectives. Does a competing system have some special value to customers? It won’t be enough for this system to match the other one; the system will need to do better or offer some other value to the customer. Does the competitor have a weakness in their offering? This system should have a better solution in that area. Is there something that this system can have that will help it keep an advantage over time? These are all questions that business strategy and marketing teams investigate regularly.

The team should gather this kind of information into a competition document. That document gathers together intelligence about who and what might compete with this team’s system. It lists strengths and weaknesses of each competitor. The competition information informs working out the system concept in the next steps (Chapter 34).

The competition document must be an unbiased presentation of the alternatives to using the system being designed, and of the advantages and disadvantages of those alternatives.

Many people will naturally want to emphasize what they see as their own strengths and try to contract the competition to those strengths. That makes for a misleading competition document.

The competition must be presented as fairly as possible, and from the customer’s point of view. The document must be honest about the strengths that competitors have: they will have strengths and the team cannot defend against them if they do not have an accurate assessment of them. The document must be equally honest about the competitors‘ weaknesses. The team cannot design a better solution if they do not accurately know what customers don’t like about what their competition offers (or might offer), or if they don’t understand what structural problems the competition might have in designing or building their own offering.

The competition document is never really complete, because other teams and other technologies will always be changing. The competition should be revisited periodically as the project continues to find when the competition has changed, and determine when those changes need to lead to changes in the system. These changes amount to a change of system purpose, and lead to changes in the system concept, then specification, and onward. Section 33.10 discusses this process.

33.6 Defining scope

A system’s scope (Chapter 10) defines the boundaries of the system. The boundary separates two things:

1. What is to be included within the system, and thus what the project is responsible for addressing; and
2. What is outside the system and thus outside the project’s control.

The project cannot affect what is outside the system. They take that as given and work to accommodate it. This includes the environment in which the system will operate; the users who sit outside the system and use its functions; and rules that the system must follow. Understanding this environment is an important part of understanding system purpose.

The project builds the system to handle everything that is inside the scope boundary. That includes passive elements like mechanical structures; active machinery like computing or mechanical systems; and people who work within the system.

The project team has some control over the scope, especially at the beginning of a project. The stakeholders’ desired purpose is sometimes more complex than what can be developed feasibly in a reasonable time. The project team can address this three ways: by negotiating a smaller scope for the system; by negotiating a phased delivery of system versions with increasing functionality; or determining that the team should not try to build this system for these stakeholders.

Negotiating about scope involves ranking needs to find a subset that is essential and that will still satisfy stakeholders enough. The ranking includes identifying what needs are interrelated and must be satisfied together or not. This may not be possible to complete until the project has developed some of the system concept, as discussed in the next chapter (Section 34.10.3). Similarly, if the project proposes delivering a series of system versions with increasing scope, it may be necessary to get part way into concept development in order to understand what would make sensible versions.

If the project team expects that the system’s scope will need negotiation, and that the scope changes aren’t clear just from looking at purpose, the team should document the concerns, ensure that stakeholders know there is a potential concern, and include scope negotiation on the list of risks that will have to be addressed after the purpose is baselined initially.

33.7 Artifacts

The work of developing system purpose results in six major outputs:

1. A list of stakeholders, along with notes on who the contacts are at each and on how they operate. For visionary projects, the list of stakeholders will include lists of potential market segments.
2. Raw records of the interactions with each stakeholder, from which needs have been extracted.
3. A statement of the purpose for each stakeholder, in the form of an organized list of their needs, and the scope of the system in terms of those needs. This includes information about likely gaps and inconsistencies in those needs.
4. An analysis of whether stakeholder needs are mutually compatible.
5. A list of risks identified, such as gaps or inconsistencies not yet resolved and possibly stakeholder interaction risks.
6. Internal analyses and models that reflect what has been learned about needs.

The organized lists of stakeholder needs, the list of risks, and internal analyses must clearly derive from what the stakeholders have said. Ideally, anyone looking at this derived information can trace that to specific statements from the stakeholders on a given date.

This information is maintained under configuration management (Sections 17.4 and 23.7). It is in progress while being developed, and is baselined after the purpose review (Section 33.9). The team will develop new versions as they learn additional details about stakeholder needs or as those needs change (Section 33.10).

33.8 Validating purpose

The final system purpose should reflect each stakeholder’s needs accurately. Validation is the process of checking that the purpose is indeed accurate.

Validation is not a single task. It is a continuous process. Small validation steps occur all the time while the project team is learning what a stakeholder needs.

The project team validates information in order to avoid wasting effort or time on something that will be rejected in the end. That is, validation is in part an exercise in risk management. The sooner significant misunderstandings can be caught, the less time will be wasted. The active listening techniques discussed above for listening and confirming understanding during discussions provide quick feedback.

I have found it useful to have mini-reviews along the way to a final review. In these, the team takes one or two topics, summarizes their understanding back to the stakeholder, and validates the work in progress. This is useful when the project team has been assembling stakeholder information into organized forms, so that the stakeholder can check both the way the information is organized as well as the specific details.

At the end of the process, a team should review their understanding with each stakeholder. This review might take the form of a document that presents an organized record of their needs. It might include a presentation, though presentations are useful for conveying the big picture of the needs and are not good for presenting details.

33.9 Review milestone

The goal of initial purpose development is to have a clear but informal understanding of what the stakeholders want, what constraints they place on the system, and agreement from all parties that the documented understanding is correct.

Specifically:

• The team has confidence that it has a clear and complete idea of who the stakeholders are and what their objectives are.
• The team has confidence that it has an accurate understanding of other constraints that will be placed on the system.
• The stakeholders (or their proxies) can confirm that the team has understood their needs.

There is a review at the end of purpose development. This review is to check that these conditions have been met, both for the team and for stakeholders. At this review, the project decides whether the team should continue on to concept development.

While the team should have been validating their understanding with each stakeholder as they go, a final check is in order before moving on to greater investment in the concept development step next.

At the end of each significant project phase, the team also reviews internally whether the project should continue or not. At the end of purpose development, this decision is based on four things:

1. Whether some stakeholder has needs that the project cannot meet, even before spending time developing potential concepts;
2. Whether the identified gaps or inconsistencies in stakeholder needs appear likely to be resolvable during concept development, or whether the stakeholder likely will not satisfied even if the team pursues resolving those gaps;
3. Whether risks identified are acceptable or not; and
4. Whether the customer will be able to deploy and use a system meeting their needs ethically and safely.

Not all gaps and inconsistencies in stakeholder needs will necessarily be resolved by the end of the main purpose development step. That can be okay; the customer or other stakeholder may not know yet, and the team will have to work with them during concept development and negotiation. The decision at this review is based on the likelihood that the team can work with the stakeholder to resolve inconsistencies or gaps during concept development, before the project needs to begin specification and design.

Sometimes, however, an inconsistency is a sign that a stakeholder does not actually understand their own needs well enough and is asking for something impossible. This can be a sign that the team should not continue with the project.

The last condition can occur when the customer will be required by regulation or ethics to have some capability, but the customer is not aware of the need or not willing to gain the capability. For example, a customer wanting to fly an aircraft commercially may need to obtain an operating certificate as an air carrier, and establish capabilities like a safety management program. As another example, a customer might want a system to process radiological agents but is unwilling to discuss security measures to protect the material.

If the project determines not to proceed, then the team can wrap up what it has learned, archive the records generated, and inform stakeholders.

33.10 Change of purpose

A project’s purpose will change as time goes by. Indeed, change will be continuous over the life of a project and can happen at any time. No matter how much effort the project team puts into learning stakeholder needs, there will be needs that aren’t understood until later. Sometimes a need is not discovered until a system has been developed and deployed, and users finally realize something about what they do. Stakeholder needs change over time: as their competitive landscape changes, as regulation changes, as they discover new opportunities. For visionary projects, the potential customer market segments change as people discover new potential customers or find that some segment isn’t as promising as thought.

Changes that are discovered while developing the system purpose can be incorporated right away. Changes that occur after the purpose has been reviewed and baselined require more care, because system development will have proceeded based on the old needs and some parts of the system’s specification, design, or implementation may need to be changed in response.

The process for dealing with changes after the purpose has been baselined is roughly (following Section 29.7):

• Detecting that a change is needed, or receiving a request for a change. Someone on the project team discovers that a stakeholder is saying something that the team hadn’t understood before, and they begin the process to update the purpose. Alternatively, a stakeholder (especially a customer) explicitly asks for a change. Both these events trigger a procedure to record and process a change request.
• Determining the effects of the change: how does the system scope change? What parts of the system are affected?
• Determining whether to accept or reject the change.
• If accepted, adjusting the system scope if needed.
• If accepted, reiterating the purpose development phase and the rest of the development phase in order to propagate the needed changes through the system artifacts (Section 28.2). This includes reviewing and accepting the updated purpose, as well as repeating concept, specification, and later development phases until the changes catch up to the rest of the project.
• If the changes are happening after the system has been accepted (Section 28.9) and entered production (Section 29.1) and deployment (Section 29.3), the changes will be part of a new version of the system (Section 29.7).

Note that changing the purpose leads to changing the artifacts that follow from it; see Section 34.5.7 for additional notes.

33.11 Using purpose

The system purpose encodes what customers and other stakeholders need or want. The system that is eventually defined, built, and deployed is worthwhile if it meets those needs; if it doesn’t meet the needs, the effort spent to make the system is wasted. In other words, the purpose guides all the rest of the work on the system.

While a first version of the purpose is developed at the beginning of a project, it will change as time goes by. Making the purpose as complete as possible is an exercise in risk management. Changes to purpose lead to changes in all the artifacts that derive from it—concept, specification, design, and so on. These changes to the system mean that some of the effort invested in developing to the original purpose will be lost, and more effort will be required to make the changes. The amount of effort lost may be small if the change is small, but a change in purpose can potentially lead to large changes in the system design and thus a lot of extra effort. A project can reduce the amount of extra effort by putting effort into working out the purpose first.

The purpose is recorded in a number of documents. These documents are kept under configuration management so that it is clear to anyone who needs to use purpose information that they are using the correct version, not something out of date.

The team uses the purpose directly to guide the concept they work out, and they judge the concepts by how well they satisfy the purpose. The system specifications start with the purpose and the concept, and then elaborate them into details about the system.

The team uses concept and specifications as they proceed into design and implementation. In this way they are using the purpose indirectly.

The team verifies each step of development, from purpose and concept to specification, from specification to design, and from design to implementation, to ensure that the system as finally implemented meets its purpose. However, this is like a game of telephone where the chain of interpretations can lead to differences between the original purpose and the final implementation.

To counter these accumulated errors, projects validate the final system implementation directly against the original purpose. The customer or other stakeholders can participate in the validation activities. This is part of the final system acceptance (Section 28.9).

The purpose is used in other processes along the way.

When there is a request or need to change the purpose, the team looks at the changes to determine whether to agree to make the change as discussed above. If so, the team updates the old purpose with the changes, produces a new version of the purpose documents, and propagates the changes into the artifacts like concept and specifications that derive from the purpose.

The purpose also plays a role in contracting. If the project is developing the system for a specific customer or funder, they will develop a contract that determines what the project will build. That contract usually includes much of the system purpose as the definition of what the project is to deliver. Some of the purpose may be first documented in a request for proposals. The team typically works out purpose and concept as part of developing a proposal for the contract (Section 25.1). The purpose and parts of the concept are often then embedded in the contract, possibly by reference.

The team should bear in mind what they do not yet know once they have worked out the purpose. Purpose development is, obviously, a very early stage of a project. They do not know how they will approach designing and building the system; that comes with working out the concept. They do not know how much time, effort, or other resources will be required; that comes only after specification and some design has been worked out. They also do not yet know what they don’t know; there will be surprises in what stakeholders need as the project moves forward. The team must resist providing estimates of what will be required to make the system based only on the purpose [McConnell09, Chap. 1].

Purpose development happens before milestones in which the project decides whether to continue onward to build a system. It happens before a contract for the system has been signed. There is, therefore, a reasonably likely chance that the project will end after the effort to work out purpose (and concept) has been spent. In many organizations this means that the work of developing purpose and concept is funded internally (using “business development” funds). The process to get approval to use these internal resources is dependent on making the case that the project has a reasonable chance of getting funded; see Chapter 26 for a discussion about the case for a project.