Requirements Packages

By Dieter E. Jenz, July 2000

We are all aware that getting the right requirements and getting requirements right is essential for project success. However, in practice very often we see an astounding recklessness. People argue that requirements keep changing all the time and that it is only extra work to capture requirements and keep track of them.

But what if we could get out much more of all the requirements we capture? By that I mean: derive other products which we need during design and development and just generate them. Requirements packages are the way to achieve this goal.

What is the business case for requirements packages?

In our software process we strive to speed up analysis, design and development by distributing work over several teams. As we know, the larger a team becomes the more administrative overhead is incurred. Therefore, we want to keep our teams small.

At the same time, we aim at achieving a high degree of parallelism. For example, we might have four small teams working on use case modeling in parallel where each team is assigned a few use cases. Undoubtedly, the question arises how we would maintain the systems requirements specification (SRS).

The SRS is a document which contains functional and non-functional requirements. With regard to describing functional requirements we are in danger of redundancy. Our primary carrier of functional requirements are use cases which we model using UML syntax and semantics. We would not like to run into the problem of having to maintain functional requirements in two places: in the CASE tool and the SRS (which in many cases is a Microsoft Word document).

As we are progressing with modeling we repeatedly face the problem of how to ensure consistency between CASE tool and SRS. Only the most disciplined stand a chance to succeed in maintaining consistency.

There is yet another question to solve: how can we support our highly parallel working approach? A single SRS always becomes a bottleneck, since only one team at a time is allowed to make changes to the SRS. They check out the document, apply their changes to it and check it back in. Only then may some other team proceed. Surely, this inhibits progress and is not what we want.

It definitely makes more sense to split a SRS into independently manageable requirements specifications. As the primary focus is the use case we are well advised to chain a requirements specification to a use case. Thus, in the first instance there is a one-to-one relationship between use case and requirements specification package. To be exact, however, a use case is contained in a requirements specification package, since non-functional requirements have to be considered as well.

In practice, each team would work on one or more requirements specification packages in an iteration. Each team can create and maintain their requirements specification packages independently. They are in fact the sole owners of their specification packages.

By the way, splitting up a SRS into many requirements specification packages does not mean that we give up our SRS. We can always build a SRS from its parts.

What's in a requirements package?

We want a requirements package to be a logically self-contained unit of work. It should contain all the information necessary to completely describe a use case. How about abstract use cases? They represent requirements as well and thus we do not need to distinguish between "real" and abstract use cases.

Keeping to our definition a requirements package contains

General information about the use case (purpose statement, use case owner etc.)
Use case description, including pre-conditions, post-conditions, main success scenario etc. (a CASE tool can be used to create and maintain a graphical representation of the relationship between use case and actor(s))
One or more user interfaces (if applicable)
One or more dialog maps (if applicable (one dialog map for each user interface))
Business rules (as far as they apply to the use case)
Test requirements for system test
Non-functional requirements for the use case

How can we manage requirements packages?

Requirements packages are made up of information of different types. Today, for example, we keep non-functional requirements in a Microsoft Word document, functional requirements (i.e. use cases) in the CASE tool repository (the basic definitions) and in a Microsoft Word document (the scenarios) and a user interface prototype in the repository of an IDE. We are aware that we are in danger of losing consistency and integrity.

To remedy the problems we can take an XML-oriented approach and design document type definitions (DTDs) or schemas (much better) for our various information types. We would have a schema for non-functional requirements, one for describing use case scenarios, etc..

However, the question remains: how can we really "bind all the information together" in a requirements package? We need to have some linking mechanism which allows us to create and maintain references to our various information sources. Fortunately, the XML Linking Language (XLink) has just reached candidate recommendation state and can be considered relatively stable. The XLink specification is being developed under guidance of the WWW consortium.

Of course, a specification alone will not do. We need a tool. To my knowledge, X2X is the first tool on the market. X2X allows linking between documents and information resources. However, links are not physically contained in the resources. Thus, it is possible to include a link to a Microsoft PowerPoint file, for example. With a tool like this, we can create requirements packages, which are nothing else than XML files containing links to our information resources.

Surely, this approach has its weaknesses, too. For example, all the links must be managed manually. There are no built-in integrity and consistency checks. On the other hand, however, we are better off by far. We can "link together" information from different sources.

Beyond that, taking a more XML-centric approach to describe requirements has its advantages, too. We can access elements in an XML document and use it in different ways, for example, to generate documents for review by the customer.

The potential

There is great potential in the use of requirements packages. We gain a lot and lose nothing. The XML-centric approach helps us tremendously, even if we are not able to express all the information we gather in a formally structured manner.

The real advantage lies in the significant productivity gain, accompanied by a quality improvement. Teams are not hindered in ploughing ahead as fast as they can. The highly iterative and incremental project approach is supported and we can achieve a high degree of parallelism.

There is no need to forgo a conventional SRS, however. On the contrary: we can produce a complete SRS at any time, which reflects the current state of analysis and design.

Products or trade names are trademarks or registered trademarks of their respective owners