By Year:


Requirements Quarterly

An Aladdin's Cave of articles and reviews:

Issue 58 (pdf) | March 2012
Issue 57 (pdf) | September 2011
Issue 56 (pdf) | May 2011
Issue 55 (pdf) | September 2010
Issue 54 (pdf) | April 2010
Issue 53 (pdf) | January 2010
Issue 52 (pdf) | October 2009
Issue 51 (pdf) | April 2009
Issue 50 (pdf) | January 2009
Issue 49 (pdf) | October 2008
Issue 48 (pdf) | June 2008
Issue 47 (pdf) | March 2008
Issue 46 (pdf) | December 2007
Issue 45 (pdf) | September 2007
Issue 44 (pdf) | June 2007
Issue 43 (pdf) | March 2007
Issue 42 (pdf) | December 2006
Issue 41 (pdf) | September 2006
Issue 40 (pdf) | June 2006
Issue 39 (pdf) | March 2006
Issue 38 (pdf) | December 2005
Issue 37 (pdf) | September 2005
Issue 36 (pdf) | June 2005
Issue 35 (pdf) | March 2005
Issue 34 (pdf) | December 2004
Issue 33 (pdf) | September 2004
Issue 32 (pdf) | June 2004
Issue 31 (pdf) | March 2004
Issue 30 (pdf) | December 2003
Issue 29 (pdf) | August 2003
Issue 28 (pdf) | February 2003
Issue 27 (pdf) | November 2002
Issue 26 (pdf) | May 2002
Issue 25 (pdf) | January 2002
Issue 24 (pdf) | July 2001
Issue 23 (pdf) | March 2001
Issue 22 (pdf) | October 2000
Issue 21 (pdf) | July 2000
Issue 20 (pdf) | March 2000
Issue 19 (pdf) | December 1999
Issue 18 (pdf) | August 1999
Issue 17 (pdf) | June 1999
Issue 16 (pdf) | February 1999
Issue 15 (pdf) | October 1998
Issue 14 (pdf) | April 1998
Issue 13 (pdf) | January 1998
Issue 12 (pdf) | October 1997
Issue 11 (pdf) | July 1997
Issue 10 (pdf) | April 1997
Issue 09 (pdf) | January 1997
Issue 08 (pdf) | October 1996
Issue 07 (pdf) | July 1996
Issue 06 (pdf) | April 1996
Issue 05 (pdf) | January 1996
Issue 04 (pdf) | October 1995
Issue 03 (pdf) | April 1995
Issue 02 (pdf) | January 1995
Issue 01 (pdf) | October 1994

Featured Articles

RESG/BCS Nottingham & Derby – Joint Requirements Engineering Event – Review
Tom James

Back in May, the Nottingham and Derby Branch of the BCS invited Alistair Mavin as the guest speaker at their regular monthly branch meeting. The presentation was a huge success and attracted a significant amount of interest for future requirements engineering focussed talks. Sparked by the strong appetite from the Nottingham and Derby members for more events, Alistair and Tom James, Nottingham and Derby Branch Chairman, set to work to organise the first requirements engineering event.

Having issued a survey to all branch members as well RESG members, it was evident that strong interest existed across a vast range of requirements engineering topics as well as delivery styles.

After much planning, The Easy Approach to Requirements Syntax (EARS) was agreed as being the topic that would be covered at the first event and would be delivered as a presentation. EARS is the requirements framework that has been adopted by Rolls Royce and was conceived and developed by Alistair.

The response to the event was exceptional. In excess of 35 people turned out to Novotel East Midlands, with one attendee flying 284 miles from Glasgow, prepared to be enlightened as to the great benefits that anyone passionate about crafting high quality can gain with EARS.

The room was buzzing throughout the talk with Alistair keeping the room alive with an invigorating practical insight into the structure of the EARS notation, even successfully fending off the odd heckle from a jesting member of the audience!

The room was captivated throughout which was evident from the questions that were asked in-flight as Alistair was speaking. Peoples’ questions were targeted at helping them to adapt the aviation based examples which Alistair used to demonstrate the EARS concepts, to identify where EARS would fit into their own work. Often, the answer was not completely clear cut, which resulted in some healthy discussion amongst the audience as to how EARS could be applied to certain requirements based problems. It was uplifting from the discussion to see that people were passionate about taking the pertinent points away to make a positive difference to improving the quality of their own requirements.

The evening ended with a complimentary bar which was hosted by the Nottingham and Derby Branch of the BCS. It was great to see so many retire to the comfort of the hotel lounge to continue the lively discussion. Members networked with fellow IT professionals, sharing experiences and exchanging contact details.

A follow up survey was issued to all attendees of the event which pictured the evening as a resounding success with 100% indicating that their expectations of the event had either been met or exceeded. One participant commented “Wasn’t sure what to expect but presentation was excellent.”

Members were also unanimous in their interest for a future requirements engineering based event, indicating what can only be described as a triumphant first joint event between RESG and BCS Nottingham and Derby. Plans are already in motion for the next event, with more details to be announced.

Tom James

Alistair Mavin’s papers about EARS are available in Open Access from here.

Systems and Conflicts
Fernando Muradas (Brazilian Navy / Oxford University)

Figure 1 – Classification of Group tasks (McGrath, 1983)

There is a consensus that around 70% of all problems related to system development are consequences of inadequate requirements elicitation. Thus, an improvement on requirements elicitation is mandatory to any software development process improvement initiative.

When we observe the requirements area in a detailed manner, it is possible to notice that it depends directly on group activities such as requirements elicitation and validation, as there are many people from the client and development organisations involved. Any group task relies on several factors. Among these factors there are: interpersonal relationships, intergroup relationships, social and psychological factors, relationships between the group and the tasks to be performed, and finally the group and tasks’ relationships with the environment.

Read more »

RE: An Alternative Perspective on Microfinance
Camilo Fitzgerald, August 2012

Community Based Saving Bank in Cambodia

Recently I had a chat with the CEO of a microfinance institute in Nicaragua. We exchanged thoughts on the problems faced in microfinance and the types of solutions that requirements engineering can provide. I was very happy when the conversation culminated in a job offer in a research position for when I finish my doctoral thesis, which I gladly accepted. So, what exactly can RE do for microfinance?

Microfinance is a movement aimed at providing financial services to those in developing countries who would not otherwise receive them. Management of loans and other financial services has a cost that remains constant regardless of the amount of money involved. There is therefore little incentive for commercial banks to provide these services to poorer sections of society where it becomes difficult to break even. The microfinance movement aims to set up self- sufficient financial service providers that enable small businesses to manage their risk in developing countries – thereby stimulating economic growth.

Read more »

Event Report: Power and Politics in Requirements Engineering
Monde Kalumbilo, University College London (June 2012)

Thursday 14 June 2012, 6pm-8:30pm – BCS, 5 Southampton Street, LondonThe aim of this RESG event was to present work on an exploration of concepts of power and politics, and a proposal of a framework in which they can be modelled within the context of requirements engineering.

Emmanuel Letier (University College London & Chair) in introducing the event highlighted how the work, which is a joint effort by Alastair Milne (City University London) and Neil Maiden (City University London), had won the best paper award at the 2011 International Conference on Requirements Engineering (RE’11) in Trento Italy. In his opening remarks, Emmanuel commented on how unusual the paper was from typical technical presentations at RE’11, reading more like an essay.

Alastair Milne presented the paper. This RESG event was Alastair’s first opportunity to present the work as he had not attended the RE’11 conference. He started his presentation by sharing how his talk was inspired by his experiences in working on requirements as a developer, systems analyst, project manager, and on the business side, where he found that in reality people are often unreasonable, not very helpful, focus on trivial rather than important areas and do not make decisions on a ‘rational’ basis. Alistair’s assertion is that if power and politics are taken into consideration, such behaviour starts to make a lot more sense.

Read more »

Linking Key Risks to Requirements to Reduce Initial Design Effort

Steve Rivkin, October 2012

This article describes how the close integration of risk management and requirements management can be used to advantage to link risks accurately via requirements to specific elements of design, thereby providing the capability to reduce the overall cost of designs.

On many large projects it is common practice for the client’s project team, prior to going out to tender, to produce an Initial Reference Design to help investigate any key risk areas that may have been identified. In particular, where construction is involved, it may be necessary to gain Approval in Principle for certain aspects of proposed construction. The Initial Reference Design serves a number of purposes:

  1. It establishes the feasibility of certain aspects of the design
  2. It assists in gaining a more accurate estimate of the overall cost of the project prior to going out to tender with the main contracts
  3. It helps to mitigate or de-risk those areas of high risk relating to the design which might deter prospective bidders.

Read more »

A Call to Action: Vision for Requirements Engineering Revisited
Dr. Ralph Young, CSEP (
“Engineering can provide a life of genuine satisfaction in many ways, especially through ministering in a practical manner to the needs and welfare of mankind.” – Vannevar Bush
“No part of the delivery process is as critical, nor as difficult – because requirements map the human world to the technological world.” – Jim Highsmith


William Heaven requested that I write a sequel to my article that was published in the July 2001 issue of Requirements Quarterly 1 that would provide an assessment ten years later regarding the extent to which my vision has been fulfilled 2. One might argue that great progress has been made. My perspective is that things have improved somewhat – for example, there are new professional organizations that are looking at the issues from a broader perspective; certifications are being offered and earned; research is being done concerning the return on investment of systems and requirements engineering; there have been improvements in the availability of useful and effective automated tools; and there have been other technology advances. These initiatives can improve the understanding of what needs to be done. Professionals including the readers of RQ have been working hard to grow and improve the field. Yet, clearly there are ample opportunities for further progress.

Read more »


  1. The article is available online at  pp. 3-6.
  2. In this article, I make generalizations. Also, I suggest that people need to act differently; however, it is not my intent to imply that professionals in the requirements engineering field are less capable than those in other fields. In addition, I have not provided suggested solutions in all cases (although the information in the provided references should be helpful). I do not pretend to have all of the answers. My intent is to reflect thoughtfully on what I have learned with the hope that some of the ideas will be helpful for others to explore and apply, resulting in improvement in the practice of requirements and systems engineering.
Best Requirements Management Platform?
David Gelperin, CTO & President of ClearSpecs Enterprises
“Using Word or Excel for managing requirements is analogous to using roman numerals for arithmetic.”


When selecting a requirements management platform, most believe there are only two choices. One is to use word processors (Word) or spreadsheets (Excel). The other is to use complex commercial products.

This note identifies a third option that replaces the use of word processors or spreadsheets. It identifies products that are easy to use, inexpensive and functionally superior to Word or Excel for managing requirements.

Read more »

A Whitewater Guide to Requirements Deliverance
Olly Gotel

Deliverance, the movie

One of the only times that I get completely lost in the moment is when I am paddling white water. It is both a physically and mentally taxing activity! As the difficulty of the rapids increases, there is simply no room to concentrate on anything else but the water and my moment-to-moment actions to work with it. If you are not a boater, perhaps you sat at the edge of your seat when you first watched Jon Voight and Burt Reynolds canoe down monstrous rapids to the sound of distant banjo music in that classic 1972 movie?

When running white water, it is important to maintain composure in the midst of ‘apparent’ turbulence, and there are actually many interesting parallels between what makes for a challenging but safe river run and what makes for the successful deliverance of project requirements. Always one to combine work with pleasure, here is my ten-point white water inspired guide to help get you from the requirements put-in to the take-out on your project.

Read more »

Upfront Analysis: The Payoff
Camilo Fitzgerald
Sign A – Restaurant Closed For Business?

Sign A – Restaurant Closed For Business?

The question of how much upfront RE analysis to perform is one of considerable complexity that has always plagued software projects – proposed answers to have come from both ends of the spectrum. Research in requirements engineering typically suggests that more needs to be done [1], and that the cost ratio of fixing defects at the requirements level to later stages is between 5 and 10 for smaller projects and between 10 and 100 for larger one [2]. In practice, however, many a manager says, “I know that we should work out the requirements in detail, but we don’t have time. We have to get started on the programming because we have a short deadline to deliver the code!” [3].

The upfront analysis question is prevalent in many fields – When do we stop exploring a problem and begin taking action to solve it?

During my stay in Japan in the past six months I have seen many examples of signs designed to be understood by foreigners that illustrate the problem. Some of these have answered this question well by clearly communicating the desired message; some have done poorly; while others have simply left me baffled.

I encountered Sign A on the entrance to one of my favourite Tokyo restaurants. At first I was disappointed, thinking that I would have to satisfy my hunger somewhere else. I grew suspicious, however, when observing that the sign was permanently fixed to the door and on enquiring discovered that the establishment was in fact open. I later succeeded in translating the Japanese characters on the sign, revealing that its desired purpose was to state ‘that the door should be kept closed’. The restaurant manager had not realised the more obvious interpretation of the sign, which I suspect may have lost the custom of many a foreigner.

Read more »

The Forgotten Keystone of Requirements Engineering
Soo Ling Lim
A newly launched expense system was rejected by its users. They were unaware of the project and the system was not meeting their needs. The system had tobe redeveloped.
A railway timetabling website project was delayed for half a year. The website was completed on time, but a week before its scheduled release, the project manager found out to his horror that the new timetables needed approval. The approval took six months and should have been sought at the start of the project.
A team of developers spent the first year after their software was released handling change requests from users who had been ignored during requirements elicitation.
A medical software was banned from sales because it had not been approved by the health authority.

All these projects suffered from the same problem – their stakeholders were not identified correctly at the start. By stakeholders, I mean individuals or groups who can influence or be influenced by the outcome of the software project.

Stakeholders play a central role in requirements elicitation. Requirements and project constraints come from stakeholders, so omitting stakeholders gives rise to missing requirements, which leads to building the wrong product. Some projects have only a handful of stakeholders; others can have hundreds or even hundreds of thousands of stakeholders.    Some stakeholders have more influence, knowledge, or interest in the project than others. As such, the identification of suitable stakeholder representatives is crucial.

It is a mystery to me why stakeholders seem to be ignored or forgotten in RE. In a recent RESG poll by Camilo Fitzgerald [1], no one was interested in stakeholder identification! Yet in most of the projects I have seen, stakeholder identification is at worst non-existent and at best reactive – the analyst starts with an incomplete list of stakeholders and tackles new stakeholders as they appear throughout the project. In most cases, this reactive approach slows down the process and adds rework. But when an important stakeholder appears too late in the process, we have yet another horror story like the ones above.

Read more »

HFS: Human Flesh Search
Ian Alexander

Fig 1. Chinese root of ‘Human Flesh Search’

For a system to produce purposive results, it has to have been specified, designed, and tested against its requirements; it has to be commissioned and deployed prior to use; and it inevitably stays the same until it is deliberately changed, whether by redesign, “maintenance” software coding, or the updating of business rules if table-driven.

Only – all these laws are false, in the case of systems built on social networks and making use of the combined power of the Internet and human capabilities.

The International Council on Systems Engineering, INCOSE, has of course long defined a system as “a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies and documents…” (Eberhardt Rechtin, The Art of Systems Architecting, 2nd Ed., 2000).

It should be no surprise that the “parts” of an aircraft, or a bank, include both people and policies as well as hardware and software: these systems couldn’t work without rules to govern them and people to maintain them.

But these sober, Systems Engineering thoughts pale into insignificance beside the lurid accounts of Human Flesh Search that have appeared recently in the Western press. Western, for HFS stems from China – perhaps the first of many significant innovations from that dynamic economy and its many scientists and engineers.

Read more »

Building Myself a Kayak: Some Lessons for Requirements and Software Engineering (Part I)

During the summer of 2009, I decided to build myself a skin on frame kayak. Being a complete kayaking fanatic, I wanted to learn more about the history of the kayak1 and to understand how design decisions impact a kayak’s behaviour on the water. What better way to do this than to go through the process of building a traditional Inuit kayak for myself? Having absolutely no practical skills, it was clear that I was going to have to learn to do this in a workshop setting under the watchful eye of a master kayak builder.

Read more »

Sky-High Goals, Lower Costs

Ian Alexander (March 2011)

In the December 2010 issue of Scientific American magazine (, David Freedman discusses “Jump-starting the orbital economy” – turning space travel from a costly government-financed research venture into a profitable business.Unmanned geostationary satellites have already made that leap, of course: that strange orbit at 35,800 kilometres up, around the equator, is thickly populated with squat but profitable boxes of communications equipment, doing everything from monitoring the weather to providing television to far-flung islands.Manned space flight is another matter. NASA’s last space shuttle is due to launch next summer: after that, the funding, like the enthusiasm for costly adventures with no sight of a financial return, dries up. President Obama has cancelled NASA’s Constellation launcher, the costly agency-funded replacement for the shuttle. According to Freedman, most of the $9 billion of R&D effort so far spent will be written off.But NASA is not giving up the ghost – or should I say the spirit of adventure – just yet. Instead, the space agency has decided to pass the mantle of invention to private companies. They are expected to come up with innovative ideas; in return, NASA will provide them with seed-corn funding to help them get started – and after that, if their ideas work, NASA will provide them with a guaranteed customer. Just the thing to help you get unit costs down as you ramp up production.

Read more »

Making Your Requirements Knowledge Count: Working in RE

Ljerka Beus-Dukic welcomed everyone to this mainly-for-students event; it was good to see several non-student visitors too. The event was in two equal parts. First the four speakers each gave a short talk on how they used requirements in industry or commerce. Then the speakers formed a panel and answered questions from students about practice “in the real world”.

Read more »

Going to Other People’s Events

Do you ever go along to other people’s events? I don’t mean, do you gatecrash parties, that sort of thing. I mean, do you ever choose to step out of your familiar round of IET, BCS, INCOSE, your organisation, etc, and go to an evening or lecture or seminar that wasn’t intended for people like you?

Read more »