Requirements Management

Introduction

Managing a large complex contract is a difficult task. A natural approach is to cut up the task into more manageable pieces. Requirements Management (RM) has been identified as an essential part of Contract Management. For a complex contract, there can be thousands of requirements, so RM is split off as a separate management area, with its own tools. A typical RM tool is DOORS from Telelogic. The requirements are put into a database, and links created between the requirements, leading to a linked structure as shown in the diagram

This seems quite useful, until it is realised that the structure has no idea of the meaning of the words in each requirement. The links can be crudely typed, with "depends on" and "found in document XX" some of the typical types. While the requirement structure is simple and small, this is adequate. When the requirement structure is complex, this is better than nothing, but not very good. As with project management, we have shifted from the number of objects that can be held in one's head (no more than fifty) to the number of similar objects that can be handled if indexed (about two hundred and fifty). With projects having thousands of requirements, we are still a long way from our goal. The segmentation of the problem has increased the duplication - we have requirements in the contract, and have split them out from the contract, although the contract is still authoritative, so any difference that is allowed to creep in could be costly. The structure for a large aerospace contract might look like

The result of segmentation is that we need an army of people to try to hold all the pieces together - not usually very successfully.

Presentation on Requirements Management

Transformation

People have looked at the limitations of linking requirements without the system having any notion of semantics. HiVe is one example of a solution, where a High Level Logic (HLL) language is used to model the requirements. A comparison has been made between HiVe and DOORS,

Reference: http://dspace.dsto.defence.gov.au/dspace/handle/1947/3686

The particular language used for HiVe is Isabelle. There are several problems introduced:

1. The assumption of a hierarchy will not usually be valid - the requirements structure is a web of constraints, not a tree
2. The severe limitation of the HLL used (unification doesn't reach very far, and a single requirement can't be analysed in isolation)
3. The difficulty introduced in trying to convert requirements expressed in natural language into a form acceptable to the HLL
4. The explosion in size of the requirements - a thousand requirements in natural language may end up as twenty thousand obscure statements in the HLL, still without capturing the exact meaning, increasing rather than decreasing the complexity of the problem.

The result is a system that is essentially unusable on anything with complex requirements.

There have been a number of attempts at subsetting what can be said in a requirement - if a complete set of requirements can be written within the limitations, well and good. If corners have to be cut to force the requirements into the subset, or, worse, the author deliberately avoids specifying some things because the subset doesn't support them, the result is likely to be wastage and inefficiency after the specification stage, because the specification was not complete.

An obvious alternative path is to use a system developed to read contracts and extract their structure - it uses the language of the contract, many levels above the sort of formal language typical of Isabelle. Instead of someone having to twist the requirements, the requirements that appear in the contract are used. There is no transformation, there is no manual linking of requirement statements with "sort of appropriate" link types, the statements are linked by what they mean.

For requirements analysis, see ARIA and Presentation

Presentation on Bid Compliance

For Natural Language Processing concepts, see NLP