Why do the business requirements and the final software product often have little in common? Why are stakeholders, developers and managers reluctant to embrace a full requirements process? Why does everybody say, "we don't have time for requirements"? Why is the potentially most beneficial part of the development process ignored or short-changed?

Following are some observations about why the real requirements for the product often go undiscovered. I will address this by focusing on the different concerns of the people involved in requirements.

Stakeholders are the people who have demands on the product. They will use the delivered product, or they are people who have knowledge that is needed to build the product. Simply put, stakeholders know the requirements, and it is up to the requirements analysts to extract the requirements from the stakeholders.

However, the stakeholders often see the requirements effort as a disruption to their work. This is not surprising. The delivered product is often not what they envisaged, and so any time they spent with the product developers is looked on as a futile and unnecessary disruption to their work.

Not all stakeholders are always included. Frequently, there is little or no stakeholder identification at the beginning of the project. I always recommend to clients that they hold a session or two where they use checklists to identify all the people who could influence the product. Not only the people who will be using it, or the managers of those people, but others who have expert knowledge, know of regulations governing the industry, inspectors, usability people, auditors, and the many other people who know something that will contribute to the success of the product. ItÕs really simple: if any of these people are missed, then it leads to missed requirements. There is a secondary effect of missing stakeholders Š the lack of political legitimacy for the project from the people who feel they should be stakeholders, but were not approached by the project team.

To ask a stakeholder to participate is one thing. To have them participate is another. I have observed projects where the stakeholders resented the time that they gave to the project - "We have our own work to do". How does one get people to participate? Reward them.

Give them feedback. Show them that the time they spend, and the expertise they give, is shaping the eventual product. This means giving feedback in stakeholder language. Stakeholders usually do not have the same regard for, or need of, the degree of technicality often used by the developers. In particular, my observations tell me that some models are particularly unsuitable for showing to users. They sit and nod while some enthusiastic developer explains message passing between collaborating objects. They say they agree, which usually turns out to be a tactic for getting the developer to go away.

What's wrong with English (or whichever human language your organisation uses)? While it is the language of the stakeholder, it is not always precise. Thus, as well as a description, I add a measurement — I call it a fit criterion — to each requirement. The fit criterion uses numbers to measure the requirement, thus making it unambiguous and testable. The fit criterion allows me to use natural language, and to ensure that my stakeholder and I have precisely the same understanding of what is required.

The fit criterion is not arbitrary. It is a negotiated measurement of the requirement. As I negotiate it, I am demonstrating to the stakeholders that I am trying to ensure the product fits their expectations, and I am discovering the real requirement. I cannot derive a measurement for the requirement without having a precise understanding of it. By negotiating the fit criterion, my stakeholders and I arrive at an identical meaning for each requirement. When they know that I have understood, and that the product builder will build precisely what they asked for, the stakeholders are far more willing to lend their time and resources.

A fundamental conflict is that the developers revel in a type of technical precision that is not necessarily relevant to the requirements gathering activity. The requirements activity is fundamentally a human-oriented process, whereas developers are attempting to do it using object-oriented technology. Objects are a great way to construct software, but a polymorphic encapsulation with inheritance and message passing bears no resemblance to the stakeholdersÕ workplace.

My observations in this area suggest that the developers need tools that help them to communicate with the stakeholders using analogue not digital means. Most of the UML models are not appropriate for requirements work. They are good design models, lousy requirements models. Scenarios work well because they look like the stakeholdersÕ world. In fact, almost all natural-language models are fine. Paper and pencil are the overlooked tools of requirements gathering. That and two ears.

Project management is faced with a conflict between the developersÕ desire for new technology, the marketing departmentÕs desire for features and the usersÕ desire for a product that matches their work. We should also take into account the different stakeholdersÕ interests and their desire to see the effect of their contributions in the end product.

So how do we measure success? By delivery time? By cost to build? By the amount of code that was reused? These measures might be useful for some other purpose, but they do nothing to ensure that the product is useful, or will be used. If the product is not useful, then it usually has to be rebuilt. Although I may be dealing with the wrong clients, I have never once seen the cost of starting over charged to the original project team. It seems that if a product is rejected by the intended users causing the product to be rebuilt, then the cost incurred so far is written off and the new effort starts from scratch. Fraud! Management never get to see the real cost of the product, and do not get the most useful measurement of all Š is the cost of building justified by the benefit of having the product?

Software products are built to help with work. While the cost of building a software product is no doubt important, the benefit from having that product is surely a more important measurement. Without knowing this benefit, it is difficult to justify launching a software project. Without it, it is impossible to know whether the development was worthwhile, or whether future efforts are justifiable.

Measuring benefits is linked to the stakeholders. As each stakeholder has some requirement to contribute to the product, each stakeholder receives some benefit from that product. This should be measured. And if the benefit from a requirement is known, does that not give requirements management a better chance to know if that requirement should be included in the final product? Is this not the way that we can know Š I stress that knowing is better than guessing Š if a requirement is a genuine requirement or just another instance of gold plating?

Each of the stakeholders has a meaning for his interests. Each of the stakeholders is different, each with a different view of the work that he is doing, and each has a different perspective that somehow contributes to the final shape of the product. Each stakeholder holds a certain amount of power. This can be power because of the stakeholderÕs position in the organisation, or power because of particular knowledge. Naturally, the greater the power the greater the stakeholderÕs influence on the product. Requirements that come from powerful stakeholders are more likely to be part of the product than requirements from less powerful stakeholders.

Stakeholders also have an interest. This is a particular interest in one or more aspects of the product. For example, consider a stakeholder from the marketing department. This stakeholder would be interested in the usability aspects of the product, itÕs appearance, its features and the way the product appears to the prospective buyer. Thus it is not always necessary for the stakeholder to be close to the work to have an interest in some aspect of the work.

Additionally, each stakeholder has a proximity to the work. That is, some stakeholders can be directly involved in part of the work, while others are slightly removed from it. For example, they might supervise, or check the quality of the output from some part of the work. Others are more distant still Š they advise or have some consulting relationship with the work.

This means that we can allocate to each stakeholder a ranking based on power, interest and proximity. Stakeholders with high ratings in all three attributes are very likely to have their requirements accepted. Similarly, those with low ratings do not have the same influence on the final product.

However, each stakeholder has a meaning for the part of the work that they consider theirs. That is, they have a metaphor for their work, they think of it in a certain way. Each stakeholder is an individual, and has an individual view of their work.

This brings us to the role of the requirements analysts. It can be said simply: they have to ensure that the eventual software product conforms to the stakeholdersÕ meanings. That is, it represents the work in a way that is meaningful to the stakeholders. The stakeholders can see each of their work artefacts represented in the product. The way that the artefacts are represented may be different, but they are part of the product nevertheless.

Moreover, the products features must conform in total to the aggregation of the stakeholdersÕ meanings. Given that each stakeholder has a rating of power, interest and proximity, the total meaning of the product must conform to the weighted influences of the contributing stakeholders.

Not so simple anymore.

But consider the prize if your software product fits the sum of the weighted stakeholdersÕ expectations. It means that the product is what is actually wanted. It means that the product fits the work, and fits the people who do the work. Additionally, it satisfies and rewards the efforts of the people involved. While ever, software is built by people, it will be necessary to give importance to those people. Just as Prince Charming searched the Kingdom for the wearer of the glass slipper, the requirements analyst who wants to live happily ever after must search for, and involve, and reward, all of the stakeholders who have something to contribute.

James & Suzanne Robertson

REFERENCES

Beyer, Hugh and Karen Holtzblatt. Contextual Design. Defining Customer-Centered Systems. Morgan Kauffmann, San Francisco, 1998.

DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, New York, 1987

Highsmith, Jim Adaptive Software Development Dorset House, New York, 2000

Leffingwell, Dean and Don Widrig. Managing Software Requirements - a Unified Approach. Object Technology Series (Series editors Booch Jacobson Rumbaugh), Addison-Wesley, 2000

McWhinney, Will Paths of Change Revised Edition, Sage, Thousand Oaks, CA, 1997

Robertson, Suzanne & James Mastering the Requirements Process. Addison-Wesley, 1999.

______________________ Volere Requirements Specification Template. Downloadable at http://www.volere.co.uk

This work is copyright © 1995 - 2002 Atlantic Systems Guild, but may be adapted for your internal use provided copyright is acknowledged. Please let us know what you are using it for.

top of page