Requirements

1
Requirements
2
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.

3
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.

4
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.

5
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.

6
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?

7
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.

8
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.

9
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.

10
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.

11
Analysing the statement of requirements

• Types of questions
• Scoping questions
• Questions about input data
• Questions about output data
• Questions about behaviour

12
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.
  

13
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.

14
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?
  

15
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.

16
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.
  

17
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

18
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.

19
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.

20
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
  non-behavioural 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.

21
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.

22
Review

• The business of removing ambiguities, eliminating
  design and implementation directives, for
  example, needs to be carried out whatever
  software development method is employed.

23
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)

24
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.

25
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.

26
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
  
• Jacksons 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.

27
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.

28
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.

29
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.

30
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.

31
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.

32
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.

33
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.

34
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.

35
The meaning of requirements (Michael Jackson)
36
The meaning of requirements (Michael Jackson)
37
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.

38
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.

39
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.

40
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,
  grand-daughter, 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.

41
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

42
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.

43
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

44
Deduction
45
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.

46
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"

47
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
  sub-proof. 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.

48
Logical implication Logical equivalence

• Two propositions are said to be logically
  equivalent if their truth tables are identical.
  
• Example p ? q is logically equivalent to p ? q

49
Logic Example

• All humans are mortal
• Socrates is a human
• From these premises, we prove
• Socrates is mortal

50
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.

51
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,

52
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.

53
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 customers requirement. This is
  why it has traditionally represented the
  intermediate product between requirements and
  programs.
• Requirements - Specification - Program.

54
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.

55
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.

56
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.

57
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.

58
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.

59
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.

60
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?

61
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.

62
Walk through Admit Patient

• Locate the instance, aWard, of Ward with the ward
  name wName linked to hat via wards. (UI)
  
• Locate the instance, aTeam, of Team with the team
  code tCode linked to hat via teams. (UI)
  
• Check that aWard is not linked via hasOn to any
  instance of Patient with name pName.
  
• Create an instance, aPatient, of Patient with
  name pName, address anAddress and dob aDOB.
  
• Create a hasOn link between aWard and aPatient.
• Create a treats (or caresFor) link between aTeam
  and aPatient.

63
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 customers
  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.

64
(No Transcript)
65
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

66
System??

• A system is any complex collection which has a
  significant purpose as a whole thing
  
• the tube
• a person
• payroll
• set of equations

67
So what is a

• System model?
• Working model?
• Software system?
• System design?
• Mathematical model?
• Simple/complex system?
• Good/poor model?

68
...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

69
The Modeling Relation
observable event
symbolic expression
translate
derive using rules of reasoning
entail through causal behaviour
commute
translate
model
world
70
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

71
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

72
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.

73
Requirements EngineeringCriteria
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.
74
Requirements EngineeringCriteria
(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 customers 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.
75
Requirements EngineeringCriteria
(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.
76
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)
77
Jacksons 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.
78
Jacksons 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.
79
Jacksons 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.
80
Jacksons Frames
For example, decomposition has traditionally
stood as if they were self-sufficient. "Having
divided to conquer, we must re-unite 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.
81
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.
82
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.
83
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

84
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.

85
Inadequacies in Functional Requirement (Summary)

• Behavioural and non-behavioural requirements are
  intermingled.
  
• The statement of requirements contains
  ambiguities, both constraints and
  non-functional.
  
• 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.

86
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.

87
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.

88
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.