Transcript Requirements

Requirements
Requirements
1
Requirements: First Ideas
• Requirements should state what a system will do
but not how it will be done.
• A basic question in Requirement Engineering is
how to find out what users really need.
• In order to gain an insight into the nature of
requirements we need to look beyond such high
level statements.
• Requirements are concerned solely with
phenomena in the world (or environment).
• Specifications are concerned solely with the
shared phenomena between the world and the
machine.
Analysing the statement of
requirements
• The customer produces a statement of
requirement. The developer performs a process
known as requirements analysis. Once the
software developer fully understands what the
customer wants, a precise specification for the
software is written. This specification is known as
the negotiated statement of requirements and
represents an agreement between the customer and
the software developer about what the software
will do.
Analysing the statement of
requirements
• The starting point of any software project is a
document prepared by the customer for a system,
known as the statement of requirements. This
document, can be a few pages in length or can
consist of a number of volumes of text. Normally,
the less experienced in computing a customer is,
the smaller the statement of requirements will be.
Analysing the statement of
requirements
• If the customer is knowledgeable about computing
systems and what can be done, there is a tendency
to include implementation issues and directives,
such as ‘the language used must be Java or ‘the
system must run on a XYZ PC’. In the statement
of requirements, the customer sets out in detail
what a proposed software system is required to do,
and may specify constraints upon the system and
constraints upon the development process.
Analysing the statement of
requirements
• Given a statement of requirements, the developer
has to carry out the process of requirements
analysis. Requirements analysis consists of
analysing the statement of requirements and
extracting and clarifying the important parts; that
is, the behaviour and the constraints. It involves a
period of considerable interaction with the
customer and is probably the most difficult part of
the software project. Why is it so difficult?
Analysing the statement of
requirements
• First, it involves two parties. One of these is an
expert in computing who often has little
knowledge of an application (the developer),
while the other is an expert in a particular
application but with a scant knowledge of the
capabilities of computing systems (the customer).
Hence, there is quite a considerable ‘culture gap’
between the two parties.
Analysing the statement of
requirements
• Second, the statement of requirements usually has
certain problems which make the task of
requirements analysis very difficult.
• Behavioural and non-behavioural requirements
are intermingled.
• The statement of requirements contains
ambiguities.(constraints and non-functional)
• The statement of requirements contains
platitudes.
Analysing the statement of
requirements
• Difficulties with statement of requirement.
• Design and implementation directives are
included.
• There will be omissions from the statement of
requirements.
• Behaviour is described at different levels of
detail.
• The behavioural specification should be
unambiguous.
Difficulties with statement of requirement.
• The behavioural specification should be free of
design and implementation directives.
• The behavioural specification should be in a
form that enables the developer to reason about
the properties of the system it describes.
• The behavioural specification should be free of
extraneous detail.
• The behavioural specification should be
partitioned.
• The behavioural specification should be
understandable by the customer.
Analysing the statement of
requirements
• Types of questions:
– Scoping questions
– Questions about input data
– Questions about output data
– Questions about behaviour
Analysing the statement of
requirements
Scoping questions
– These are questions which attempt to delineate
what facilities should be in a system and what
facilities should not be included.
Analysing the statement of
requirements
• Questions about input data
– A common category of questions involves the
information or data that is to be processed by a
system. This data will be provided from a
variety of sources: from operators of
computers, from files which are already in
existence, from other computers or from pieces
of electronic equipment such as the bar-code
readers you find in a supermarket.
Analysing the statement of
requirements
• Questions about output data
– Computer systems provide a variety of data for
the users. This data can be provided as a printed
report or on a screen. Very penetrating
questions can be asked about the data that is to
be provided. A good question to start off with
is:
– Is this data to be provided on paper or on a
screen?
Analysing the statement of
requirements
• Questions about behaviour
• An important category of questions concerns what
the system should do. These questions will range
from very broad questions to very detailed ones.
Normally the requirements document provided by
a customer will be deficient in two ways: first, it
will not contain descriptions of everything the
customer requires of a system and, second, details
of functions will be very vague.
Some requirements
– The system should provide a facility which allows clerical staff to input
patients’ details.
– The system should report on bed occupancy in wards.
– The system should monitor the state of the reactors in our chemical plants.
– The system should provide a report which details the malfunctioning
reactors in our chemical plant.
– We would like a computer program which keeps track of the bookings that
the passengers of our airline have made in the past.
– The computer program should be able to tell me which passengers are the
most valued.
– Our hotel booking system should process guest details.
– The program which administers our surgery should keep track of the
prescriptions that we issue.
Some requirements
– The system must be completed by 1st January
2007.
– The system specification must be formally
accepted by the steering committee.
– The system must produce a monthly report of
admissions.
– If the system cannot allocate the requested bed
then the system will search for an alternative
Some requirements
–
The programs must be written in C#.
–
The development process should be managed
using the Unified Process.
–
The system should be user friendly.
–
The system must produce a monthly report of
completed treatments.
The inevitable intertwining of
categories of questions
• An important point to notice about the previous
questions is that, although we have tried to present
them in a number of categories, in real life things are
never so simple: a question will often involve any
combination of concerns concerning detailed system
functions, input data, output data and scoping. For
example, some of the questions in the previous section
involved both aspects of a system which were
function-related and aspects which were data-related.
In posing questions you should not be too worried by
the fact that a question does not fit neatly into one of
the four categories above.
Review
• The development of a piece of software cannot
start until a requirements specification is
provided by a customer.
• This specification is usually inadequate for
several reasons:
• the specification will contain behavioural and nonbehavioural requirements;
• the statement of requirements may contain
ambiguities and platitudes;
• the statement of requirements may contain design and
implementation directives;
• there will be omissions from the statement of
requirements;
• behaviour is described at different levels of detail.
Review
• The software developer and the customer
develop a negotiated set of requirements that is
a better description of what the software will do.
• In a simplified view of the process, the
negotiated statement of requirements is achieved
by the software developer asking questions of the
customer about the requirements specification to
elicit more information about the proposed
system.
Review
• The business of removing ambiguities, eliminating
design and implementation directives, for example,
needs to be carried out whatever software
development method is employed.
The meaning of requirements
(Michael Jackson)
The whole business of software development is
making descriptions.
– A requirement is a description of an application domain
and the problems to be solved.
– Specifications are descriptions the interface between the
machine and the application domain.
– Programs are descriptions of machines
• Language is the raw material of description.
• Two types of domain
– the generic domain (WAP, GIS, Accountancy).
– the application specific domain (e.g. hospital system)
The meaning of requirements
(Michael Jackson)
• All the terminology used in requirements
engineering should be grounded in the reality
of the environment for which a machine is to
be built. Jackson distinguishes the machine as
part of the system (e.g. the automated part of
a hospital administration system).
• The requirement identifies which actions are
controlled by the environment, which actions
are controlled by the machine, and which
actions of the environment are shared with
the machine.
The meaning of requirements
(Michael Jackson)
• Environment
• An environment assertion E
expresses a condition over the
phenomena of the environment that
we know to be true irrespective of
the properties and behaviour of the
machine.
The meaning of requirements
(Michael Jackson)
• Simple definition is not very helpful.
– “Requirements say what the system will do and not how
it will do it”
• Jackson’s description: A customer requirement R
expresses a condition over the phenomena of the
environment that we wish to make true by installing
the machine. A requirement is an optative property,
intended to express the desires of the customer
concerning the software development project.
• Requirements are refined to specifications by using
domain knowledge.
The meaning of requirements
(Michael Jackson)
• A specification S is an optative description of a
condition over the shared phenomena at the
interface between the machine and the environment.
• A machine satisfying S will ensure satisfaction of
the requirement R.
• Correct specifications, in conjunction with
appropriate domain knowledge, entail the
satisfaction of the requirements.
• A requirement is an optative (desirable) property.
Let R be the set of requirements for a software
development project, i.e., the set of optative
properties whose satisfaction will fully satisfy the
customer.
The meaning of requirements
(Michael Jackson)
• The environment (AKA application or
domain knowledge) is the portion of the real
world relevant to the software development
project. Requirements exist only in the
environment.
• Correct specifications, in conjunction with
appropriate environment (or domain
knowledge), entail the satisfaction of the
requirements.
The meaning of requirements
(Michael Jackson)
• Definition. You must distinguish between defining new
terms and using existing terms to make statements. We use
Courier New when taking about a software artefact.
• Using formal definition we define new terms on the basis of
terms previously designated or previously formally defined.
• The scope of a description restricts the classes of phenomena
it can talk about (themes).
• The span restricts the area of the world that we can talk
about (location).
• Refutable descriptions say something precise about the
domains.
• Partial descriptions. Need to separate concerns not consider
everything at once.
• Hierarchical structures are a way of separating concerns,
can be rigid.
The meaning of requirements
(Michael Jackson)
• Jackson uses the term “system” to refer to a
general artefact that might have both manual
and automatic components, such as an
“airline reservation system.”
• The computer-based artefact that is the target
of software development, is called the
“machine.”
The meaning of requirements
(Michael Jackson)
• The developers propose to build a computer-based
machine and connect it to the existing environment
in such a way that the behaviour of the environment
becomes satisfactory. Although we are accustomed
to think of machine inputs and outputs, it is
important to realize that those inputs and outputs are
phenomena in the environment. If they were not part
of the environment, then they could not possibly
connect the machine to the environment or affect
the behaviour of the environment. From this
perspective, all statements made in the course of
requirements engineering are statements about the
environment.
The meaning of requirements
(Michael Jackson)
• Phenomena . Are objects or events in the domain
that need to be described.
• The machine can affect, and be affected by, the
environment only because they have some shared
phenomena in common. That is, there are some
events that are events both in the machine and in the
environment; and there are states that are states of
both.
The meaning of requirements
(Michael Jackson)
• Phenomena . Are objects or events in the domain that
need to be described.
• Shared phenomena form the connections among
distinct domains in a very obvious way. The distinct
connected domains may be the machine and its
environment, or agents or domains recognised
within the environment. For example, a passenger in
a lift presses a button, and in the same event the
controlling computer receives an input signal; or the
controlling computer in a railway signalling system
sets an output line to high, and in the same event a
red signal light is illuminated.
The meaning of requirements
(Michael Jackson)
• Requirements are located in the environment,
which is distinguished from the machine to
be built. A requirement is a condition over
phenomena of the environment. A
specification is a restricted form of
requirement, providing enough information
for the implementer to build the machine (by
programming it) without further environment
knowledge.
The meaning of requirements
(Michael Jackson)
The meaning of requirements
(Michael Jackson)
The meaning of requirements
(Michael Jackson)
• To describe requirements appropriately we
must fit our descriptions into an appropriate
structure. This structure must respect the
distinction between the machine and the
environment, and the distinction between
those environment properties that are given
(indicative descriptions) and those that must
be achieved by the machine (optative
descriptions). A specification is also an
optative property, but one that must be
implementable.
The meaning of requirements
(Michael Jackson)
• Formalisation is a fundamental problem of
requirements engineering. Since most environments
are parts of the physical world, and therefore
informal, the formalisation task is inescapable.
Jackson uses designations and the distinguishes
between definition and assertion. By using the
smallest possible set of designated terms,
augmented by appropriate definitions, the developer
can create a narrow bridge between the
environment and its descriptions in the
requirements. In this way a sufficiently faithful
approximation to the informal reality can be
obtained.
The meaning of requirements
(Michael Jackson)
• Ground terms are the terms that fix the relationship between
the description and what it describes. The fundamental
technique in providing an unambiguous mapping is to
choose as ground terms only those phenomena that admit of
sufficiently reliable and unambiguous recognition.
• Designations: Each choice of a term must be explicitly made
and explicitly captured using a designation. A designation
associates a formal ground term, such as a predicate, with
the denoted phenomena, such as an event or entity class or a
relationship over events or entities.
• In logic, a designation is called an “interpretation.” Jackson
avoids the word “interpretation” because it is highly
overloaded in computing. It also carries the unfortunate
connotation that the logic is real and important, while any
correspondence it might have to the world is casual and
incidental.
The meaning of requirements
(Michael Jackson)
• Ground terms fix the relationship between the
description and what it describes. For example, if
we wish to describe human biological relationships
we may use many terms such as mother, father,
uncle, brother, aunt, niece, granddaughter, second cousin, and so on. But a
sufficient set of ground terms is {male,
female, parent}. All the other terms can be
defined on the basis of these three, and all our
descriptions can then be understood if these three
ground terms are understood. Another example
would be some of the classes and associations in
HAS.
The meaning of requirements
(Michael Jackson)
•
Arguably, all of the following are requirements:
–
The computer must not weigh more than 0.25 Kg.
–
The system must be completed by 1st January 1998.
–
The programs must be written in Ada.
–
The system specification must be formally accepted by the steering committee.
– The system should be user friendly (platitude?)
–
The operator interface must be easy to learn.
– The system must produce a monthly report of outstanding debts.
–
•
If passenger in the lift presses the open button while the lift is stationary at a
floor, the doors should begin to open within 0.5 secs.
Jackson looks at requirements in a narrow sense, in which we would include at
most the last three of the examples above, but more probably only the last two. In
effect, we are concerned with what are often called functional requirements (use
cases). However, we do also include under this heading such requirements as
real-time response and those properties of operational safety that can be precisely
stated in terms of system behaviour. Requirements of these kinds are functional;
but they are often excluded from the corpus of functional requirements for no
better reason than the technical difficulty of treating them in a sufficiently
The meaning of requirements
(Michael Jackson)
• The full description of a requirement therefore consists of at
least two parts. We must describe the requirement itself – the
desired condition over the phenomena of the environment.
And we must also describe the given properties of the
environment by virtue of which it will be possible for a
machine, participating only in the shared phenomena, to
ensure that the requirement is satisfied. This distinction
between the desired and the given must be reflected in a
separation of descriptions:
•
Optative: A customer requirement R expresses a condition
over the phenomena of the environment that we wish to
make true by installing the machine.
• Indicative: An environment assertion E expresses a
condition over the phenomena of the environment that we
know to be true irrespective of the properties and behaviour
of the machine.
The meaning of requirements
(Michael Jackson)
• We read inference rules as:
– “given A => B and A we infer B “
– “if from assumption A we infer B, then (without
any assumptions) we infer A => B“
Deduction
Requirements
44
The meaning of requirements
(Michael Jackson)
• Logical entailment is written |between formulas of the
propositional calculus is the
relation A |- B which holds if, and
only if, from assuming A we can
prove B (by using only the
inference rules of the calculus).
• Entailment is often called
provability.
The meaning of requirements
(Michael Jackson)
• Logical entailment (|-) between formulas of
the propositional calculus is the relation A |B which holds if, and only if, from assuming
A we can prove B (by using only the
inference rules of the calculus).
• soundness: “all that can be proved, is true“
• completeness: “all that is true, can be proved"
The meaning of requirements
(Michael Jackson)
• The symbol |- is called turnstile. It is used
to indicate derivation via a sub-proof. The
statement P,Q |- R is called a sequent. Its
meaning is that the expression R is derivable
from the local assumptions P and Q in a subproof. Expressions to the left of the turnstile
are also called local assumptions or local
hypotheses; the expression on the right is
called the local conclusion.
Logical implication
Logical equivalence
 Two propositions are said to be logically
equivalent if their truth tables are identical.
p
q
~p  q
pq
T
T
F
F
T
F
T
F
T
F
T
T
T
F
T
T
Example: ~p  q is logically equivalent to p  q
Requirements
48
Logic Example
• All humans are mortal
• Socrates is a human
• From these premises, we prove
• Socrates is mortal
The meaning of requirements
(Michael Jackson)
• The relationship between E, S and R is an
entailment rather than an inference.
• The implication E /\ S => R
• (unless it were a tautology) would itself be a
further assertion about the environment, in
addition to the assertion E. But the essence of
the relationship is precisely that R can be
deduced (or proved) from E and S with no
further knowledge of the environment.
The meaning of requirements
(Michael Jackson)
• To show that the requirements are satisfiable
by some machine we derive a specification of
the machine. A specification S is an optative
description of a condition over the shared
phenomena at the interface between the
machine and the environment. machine
satisfying S will ensure satisfaction of the
requirement. That is,
The meaning of requirements
(Michael Jackson)
• If a machine whose behaviour satisfies S is installed
in the environment, and the environment has the
properties described in E, then the environment will
exhibit the properties described in R. The
relationship among E, S and R is an entailment, not
an implication. The implication
• (unless it were a tautology) would itself be a further
assertion about the environment, in addition to the
assertion E. But the essence of the relationship is
precisely that R can be deduced from E and S with
no further knowledge of the environment.
The meaning of requirements
(Michael Jackson)
• The nature of a specification
• A specification forms a bridge between requirements engineering, which
is concerned with the environment, and software engineering, which is
concerned with the machine. The distinction is of practical importance,
because it clarifies the differing responsibilities of those whose expertise
lies in acquiring and using knowledge of the environment – often called
application or domain knowledge – and those whose expertise lies in the
invention, design, and construction of computer software. In principle, a
specification allows requirements engineers to reason about the
requirement and its satisfaction in the environment, without mentioning
the properties of the machine. It also allows programmers to reason about
the software and its adequacy for its purpose without mentioning either
the environment properties or the customer’s requirement. This is why it
has traditionally represented the intermediate product between
requirements and programs.
• Requirements -> Specification -> Program.
The meaning of requirements
(Michael Jackson)
• Since most environments are parts of the
physical world, and therefore informal, the
formalisation task is inescapable. Jackson
uses designations and the distinguishes
between definition and assertion.
The meaning of requirements
(Michael Jackson)
• Designations: Each choice of a term must be
explicitly made and explicitly captured using a
designation. A designation associates a formal
ground term, such as a predicate, with the denoted
phenomena, such as an event or entity class or a
relationship over events or entities. For example,
we might write the designation.
Formal term
Domain Information
mother(x,y)
x is the genetic mother of y
The meaning of requirements
(Michael Jackson)
• mother(x,y) is a formally designated term corresponding to a real
world fact. It matches an observable phenomenon, recognisable if and
only if x is actually the mother of y. child(x,y) is not designated;
it is not a directly observable phenomenon at all. It is defined in terms
of mother(x,y). Any assertion about mother(x,y) is
immediately translatable into an assertion about child(x,y). The
definition adds nothing to our capacity to describe the environment –
merely to the convenience of our descriptions.
Formal designated
term
Semantics (recognition rule)
mother(x,y)
x is the genetic mother of y
child(x,y)
child(x,y) :- mother(y,x)
The meaning of requirements
(Michael Jackson)
• These formal definitions add nothing to the bridge between the
reality and its description; nor do they constitute fresh assertions
about the reality. They merely provide more convenient terminology
for saying what we could have said less conveniently without them.
They may be thought of as abbreviations descriptions using the
formally defined terms can always be rewritten to use only the
designated ground terms on which they are ultimately based.
Formal term
Semantics
mother(x,y)
x is the genetic mother of y
child(x,y)
child(x,y) :- mother(y,x)
The meaning of requirements
(Michael Jackson)
• The designation adds significantly to our capacity to describe the
environment we can make assertions that can not be made without
them.
Formal term
Semantics
mother(x,y)
x is the genetic mother of y
child(x,y)
child(x,y) :- mother(y,x)
The meaning of requirements
(Michael Jackson)
• The two tools, designation and definition, underpin an essential
discipline in description. Every term used in every description must
be either designated or defined, and its meaning must therefore be
directly or indirectly grounded in reliable observation of the
environment.
Formal term
Semantics
mother(x,y)
x is the genetic mother of y
child(x,y)
child(x,y) :- mother(y,x)
Walk through Admit Patient
• Given: A name, pName; an address,
anAddress; a date of birth, aDOB; a ward
name, wName; and a team code tCode.
• What actions need to be taken to admit a
patient?
Requirements
60
Walk through Admit Patient
• Specifying a machine solely in
terms of its states appears to
introduce serious implementation
bias, because its states are internal
and not directly observable at the
interface between the machine
and its environment.
Requirements
61
Walk through Admit Patient
1. Locate the instance, aWard, of Ward with the ward name
wName linked to hat via wards. (UI)
2. Locate the instance, aTeam, of Team with the team code
tCode linked to hat via teams. (UI)
3. Check that aWard is not linked via hasOn to any
instance of Patient with name pName.
4. Create an instance, aPatient, of Patient with name
pName, address anAddress and dob aDOB.
5. Create a hasOn link between aWard and aPatient.
6. Create a treats (or caresFor) link between aTeam
and aPatient.
Requirements
62
Requirements are complete if
•
There is a set R of requirements. Each member of R has been validated (checked
informally) as acceptable to the customer, and R as a whole has been validated as
expressing all the customer’s desires with respect to the software development
project.
•
There is a set E of statements of domain knowledge (environment). Each member of
E has been validated (checked informally) as true of the environment.
•
There is a set S of specifications. The members of S do not constrain the
environment; they are not stated in terms of any unshared actions or state
components; and they do not refer to the future.
•
[Proof1] A proof shows that
•
S, E |- R.
•
This proof ensures that an implementation of S will satisfy the requirements.
•
[Proof2] There is a proof that S and E are consistent.
•
This ensures that the specification is internally consistent and consistent with the
environment.
•
Note that the two proofs together imply that S, E, and R are consistent with each
other.
Requirements
63
Requirements
64
What is Modelling?
• A model is anything
that is used as a
replacement for ‘the
real thing’ for some
purposes
– map
– information system
– family tree
Requirements
65
System??
• A system is any
complex collection
which has a
significant purpose as
a whole thing
– the tube
– a person
– payroll
– set of equations
Requirements
66
So what is a…
• System model?
• Working model?
• Software system?
• System design?
• Mathematical model?
• Simple/complex system?
• Good/poor model?
Requirements
67
...and an abstraction?
• An abstraction is a representation which is
simplified, some complexity having been
removed
• Any model must involve some degree of
abstraction
• Mathematics provides a FORMAL means
of abstract modelling
Requirements
68
The Modeling Relation
observable
event
entail
through
causal
behaviour
translate
commute
symbolic
expression
derive
using
rules of
reasoning
translate
world
model
Requirements
69
What is logic?
• It describes the way we REASON
• FORMAL LOGIC formalizes the rules for
reasoning
• MATHEMATICAL LOGIC is a system for
modelling formal logic; it uses...
• DISCRETE mathematics
• SET THEORY is a discrete mathematics
Requirements
70
Some Familiar Models
• a family tree
• a map of the Underground
• a table of football league standings
• a histogram of student numbers by A-level points
• a list of the top 20 record titles
All these can be defined using the same formal structure:
THE SET
Requirements
71
Valid or Correct Models
• A model is said to be valid (or legal) if it conforms to a given
modeling paradigm (e.g. UML). A model is correct if it
faithfully represents reality. Assuming that the modeling
paradigm is correct, we can state that all correct models are
valid models. However, the converse may not true – valid
models are not necessarily correct models. For example,
imagine that an existing hospital is being modeled, but the
modeler fails to include a critical state, such as a WardFull
state. In this case, the UML class diagram is valid (UML does
not require a WardFull state , but merely allows it), but is
incorrect, since it does not represent reality. However, if the
modeling paradigm required every model to include the a
WardFull state, the model would be invalid.
Requirements
72
Requirements Engineering
Criteria
If the five following criteria are satisfied, then requirements
engineering, in the strongest sense, is complete. We are
guaranteed that the specification is implementable (at least in
principle) without recourse to any additional information. We
are also guaranteed that if the specification is implemented as a
machine which is subsequently connected to the environment,
then the requirements will be satisfied.
Requirements
73
Requirements Engineering
Criteria
(1) There is a set R of requirements. Each member of R has
been validated (checked informally) as acceptable to the
customer, and R as a whole has been validated as expressing all
the customer’s desires with respect to the software
development project.
(2) There is a set K of statements of domain knowledge. Each
member of K has been validated (checked informally) as true
of the environment.
Requirements
74
Requirements Engineering
Criteria
(3) There is a set S of specifications. The members of S do not
constrain the environment; they are not stated in terms of any
unshared actions or state components; and they do not refer to
the future.
(4) A proof shows that
S, K |- R.
This proof ensures that an implementation of S will satisfy the
requirements.
(5) There is a proof that S and K are consistent. This ensures
that the specification is internally consistent and consistent
with the environment. Note that the two proofs together imply
that S, K, and R are consistent with each other.
Requirements
75
What is a UML model?
The intermediate descriptions or documents that are produced
in the course of developing a piece of software are known as
models. (Priestley)
A model is a description of (part of) a system written in a well
formed language. A well defined language is a language with
well-defined form (syntax) and meaning (semantics), which is
suitable for automated interpretation by a computer
(Kleppe/Warmer/Bast).
A model is a consistent, coherent set of model elements that
have features and restrictions, where model elements are the
compositional elements that may be used in artefacts written in
the UML/OCL (Warmer and Kleppe 2003).
A constraint is a restriction on one or more values of (part of)
an object-oriented model or system. (Kleppe/Warmer/Bast)
Requirements
76
Jackson’s Frames
Jackson focuses on a conceptual framework centered around
problems rather than solutions [Jack94]. A problem can be
characterized by its principal parts (hypothesis, conclusion)
and a solution task (to show how the conclusion follows from
the hypothesis). The principal parts of a problem to construct
are the unknown, data, and condition. The solution task is to
construct the unknown so that it satisfies the condition with
respect to the data.
Requirements
77
Jackson’s Frames
He provides three examples of problem frames: the JSD
problem frame, where the solution task is to construct a system
that models, or simulates, the real world and satisfies the
function; the workpiece frame where the solution task is to
construct the machine to perform the operations on the
workpieces in response to the operation requests; and the
environment-effect frame where the solution task is to
construct the machine so that it senses and controls the
environment through the connection, and ensures satisfaction
of the requirement.
Requirements
78
Jackson’s Frames
The problem frames are far from interchangeable. The chosen
frame must fit the problem. A good software development
method prescribes a very specific problem frame and exploits
its properties to the fullest. A simple problem is a problem for
which we have a close-fitting frame and an effective method
that exploits it.
Requirements
79
Jackson’s Frames
For example, decomposition has traditionally stood as if they
were self-sufficient. "Having divided to conquer, we must reunite to rule". There is difficulty when the same domain object
appears as two different principal parts in two different
problem frames. To develop one implementation that conforms
to both applies "the Shanley Principle" should be used. A
classic illustration of this principle is a comparison of the V-2
rocket vs. the Saturn rocket. The Saturn uses the fuel pressure
to functionally replace structural rods of the V-2, thus solving
two problems with one domain entity.
Requirements
80
safety property
A property that specifies an invariant over the states in a
design. Loosely speaking, a safety property claims that
"something bad" does not happen. More formally, a safety
property is a property for which any path violating the
property has a finite prefix such that every extension of the
prefix violates the property. For example, the property,
"whenever signal req is asserted, signal ack is asserted within
3 cycles" is a safety property.
Requirements
81
liveness property
A liveness property claims that "something good" eventually
happens. More formally, a liveness property is a property for
which any finite path can be extended to a path
satisfying the property. For example, the property "whenever
signal req is asserted, signal ack is asserted some time in the
future" is a liveness property.
Requirements
82
Requirement (Summary)
•
A functional requirement is an optative (or desirable) property, intended to express the
desires of the customer concerning the software development project. Requirements are
refined to specifications by using domain knowledge. Requirements need to be satisfied
initially by a specification and eventually an implementation. Correct specifications, in
conjunction with appropriate domain knowledge, imply the satisfaction of the
requirements
•
A specification is an optative property, intended to be directly implementable and to
support satisfaction of the requirements. It is a description of the interface between the
machine and the application domain. Along with domain constraint specifications must
satisfy the requirement. The machine is computer-based artefact that is the target of
software development (mention of machine required). It is part of the larger “system”,
which is the general artefact that might have both manual and automatic components,
such as a “hospital system.”
•
The environment (AKA application or domain knowledge) is the portion of the real
world relevant to the software development project. Inputs and outputs are phenomena
in the environment. They connect the machine to the environment or they may affect the
behaviour of the environment (e.g. elevator controller) .
•
The relationship E,S  R
•
If a machine whose behaviour satisfies S is installed in the environment E, and the
environment has the properties described in E, then the environment will exhibit the
properties described in R. The relationship among E, S and R is an entailment
relationship
Requirements
83
Functional Requirement
(Summary)
• The FR should be unambiguous.
• The FR should be free of design and implementation directives.
• The FR should be in a form that enables the developer to reason about
the properties of the system it describes.
• The FR should be free of extraneous detail.
• The FR should be partitioned.
• The FR should be understandable by the customer, analyst and
developer.
Requirements
84
Inadequacies in Functional
Requirement (Summary)
•
Behavioural and non-behavioural requirements are intermingled.
•
The statement of requirements contains ambiguities, both constraints and nonfunctional.
•
The requirements contains platitudes (e.g. user friendly)
•
Design and implementation directives are included.
•
There may be omissions and overlaps requirements (not partitioned).
•
Behaviour is described at different levels of detail. To some extent this is
unavoidable, but high and low level should not be mixed randomly.
Requirements
85
Reducing Inadequacies in Functional
Requirement (Summary)
• The analyst can address these issues by devising several types of
questions. Scoping question. These are questions which attempt to
delineate what facilities should be in a system and what facilities
should not be included. Is accounting or billing part of the
functionality within the scope of the HAS? Questions about input data.
A common category of questions involves the information or data that
is to be processed by a system. This data will be provided from a
variety of sources: from operators of computers, from files which are
already in existence, from other computers. Is the HAS the only way of
accessing patient or doctor information? Can HAS access databases?
What is expected to be typed in by operator? How much and what is
the frequency of data entry.
Requirements
86
Reducing Inadequacies in Functional
Requirement (Summary)
• Questions about output data. Computer systems provide a variety of
data for the users. This data can be provided as a printed report or on a
screen, WWW, PDAs. Very penetrating questions can be asked about
the data that is to be provided Examples Is this data to be provided on
paper or on a screen? Is the HAS the only way of accessing doctor
patient Information? Is output data archived?
• Questions about behaviour. An important category of questions
concerns what the system should do. These questions will range from
very broad questions to very detailed ones. Normally the requirements
document provided by a customer will be deficient in two ways: first,
it will not contain descriptions of everything the customer requires of a
system and, second, details of functions will be very vague. Examples:
The system should report on bed occupancy. Reports on successful
treatments. Update patient records.
Requirements
87
Reducing Inadequacies in Functional
Requirement (Summary)
• A note of reality. In real life things are never so simple: a question (or
answer) will often involve any combination of concerns concerning
detailed system functions, input data, output data and scoping. For
example, some of the questions above involved both aspects of a
system which are function-related and data-related. Although an
awareness of these categories of question will help organise knowledge
about the system the analyst should not be too worried by the fact that
a question does not fit neatly into one of the four categories above.
Requirements
88