I’m going to take a little departure from building Road Maps to begin a new series How to build better systems. Applied Enterprise Architecture means a little hands-on practical application is always a good way to keep our knives sharp and skills current. We will begin with the specification. I define a Systems requirements specification (SRS) as a collection of desired requirements and characteristics for a proposed software system design. This includes Business Requirements (commonly known as a BRD), non-functional requirements, and core architectural deliverables. The collection is intended to describe the behavior of a system to be developed. The collection should include a set of use cases that describe interactions the users will have with the software. The specification should be accompanied by a set of architectural guidelines for the project team (see Nick Malik’s fine post “A practical set of EA deliverables” for good examples) to follow as first principals. This is true (in slightly different variants) no matter what Systems Development Life Cycle (for example Waterfall, Agile, Spiral, and others, even Test Driven Development) we are planning to use to manage the development effort. Getting this right means can reduce defects and errors early and remains the single most effective action we can take to improve our project outcomes.
We probably can all agree that defining functional and non-functional requirements are the most critical elements of a project’s success or failure. In fact searching Google for the simple search term “defining good requirements” returns over ninety-one (91) million hits! Yet in spite of all the good advice and fine writing available we have all seen inaccurate, incomplete, and poorly written requirements specifications. We all know this will result in poor quality products, wasted resources, higher costs, dissatisfied customers, and late project completion. The cost to remediate these defects in development projects is staggering. I’m going to try to keep this very professional and objective. I can’t help thinking this is probably a very good place to rant about the dismal state of affairs many of us find ourselves in today. We spend an enormous amount of energy to test executable code, yet the tests themselves are constructed on faulty assumptions or ambiguous specifications (you figure it out) that can’t be tested in the first place. This is a common and all too familiar challenge I see everywhere in my practice. And I mean everywhere.
How bad is it?
More than 31% of all projects will be cancelled before completion. 53% of projects will take more time to complete and will cost twice as of their original estimates. Overall, the success rate for IT projects is less than 30%. Using generally accepted quantitative findings fixing requirements defects (errors) can eat up to roughly one third of most software project budgets. For example, requirements errors have been found to consume 28% to 42.5% of total software development cost (Hooks and Farry, 2001). Rework can consume up to 40–50 percent of project budgets (Boehm and Basili). In fact, faulty requirements form the root cause for 75–85 percent of rework (Leffingwell). And early detection is critical. The cost to a 1 million dollar budget at the low end of scale can be more than $250,000. Finding and fixing defects outside the SDLC phase where it originates has its own cost (up to 400 times as much to remedy – Reifer, 2007). It might cost $250 to $1000 to find and fix a requirements defect during the requirements phase. If uncovered when the product is in production repairing it can cost $100,000 to $400,000 in this example. As Willie Sutton once said he robbed banks “because that’s where the money is”. And so it is here where the real opportunity lies (and has been for some time) to capture and preserve real business value. Reducing specification requirements errors is the single most effective action we can take to improve project outcomes.
The four biggest causes of failed projects are:
- incomplete, missing, or poorly written requirements,
- lack of user input and buy-in,
- failure to define clear objectives, and
- scope creep.
All four of these toot causes result from poor requirements and specifications practices. It is clear that current requirement management processes and tools are simply not working.
This is how we have always performed the work, why change the way we do this now? Crafting requirements specifications can seem like a daunting task. And how can the author tell the difference between a good requirement and a bad one? How can we ensure clear unambiguous system requirements are crafted on a consistent and repeatable basis? While many new business analysts are looking for templates it is rare a template provides enough rigor and information to help write better system requirements. Templates can help you get started, but they don’t really tell you what a good requirement looks like. Understanding what represents good content in the requirement is a little more difficult (ex; Specific, Measurable, Achievable, Realistic, and Timely). Even more difficult is preventing text ambiguity from occurring in the document(s) due to the presence of ‘non-actionable’, vague or imprecise language.
There is a better way
I have stumbled across a better way to tackle this challenge. The approach uses process improvements, a few new roles, and Natural Language Processing (NLP) technology to identify defects early in the development life cycle before they become expensive to correct.
The approach I propose is inexpensive and mitigates much of the risk associated with defects and errors early in the development life cycle. We already have many fine tools to manage the traditional requirements practice. What I intend to share with you is very different and until very recently widely unknown to many in the development community. The method works (IIBA’s Business Analysis Body of Knowledge) across all five types of requirements:
- Business Requirements
- Stakeholder Requirements
- Functional Requirements
- Nonfunctional Requirements, and
- Transition Requirements
The immediate benefit reduces costly rework (or downstream change requests) and the opportunity to build the right product the first time. The more significant value is uncovering and reducing requirements defects early. This is the single most effective action (have I said this before?) we can take to improve our project outcomes. In the coming weeks I will address a method to tackle this challenge that is inexpensive and uncovers many of the defects and errors early in the development cycle. I will share with you how to evaluate the following key elements:
- Structural Completeness/Alignment (%)
- Text Ambiguity and Context (Quality %)
- Section Quantity/Size
- Volatility (Change over time)
- Lexicon (Frequency Distribution across documents) Discovery
- Plain Language (Readability) Word Complexity Density – complex words
I will also illustrate how use Natural Language Processing (NLP) and text engineering tools to automate and identify defects. One of the most powerful features of this method is the immediate feedback provided to authors and designers early in the development life cycle. They can then take action to correct the defects uncovered while they are still relatively inexpensive to remedy. The end result is improved specifications to drive better products. So if you are program manager, analyst, developer, or architect stay tuned for an approach that just may change the way you think about your writing. And improve your delivery of quality systems.