Content uploaded by Benjamin D. Rodes
Author content
All content in this area was uploaded by Benjamin D. Rodes on Jul 10, 2017
Content may be subject to copyright.
The Seven Artifact Reference Model
M. Anthony Aiello and Benjamin D. Rodes
Dependable Computing
Charlottesville Virginia, USA
(tony.aiello,ben.rodes)@dependablecomputing.com
Abstract—This paper presents the Seven Artifact model, a
problem-oriented reference model for systems engineering. This
model explicitly identifies the problem to be solved, situates
machine phenomena in correspondence with environment phe-
nomena, and explicitly includes an argument of problem solution.
The Seven Artifact model is presented in terms of reference
artifacts and reference processes and is illustrated by application
to a simple example.
I. INTRODUCTION
Establishing justifiable assurance of safety requires an un-
derstanding of the context in which the system will be oper-
ated. This is clear from several definitions of the safety case:
(list?). Correct and complete identification of the environment
is critical to the assurance of the system: engineers must be
certain that they know when the system will be able to operate
as intended and when the system may not operate as intended.
Additionally, should the system be reused as a component in
a larger system or system of systems, complete and correct
identification of the intended environment is essential to pre-
dict and assess the operation of the system in the new context.
Cyberphysical systems, by their very definition, must mon-
itor and control the environment in which they operate. Crit-
ically, however, the phenomena that the machine manipulates
are only representations of environmental phenomena — not
the actual phenomena. Misunderstanding the nature of these
representations or incorrectly handling them during computa-
tion is a significant source of errors that are very difficult to
identify and fix.
Justifiable assurance also requires the provision of an ex-
plicit and rigorous argument. The relationship between the
argument and system development artifacts is unfortunately
unclear. Typically, construction of the argument is deferred un-
til development is complete, leaving the relationship between
the argument and critical system development artifacts unclear.
As a result, typical arguments focus on system assessment
while providing minimal attention to the correctness and
completeness of critical intermediate artifacts.
The importance of the environment, its representation in
the cyberphysical system, and the role of the argument in
the systems engineering process gives rise to the following
question:
“How can we better argue that we have identified the envi-
ronment, ensure that environmental phenomena are correctly
Approved for Public Release; Distribution Unlimited (Case Num-
ber: 88ABW-2017-0492)
represented and manipulated by the machine, and ensure that
the customer’s problem is fully understood and completely
solved?”
In this paper, we answer this question by proposing a new
reference model for systems engineering and situate the model
in relation to prior reference models. To aid application of the
reference model, we propose a set of reference processes from
which a complete development process can be assembled. We
illustrate both the reference model and the reference process
by way of application to a simple example.
II. RE LATE D WORK
A. The Functional Documentation Model
Parnas and Madey lay out a reference model for the design
of software systems that is based on four classes of variables
and five relations or predicates on those variable classes [1].
The four variable classes are:
1) monitored (m)
2) controlled (c)
3) input (i)
4) output (o)
The five relations are:
1) NAT — the environment
2) REQ — the requirements
3) IN — the inputs
4) OUT — the outputs
5) SOF — the software
The Functional Documentation Model, frequently called the
four-variable model, has been very successful; a subset of the
model is implemented in the SCR toolset [2].
B. The WRSPM Model
Gunter et al. lay out an alternative reference model that,
rather than focusing on variables and relations directly, in-
creases its scope to also include artifacts that are more familiar
to systems engineers. The model has five elements:
1) World
2) Requirements
3) Specification
4) Program
5) Machine
A key feature of the WRSPM model is its emphasis on the
explicit identification of the environment (the world) in which
the system will operate. In their comparison of the WRSPM
model to the functional documentation model, Gunter et al.
emphasize that the separate identification of the system and
the environment enables them to resolve some ambiguities
permitted by the functional documentation model.
A critical component of the separation of the environment
from the system in the WRSPM model is the identification
of environment and system phenomena. These phenomena are
partitioned into visible and hidden phenomena. The system,
for example, in the WRSPM model, has access to the visible
phenomena of the environment but does not have access to
the hidden phenomena of the environment.
Moreover, Gunter et al. explicitly identify the importance
of calling out the relationship between the visible phenomena
in the environment and the visible phenomena in the system.
They name this relationship the designated terminology and,
when introducing it, call the designated terminology the sixth
artifact in the reference model. However, the designated termi-
nology never appears in the name of the reference model and
is quickly set aside in favor of focusing on the other artifacts
in the model.
Hall and Rapanotti propose a refinement to the WRSPM
model that endeavors to simplify proof obligations for the
relationships amongst the artifacts by introducing time, specif-
ically the time at which the system will be introduced into
the environment and the time at which the system will be
removed from the environment. Rather than further clarifying
the distinction between the environment and the system, this
enhancement further confuses the two by assuming that time
in the environment is the same as the representation of time
in the system. Although this distinction should be evident,
so many system failures have been traced to the incorrection
assumption that system time matches time in the environment
that any reference model explicitly including time must make
the distinction clear.
C. The WRASPM Model
Strunk et al. present an enhancement to the WRSPM model
that focuses explicitly on the role of the designated terminol-
ogy. The goal of this enhancement is to provide a defensible
clarification for the role of requirements and specification.
Requirements, according to Strunk et al., are phrased entirely
in terms of environment phenomena and, more specifically,
in terms of visible phenomena of the environment. Specifi-
cations, on the other hand, are phrased entirely in terms of
system phenomena and, more specifically, in terms of visible
phenomena of the machine. Since each of these two artifacts
is restricted to referencing disjoint sets of phenomena, a new
artifact is needed that links the visible phenomena of the
environment that are referenced by the requirements to the
visible phenomena of the system that are reference by the
specification. This artifact, which subsumes the role of the
designated terminology in the WRSPM model, is called the
axioms, and is represented by A.
The axioms in the WRASPM model do more than trivially
related phenomena in one set to phenomena in another: they
may also specify constraints under which the phenomena may
be considered to be equivalent. These constraints represent an
early form of the correspondence model (described in more
detail below) as they begin to identify the ways in which
machine representations are understood to differ from their
corresponding real-world phenomena.
D. Challenges
Three significant challenges remain unaddressed by the
reference models described above.
1) The Role of the Problem. Each model implies solution
to an identified problem, but does not explicitly include
the problem as a first-class citizen in the model.
2) The Role of Correspondence. The WRASPM model
identifies the relationship between environment and
machine phenomena using axioms, but stops short of
providing a comprehensive description of this critical
correspondence.
3) The Role of the Argument. Each model implies an
argument that the identified problem is solved, but does
not explicitly include the argument as a first-class citizen
in the model.
We introduce the Seven Artifact model to address each of
these concerns. We describe how each of these challenges is
specifically addressed in Section V.
III. REF ER EN CE ART IFAC TS
The reference model is largely based upon these obser-
vations and upon prior related work on problem-oriented
development approaches [3] [4] [5].
Generally, a problem oriented reference model consists of
four abstract components:
1) the Problem;
2) the Environment;
3) the Solution; and
4) the Argument.
The Argument tells us that the Solution in its intended Envi-
ronment solves the Problem.
The reference model extends the basic problem-oriented
concepts to include the following artifacts:
1) the Problem;
2) the Requirements;
3) the Context;
4) the Correspondence;
5) the Specification;
6) the Implementation; and
7) the Argument.
Many of these artifacts are familiar but some — notably the
Context and the Correspondence — may be unfamiliar.
The reference model enhances the typical systems engineer-
ing picture in several important ways:
•Separation of the requirements from the problem:
Traditionally, requirements define a problem to solve;
however, elicited requirements might not define the right
problem. Often development begins with an abstract prob-
lem description that is further refined into requirements.
The reference model separates the abstract problem from
the requirements to better align with how systems are
developed and to explicitly address the risks associated
with abstract problem identification and requirements
elicitation separately.
•Replacement of the environment with context: the
reference model defines a more general notion of con-
text that subsumes the physical environment, providing
additional and important information for development
beyond what is defined in terms of physical phenomena.
Regulation, for example, is part of a system’s context but
not necessarily its physical environment.
•Addition of correspondence: Correspondence is an ex-
plicit relationship between phenomena of the real-world
and phenomena specific to the solution. Correspondence
is helpful in justifying that an implemented solution
actually solves the problem by showing how phenomena
are related.
•Refinement of the solution into the specification and
implementation: The “solution” is essentially the imple-
mented system; however, solutions are not engineered di-
rectly from the problem in practice. Refining the concept
of “solution” into the specification and implementation
is more aligned with how systems are developed. A
specification is developed to satisfy requirements, and an
implementation is developed to satisfy the specification.
Risks associated with development of the specification
and the implementation are therefore crucial in justifying
the solution system solves the problem.
These enhancements allow systems engineers to make a
more compelling and comprehensive argument. Specifically,
the argument tells us that:
1) the Problem, Context and Requirements are adequately
defined and
2) the Implementation of the Specification in Correspon-
dence with its intended Context satisfies the Require-
ments of the solution to the Problem.
The assurance goal implied by this kind of argument is
successful development of the intended system.
A. Terminology
Before describing each of these components of the refer-
ence model in detail, we first introduce some definitions for
recurring concepts.
•Phenomenon A phenomenon is an observable entity.
Examples of phenomena include events, values and re-
lationships.
•Variable A variable describes a phenomenon that has
values.
•Type A type describes the set of possible values for
variable.
•Instance An instance is a particular value of a given type.
•Domain (or Knowledge Domain) A community of like-
mindedness and shared “mental space”. A domain refers
to the knowledge ecology of an expertise or field. Al-
though a domain can be partially captured in artifacts doc-
umenting regulations, protocols, operational definitions,
relevant phenomena, etc., domains are abstract concepts,
defined by a collective of mental models and social
convention/agreement of experts.
•Optative Optative expresses realizable intention or desire.
•Indicative Indicative expresses a statement of fact.
•Successful Development System development is consid-
ered successful if (1) the problem is adequately defined
and (2) the problem is solved. More specifically, the
problem is solved if the system implementation of the
system specification in correspondence with its intended
context satisfy the requirements of the solution to the
problem.
B. The Problem
The problem captures the essence of the customer’s need as
simply and succinctly as possible with respect to the context.
Hence, the problem is an abstract problem description and/or
a set of abstract requirements, not a completed requirements
document. The rationale is to first focus the abstract problem
and then refine the problem into requirements in subsequent
development activities.
We think of the problem as being the first component of
the reference model as it drives development, but it cannot be
defined without reference to its context, and in particular its
physical environment. This is natural, as the problem emerges
from the context and is typically defined to alter some set of
phenomena of the environment. Rigorously,
AProblem describes an alternate optative Environ-
ment in which some Phenomena differ from those
in the actual, indicative Environment as defined in
the Context.
C. The Context
The context is a comprehensive and indicative description
of constraining aspects of the world that the system under
development will operate in. Context typically cannot be fully
documented due to scope. Instead, context is defined largely
based on domain specific reckoning of context. Context is
therefore defined operationally; however common entities of
the context include the physical environment, the system do-
main, staff/support infrastructure, maintenance infrastructure,
regulations, etc.
The concept of “context” is an extension of “environment”
or “world” (the physical environment) within a problem-
oriented approach. Since all systems operate within the a
physical setting, the physical environment is a mandatory com-
ponent of the context. The rationale for extending the physical
environment into the notion of context is the observation that
often other indicative factors that are not easily expressed as
physical phenomena constrain development. For example, the
domain in which the system is developed and regulations.
The environment is a highlighted component of the context
within the reference model, not only because the environment
is a mandatory component, but the environment is perhaps
the most pervasive element of context throughout the system
development. Regulatory context, for example, influences re-
quirements and constraint design and implementation, but en-
vironment influences all phases stages of system development.
Further, a system is typically alters some phenomena of the
physical environment in some manner to solve the problem,
whereas other components of the context are not altered by
the system. We therefore provide a more rigorous definition
of the environment as follows:
The Environment includes a set of related Indica-
tive Phenomena that are usually treated as a unit
in problem analysis. The Types associated with the
Phenomena of the Environment exist in the world
outside of the System. These Environment Types are
sometimes also called Real-World Types.
D. The Requirements
The requirements refine the identified problem, constraining
the solution space of the problem further by identifying
elements of the solution that are of particular importance to
the customer. Rigorously,
Requirements express the solution to the Problem
in terms of Variables or Values of the Phenom-
ena shared between the Problem and the Envi-
ronment. Because Requirements, through Problem
they solve, express a possible, future Environment,
they are an Optative description.
While the problem speaks about the future environment
in simple, succinct terms, the requirements speak about the
future environment in detail. Because the requirements are
restricted to environmental phenomena, engineers are limited
to describing what the solution will accomplish. Without
reference to the phenomena of the system, engineers are
precluded from saying how the system will solve the problem.
E. The Specification
The specification is the beginning of the realization of the
solution requirements. Rigorously,
The Specification describes an Optative set of Phe-
nomena that is the System. The Types associated
with the Phenomena of the Specification exist in
the System. These System Types are sometimes also
called Machine-World Types.
While the requirements speak about the future environment
in detail, the specification speaks about the future system in
detail. The specification is restricted to system phenomena,
limiting engineers to describing the system that will solve the
problem.
F. The Correspondence
The requirements express the solution in terms of environ-
mental phenomena. The specification expresses the solution
in terms of system phenomena. In order to show that the
specification indeed satisfies the requirements, and thus solves
the problem, the relationship between system phenomena
referenced in the specification and environmental phenomena
referenced in the requirements must be described. The corre-
spondence expresses this relationship. Rigorously,
The Correspondence between System Types and
Environment Types is made through an Indicative
description of the Environment. This description
provides a Correspondence Model of critical rela-
tionships amongst Phenomena that are shared be-
tween the Environment and the Specification.
G. The Implementation
The implementation is the realization of the specification
and by extension the solution requirements. Rigorously,
The Implementation expresses the realization of
the Specification in terms of the System Types
introduced in the Specification. Additionally, the
Implementation may rely on hidden Phenomena
of the System — that is, System Phenomena that
were not shared between the Specification and the
Environment and are not described in the Corre-
spondence.
The specification can be conceptualized as a high-level
system design. During implementation, the specification is
further decomposed into a detailed design until the level of
granularity is sufficient to build the actual system.
H. The Argument
The reference model artifacts are tied together by the last
reference model artifact, the argument. The argument provides
the rationale for belief that the problem has been identified
and the implemented system successfully solves the identified
problem. Rigorously,
The Argument is an explicit and comprehensive
logical structure, supported by a body of evidence,
justifying that the developed/implemented system
is Successful. Successful development requires not
only a justification that the developed system solves
the identified Problem within the given Context
(e.g., Environment and regulatory considerations),
but also requires justification that the Problem and
Context are correctly, completely and appropriately
identified.
Where possible, the argument can be based on deductive/
formal logic; however, requirements are fundamentally infor-
mal and doubts exist about the fidelity of formal models.
Consequently, the argument is primarily informal and based
on inductive logic.
IV. REF ER EN CE PROCESSES
The reference model provides a set of standard artifacts and
describes their interrelationships. To better use the reference
model, we propose a set of reference processes. The reference
process defines a set of high-level development activities. The
purpose and rationale of these processes is to organize general
engineering activities associated with the application of the
Problem
Definition
Problem
Environment
(mandatory component
of Context)
Solution
Development
Solution
Solution
Assessment Argument
Fig. 1. High-Level Reference Processes
reference model and to relate these activities to the artifacts
defined in the previous section.
The reference processes ground the reference model in
abstract development activities, providing more structure/
guidance for the application and further discussion of the
concepts. The reference processes do not provide detailed
descriptions of development activities, but rather describes the
general activities that surround the reference model artifacts. In
general, reference processes produce reference model artifacts
as outputs.
There are three primary development activities (shown in
Figure 1):
1) understanding the problem,
2) developing the solution, and
3) assessing the solution.
While these activities speak to the rationale underpinning
a general problem-oriented approach, they are too abstract
and do not provide sufficient granularity to align with all
of the reference model artifacts. The reference processes are
therefore refined into five development activities to expose the
relationship between reference model artifacts, and further, to
expose the mechanics of composition (shown in Figure 2):
1) Problem Definition;
2) Solution Definition;
3) Solution Specification;
4) Solution Development;
5) Solution Assessment.
The remainder of this section further describes the detailed
processes and relationships shown in Figure 2. To simplify
the discussion, and to separate out the mechanics of the
adoption of these processes, the model is described as a linear
progression of activities (a waterfall model). Feedback loops
between any set of processes, either for development or to
accomodate future system change and maintenance, are neither
precluded nor mandated by the reference process.
A. Problem Definition
The problem, as described in the reference model, is the
fundamental driver of system development. The first process
component of the reference process is therefore the activity of
defining the problem. The inputs to this activity are any initial
customer ideas about the problem and knowledge about the
problem’s context. In some cases, the context and/or problem
may be previously or partially defined. The output artifacts are
the problem (the abstract problem description) and an an initial
description of the context, which are conceptually developed
in two subprocesses:
1) problem elicitation and
2) initial context elicitation
A specific order in which the outputs are produced is not
assumed. The problem and context will likely be elicited
concurrently. The produced context should be complete with
respect to the identified problem, but, as is discussed in
more detail below, the context is considered “initial” since
further refinement of the problem in subsequent development
activities often reveals deficiencies in the originally developed
context.
B. Solution Definition
The second process component is the definition of the
solution. The primary purpose of solution definition is to
engineer system requirements by refining the previously iden-
tified problem; however, in the process of developing system
requirements, engineers often reveal more information about
the problem necessitating refinements to the context. For
example, a new requirement may reference an environmental
phenomenon that was never defined, or reference functionality
necessitating further explication of relevant regulations. Solu-
tion definition therefore consists of two subprocesses:
1) continued context elicitation and
2) requirements engineering
The problem and the initial context are inputs from the
problem definition activity. The solution requirements and the
context are outputs.
The formality with which requirements are documented
is not specified by the reference process. Requirements can
sometimes be refined into formal descriptions, but not all
requirements are amenable to formalization (e.g., usability
requirements). Whenever possible, formalizing requirements
is advisable to avoid issues associated with the ambiguity of
natural language.
C. Solution Specification
The third process component of the reference process is
the specification of the solution behavior. For this process
component, the requirements and the context are inputs from
the solution definition activity. The specification and the
correspondence are outputs, produced by means of two sub-
processes:
1) correspondence analysis and
2) specification
Problem Definition
Problem Elicitation
Initial Context
Elicitation
Problem Context
Solution Definition
Requirements Correspondence
Model Specification
Solution Development
Implementation
Solution Assessment
Argument
Requirements
Engineering
Additional Context
Elicitation
Solution Specification
Specification
Correspondence
Analysis
Argument Development
Argument Review Approval
Solution Design
Implementation
Fig. 2. Detailed Reference Process
The specification development activity produces the specifi-
cation artifact that stipulates the how the solution system will
be developed to satisfy the system requirements. Correspon-
dence analysis examines those phenomena in the environment
that must be accessed by the system under development and
relates those environmental phenomena to system phenomena
for use by the specification. Correspondence analysis can be
performed after the specification is produced, but could also
be performed iteratively or concurrently with the specification
activity as system phenomena are identified within the speci-
fication artifact.
D. Solution Development
The fourth process component is the development of the
solution. In this process component, the specification is refined
through a detailed system design activity, resulting in detailed
design demands. Design demands are traditionally specified to
a level of granularity sufficient to allow system engineers to
directly implement a solution to satisfy the demands. Concep-
tually, solution development consists of two subprocesses:
1) solution design and
2) implementation
Design demands may also be satisfied by integrating other
modular components. During design, developers assess the
possible benefits in integrating other modular components into
the implemented system rather than implementing the system
in house. For example, developers may find cost and organi-
zational benefits by using existing and reusable components,
or by further decomposing the solution into subproblems to
be compartmentalized and developed in parallel development
efforts.
The use of components to satisfy design demands implies
a third solution development subprocess, component inte-
gration, see Figure 3. The implemented system is produced
by some combination of local (in house) implementation
and component integration. The exact distribution of local
implementation and component integration is based on system-
specific design decisions. Design demands earmarked to be
satisfied by components are said to be delegated or allocated
to components.
The component integration activity requires the selection or
development of components. Components may or may not be
previously developed, developed by third parties or developed
under the concepts of SIAT. Regardless of the origin and devel-
opment methodology of components, justification is required
to demonstrate that the composed components are compatible
and that the design demands delegated to components are
satisfied by the provided behavior of referenced components.
The relationship between development processes is shown
in Figure 3. General compatibility is assessed through as-
sessment and comparison of contexts. Delegated demands
are satisfied by contractural agreement between the delegated
demand and component requirements. This approach keeps
to the problem-oriented approach, hiding component detailed
design from high-level components, promoting flexibility in
component development. Justification of general compatibil-
ity and contractual satisfaction becomes part of the assur-
ance argument developed in the solution assessment process.
Component systems may themselves be implemented using
components recursively.
Component integration is both a development and main-
tenance activity. Component integration is performed post
system deployment in response to changes to components.
Solution Development
(SOS)
Implementation
Detailed Design
Demands
Solution Design
Local
Implementation
Component
Integration
Component Integration
Selection/Development
Compatibility
Assessment
Contract
Satisfaction
Problem Definition
Problem Elicitation
Initial Context
Elicitation
(System)
Problem
Solution Definition
(System)
Requirements
Correspondence
Model
(System)
Specification
Requirements
Engineering
Additional Context
Elicitation
Solution Specification
Specification
Correspondence
Analysis
(System)
Context
Solution Assessment
(System)
Argument
Argument Development
Argument Review (System)
Approval
Solution Development
Solution Design
Implementation
(System)
Implementation
SOS
System (selected or developed component)
Fig. 3. Recursive Component Development and Integration
E. Solution Assessment
The final process component is assessment of the solution.
The goal of this process component is to verify and validate
that the implemented system is a solution to the problem.
The inputs to this process are all of the reference pro-
cess outputs: problem, context, requirements, correspondence,
specification, and implementation. Solution assessment also
uses fine-grained details about each development process and
development artifact as necessary. For example, if components
are integrated into the solution, solution assessment also uses
details of the compatibility assessment and contract satisfac-
tion. The outputs of solution assessment are an assurance ar-
gument and documented approval of the implemented solution
based on a careful review of the argument. Solution assessment
therefore consists of two subprocesses:
1) argument development and
2) argument review
The argument is a comprehensive justification that the
development process was successful: the solution system (the
implementation) solves the problem, and the problem (the
problem description, context, and requirements) has been
adequately identified. The argument can be iteratively and
incrementally developed in parallel with all other reference
model processes [6]
Because of the scope and purpose of the argument, argument
development can serve as an initial and incremental assess-
ment of the implemented system: assessments are required at
each level of argument development to justify claims. The
argument, however, is an artifact documenting belief that
the development is successful. Final approval of the solution
system is still necessary prior to system deployment.
A domain-specific authority is designated to review and
confirm the solution system is indeed successful. Since the
argument captures the comprehensive belief that the system
is successful, review of the system is primarily a review
of the argument (argument claims and supporting evidence).
The reviewing authority can be the customer, domain-specific
experts and/or other third-party stakeholders (e.g., certification
authorities). At the end of the review activity, the solution is
either approved for use, or deficiencies are identified necessi-
tating refinements in earlier reference processes.
V. DISCUSSION
The Seven Artifact model addresses each of the challenges
laid out in Section II. Specifically, the Seven Artifact model
explicitly includes the Problem, situates the Correspondence,
and explicitly includes the Argument.
A. The Role of the Problem
Each of the reference models discussed above imply that
the system being developed is intended to solve an identified
problem. Parnas and Madey focus entirely on requirements
and imply that requirements are the first or only statement of
any problem the customer wishes to see solved [1]. Gunter
et al. begin by noting that requirements frequently fall into
two categories: requirements that are written by the customer
and requirements that are written by the developers, thus
acknowledging that systems are developed to solve customer
problems without, however, directly discussing problems [7].
Hall and Rapanotti discuss problem and solution, but do not
draw a distinction between problem and requirements [8]; in
later work, Hall and Rapanotti can be seen to define problems
as encompassing requirements, systems and their environ-
ment [9]. Strunk et al. use the WRASPM model to draw a
sound distinction between requirements and specifications, but
do not draw a distinction between problem and requirements.
Jackson deals extensively with problems and their solutions
in his presentation of problem frames [4]. A problem is solved
when the machine, in its environment, satisfies its require-
ments. This formulation strongly suggests that the problem
and the requirements are equivalent or, if not equivalent, that
the requirements are a refinement of the problem.
The Seven Artifact model includes the problem as a first-
class artifact and views the problem as being distinct from
the requirements. The model defines the problem as the
initial statement of customer need, much in keeping with
Jackson’s illustrations throughout his presentation of problem
frames [4]. The problem articulates a need that the customer
has identified and may be vague, while the requirements begin
to outline and constrain the solution to the problem in terms
of environmental phenomena. There is, thus, a one-to-many
relationship between problem and requirements that we feel
underscores the importance of keeping these two artifacts
separate: for any given problem, several sets of requirements
may be advanced to describe solutions to the problem. The
one-to-many relationship is seen often in the way systems are
acquired: a single bid (which contains a problem statement)
is answered by many bids (which contain requirements), one
of which is eventually selected to be refined and reduced to a
working system that, ideally, completely solves the problem.
The role of the problem and the role of requirements in the
Seven Artifact model are discussed further, below.
B. The Role of Correspondence
Gunter et al. propose the WRSPM model to address, in part,
weaknesses that they identify in the IN and OUT relations of
the Functional Documentation Model [7].
Strunk et al. propose the WRASPM model to address,
in part, lack of clarity in the role of the designated termi-
nology [5]. Using the axioms, WRASPM clearly identifies
which environmental phenomena are represented by which
system phenomena, by explicitly stating the relationships and
constraints on phenomena described in the requirements and
phenomena described in the specification.
Xiang et al. describe a system by which explicit models
of the correspondence between real-world types and their
representation in computer software may be constructed and
analyzed [10]. These correspondence models subsume the
role of the designated terminology from the WRSPM model
by documenting explicitly the correspondence between en-
vironmental phenomena and associated system phenomena.
Additionally, correspondence models extend the axioms from
the WRASPM model by documenting the essential approxi-
mation that occurs when real-world types, which are usually
continuous or infinite, are represented by machine-world types,
which are necessarily discrete and finite.
The Seven Artifact model extends the correspondence
model from computer software to systems and includes corre-
spondence as a first-class artifact. The role of correspondence
in the Seven Artifact model is discussed further, below.
C. The Role of Argument
Argument plays a central role in each of the reference
models described above, although none of these reference
models explicitly include argument as a component.
The relations in the Functional Documentation Model pro-
vide the foundation for defining ”software acceptability” [1].
Software is acceptable when a proof in deductive logic can be
completed for the proof obligation:
∀m, i, o, c[IN(m, i)∧SOF(i, o)∧OUT(o, c)∧NAT(m, c)
=⇒REQ(m, c)] (1)
(See Section II for definition of terms.) The claim of software
acceptability and evidence from completion of the proof
outline a partial, implicit argument for the developed system.
Unfortunately, the model does not stress the importance of
argument in establishing the correctness of the critical rela-
tions or the variable classes. This step is perhaps viewed as
obvious, but underscores the risk of argument based purely
on formal logic: epistemic uncertainty remains that, when left
unaddressed,
The artifacts in the WRSPM model provide the foundation
for several defined proof obligations on both the system and
the environment side [7]. As for the Functional Documenta-
tion Model, these proof obligations, combined with evidence
from completing the proofs, outlines an implicit argument for
system acceptability. The argument in the WRSPM model
is richer than the argument in the Functional Decomposition
Model, as it considers both system-side and environment-side
obligations. Nevertheless, the argument in the WRSPM model
is not explicit and does not ask for explicit evidence to support
claims of correctness or completeness in the identification of
critical artifacts, including the world, the requirements and the
machine.
In describing the WRASPM model, Strunk et al. make
explicit reference to argument, noting: “If the system re-
quirements are stated as the goal, then an assurance case
can be constructed from the details of the specification” [5].
Unfortunately, this statement is somewhat confusing, as “sys-
tem requirements” are not a valid goal — goals must be
assertions. In later work, Strunk and Knight revisit the role
of system requirements in the assurance case, but focus on
synthesizing the narrower concept of problem frames (cf. [4])
with assurance argumentation, rather than the role of the
argument in the WRASPM model.
The Seven Artifact model refines and extends the work of
Strunk and Knight and Strunk et al., explicitly including the
argument as a first-class artifact and detailing its role. The
Seven Artifact model goes beyond identification of the goal,
inferences and evidence associated with requirement satisfac-
tion, and makes explicit provision for arguing the correctness
and completeness of each other artifact, ensuring that doubts
arising from each artifact are presented and addressed. The
role of the argument in the Seven Artifact model is presented
in detail, below.
VI. IL LU ST RATI VE EXAMPLE
The proposed reference model and reference processes
provide systems engineers with clear identification of re-
quirements, context, architectural demands, and interfaces. To
illustrate the model and processes, we present and discuss an
example of a simple pitch-attitude monitoring capability for
an unmanned aircraft.
A. Understanding the Problem
The customer has been flying a remotely piloted aircraft for
a while and is concerned because sometimes the pitch attitude
becomes excessive without warning. The customer might say
to the developer, simply, “my pitch attitude becomes excessive
without my realizing it,” but, more likely, the customer will
have already decided that he or she would like to have a
monitoring system. The customer might therefore state his or
her need like this:
A system is needed to provide pitch-attitude mon-
itoring for a small, remotely piloted aircraft. The
system should continuously monitor pitch attitude
and alert the pilot when pitch attitude exceeds ±
45◦.
We call this need a problem, and cast the development effort
in terms of solving the customer’s problem. A successful de-
velopment effort solves the customer’s problem completely —
or sufficiently completely that the customer will be satisfied.
Integral to solving the customer’s problem are business-related
concerns — such as managing the effort so as to complete the
solution on budget and on time — and regulatory concerns
— such as adhering to any regulations that might inhibit the
customer’s use of the solution.
Often, contrary to initial statements, which focus entirely
on functionality, assurance is integral to the problem. The
first step in solving a problem is therefore understanding
the problem as completely as possible. This means that the
statement of functionality must be refined, the overall system
context must be defined, and assurance must be defined. The
developer, upon receiving the problem statement, might ask
questions like:
•Is there additional functionality desired that has not been
expressed?
Or:
•Is the aircraft fitted with a pitch sensor?
•Does the aircraft system have an alerting capability?
•Does the aircraft have a computer system that can be used
to conducting monitoring and activate the alert?
Or:
•What level of assurance is required?
•Does the assurance arise as a result of regulations?
Upon receiving answers to these questions, the refined
problem statement might be written:
A system is needed to provide pitch-attitude mon-
itoring for a small, remotely piloted aircraft. The
system should continuously monitor pitch attitude
and alert the pilot when pitch attitude exceeds ±
45◦. The system is comprised of a pitch sensor, a
computer, and an alarm. The pitch sensor provides
input to the computer through memory-mapped I/
O. The alarm is activated by the computer through
memory-mapped I/O. The system must provide at
least five nines of availability.
B. Defining the Solution
The problem statement is equivalent to a set of very
high-level requirements: it captures the essence of what the
customer wants. But requirements are best thought of as being
about the solution, describing what functionality/behavior the
system must provide, in terms of changes to the environment,
to solve the problem. We therefore separate the problem state-
ments from the requirements. Additionally, there is typically
more than one set of requirements for a given problem state-
ment, just as there is more than one possible implementation
that satisfy a given set of requirements.
The second step in solving a problem is identification of
the context in which the problem exists and the solution must
operate. This identification actually takes place concurrently
with understanding the problem, extends into the identification
of solution requirements and continues through design and im-
plementation. The context consists of the physical environment
and potentially other factors, such as regulatory constraints.
The third step in solving a problem is to work with the
customer to identify the requirements that will constrain the
solution to the problem. This task is among the most difficult
in system and software engineering, as it is fundamentally
informal and fraught with opportunities for misunderstanding
and miscommunication. This task is also among the most
important in system and software engineering, as errors intro-
duced in requirements are exponentially more expensive to fix
than errors introduced later in the development cycle. Working
from a clear understanding of the problem helps to ensure that
requirements are accurately and completely identified, but does
not guarantee it.
The requirements for the pitch-attitude monitoring system
might include the following:
The system shall raise the alarm when pitch attitude
is greater than 45◦or less than –45◦.
Requirements describe how the environment should change
to solve the problem. Thus, the concurrency of solution
requirements and solution context identification is essential.
This is clear from the example above:
•“raise the alarm” refers to the alarm — a part of the
identified context, as stipulated in the refined problem
statement
•“pitch attitude” refers to a state of the aircraft — a part of
the environment from the point of view of the monitoring
system, because it is beyond the system boundary
•the thresholds also refer to the state of the aircraft
Additionally, elements of the solution context may contribute
requirements that are not explicit in the problem statement.
The regulatory environment, in particular, is a frequent source
of additional requirements.
C. Developing the Solution
The fourth step in solving a problem is, broadly speaking,
building the solution. This step includes specification, design
and implementation.
The specification is high-level description of how the system
will satisfy its requirements. Ideally, the specification should
be sufficiently abstract to support multiple paths of implemen-
tation. In this respect the specification can be thought of as
“what” the system must do to satisfy its requirements, and
further design specifies “how” the specification is satisfied.
The distinction between “how” and “what” is often unclear
and dependent on point of view [11]. The specification for the
pitch-attitude monitoring system might include the following:
The system shall issue the alarm command to the
transmitter when the pitch input provided by the
pitch sensor is greater than 45◦or less than 45◦.
The design describes how the system will bring about the
change to the environment. The implementation yields the
system that effects the change.
D. Identifying Solution and Problem Discrepancies
Careful examination of the example from the specification
and the example from the requirements reveals a problem.
The requirements are stated in terms of the environment, but
the specification is stated in terms of the system. There is an
implicit assumption encoded in the specification that “the pitch
input provided by the pitch sensor” is the same as the “pitch
attitude” described in the requirements.
This assumption is fundamentally flawed. While it is de-
sirable for the pitch input from the sensor to be the same
as pitch attitude, they are in reality distinct phenomena. The
input received from a properly designed, properly installed,
and properly functioning sensor should closely correspond to
the phenomenon it observes, but it cannot be relied upon to
perfectly represent that phenomenon at all times. Instead, the
input from the sensor approximates the phenomenon, but is
subject to latency, inaccuracy, imprecision, range limits, etc.
Without identifying the flaw in this assumption, the valida-
tion effort might conclude that the specification satisfies the
requirements simply because it includes the same thresholds.
The result would be a system that, once fielded, sometimes
satisfies the requirements but sometimes does not. If the cus-
tomer considers ±45◦pitch to be a hard limit, the system will
not satisfy the customer and development will be unsuccessful.
E. Validating the Solution
Validating that the specification satisfies the requirements
therefore requires identifying the correspondence between el-
ements of the specification and elements of the environment. In
this example, the pitch input from the pitch sensor corresponds
to the pitch attitude of the aircraft. The identification of
the correspondence includes identifying what is lost in the
approximation of the pitch attitude by the pitch sensor, to
include accuracy, precision and latency.
If the pitch sensor promises ±1◦accuracy, then the system
may not warn the pilot until the pitch attitude has exceeded
±46◦. If the pitch sensor furthermore promises ±2◦precision,
the warning may not take place until the pitch attitude has
exceeded ±48◦. Moreover, if the pitch sensor promises 0.5
seconds latency, the response may be delayed even further.
Exactly when the warning will be issued will depend on the
dynamics of the aircraft and how quickly pitch attitude can
change in 0.5 seconds.
Having identified the approximation of pitch attitude by
the pitch sensor in the correspondence, it is now clear that
validation cannot succeed. In identifying the requirements, we
have unwittingly stipulated a requirement that cannot possibly
be satisfied. We cannot show that the specification will satisfy
the requirement because, most of the time, it will not.
There are two solutions to this problem:
1) We modify the requirement so that it is satisfiable;
2) We change our understanding of validation to include
the necessary approximation made by the sensor.
The first approach is much better than the second ap-
proach. While the second approach has the advantage of
being simpler and more expedient, it prevents the issue from
being clearly documented and explained. If instead we modify
the requirement, we will clearly document the problem of
approximation of pitch attitude by the sensor. Doing this
will force us to consider other requirements related to pitch
attitude — we are thus likely to identify and correct all of the
related requirements issues at once. A risk in modifying the
requirement, however, is that the new requirement is overly
tailored to the details of the solution. We must be careful to
express the revised requirement so that the new requirement
admits the necessity of approximation but does not depend
upon or assume a specific approximation.
F. Refining the Problem and Solution
There are a number of ways in which the revised require-
ment might be stated. The exact phrasing will depend upon
the needs of the customer — in particular, how precise the
customer requires the pitch-attitude monitoring to be. Simple,
straightforward phrasing of the requirement is no longer pos-
sible: acknowledgement of the approximation requires consid-
eration of false positive as well as false negatives for the alarm
— even when all parts of the system are operating correctly.
While we might be tempted to say that the rate of false
positives and false negatives is a design detail, the discussion
above shows that it is not. The customer may not be used to
thinking of these kinds of details, but they are fundamentally
part of the requirements that define the solution.
In this example, the customer may not be overly concerned
with precision, and may accept requirements that say:
The system shall raise the alarm when pitch attitude
is greater than 45◦or less than –45◦. The system
shall not raise the alarm when pitch attitude is less
than 40◦or greater than –40◦.
These requirements state the limit of acceptability for false
positives and false negatives without resorting to probabilities
— probabilities that, mostly likely, the customer does not
know. Between these stated limits, the behavior of the system
is not constrained. The alarm may be raised or not and the
requirements will still be satisfied.
With a sufficiently accurate and precise sensor, with suffi-
ciently low latency given the dynamics of the aircraft, we can
ensure that an alarm is never raised when it should not be and
is always raised when it should be — provided that the system
is working correctly.
VII. CONCLUSION
We introduced a novel reference model that addresses the
importance of clearly and completely identifying the context in
which a system and its development effort will take place. The
reference model emphasizes the relationship between environ-
mental phenomena and their representation in the machine,
enabling engineers to ensure that the interface between the
machine and its environment are correctly handled.
To aid adoption of the reference model, we presented a
set of reference processes that, together, describe a defensible
development approach that emphasizes successful solution to
the customer’s problem.
We illustrated the reference model and reference processes
by application to a simple example.
ACKNOWLEDGMENT
This work was funded in part by USAF AFLR/RQQA
contract FA8650-14-C-2528.
REFERENCES
[1] D. L. Parnas and J. Madey, “Functional documents for computer
systems,” Science of Computer Programming, vol. 25, pp. 41–61, 1995.
[2] C. Heitmeyer, A. Bull, C. Gasarch, and B. Labaw, “Scr: a toolset for
specifying and analyzing requirements,” in Computer Assurance, 1995.
COMPASS ’95. Systems Integrity, Software Safety and Process Security.
Proceedings of the Tenth Annual Conference on, Jun 1995, pp. 109–122.
[3] E. A. Strunk and J. C. Knight, “The essential synthesis of problem
frames and assurance cases,” Expert Systems, vol. 25, no. 1, pp. 9–27,
2008.
[4] M. Jackson, Problem Frames: Analyzing and Structuring Software
Development Problems. Boston, MA, USA: Addison-Wesley Longman
Publishing Co., Inc., 2001.
[5] E. Strunk, C. Furia, M. Rossi, J. Knight, and D. Madrioli, “The engi-
neering roles of requirements and specification,” University of Virginia,
Department of Computer Science, Tech. Rep. CS-2006-21, 2006.
[6] P. J. Graydon, “Assurance based development,” Ph.D. dissertation,
Charlottesville, VA, USA, 2010.
[7] C. A. Gunter, E. L. Gunter, M. Jackson, and P. Zave, “A reference model
for requirements and specifications,” IEEE Software, vol. 17, no. 3, pp.
37–43, May 2000.
[8] J. G. Hall and L. Rapanotti, “A reference model for requirements
engineering,” in Proceedings. 11th IEEE International Requirements
Engineering Conference, 2003., Sept 2003, pp. 181–187.
[9] ——, “Assurance-driven design in problem oriented engineering,” In-
ternational Journal on Advances in Systems and Measurements, vol. 2,
no. 1, pp. 26–31, 2009.
[10] J. Xiang, J. Knight, and K. Sullivan, “Real-world types and their
application,” in International Conference on Computer Safety, Reliability
and Security (SAFECOMP), 2015.
[11] M. Whalen, A. Gacek, D. Cofer, A. Murugesan, M. Heimdahl, and
S. Rayadurgam, “Your “what” is my “how”: Iteration and hierarchy in
system design,” Software, IEEE, vol. 30, no. 2, pp. 54–60, March 2013.
