 | Level: Intermediate Randy Masciana, Testing Consultant
13 Sep 2005
Updated 10 Nov 2005 Author Randy Masciana proposes an xml-based approach to address a gap that can occur between software requirements and the code written to satisfy those requirements. Introduction
A gap often exists between software requirements and the code written to satisfy those requirements. One cause of this gap is the translation process that occurs between the written prose of the use cases and the semantics of the software programming language. One possible solution lies in bridging the gap by using XML formatted Structured Requirements in IBM® Rational® RequisitePro® that can also be used as configuration rules for the application.:
The software requirements - software code gap
The Gartner Group has reported that about 25% of all software projects fail outright, and that another 60% result in sub-standard products. One of the main reasons found for these failures is that requirements are not completely gathered, or are not accurately represented to software development personnel. Although requirements management tools such as RequisitePro are being used, to date the value of such tools has often been realized downstream of the process that interprets the requirements into written form (for example, utilizing traceability back to features, and forward to test cases). Unfortunately, by this time the most critical damage has already been done. Consider the following scenario: The use cases so adroitly managed by IBM Rational RequisitePro sometimes contain incomplete or inaccurate content. These use cases are then transformed into a sequence of increasingly detailed software models with tools like IBM Rational Rose or XDE, and perhaps also become more technically described in detailed software design specification documents managed by RequisitePro. Eventually, the use cases, models and specs are realized in software code. Then, during testing, the results of the code are diligently validated against the flawed requirements. Bugs are reported and fixed, and the undesirable code is worked until it is ready to be presented to the unwary user. Finally, the project is added as a data point in the 85% project failure statistic calculation.
While it is good to maintain a certain level of comfort whenever possible in life, there are times when the soothing short-term reassurance and confidence that comes with repeating the same wrong processes should be sacrificed for long-term success. Such is the case for changing the well-established pattern for translating requirements into code, as it is painfully detailed above. What is proposed here is a new method to improve the creation of documented requirements – a method that makes greater use of technology, and thereby reduces the amount of error that has historically resulted from this process. But remember – this is a new method, so hold on to your seats!
Structured Requirements: A bridge across the gap
Suppose that a single document set could be used as both the canvas on which requirements were painted and the template from which software code was configured. The advantage would be the elimination of a large portion of the process of translating requirements into code. If the content of this document set were simple enough, then users would be able to, more completely than in the past, validate requirements prior to the transformation of requirements into code by the development team. Requirements would have to be structured enough that they would be of value in the configuration of application code. Of course, nonfunctional requirements would not benefit from this Structured Requirements approach, but the more functional requirements that could be documented in this structured way, the greater the chance for project success.
One type of document set that springs to mind immediately as a natural candidate for implementing Structured Requirements is XML. The hierarchical nature of XML would allow complex relationships to be defined both in natural language requirements and in code. If functional requirements could be defined in XML documents, then these documents could clearly serve as application configuration rule sets, because most modern programming languages include direct support of XML documents.
Of course, users might not want to be asked to review XML documents, so the actual Structured Requirements documents should be in outline format. But if you are using IBM Rational RequisitePro to manage requirements, then it would be a simple matter to export the user-approved requirements documents to Microsoft® Word 2003, where an XML schema could be applied to transform the Structured Requirements into more technical terms, prior to allowing the requirements to proceed any further down the design and development path.
Some considerations when applying Structured Requirements in practice
The most looming question when applying Structured Requirements is: Can functional requirements be communicated in outline form (so that they can be more accurately reviewed by the user and then transformed into XML using an XML schema)? Throughout modern times, complex projects related to story-telling have been visualized in outline format prior to their construction. One need only look at how books, movies, computer games, newspaper stories, and magazine articles are designed for examples. If use cases are all about telling stories related to required functionality, then such stories should be easily and accurately describable in outline format.
To some degree, system analysts would need to become savvy about which types of constructs make sense as units of an application configuration. However, the XML schema that is applied to the completed Structured Requirements could be tailored such that the outline formatted requirements are more readable by users, and the transformed XML formatted requirements are more useful for design and development individuals. Some of the elements of the use case story-telling are related to non-functional requirements and so the system analyst would have to be cognizant of the need to separate such requirements from the Structured Requirements that are used for design and development.
There are some Word 2003 considerations in creating Structured Requirements. All that is required is to first write the requirements in an outline format, say in IBM Rational RequisitePro (see Figure 1). Next, save the use case document as a Word 2003 document from RequisitePro. Then, open the saved document in Word 2003 (do this outside of Requisite Pro, as Word 2003 is not supported in RequisitePro). You can perform any desired massaging of the document in Word 2003, but a word of caution applies: don’t change any of the actual Structured Requirements content that will be used directly by your application code (or the value of this whole approach will be diminished).
Figure 1. Documenting Structured Requirements in IBM Rational RequisitePro
By default, Word 2003 will use the standard Word XML schema, WordML, to format your requirements. However, you can also wait until the project is further into the Elaboration or Construction phases and then attach an application-specific schema, which by that time would have been created by developers to parse the XML formatted requirements as rule code sets (Word 2003 calls all schemas other than WordML "custom schemas"). Your custom application schema can be constructed to look at only certain portions of your XML formatted Structured Requirements. You can attach any number of custom schemas to each of your Structured Requirements documents, so that different parts of your application could derive from different XML rule sets. Word 2003 can also show you what the documents look like, after any selected schemas are applied to them.
When you are satisfied that the document(s) represent the requirements that you want to feed to the application code, save the Word 2003 document as an XML file.
Alternate flow: XML formatted Structured Requirements
If your organization does not have access to Word 2003 or Office Professional 2003, then you could try utilizing the often proclaimed virtue of XML that states that XML is "human-readable." That is, with only a few minutes of familiarization, users should be comfortable with reviewing actual XML in your use case documents. In this case, you could eliminate the following steps:
- Saving the use case document as a Word 2003 document
- Applying your application-specific schema
- Saving the document as XML
Structured Requirements bridge complete
Once you have created Structured Requirements in IBM Rational RequisitePro and you have selected and translated the desired portions of your Structured Requirements outline (using the XML schema(s) for your application), construction of the XML bridge between requirements and application code will be complete! This bridge will serve to improve the quality of application code, by enabling the code to connect directly with the use case requirements. This will eliminate a great many of the interpretation problems that exist with so many projects today. The requirements will be more concisely written and thus the user approval process of the requirements will be more accurate.
You can open an express lane on the quality bridge by using the very same XML, derived from Structured Requirements, to also drive the testing of the application. This process is described in my developerWorks article, Using IBM Rational Functional Tester 6.1 to implement a reusable testing framework (see the Resources section, below).
Resources Learn
Get products and technologies
Discuss
About the author | | | Randy Masciana is a testing consultant currently engaged with the Bureau of Laboratories at the Florida State Department of Health under a U.S. Government grant from the Centers for Disease Control. Randy is also president of three organizations: Big Iron Software, Inc., Non-Figurative Analysis, and Hyperbolic Games. He specializes in analysis, as well as the creation of custom software solutions (in English, UML, VBA, VB.NET, C#.NET, Java, and Cobol) for complex problems across a number of industrial and government domains. He can be reached by e-mail. |
Rate this page
| |
