Requirements Specification Software

The Purpose of this Page

This page gives a glimpse of a requirements specification software application that I have been doggedly pursuing since the late twentieth century—and which has now reached an advanced stage of development. Its emphasis is squarely on improving the specifying of requirements; it is not concerned with managing requirements, which is well handled by existing applications. The purpose of this page is to spark interest from any company that might benefit from acquiring the rights to this software—especially vendors of requirements management products who wish to offer serious, rich requirements specification functionality.

Origins
Once upon a time a start-up company needed a system to drive its new business venture. Its development team specified the system's requirements and was putting the final touches to a hundred detailed use cases when the boss gave the green light and demanded that the business start operating at the earliest possible date—which an all-hands-to-the-pump crash effort achieved in a miraculous five weeks (albeit with a morass of cobbled-together spreadsheets and manual processes). The requirements and use cases were cast to one side, because they were not in a form that could readily be acted upon. I was part of that development team and I felt this was a shame and a waste—that it must be possible to do better. This led me to reflect on the ways that the right software could assist the requirements process and then exploit the requirements once they're written. I made some observations:
Observation 1.
 The only thing you can do with textual requirements is to read them. That's tediously time-consuming and liable to human error. Further, when you lay out a piece of text, those pieces with special formatting tend to reflect the items with special meaning. If we could mark up its meaning instead, we'd be a long way towards making it machine-understandable—to be able to extract meaning in ways other than a human being reading it.
Observation 2.
 Almost all systems are implemented in multiple phases—which means that some requirements remain unsatisfied until the final phase (and the bulk of requirements often aren't satisfied in the first phase). How is a business to manage with a system that doesn't yet do all it needs to? A software application that understands the requirements to some degree is in a position to plug some of the gaps. And the more gaps that can be filled in this way, the quicker an acceptable initial system can be deployed.
Observation 3.
 A requirements specification application must itself possess many features that almost every software system needs—awareness of users, access control, database support, maintenance and inquiry functions, considerable configurability, a rich user interface ... the list goes on. Such an application is well placed to make these features available for use in the initial implementation of a system—to plug the kind of gaps mentioned in Observation 2. (However, I always sensed that to achieve this, these features would need to be developed in the right way in the first place—that they would be hard to retro-fit later.)

These observations are on top of the factors that determine the best way to frame requirements themselves—such as the importance of the first audience for requirements, the customer, being able to understand them. That means writing in the customer's language, free of obscure technical notations, which usually means that requirements must be expressed textually, with judicious use of diagrams whenever they'll help. But I won't cloud this page with a discussion of that subject.

Since no product on the market remotely did what I wanted, I embarked upon developing my own. (They say that the reasonable person adapts themself to the world, and the unreasonable person attempts to adapt the world to themself—so all progress is made by the unreasonable person. In this sense I'm proudly unreasonable.)

Poor analyst with no exciting tools
An analyst envious of the goodies available to a software engineer

The Result
The result is an application that lets you write a requirements specification in a way that resembles a word processor, but which captures as much as possible the meaning inherent in the requirements and in the other information in a specification. The user interface comprises dynamic forms, rich styled text and free-format diagrams—which are all demonstrated in combination in the following screenshot of the editing of one of the requirement patterns from my book:
Extendability pattern screenshot
Editing the extendability requirement pattern. Click here to view it at full size.

The structure and appearance of a requirements specification, of individual requirements and of particular types requirements are completely configurable; terms like schema, pattern and style sheet describe how these are implemented. Any requirement can contain secondary information that is not normally presented in the specification itself. The individual requirements can reside in specification documents, or in a database, or both.

To apply a requirement pattern to a requirement, simply pick the pattern you want from a pop-up menu:
Requirement pattern pop-up menu
Applying a requirement pattern to a requirement.

You can either type in your own requirement definition or pick a template or example to use as a starting point:
Click on requirement template or example
Picking a requirement template or example.

All of the 37 requirement patterns in my book are directly available, along with all of the book's more than 400 templates and examples. These provide a wealth of well thought-out starting points. You can also add more patterns of your own, or modify any of them. Once you have engaged a requirement pattern, it guides the detailed editing of the requirement's content. The result is a requirements specification in XML, with even the detailed contents of individual requirements marked up—in a machine-interpretable form, that is. But a machine-interpretable form is of no use if there is no machine in existence to interpret it—to bring it to life. That is the next stage, which I'm currently working on. This sums up the key benefits to the specifying of requirements that this application aims to provide: guide, provide and bring alive.