Requirements

1. Requirements 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” • 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.

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

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 Requirements

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 Requirements

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.