requirements l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Requirements PowerPoint Presentation
Download Presentation
Requirements

Loading in 2 Seconds...

play fullscreen
1 / 88

Requirements - PowerPoint PPT Presentation


  • 209 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Requirements' - Antony


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
requirements

Requirements

Requirements

requirements first ideas
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
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 requirements4
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 requirements5
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 requirements6
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 requirements7
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 requirements8
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 requirements9
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
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 requirements11
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 requirements12
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 requirements13
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 requirements14
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 requirements15
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
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 requirements17
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 requirements18
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
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
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.
review21
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.
review22
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 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 jackson24
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 jackson25
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 jackson26
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 requirementR 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 jackson27
The meaning of requirements (Michael Jackson)
  • A specificationS is an optative description of a condition over the shared phenomena at the interface between the machine and the environment.
  • A machine satisfyingS 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 jackson28
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 jackson29
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 jackson30
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 jackson31
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 jackson32
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 jackson33
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 jackson34
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 jackson37
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 jackson38
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 jackson39
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 jackson40
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.
the meaning of requirements michael jackson41
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 jackson42
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 jackson43
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
Deduction

Requirements

the meaning of requirements michael jackson45
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 jackson46
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 jackson47
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.
logical implication logical equivalence
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

Requirements

logic example
Logic Example
  • All humans are mortal
  • Socrates is a human
  • From these premises, we prove
  • Socrates is mortal
the meaning of requirements michael jackson50
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 jackson51
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 jackson52
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 jackson53
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 jackson54
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 designationsand the distinguishes between definitionand assertion.
the meaning of requirements michael jackson55
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.
the meaning of requirements michael jackson56
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.
the meaning of requirements michael jackson57
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.
the meaning of requirements michael jackson58
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.
the meaning of requirements michael jackson59
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.
walk through admit patient
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

walk through admit patient61
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

walk through admit patient62
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.

Requirements

requirements are complete if
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

what is modelling
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

system
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

so what is a
So what is a…
  • System model?
  • Working model?
  • Software system?
  • System design?
  • Mathematical model?
  • Simple/complex system?
  • Good/poor model?

Requirements

and an abstraction
...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

the modeling relation
The Modeling Relation

observable

event

symbolic

expression

translate

derive

using

rules of

reasoning

entail

through

causal

behaviour

commute

translate

world

model

Requirements

what is logic
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

some familiar models
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

valid or correct models
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

requirements engineering criteria
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.

Requirements

requirements engineering criteria74
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 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

requirements engineering criteria75
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.

Requirements

what is a uml model
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

jackson s frames
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

jackson s frames78
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; andthe 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

jackson s frames79
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

jackson s frames80
Jackson’s 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.

Requirements

safety property
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

liveness property
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

requirement summary
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

functional requirement summary
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

inadequacies in functional requirement summary
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.

Requirements

reducing inadequacies in functional requirement summary
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

reducing inadequacies in functional requirement summary87
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

reducing inadequacies in functional requirement summary88
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