Thinking about Requirements Engineering some basic principles Karl

Thinking about Requirements Engineering: some basic principles Karl Cox Empirical Software Engineering National ICT Australia and Computer Science and Engineering UNSW

Outline • What is Requirements Engineering? • Some issues with typical analysis • Basic principles of Requirements Engineering • Summary • References

What is Requirements Engineering? • • Definitions Track record What Requirements Engineering really is Phenomena

Some Requirements Definitions • ZAVE (1997) – “Requirements engineering… is concerned with the real-world goals for functions of and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour…” • SWEBOK (2001) – “A requirement is defined as a property that must be exhibited in order solve some problem of the real world. ” • Robin Goldsmith (2004) – “What must be delivered to provide value. ”

Software Project Track Record • Chaos reports: 75% of projects failed or failed to deliver key functions. – Why? Poor / no requirements engineering. • 2004 Job. Serve report: only 16% of UK software projects are successful. – Why? Poor / no analysis skills. – “Projects are often poorly defined, codes of practice are frequently ignored and there is a woeful inability to learn from past experience, " says Professor John Mc. Dermid

What Requirements Engineering really is • ZAVE (1997) – “Requirements engineering… is concerned with the real-world goals for functions of and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour…” • SWEBOK (2001) – “A requirement is defined as a property that must be exhibited in order solve some problem of the real world. ” • Robin Goldsmith (2004) – “What must be delivered to provide value. ”

Where (Not what and how) The Computer and Program The solution is here The World outside the Computer Connections between the world and the computer The problem is here

Phenomena Real World phenomena Application Domain Specification phenomena Interface Solution phenomena Machine

Some issues with typical analysis • • • Formal methods Context Diagrams Object-oriented analysis Use case analysis Non-functional requirements

Insanity • “We receive the results we create. As an industry, we keep doing the same things and expecting a different result. That’s the definition of insanity. ” • Robin F. Goldsmith, Discovering the REAL Business Requirements for Software Project Success, Artech House Books, 2004

Formal Methods … and Ambiguity Shoes Must Be Worn x (On. Escalator(x) y (Pair. Of. Shoes(y) Is. Wearing (x, y)) For each individual x that is on the escalator, there is at least one y such that y is a pair of shoes and x is wearing y.

Formal Methods … and Ambiguity Dogs Must Be Carried x ((On. Escalator(x) Is. Dog(x)) Is. Carried(x)) For each individual x that is on the escalator and is a dog, that individual is being carried.

One more for fun Thoroughfare Only: Passengers Must Not Travel Between the Doors I wouldn’t want to begin to describe this formally!

Precisely • “There’s no point being precise about something when you don’t know what it is you are talking about” - John von Neumann. • Formalism is useful only when you are confident it represents the real world precisely AND that it is necessary at all. • And unfortunately this is what the formal methods and mathematics advocates typically DON’T DO. They forget about the informal real world because it is too ambiguous. • Formal methods / mathematics can only be the handmaiden of software engineering, not the Queen.

Context Diagrams 1 Customers Warehouse Orders Acknowledgements Shipping Info Order Processing Accounting Info Accounts Dept. “The Context Diagram documents the domain of study by showing the set of data flows that cross into and out of the domain. ” - Tom De. Marco, Structured Analysis and System Specification, 1978.

Context Diagrams 2 • De. Marco’s ‘domain of study’ is the system. • “Boxes (representing sources and sinks) are used rather sparingly in Data Flow Diagrams, and usually not in a very rigorous fashion. Since they represent something outside the area of our major concern, they exist only to provide commentary about the system’s connection to the outside world. ” - De. Marco. • In this kind of Structured Analysis, the Context Diagram shows the context of the system, not the context of the problem.

Context Diagrams 3 • We should be interested in more than the context of the system. A requirement resides in the problem domain, or Application Domain. • If we want to know anything about our requirements we must know something about our problem context. • We should be showing all the domains relevant to our problem and the connections between domains as well as the MACHINE (general purpose computer which we program to meet our requirements).

Context Diagrams 4 Analog devices e ICU Patients d Machine b Medical Staff c Nurse’s Station a Periods & Ranges

Context Diagrams 4 Analog devices e ICU Patients d Machine b Medical Staff c Nurse’s Station a Periods & Ranges a: Period, Range, Patient. Name, Factor b: Enter. Period, Enter. Range, Enter Patient. Name, Enter. Factor c: Notify d: Register. Value e: Factor. Evidence

Remember Phenomena Real World phenomena Application Domain Specification phenomena Interface Solution phenomena Machine

Object-Oriented Analysis • Seamless Development – Object-oriented programming promised the idea of encapsulation and this presented a way to represent things in the real world. – A software object could be represented as a design object which was a representation of an analysis object. – The assumption was that to represent the real world as an object was simple.

Object-Oriented Analysis 2 • Data-driven and process-focussed in one • Objects are considered superior to entities in an ERD and processes in a DFD as they capture both in one diagrammatic element. • Most of UML’s class modelling is really entity-relationship modelling.

Object-Oriented Analysis 3 • “Object-oriented designers do not usually spend their time in academic discussions on methods to find objects; in the physical or abstract reality being modelled, the objects are just there for the picking! The software objects will simply reflect these external realities. ” – Bertrand Meyer, Object-Oriented Software Construction, 1988. • Perhaps this is a little over the top. The idea of an object comes from programming and doesn’t fit very well with individuals in the real world. • Individuals such as aeroplanes, tax returns and paychecks are certainly potential objects in an OOA but it isn’t an exact mapping. – When did you last send a message to a paycheck? – What reply would you get back if you sent a message to an aeroplane? – What methods does a tax return perform in response to messages it receives?

Object-Oriented Analysis 4 • When the sun rises, does it send a message to each bird to tell it to start singing? • Clearly this is nonsensical. • To read up on what object-oriented can really do for software engineering take a look at: – Steve Cook and John Daniels, Designing Object Systems, 1994

3 Restrictions on OOA - 1 • Each object belongs to a fixed class, determined when the object is created. • But the world is not like this: – – – pupils become teachers Bills become laws Partnerships become corporations Doctors become lawyers Cotton mills become offices or hotels Caterpillars become butterflies

3 Restrictions on OOA - 2 • Each object inherits properties and behaviour from just one class at the next level up in the tree. That’s single inheritance. • But the world is not like this: – The logistics manager wants to classify the company equipment as production plant, office equipment and distribution vehicles. – The finance director classified it as owned, rented and leased. – The two classifications can’t coexist in the same singleinheritance hierarchy.

3 Restrictions on OOA - 3 • Objects are reactive rather than active. If you don’t send a message to an object, it won’t do anything. • But the world is full of individuals, like – – People Vessels in chemical plants Government departments who all do things spontaneously. • All these restrictions have programming solutions - but they are no good at representing the richness of the world.

Use Cases • UML tells us that the way to do requirements engineering is to capture the functions that users want when they use the computer. • It’s the first question we ask our customers, “What functionality do you want? ” – This way madness lies.

Here’s a Use Case example Borrow a book Return a book Library Member Renew a loan

Here’s the Use Case problem The Library Member’s requirements: borrow a book, return a book, renew a loan Issue a book Process a book return Library Member Librarian The Librarian has to: issue a book, process a book return, and issue a book renewal. The Library Member’s requirements aren’t quite the same as the Librarian’s tasks. Issue a book renew

Use Case problems • So what happens when a librarian’s job is to loan books out and collect returns? • What happens to the Library Member when we cannot show actors one step removed from the machine? – Do we just forget about them or fudge them? – But isn’t a library’s purpose to provide books and services to its library members? – And if we ignore this fact, what are we essentially doing? – We’re ignoring the problem context, and – We’re ignoring the requirement. – And that’s bad.

Non-functional Requirements • “Not pertaining to the function (that is, observable behaviour) of the machine, or to the resulting observable effects in the problem domain. ” • Some examples in this style, – – The Ada programming language must be used; The software must be delivered by 31 July; The computer must be fully ruggedised; All software modules must be tested at least up to branch coverage; – The software must be readily modifiable.

More non-functional requirements • Non-functional requirements, by their very name, convey less importance than functional requirements. • Accept this at your peril. • An example: • “The staff meeting minutes must be distributed to staff… • within an hour of closing of the meeting. ”

“Non-functional” examples • These were considered non-functional for an office lighting control system: – The control panels should be easy and intuitive to use; – No hazardous conditions for persons, equipments or the building are allowed; – The system issues warnings on unreasonable inputs at its control panels; – In any case of failure the system shall provide a stepwise degradation of functionality down to manual operability; – If the outdoor sensor does not work correctly, the control system for room lighting should behave as if the sensor were continuing to show the last correct measurement of outdoor light before the failure.

Non-functional really means… • • You haven’t understood the problem in detail, so You haven’t understood the requirement, meaning You need to re-examine the problem in order to Identify the real requirement. • To separate function from non-function is amateurism and over-complicates because • it’s also hard to trace between both in documentation, that’s why most documents don’t even try, • …and that’s where things can start to go wrong.

Insanity, revisited • “We receive the results we create. As an industry, we keep doing the same things and expecting a different result. That’s the definition of insanity. ” • Robin F. Goldsmith, Discovering the REAL Business Requirements for Software Project Success, Artech House Books, 2004 • Sticking to the typical ways will drive us all insane. The answer’s not in the machine but in the world. • Would you use a hammer to paint a portrait? That’s what it will feel like if you follow the latest panacea and don’t question what you’re doing and why.

Basic Principles of Requirements Engineering • • • Jackson’s principles Thinking outside the box “Why isn’t important” “It’s not a requirement if it isn’t implemented” The Three Descriptions

Jackson’s Principles 1* • The Principle of Dispassionate Methodology – Don’t get your method advice from a method enthusiast. The best advice comes from people who care more about your problem than about their solution. – *These principles are taken from Michael Jackson’s, Software Requirements and Specifications, 1995.

Jackson’s Principles 2 • The Principle of Beneficent Difficulty – A method without limitations, whose development steps are never impossible to complete, whose stages diagnose and recognise no difficulty, must be very bad indeed. • The Principle of Separation of Concerns – Never mix intention and problem context in the same description.

Jackson’s Principles 3 • The Principle of Close-Fitting Requirements Methods – Close fitting requirements methods allow a good tight grip on the problem. • The Principle of Exploiting the Appropriate Methodology – A method should exploit the stipulated characteristics of the principle parts of its problem. • The Principle of Problem Sensitivity – A method for solving problems must be closely expressed in terms of the problems it can help you solve. • If the method doesn’t talk about a problem, how can it help you solve it?

Jackson’s Principles 4 • The Principle of Deferred Invention – Invention should be delayed until description of what is already given has been completed. • The Principle of Commensurate Care – The care taken in each aspect of a development should be proportional to Px. D, where P is the probability that it will go wrong and D is the size of the disaster if it does. • The Principle of Domain Relevance – Everything that’s relevant to the requirements must appear in some part of the application domain. – The application domain is NOT limited to the parts of it that are directly in contact with the machine.

Thinking outside the box • Fred: “I couldn’t find a good definition on Return On Investment. ” • Steve: “Really? Where did you look? ” • Fred: “In the software engineering literature. ” • Steve: “Why didn’t you look in a simple Finance book or Accounting book? ” • Fred: “I’m an engineer, I only read engineering journals and books. ” • Steve: “We’ll call you about the project contract when we know more. Thanks, Fred. ”

The “Why” isn’t important • Fred: “Why isn’t important, it’s just a Post-it Note on a class diagram. ” • Why did Fred say this? Well, Jane, his customer, had asked, • “Could you explain why you’ve modelled these two classes - what are they representations of in my problem? ” • Fred looked bemused and moved on to his next point. Obviously Jane didn’t know about software. Jane stopped listening and wondered how much more time she’d be wasting today. • The classes were part of design and had nothing to do with identifying the problem. • Fred’s a UML enthusiast.

It’s Not a Requirement! • “It’s not a requirement if it isn’t implemented. ” • What does this really mean? • When is a requirement not a requirement? • WHEN YOUR CUSTOMER DOESN’T WANT IT ANYMORE • If you don’t happen to implement it, or can’t implement it yet, but your customer WANTS it, it is still a requirement. • And that means it needs recognition now, • and that means documenting it in your requirements documentation now.

The 3 Descriptions • 1. The Problem Context – What’s in the problem domain? What’s the boundary, or the scope, of the problem domain? • 2. The Requirements – What are the effects we want to machine to bring about in the problem domain? • 3. The Specification – How do we describe the external behaviour of the machine to enforce the requirements that will bring about the desired effects in the problem domain? • Don’t mix these up. If you do, you won’t be sure if your talking about context, requirement or specification. • If you’re not sure, you’ll get the software wrong.

Summary • The problem is in the world. • The requirement is needed in the world. • The machine is not the requirement, nor the problem. • The specification isn’t the requirement. • Question your methods. • Question everything about your software problem. • The generality of a method is inversely proportional to its utility. • Asking “why? ” is good.

Some Useful References • Michael Jackson, Software Requirements and Specifications, Addison-Wesley, 1995. – A seminal work. An entertaining, insightful book. Problem frames were presented to world for the first time. A classic. Most of this presentation is inspired by or taken from this work. • Michael Jackson, Problem Frames, Addison-Wesley, 2001. – Yet another seminal work. This book focusses entirely on understanding and describing problems in much more detail than his 1995 work. This book tends to frighten (some) academics. A classic. • Ben Kovitz, Practical Software Requirements, Manning Publications, 1999. – Described as idiosyncratic by an academic, described as delightful by a practitioner. Who are you going to believe? An excellent introduction to problem frames but can be hard going elsewhere. • Ian Bray, An Introduction to Requirements Engineering, Addison-Wesley, 2002. – Was going to be called a “duffer’s guide” but Ian soon realised that duffers are no good at requirements! An excellent introduction to a whole range of techniques and tools, with a focus on problem frames.

Some more useful references • Don Gause and Gerry Weinberg, Exploring Requirements, Dorset House, 1989. – One of the very first books on requirements elicitation and still just about the best. An entertaining, seminal classic. • Don Gause and Gerry Weinberg, Are Your Lights On? Dorset House, 1990. – Yet another classic, more generally focussed than the 1989 book. More cartoons in this book! • Alan Davis, Just Enough Requirements Management, Dorset House, 2004 – Hot off the press, Al Davis talks about what is really needed in practice and discusses the critical idea of requirements triage further. • Bashar Nuseibeh and Steve Easterbrook, “RE: The Roadmap”, Int. Conf. on Software Engineering, 2000 – A paper! This set out the future research directions of RE and provides an excellent introduction to the subject. A classic of its own.