The meaning of requirements
Download
Report
Transcript The meaning of requirements
Requirements
Requirements
1
Logic
• ‘Formal logic’ is not a phrase that attracts. Everybody,
perhaps, would like to be logical — but not too logical, in
case they become unfeeling like Star Trek’s Mr Spock...
Hardly anybody wants to be formal.,. We’d rather be
informal, casual, easy, and logical only up to a point.
• But formal logic is hot stuff, because it is the machinery in
the engine room of computing. Computers do very simple
formal logical reasoning, and can’t do anything else. The
programming languages that drive those computers are
formal logics. The protocols that drive the internet and the
grid are formal logics too. Computers do what they do as
well as they do because we know quite a lot about formal
logic, and they keep falling over because we don’t yet know
quite enough.
From: Proof and Disproof in Formal Logic by Richard Bornat
Logic
• Theories in mathematical logic are defined by
their axioms and inference rules (e.g. predicate
logic).
• An axiom is a distinguished expression that
cannot be proved or disproved. We accept it as
being obviously true.
• An inference rule is a valid argument which
permits the substitution of expressions in the
steps of a formal proof.
• A theorem is either an axiom or an expression,
that using the inference rules, is proved equal to
an axiom or a previously proved theorem.
Valid Argument
• We call an argument valid when the conclusion is entailed by, or
logically follows from, the premises. Validity is a property of the
argument's form. It doesn't matter what the premises and the
conclusion actually say. It just matters whether the argument has the
right form. So, in particular, a valid argument need not have true
premises, nor need it have a true conclusion. The following is a valid
argument:
•
All cats are reptiles.
•
Bugs Bunny is a cat.
•
So Bugs Bunny is a reptile.
• Neither of the premises of this argument is true. Nor is the
conclusion. But the premises are of such a form that if they were
both true, then the conclusion would also have to be true. Hence the
argument is valid.
• Arguments are not true or false they are valid or invalid
http://www.jimpryor.net/teaching/vocab/validity.html
Not valid
https://www.youtube.com/watch?v=bWL0BGlvmqg
A sound argument is a valid argument where all the
premises are true
https://www.youtube.com/watch?v=bWL0BGlvmqg
Requirements
• 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.
Requirements
• 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.
Requirements
• 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 (Medical Ontology, 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)
• 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 e.g. patients must be
admitted to a hospital.
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 (S) by
using domain knowledge.
• What is the difference between E and R?
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) 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.
• Check out the logical meaning of Entailment,
Consequence , Inference, and Proof.
http://math.stackexchange.com/questions/286077/implies-vs-entails-vs-provable
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.”
• In Jackson’s terminology, the computerbased 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 e.g. 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)
• The description of requirements 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[1].
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 can 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
31
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
a logical calculus).
• Entailment is often called provability.
The meaning of requirements
(Michael Jackson)
• Logical entailment (|-) between formulas in
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 of logic : “all that can be proved,
is true“
• Completeness of logic: “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
pq
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
35
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
• would itself be a further assertion about the
environment, in addition to the assertion E.
• Check the difference between
• The relationship E, S |- R 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
• 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
47
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
48
Requirements
49
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
50
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
51
What is Modelling?
• Many definitions!
• A model is anything
that is used as a
replacement for ‘the
real thing’ for some
purposes
– map
– information system
– family tree
Requirements
52
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
53
So what is a…
• System model?
• Working model?
• Software system?
• System design?
• Mathematical model?
• Simple/complex system?
• Good/poor model?
Requirements
54
...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
55
The Modeling Relation
observable
event
entail
through
causal
behaviour
translate
commute
symbolic
expression
derive
using
rules of
reasoning
translate
world
model
Requirements
56
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
57
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
58
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
59
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
60
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
61
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
62
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
63
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
64
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
65
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
66
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
67
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
68
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
69
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
70
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
71
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
72
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
73
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
74
Ground Terms
• Ground terms for a description are the
terms that 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.
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 for mother as:
Definition
• A formal definition defines new terms
on the basis of terms previously
designated or previously formally
defined. There is a difference
between designation and definition.
Suppose that for an inventory
system we have designated an event
class:
Definition
• A formal definition defines new terms
on the basis of terms previously
designated or previously formally
defined. There is a difference between
designation and definition. Suppose
that for an inventory system we have
designated an event class:
Definition
• ExpectedWidgetStock(t,s) is defined to
mean that s is the cumulative sum of (positive
and negative) movement quantities m, the sum
being taken over all possible choices of tm, e,
and m for which WidgetMvmt(tm,e,m) is true and
tm<t. That is, s is the sum of the movement
quantities in all WidgetMvmt events occurring
before t.
We need another designation
• Now suppose that we want to know: How
many widgets do we actually have in stock?
We need to designate an independently
observable phenomenon, recognisable as
the presence of s widgets in the warehouse
at time t phenomenon:
There exists Ö, For all
• We can now assert that the actual
stock of widgets changes only by
stock movement events; there is no
theft or evaporation, and no
spontaneous creation of widgets:
Air Trip
• We can define an Air Trip which defines the
individual i and the four predicates; Trip,
TripPlane, StartsTrip and FinishesTrip, in
which i may appear as an argument. There is a
defined individual i for each distinct choice of p,
e, f, t1 and t2 such that Plane(p) and
TakeOff(e,p,t1) and Land(f,p,t2) are all
true, and t1 is earlier than t2, and no Land event
of the same plane intervenes between e and f.
Air Trip
• The values of the identifier i for which Trip(i)
is true by this definition do not denote
independently observable individuals in the
environment. They can not, therefore, appear as
arguments in designated terms. But they can be
used both in descriptions and in further
definitions. For example:
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
84