On Business Requirements
Slides from a talk I gave to colleagues at Franmax on 20 December 2018. It started with a deceptively simple question: what exactly does „gathering business requirements“ mean? We use the term daily, yet when asked to say where a requirement ends and a solution begins, we start to mumble. The answer I went looking for is in Michael Jackson’s problem frames.
The slides are as they were in 2018 and are not edited. What is printed under them is for the reader: what was said out loud where the slide does not say it, an explanation where the slide alone does not carry, and, where a slide cites a source, a link to the work. The note under the last slide gathers every source.
Today I want to present my research into business requirements and my thoughts on the subject.
The topic became live for me on the AMM project. Most of what a business analyst produces these days is user stories, but business requirements are still needed a) to set the direction and b) to define and communicate the scope of a project or a piece of work.
Preparing business requirements on a project is fairly new ground for me. Over the last ten years working as a business analyst I mostly received them already written and produced specifications for the developers on top of them. At my previous employer we ran an internal project to improve how we run projects, including how business requirements are prepared to a client's order. I went some way into goal-oriented requirements engineering and built a DSL (domain-specific language) notation in UML — in plain words, a notation for drawing goal models. About two months full time in all.
That was enough to start finding my way around the topic, but not enough to describe a method for writing business requirements without digging further.
So I did a small study, thought the material over, and came up — I think — with a fairly workable core idea for how business requirements can be formulated and written down. The work is far from finished. One of the aims of this talk is to get feedback on whether the direction looks promising.
The importance of requirements was understood long ago and has not gone away.
Boehm said in 1981 that a late correction can cost up to 200 times more. Boehm is the author of the Constructive Cost Model (COCOMO) estimation method; the term man-month comes from Brooks, from his 1975 book The Mythical Man-Month.
Barry Boehm's 1981 book Software Engineering Economics documents his Constructive Cost Model (COCOMO). It relates software development effort for a program, in Person-Months (PM), to Thousand Source Lines of Code (KSLOC).
Brooks, 1987 — the hardest, most important function of software engineering is the iterative extraction and refinement of requirements. Brooks led the development of System/360 and OS/360 at IBM and is an eminent figure in the field generally.
In 1996 a European Software Institute survey found that requirements specification is the main software problem — more than 50 per cent of respondents.
Sources: [1] van Lamsweerde, Goal-Oriented Requirements Engineering: From System Objectives to UML Models to Precise Software Specifications, ICSE 2003; the Brooks paper quoted there is No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987.
Measuring the Impact of Changing Requirements on Software Project Cost.
The business analyst is on the front line when business requirements are formulated.
Requirements engineering is an area of software engineering in its own right, a subdiscipline.
Source: [3] Nuseibeh & Easterbrook, Requirements Engineering: A Roadmap, ICSE 2000, pp. 35–46.
Discover — understand the purpose
Identify the needs
Document
Analyse
Communicate
Manage — my own addition
So: formulating requirements is a serious challenge, and people are trying to solve it.
Source: [4] Zhi Li, Progressing Problems from Requirements to Specifications in Problem Frames, PhD thesis, The Open University. The figure is taken there, unmodified, from the Robertsons' Volere requirements specification template.
Source: A KAOS Tutorial, Respect-IT, 2007.
Source: [6] Espada, Goulão & Araújo, Measuring Complexity and Completeness of KAOS Goal Models, CITI, Universidade Nova de Lisboa.
Source: [5] van Lamsweerde, Goal-Oriented Requirements Engineering, University of Louvain, 2003, quoting Jackson (1995) and Parnas (1995).
The question at the top of the slide is what the whole analogy turns on. In software the machine is obvious — it is the program we are writing. In business it is not: if the requirement speaks about a process, what is the machine that controls that process and whose specification we write?
On the left, an answer by example. The "Bad Coffee" fishbone here is not cause analysis, although that is exactly what it is normally used for. Here it is a list of levers: if you want the coffee-making process to behave differently, there are only four things you can act on — people, procedures, material and equipment. So the machine of a process is not one thing, it is that foursome.
On the right there is no answer, and that is deliberate. For Maxima's processes the machine still had to be identified, and it will be a different one for each process. In the promo compensation process the earlier slides talk about, it turned out to be SAP together with the procedure for registering the agreements: the specification "all calculations of promo compensations done in SAP" is a description of exactly that machine.
Every source cited on the slides, in one place.
[3] Nuseibeh & Easterbrook, Requirements Engineering: A Roadmap, ICSE 2000, pp. 35–46.
[7] Jackson, A Tutorial on Software Development Problem Frames, 2006.
A KAOS Tutorial, Respect-IT, 2007.
Robertson & Robertson, Volere requirements specification template.
Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987.