Prev Next

Requirement Volatility

There are ever increasing market place pressures to release products and systems as early as possible, putting stress on project teams to develop, test and deploy products in shorter and shorter periods of time. The requirements processes have changed significantly in recent years to ensure that stable, correct and well-articulated specifications are provided to architects, designers and developers when they need them. There has been a move to iterative and incremental processes and this necessitates providing a set of requirements for an iteration that are stable. The churning of requirements is often an indicator that a problem is not clearly understood, that stakeholders have not compromised and there are unresolved political issues, the scope is not defined or the business itself is in fluctuation. Enterprise Architect has a number of mechanisms that can be used to assist with this problem. Enterprise Architect does not have a built-in property for requirement volatility (stability) but using the general purpose UML extension mechanism of Tagged Values a tag could be created to record this property.

Note: Internal requirements do have a stability property but external requirements do not.

Mechanisms for managing requirement volatitlity

Mechanism

Description

Volatility as a Tagged Value

Enterprise Architect provides a series of properties for requirements, but additional properties can be created to record other properties such as a requirement's volatility or the source of the Requirement. This is achieved using the UML Tagged Value mechanism, which allows any element including requirements to have one or more tags applied, representing some property that can be assigned a value. Enterprise Architect has extended this mechanism and allows the modeler to create a list of values that can be chosen from a drop down list using the Predefined Structured Tagged Values. This allows a team to define their own list of volatility values, such as extreme, high, medium low, minimal.

Using Baselines

The Baseline facility is a powerful tool that enables a user to take a snapshot of a model or more typically a model fragment and then as the model is developed to compare the new version of the model to the baseline thus identifying anything that has changed since the baseline was taken. Baselines have general applicability but are particularly useful with requirements management where requirements are often said to be signed-off or frozen and any alterations to them must be registered as a change. The Baseline tool has a Compare utility that conveniently lists changes between the current model and the baseline.

Searches for churning requirements

Enterprise Architect has a sophisticated search facility that allows a user to search across a selected Package or the entire repository and locate elements that meet fined grained criteria. This can be used to locate requirements that have not changed by searching for a change in the modification date before a specified date, thus providing a list of stable requirements. Alternatively if volatility has been set using a Tagged Value, all elements with a specified volatility could be located. The search facility returns a list of elements that can be located in the Project Browser and the search can be used as the basis of a Model View that could be used to view volatile or alternatively non-volatile requirements.