Measuring the Readability of Software Requirement Specifications: An Empirical Study
Howard A. Kanter, Thomas J. Muscarello, Christopher Allen Ralston · 2008
Requirements and specifications documents have become the grounding force of the modern software project. Their importance has been catapulted lately, as companies see them as both instruments that help to capture business rules and direct links to financial success or liability. Good requirements not only educate but they also keep all parties informed, bound and obligated throughout the project life cycle. Poor requirements, or inconsistent elicitation processes, often contribute to the development of undesirable products or to delivered functionality that does not meet the business need. A flawed system production could lead to significant financial exposure and possibly even the loss of significant sums of money to a provider or to the client—or to both. This reality has sparked a united call for IT-specific controls that ensure that requirements are gathered, created, maintained, validated, distributed, stored and versioned consistently by all involved parties. As IT-specific controls have become critical, the role of the IT organization’s compliance executive has increased in importance and in the number of responsibilities to which he/she is assigned. It is the compliance leader’s job to eliminate inconsistent practices, to control potentially reckless power mongers, and to globally discourage fraud and criminal intent. Making control changes sooner rather than later can save a company many legal headaches and internal struggles. If quality analysis and assurance are to be a part of the audit process, then those features of the process must be made an integral part of the system being audited. This requires that everyone involved in the design and implementation must fully understand the requirements of the system. This article looks at the issue of readability of specification documents. It presents an introduction of three common measures of readability. These measures have been applied to real-world test case documents, and the results are documented here, to: • Analyze the ability of the measures to appropriately score the reading levels of the documents • Analyze the agreement of the three measures as to a document’s readability • Compare the readability score of the measure to the qualitative assessment of readability and usability of the documents tested Software Requirements Specification A software requirements specification (SRS) is basically an organization’s understanding (in writing) of a customer’s or potential client’s system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It is a two-way insurance policy that assures that both the client and the organization understand the other’s requirements from a given perspective at a given time. The SRS document states in precise and explicit language the functions and capabilities that a software system (i.e., a software application or an e-commerce web site) must provide, as well as any required constraints by which the system must abide. The SRS document is often referred to as the “parent” document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. 1