Requirements – A Socio-Technical Discipline

A Combination of Perspectives

The previous articles in this series have focused on different views and levels of requirements and the ability to be able to trace between them. Before going further with this theme it is useful to stand back and consider the nature of Requirements-related work.

Requirements discovery and communication is an activity that straddles the boundary between the sociological side of system development, and the technological side. On one hand we have people, with all their vagaries, fallibilities, opinions, inspirations, attitudes, experiences, similarities and differences. On the other we have a variety of technology that demands a precise specification if designers and developers are to use it to produce the best possible solution for the client.

Project Sociology

There are several significant aspects to the sociological side of requirements work. Firstly, the requirements analyst needs to identify and somehow (with emphasis on the somehow) involve all the appropriate stakeholders in order to discover all the requirements. Involving the stakeholders is complicated by factors like: some stakeholders are too busy to pay proper attention, some are unavailable or in different locations, some don’t know enough to supply the right requirements, and some think they know but don't.

Consider the stakeholder map in Figure 1. This map identifies the stakeholder roles for the Library Loans project that is referred to in the first 3 articles in this series.

Figure 1: A Stakeholder Map for the Library Loans project

The purpose of the map is to identify the stakeholders by identifying people, existing computer and manual systems and organisations who are potential sources for some of the requirements. The map, with its concentric rings, highlights which stakeholders inhabit which parts of the work that needs to be studied. Notice that different stakeholders clearly will have different concerns and interests and hence different requirements.

For example the Chief Librarian will be concerned about the management of the library whereas the Book Borrower will be interested in what the library provides for him – how long he can borrow books and whether the library will inform him when a book that he has requested has been returned. And the systems architect will have very different requirements like conformance to the systems architecture constraints and the elegance of the design.

Some stakeholders will share requirements but in the majority of cases each stakeholder’s role will influence which requirements he considers the most important and hence which requirements he will tell a requirements analyst.

Variety of Trawling Techniques

Once you have identified the relevant stakeholder roles, another aspect of project sociology is deciding the best/quickest/most accurate way to discover the requirements for each of the roles. In some cases the analyst will interview a representative of a stakeholder role or hold a workshop. However in a large number of cases the analyst will not be able to talk to individuals and will discover the requirements by apprenticing, observation, data analysis, research into current practices, video conferences, surveys, prototypes, simulations and many other techniques for trawling for requirements.

The best trawling technique is the one that discovers the most detailed understanding of each stakeholder’s requirements in the minimum amount of time. It is the variations in knowledge, availability, attitude and focus of each specific stakeholder that helps the analyst to choose the appropriate mixture of techniques.

For example suppose you are trying to discover the business requirements and the stakeholder you are talking to can only talk in terms of changes to the current interface design. Maybe the stakeholder is so used to the current way of doing things that he cannot think of the world in any other way. In a case like this a good trawling strategy would be to sketch a prototype that includes what the stakeholder is asking for. Then use that prototype as the basis for asking questions and making the necessary abstractions to discover the real business requirements as opposed to an interface design. We have discovered that this often uncovers questions that can only be answered by a different stakeholder with the appropriate business knowledge.

Balancing Problem and Solution

The business analyst needs to understand and articulate the business problem so that it can be solved within the constraints of the solution space. The skilled business analyst must know enough, or have access to advice, about the technology to know what is possible and sensible.

Constraint requirements help the analyst to decide whether or not to pursue a detailed line of requirements specification. If there is a constraint that clearly inhibits a technical solution for part of the business requirements then it is a waste of time to define that part of the requirements in atomic detail when a higher-level description will suffice. One has to be very careful to discover the real constraints, not just things that are currently done in a certain way that nobody thinks could be changed.

It is these artificial constraints that prevent some stakeholders from asking for things that would help them. They are often inhibited unless they know the things exist, or they have a good probability of being able to exist. So it often falls to the business analyst to invent part of the requirements. This does not mean that the analyst is making the business rules. Instead he is articulating ideas that will help the business specialist to achieve their real goals.

If the analysts simply listened to their customers, then not only would each generation of system look pretty much like the previous ones, but few genuine advances would be made. Of course a requirements analyst cannot be expected to know everything about the current and future technology. This accessing of the appropriate level of technical knowledge usually means communicating with consultant stakeholders like the ones on the stakeholder map in Figure 1, for advice and guidance.

Summary

Why is it important to see requirements analysis as a socio-technical discipline? From the sociological perspective, requirements come from people who all behave in different ways. So it is necessary to develop skills that help to be a good listener, questioner and reflector. When trying to discover requirements one needs to have a variety of techniques (workshops, interviews, apprenticing, modelling, brainstorming....) and the ability to pick the one that suits the particular people one is dealing with.

However from the technological side it is vital that the requirements, once discovered, are expressed in a consistent, complete and traceable form. This is a form that ensures that other stakeholders like the developers, testers and requirers all have the same understanding of what is required.

A good requirements analyst is someone who can combine technological and sociological skills.

James and Suzanne Robertson are the founders of the Volere requirements process, template and checklists. This requirements technique is used by tens of thousands of organizations worldwide. Their careers have taken them to every continent and along the way they have collected an impressive portfolio of projects and industries. They can be reached through the Atlantic Systems Guild, a London, New York and Aachen consultancy and think tank.  www.systemsguild.com

Volere contains a structure for discovering and tracking requirements at several different levels. Note that the Volere Requirements Template provides more guidance for structuring all levels of requirements-related knowledge.