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 stable requirements for every iteration. The churning of requirements is often an indicator that a problem is not clearly understood, that stakeholders have not been 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 an effective 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 either a selected Package or the entire repository, to locate elements that meet fine-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 Browser window; the search can be used as the basis of a Model View to be used to view either volatile or non-volatile requirements. |