In this document we focus our attention on the reasons why the current requirements capture techniques are insufficient to guarantee full use of requirements documents through the development life cycle. For a brief summary of these reasons, as well as for a very rapid overview of Useme, please refer to the Overview of Useme. For more in depth information, take a look at the Introduction document or, for a visual exploration of the tool, peruse the Visual Tour of Useme.
The effort of standardising the software development process across all teams and industries through the use of UML and automated tools for the various aspects of software development has brought a much needed improvement in the professionality, reliability and reproducibility of software development.
However we still experience major insufficiencies in the current technologies for the capture and subsequent management of requirements, which are fraught with a number of shortcomings and deficiencies.
After the initial capture effort, which provides the input to the design and implementation of the application of interest, all too frequently we have seen requirements documentation being abandoned due to the difficulty of keeping it consistent with both the natural evolution of the software and with the changes imposed by mutating requirements. We believe this to be an unnecessary waste of time and resources, as up to date requirements documentation is an extremely useful long term source of documentation for the application being built, as well as an essential input to all testing efforts on the application.
We see the essential problems with requirements management today as being the following ones.
The normally affordable requirements related tools existing today ultimately rely on the definition of a requirements document via a free form text editor. This inevitably leads to two pernicious consequences:
inconsistencies between documents produced by different team members;
document incorrectness or invalidity with respect to the underlying technologies being utilised (for example, use case specification documents with alternate flows that are missing their points of origin or return).
The result of this is lack of clarity in the requirements, confusion among the various roles in the development team and therefore danger of code defects and/or unnecessary waste of time.
Even if development teams utilise document templates to aid document standardisation, the lack of a well defined and enforceable structure in the textual documents makes this task of standardisation quite difficult, especially in large teams in which the rate ofchange of analysts and requirements specifiers on a given project is high.
Most organisations that are committed to UML as a common language for team communication often experience a gap between the UML requirements model and the textual specification documents. The model describes requirements as simple elements (for example use cases and actors) and the structural relationships between such elements (for example use case inclusion). The specification documents describe the details of each specific requirement but frequently loose the connectivity of the model due to the difficulty of capturing structural relationship within a textual context. The two types of artifacts are therefore mismatched and inconsistent, creating an obstacle instead of easing the transformation of the requirements model into the application.
Even in cases where at least the most important of the relationships are captured in the textual documentation, the task of maintaining them by hand through requirements evolution and change is daunting for the amount of time and effort that is needed. The result is a set of documents with obsolete and often misleadng information.
Except for very expensive, high end requirements management tools, most other automated systems are single user, making it difficult for team members to work on requirements documents as a community and for all the project stakeholders in general to share the information expressed in these documents. When requirements are managed by hand, the problem is of course exacerbated, with different versions of one and the same document being used as the working copy.
All requirements management tools available today are standalone applications, with their own user interfaces and their own utilisation rules and procedures, with the well known shortcomings of a non integrated development environment.
All these issues can be overcome by the use of an appropriately designed automation tool for requirements management. Useme is, we believe, that tool.
Ultimately, all requirements management professionals aim towards the creation of high quality requirements. The definition of “high quality” has been beautifully summarised by the IEEE recommended practices for software requirements (IEEE Recommended Practices for Software Requirements Specifications, IEEE Computer Society, New York 1998), through their so called quality measures. In order to be of high quality, a requirements document must be:
Achieving these qualities with the current tools alone is, as all practitioners well know, a daunting task in the best of circumstances. Useme does not guarantee that your requirements documents are accurate in representing a client's needs, but it is certainly invaluable in guiding you towards documents that satisfy the largest part of the qualities listed above.
We have presented a brief description of our reasons for conceiving and building Useme. If and when you decide to give Useme a try, we hope you will agree with us that this tool fills the gap we have identified and contributes to your productivity and your excellence.