Interdependency Between Requirements – Case for Dependency Links Links

Every system (being it biological, organisational, social, and technological or a mechanical product) from a systems thinking approach is made up of different components that enable the whole to function. A change in one component without a corresponding update on the other(s) may result in malfunction of the whole system. Similarly in construction, a facility is constructed from a set of client requirements. Each of these requirements could have related sub-requirements that are linked to each other. A change in one could potentially affect another. Changes in ‘Requirement X’ may affect ‘Requirement Y’ which could also affect ‘Requirement Z’. For example a change in the size of a room could affect energy consumption requirement. This is dependency between requirements. Motawa et al. (2007) observe that “it was important to identify what project characteristics lead to the causes of change and what these causes are, and then to understand how these causes are related to effects.

Some of the key questions were: How does one factor relate to another?

What are the internal mechanisms by which a particular factor causes a change in another factor?” Once a requirement change is authorised, it needs

77 to be checked against the design, the construction programme, the specifications and bill of quantities to substantiate the impact. Emmitt (2007) identifies that changes need to be checked against critical documents such as project brief before implementation which is a slow process since changes have implications for other interconnected aspects of the building. Austin et al.

(2002) state that most change decisions affect cost and time of construction projects and such decisions have to be properly monitored and their impact traced. Ye and Froese (2009) identify that “where a project manager is evaluating the impact of a proposed change order, he or she will want to consider the schedule, cost, scope, resource, reference documentation, and other information relating to the change but it is traditionally left to the user to manually identify each relevant dataset and to understand the interdependencies between them.” Dependency and impact also need to be handled as part of requirements change management to help analyse the impact and consequences on project variables such as schedule, budget and performance/quality. Such changes could have an effect on different project variables such as the budget, schedule and quality. Similar emphasis has been made by the Office of Government Commerce (2007b) that “Changes to design, especially after contract award, are one of the major causes of time and cost overruns and poor value for money.” Individual requirements that are related but are represented at different phases should be mapped together to provide links between them to enable traceability. Accordingly, these links should be implemented between the requirements and “even a simple active link between the client requirements and design tools can increase the use of requirements documentation throughout the design and construction process, and facilitate necessary updates of the client requirements” (Kiviniemi, 2005).

Similarly, Tvete (1999) suggests that in order to facilitate traceability, requirements need to have unique identifiers which can be an attribute, and this can make the viewing and analysis of requirements possible from different points. Traceability relationships are not only relevant for dependency checking and impact analysis, but they also provide a link between different teams using those requirements.

78 Maiden and Jones (2004) define dependency links between actors of a system where a link indicates dependency of one actor onto another for attaining a goal. According to them, the depending actor is called the depender; the actor who is depended upon is the dependee. The dependum is the process element around which the dependency relationship is centred.

Maiden and Jones (2004) specify the following four different types of dependency links.

Goal Dependency: in this dependency, the depender depends upon the dependee to bring about a certain state in the world.

Task Dependency: this type of dependency indicates that the depender depends upon the dependee to carry out an activity.

Resource Dependency: this implies that the depender depends upon a dependee for the availability of an entity.

Soft-goal Dependency: this exists were the depender depends upon the dependee to perform some task that meets the soft-goal or to perform the task in a particular way.

Thus it is vital that these relationships are adequately and thoroughly maintained, if not, subscription may be the basis for change dissemination (Sinha et al., 2006). Within the software industry, Kotonya and Sommerville (1998) and Sommerville and Sawyer (1997) in Maciaszek (2007) discuss the importance of requirements dependency matrix which can be constructed once all requirements are clearly identified and numbered. They indicated that such matrixes are simple but effective techniques to identify conflicting and overlapping requirements.

A risk analysis and prioritisation should be done once the conflicts and overlaps are resolved and a revised set of requirements produced (Maciaszek, 2007). A template of a requirements dependency matrix is demonstrated in Figure 3.6.

79 Figure 3.6: Example requirements dependency matrix

Source: (Maciaszek, 2007)

A similar concept was also developed by Symantec Corporation (2008) in the management of service groups within their Veritas Cluster Server where service groups can depend on each. In their work, they specify the dependent group as the parent and the other group, the child and the dependency relationship is called a link. “For example a finance application (parent) may require that the database application (child) is online before it comes online”

(Symantec Corporation, 2008). Three different link characterizations were identified, namely: dependency category, dependency location and dependency rigidity.

Dependency category: this can be either online or offline group dependency. A dependency where the parent starts only by waiting for the child to be brought online first is referred to as online group dependency. A dependency where one of the groups needs to be offline before the other can start is referred to as offline group dependency.

Dependency location: this can be local, global, or remote dependency.

Local dependency exists on the same system where the parent group depends on the child group being online or offline. Global dependency exists where one or more instances of the child group being online on any system determine an instance of the parent group. Remote dependency where one or more instances of the child group being online on any system other than the system on which the parent is online for an instance of parent group to occur.

80 Dependency rigidity: this type of dependency can be soft, firm or hard dependency in terms of constraints on how the different groups are brought online or offline. Soft dependency specifies the minimum constraints; firm inflicts more constraints and hard imposes the maximum constraints.

The philosophical approaches applied in these theories are relevant to this research and can be adopted in defining dependency links between requirements and sub requirements (i.e., secondary requirements) in order to facilitate traceability for dependency checking and change impact analysis.