requirements1. requirements: first ideas requirements should state what a system will do but not how...

Requirements 1

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.• In order to gain an insight into the nature of

requirements we need to look beyond such high level statements.

• Requirements are concerned solely with phenomena in the world (or environment).

• Specifications are concerned solely with the shared phenomena between the world and the machine.

Analysing the statement of requirements

• The customer produces a statement of requirement. The developer performs a process known as requirements analysis. Once the software developer fully understands what the customer wants, a precise specification for the software is written. This specification is known as the negotiated statement of requirements and represents an agreement between the customer and the software developer about what the software will do.


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


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


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


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


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


• Difficulties with statement of requirement. • Design and implementation directives are

included.• There will be omissions from the statement of

requirements.• Behaviour is described at different levels of

detail.• The behavioural specification should be

unambiguous.

Difficulties with statement of requirement. • The behavioural specification should be free of

design and implementation directives.• The behavioural specification should be in a

form that enables the developer to reason about the properties of the system it describes.

• The behavioural specification should be free of extraneous detail.

• The behavioural specification should be partitioned.

• The behavioural specification should be understandable by the customer.


• Types of questions:

– Scoping questions

– Questions about input data

– Questions about output data

– Questions about behaviour


Scoping questions

– These are questions which attempt to delineate what facilities should be in a system and what facilities should not be included.


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


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


• Questions about behaviour

• An important category of questions concerns what the system should do. These questions will range from very broad questions to very detailed ones. Normally the requirements document provided by a customer will be deficient in two ways: first, it will not contain descriptions of everything the customer requires of a system and, second, details of functions will be very vague.

Some requirements

– The system should provide a facility which allows clerical staff to input patients’ details.

– The system should report on bed occupancy in wards.

– The system should monitor the state of the reactors in our chemical plants.

– The system should provide a report which details the malfunctioning reactors in our chemical plant.

– We would like a computer program which keeps track of the bookings that the passengers of our airline have made in the past.

– The computer program should be able to tell me which passengers are the most valued.

– Our hotel booking system should process guest details.

– The program which administers our surgery should keep track of the prescriptions that we issue.

Some requirements

– The system must be completed by 1st January 2007.

– The system specification must be formally accepted by the steering committee.

– The system must produce a monthly report of admissions.

– If the system cannot allocate the requested bed then the system will search for an alternative

Some requirements

– The programs must be written in C#.

– The development process should be managed using the Unified Process.

– The system should be user friendly.

– The system must produce a monthly report of completed treatments.

The inevitable intertwining of categories of questions

• An important point to notice about the previous questions is that, although we have tried to present them in a number of categories, in real life things are never so simple: a question will often involve any combination of concerns concerning detailed system functions, input data, output data and scoping. For example, some of the questions in the previous section involved both aspects of a system which were function-related and aspects which were data-related. In posing questions you should not be too worried by the fact that a question does not fit neatly into one of the four categories above.

Review• The development of a piece of software cannot

start until a requirements specification is provided by a customer.

• This specification is usually inadequate for several reasons:

• the specification will contain behavioural and 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.

Review• The software developer and the customer

develop a negotiated set of requirements that is a better description of what the software will do.

• In a simplified view of the process, the negotiated statement of requirements is achieved by the software developer asking questions of the customer about the requirements specification to elicit more information about the proposed system.

Review• The business of removing ambiguities, eliminating

design and implementation directives, for example, needs to be carried out whatever software development method is employed.

The meaning of requirements (Michael Jackson)

The whole business of software development is making descriptions. – A requirement is a description of an application domain

and the problems to be solved.

– Specifications are descriptions the interface between the machine and the application domain.

– Programs are descriptions of machines

• Language is the raw material of description.

• Two types of domain– the generic domain (WAP, GIS, Accountancy).

– the application specific domain (e.g. hospital system)


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


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


• Simple definition is not very helpful.

– “Requirements say what the system will do and not how it will do it”

• Jackson’s description: A customer requirement R expresses a condition over the phenomena of the environment that we wish to make true by installing the machine. A requirement is an optative property, intended to express the desires of the customer concerning the software development project.

• Requirements are refined to specifications by using domain knowledge.


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


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


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


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


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


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


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


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


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


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


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


• 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“

Requirements 44

Deduction


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


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

Requirements 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

p q ~p q p q

T T T T

T F F F

F T T T

F F T T

Logic Example

• All humans are mortal

• Socrates is a human

• From these premises, we prove

• Socrates is mortal


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


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


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


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


• 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


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


child(x,y) child(x,y) :- mother(y,x)


• 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




• The designation adds significantly to our capacity to describe the environment we can make assertions that can not be made without them.





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




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

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

Requirements 62

Walk through Admit Patient1. 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 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 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 64

Requirements 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

Requirements 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

Requirements 67

So what is a…• System model?

• Working model?

• Software system?

• System design?

• Mathematical model?

• Simple/complex system?

• Good/poor model?

Requirements 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

Requirements 69

The Modeling Relation

observableevent

symbolicexpressiontranslate

modelworldtranslate

deriveusing

rules ofreasoning

entailthroughcausal

behaviour

commute

Requirements 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

Requirements 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

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

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

Requirements 74


(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 75


(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 thatS, 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 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)

Requirements 77

Jackson’s FramesJackson 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 78

Jackson’s FramesHe 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 79

Jackson’s FramesThe 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 80

Jackson’s FramesFor 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 81

safety propertyA 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 82

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

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

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

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

Requirements 87


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


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

requirements1. requirements: first ideas requirements should state what a system will do but not how...

Documents

statement of requirementsif

statement of requirementsgiven

statement of requirementsfirst

nature of requirements

task of requirements

nonbehavioural requirements

software developer

software project