Goals and Softgoals

This is a technique for linking functional requirements to nonfunctional requirements (Mylopoulos et al 2001). It is based on the concept of goals, which are used to measure the satisfaction of a functional requirement, and softgoals, which measure the satisfaction of a nonfunctional requirement.

Firstly, we break down our functional requirements into goals and subgoals. Goals are objective and discrete; we have either satisfied them, or not. So, a functional requirement is subdivided into all the required components of that functionality, and whether we have satisfied it or not.

Softgoals are similar to goals, but they are not black and white, absolute measures. Instead, we measure the extent we have satisfied that softgoal. We say we have met a softgoal when there is sufficient contribution towards it, and insufficient contribution against it. They are therefore suited to nonfunctional requirements, which are often subjective or relative properties of software.

Usability is a good example. We can list requirements to help make our software user-friendlier, but equally other non-functional requirements such as security may make the software less easy to use. Whether the software is ultimately considered usable is a question of the balance of the two.

So, we use softgoals and subsoftgoals as a way of decomposing our nonfunctional requirements and measuring our implementation or requirements against them.

Having identified the hierarchy of possible goals, subgoals, softgoals and subsoftgoals we then identify the relevant ones to target to satisfy our requirements. From this set, we can identify the relationships between them and the set we need to satisfactorily implement our features.

Object Life Histories

One of the key principles behind object-oriented development is that any system has a number of key objects or concepts that can be implemented as software entities. These objects will typically be created with an initial set of conditions and then experience many interactions and events that change their state throughout their life span.

We can represent these states, and the transitions between them as a state machine diagram. This state machine diagram can be used to help find functional requirements. This technique is known as Object Life Histories (Robertson & Robertson, p296-297)

Consider the example of a car in a typical racing game. This car may begin life on the grid, undamaged with a full tank of fuel. Throughout the course of the race a number of events can happen to the car. For instance, a car may run low on fuel and need to enter the pits to continue. A car may be struck by another car and become damaged. The car may be repaired following a visit to the pits. This set of example illustrates states (initial state, damaged state) and events (refuel, hit by another car) serving as transitions between those states.

We can use the states and transitions between states to discover functional requirements. For instance, the ability to repair damage to a car during a pit stop is a functional requirement. The ability for the car to become damaged following a collision is a nonfunctional requirement.

By adopting a different perspective of what could happen to an object during its lifetime, rather than the use-case oriented view of what changes we can affect to an object we can discover a whole new set of requirements that we may otherwise miss.

Volere Template

The Volere Template is a comprehensive document detailing a requirements specification template covering all aspects of the requirements engineering process, developed by James and Suzanne Robertson.

The template contains sections covering issues such as the driving forces behind a project, the project's constraints, functional requirements, non-functional requirements and project issues.

The Volere Template is a comprehensive document; however, it does not have to be used verbatim. The template can be trimmed to those areas most important to your project, or even simply used as a checklist or guide to structure other processes.

The Volere template can be found at www.volere.co.uk

Wikis

Wikis are a superb tool for all aspects of requirements analysis. Wikis are a participative, collaborative method of capturing, refining and communicating information. Wikis can be used to obtain input from a wide range of perspectives and sources, breaking down political, power or functional lines. Furthermore, as the history is stored, we can retrieve information such as how design decisions were taken.

Conclusion

Formally or informally, explicitly or implicitly, consciously or unconsciously, requirements engineering is a core software engineering activity that is always practiced at some level. Introducing cohesive requirements engineering processes can help us avoid wasting time and cost building the wrong software and ensure the software we build is high quality and satisfies our customers.

References

Robertson, S. and Robertson, J. (2006), Mastering the Requirements Process, Addison-Wesley

Mylopoulos, J., Chung, L., Liao, S., Wang, H. and Yu, E., 'Exploring Alternatives during Requirements Analysis', IEEE Software, January/February 2001

Alexander, I., 'Misuse Cases Help to Elicit Non-Functional Requirements', Computing & Control Engineering, February 2003

---

Title photo by 3:19, used under Creative Commons license.