Large-scale systems do not come into existence easily. Stakeholders rarely share a unique problem definition, and political, social, economic and environmental factors can have a significant and often dominant influence on the decisions made [16]. An initial obstacle is to get from an unstructured mess [17, 24] to a workable problem definition, and from that to an early set of requirements [19]. This is what we term the ‘upstream’ stage of requirements engineering.
Existing approaches to requirements engineering acknowledge that requirements stem from different stakeholders, from the operational environment, from the enterprise, and from the availability of new tech-nologies. These approaches also acknowledge that the gestation period may be many years, in which time the staff involved, the available technologies, the organizations priorities and economic situation may change. Reconciling the requirements and implementing them is a crucial issue and is logically and technically difficult [16], is political [1] and is prone to points of crisis [22]; however, eliciting the requirements is often treated as if it were simple, if it is discussed at all. In fact, elicitation is often a highly fraught, conflictual undertaking requiring careful and intensive management by project managers and engineers.
In this chapter, we present a process and tool entitled Wisdom. The Wisdom process and tool addresses the primary obstacle in eliciting requirements: problem definition. This phase revolves around how to structure the problem or need which the system will answer. These early stages of requirements elicitation are primarily concerned with the high-level business or organizational requirements. Failure to get these right means that the more detailed requirements will not be aligned with the needs of the organization. At this early upstream stage, getting the right information (from multiple sources) is only part of the problem. Interacting around that information to structure it in ways that people will accept is also crucial. Conflicts are inevitable at this phase of negotiation [16]. The Wisdom process and tool negotiates these conflicts using a combination of formal and informal group processes supported by software. It also seeks to render this kind of negotiation accountable. Wisdom can therefore be characterized as a “prescriptive” and “intrusive” approach. By using the name Wisdom we are not attempting to specify what it means to be wise or receive wisdom, there being a diverse literature on this. Rather, the name is used to emphasize use of the process and tool to draw out existing organizational knowledge at the right time. We are concerned with how expansive rationale can be captured at the beginning of a project, and is-sues be explored without decisions necessarily being made.
In Sect. 6.2 of this chapter, we provide a description of the Wisdom process. In Sect. 6.3, we provide an account of the Wisdom tool, which is designed to support the process, with examples of usage in Sect. 6.4. Finally, in Sect. 6.5, we reflect on experiences with the system.
The Wisdom process is a hybrid of existing techniques from management science and software engineering. This section will begin by describing those techniques and then continue by explaining why Wisdom brings the two together and describing how this is done.
