The requirements translation challenge --- can you meet it?

by Guest Contributor | Oct 23, 2006 8:41:00 PM

Tags: Tools & Techniques, Development tools, Guest Contributor, software, business problem, software development

Takeaway: Two thirds of all software projects undertaken this year will fail to meet user expectations. Roughly half of the rework on a typical project can be attributed to missing or misunderstood requirements. Thousands of dollars of productivity is lost to wasted effort caused by bad requirements. This article gives you insight on how to meet the challenges of requirements translation and reduce those costs.

By Dr. Joe Marasco

Two thirds of all software projects undertaken this year will fail to meet user expectations (Donald Firesmith, The Business Case for Requirements Engineering, Software Engineering Institute, 2003) � they will either be late, over budget, delivered wanting in some crucial dimension, or cancelled outright. Rework is a key factor in this equation. Creeping up on projects late in the cycle and often unexpectedly, rework burns cash (accounting for approximately 30-40 percent of all software development project budgets according to Dean Leffingwell, Managing Software Requirements, Addison-Wesley, 2003) and kills project schedules by pushing out delivery dates.

Furthermore, roughly half of the rework on a typical project can be attributed to missing or misunderstood requirements. The numbers are brutal � on a software development project that eventually "comes in" at a million dollars, somewhere between $150,000 and $200,000 is lost to wasted effort caused by bad requirements. And here's the one that will keep top executives up at night: requirements errors cost U.S. companies $30 billion a year in total (National Institute of Standards & Technology, U.S. Department of Commerce, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002). Why is it so hard to get requirements right?

Lost in Translation

We use software to solve business problems. But depending on where you are in the chain of project stakeholders starting with the business person and ending with the programmer, you have a different perspective on what, specifically, needs to be done. Table A illustrates the dilemma.

Table A

	Problem Statement
VP of Finance	"We need to do our monthly close in four days instead of six."
Financial Analyst	"We need to streamline our processes, which involve dependencies on various software systems."
Software Architect	"Our database design is out of date, causing us unnecessary delays."
Programmer Tester	"The Online Banking Application needs to be completely rewritten."

Ultimately, all these people are trying to solve the same problem, but each of them sees it differently, and each of them describes it in a dialect that they feel comfortable with. Bridging these dialects is the issue we constantly face: when we do the translation accurately, we succeed. When requirements are unclear, ambiguous or incomplete, we fail.

The players

There are at least four distinct layers and players in the software development process:

The Domain Expert: This is the person who owns the business problem and is often funding the software system. His or her job is to solve the business problem, and software is but one piece of the puzzle. Domain experts speak "business" and often make assumptions about the domain. Much of their knowledge is implicit.
The Business Analyst: This person understands "business" and "requirements," and it is his or her job to translate the business problem into a requirements specification that is handed off to IT. Sometimes this person may reside on the business side of the house, and sometimes this person resides in IT. Sometimes the business analyst is entirely missing from the process. Business analysts speak more explicit English and tend to be more detail oriented. Sometimes they may understand a modeling language, but more often not.
The Software Architect: This is the other side of the business/IT boundary. This person understands "systems" and "software." It is his or her job to maintain architectural integrity across multiple systems, and to ensure long-term stability and maintainability of the application. Software architects translate requirements into architectural "models" and thence to a design for the specific application. The language here is English, although with outsourcing, other natural languages may come into play. This person is conversant in modeling languages and is also proficient in several programming languages.
The Software Engineer (a.k.a. The Programmer) and the Testers:These are the people who actually write and test the code. These tasks are increasingly being accomplished offshore via outsourcing, so the presumption of English is not always a good one. They take designs and write and test code; there may be a very high degree of variability in experience and competency in this cohort. These folks speak "code," that is, computer programming languages, and may understand models. Their distinguishing characteristic is that things need to be "binary" for them � they cannot program things that are not explicitly specified.

We can summarize the situation with Table B.

Table B

	Domain Expert	Business Analyst	Software Architect	Programmer Tester
Native Language	English	English	English/ Other	Increasingly Other
Expertise	Business Problem	Systems Problem	Software Architecture	Writing and Testing Code
Everyday Language	Business English	Systems English	Modeling Language	C++, C#, Java

What could possibly go wrong?

In a perfect world, all of the players are "present and accounted for," competent, and able to bridge the "dialect gaps" from step to step. But even in this perfect world, we find that bridging more than one gap � say from the domain expert to the software architect � is very difficult. Each player has "language facility" with his peers, and perhaps one level up and one level down, but no more. So if, for example, either the business analyst or the software architect is missing or incompetent, the entire chain of communication breaks down.

Another weakness has to do with the critical role played by the two middle players, and the tools they use. The 1990's might be characterized as the "decade of the architect," during which the software architect came into his own as a recognized and important part of the process. Architecture was understood, finally, to be the backbone of the system, and architects started to get the respect and concomitant power and control they needed to do a good job. As this notion began to take hold, tools appeared that enabled them to do their jobs better. In particular, modeling tools such as Rational Rose became part of the process of developing better large software systems and products.

On the other hand, the business analyst has yet to be "brought into the loop" in the same way. In fact, tools are only now just appearing to help the business analyst take his rightful place in the software development process.

Use cases vs. models?

Business analysts have successfully borrowed from their system analyst brethren and adopted use cases � i.e., scenarios that describe the required behavior of systems. Written in English (or some other natural language), use cases specify the actors, functions, and objects that participate in the execution of various paths through the software system, and essentially provide a roadmap that is intended to help developers understand what they need to build.

At the same time, models have become a staple for software architects and their organizations. The good news is that models can be generated from use cases, or at least take use cases as their starting point, subject to the addition of more system-related details. Different "views" of the model provide insight for everyone on the project: some views are more relevant to upstream people, while other views are of more interest to the downstream, programmer types.

This reality, however, poses a bit of a dilemma: domain experts and business analysts favor English uses cases, whereas software architects and programmers prefer models and views. One group tends to work in text, and the other in diagrams, and translating the English language use cases into models creates an opportunity for errors to creep in. It is also often difficult to find just the right person to do the translation. The translator has to have a good grasp of modeling languages and tools, and sometimes that means a lack of facility with some of the nuances of the English language use cases.

As a result, a relatively small number of use cases are actually translated into models, for reasons of cost, convenience, and time. This is a shame, because the translation of textual use cases into models, properly done, is an excellent way to bridge the "dialect gaps" that are inherent in the requirements process.

Bridging the gaps

In a recent article ("The Case for Modeling" Karl E. Weigers, Sept. 1, 2006, Dr. Dobbs Journal, www.requirementsdevelopment.com) on requirements modeling, author Karl. E. Weigers asserts that different views of requirements are essential to improving their quality. "If you create only one view of the requirements, you must believe it. You have no other choice," he writes. "If you create multiple views, though, you can compare them to look for disconnects that reveal errors or different interpretations."

The following Figure A is perhaps worth a thousand words:

Figure A

Gaps

So how do we bridge the gaps? There are several key principles that organizations must embrace to improve requirements quality:

1. Build a culture of collaboration and clarity around requirements. Automation can play an important role in this respect, serving as a "neutral" and consistent translator of words into visuals. The ability to automatically generate visual models from English use cases can help bring all stakeholders into the process � from the domain expert on through to the software engineer � while still allowing them to work in a language that is most comfortable to each. Visual representations, for example, can help business analysts "see" errors and inconsistencies that are difficult to spot in text form. At the same time, automation relieves software engineers of having to slog through hundreds of pages of textual requirements. Linking text to the visual is key here. Traditionally, text-only specifications have opened the door to ambiguity and miscommunication, while common types of visual models are so technical that they leave business stakeholders out in the cold. This needs to change.

2. Understand that the requirements process is iterative. In fact, Andrew Stellman and Jennifer Greene, the authors of Applied Software Project Management had this to say in a recent article: "The development of the software requirements specification should be the most iterative part of the entire project. This is the point where the behavior of the software to be developed is at its most malleable - it has only been described in words, and has not yet been realized in design, architecture, code, test plans, or any other work product. The goal of this script is to ensure that as many defects are found as possible, because each defect missed at this stage will be much more costly to detect and fix later on in the project." Yet, since the artifacts produced by the requirements development phase do not represent very compelling evidence of real progress, this is all too often a process that gets rushed or overlooked. Taking the time to "get it right" � by addressing translation issues and involving all stakeholders � should not be viewed as an unwelcome delay, but rather as a necessary part of development that will ultimately offer the best chance for improving time-to-market. At the same time, improving collaboration through automation will ensure a less laborious, more efficient process overall.

3. Place increased accountability on validating requirements post-elicitation. In many cases, the most costly errors are missing requirements � those that are overlooked during elicitation. When validating requirements, care needs to be taken by the entire business and development team to make sure that not only "what's there" is correct, but that everything is "there" that needs to be. When something is inadvertently left out of the requirements specification and discovered later, the risk is that the omitted task or part of the system is a major piece of work, not just a simple fix. A good example would be omitting the requirement to "fail gracefully" subject to an error condition: often fulfilling this requirement involves fundamental changes to the architecture of the system, and can involve significant additional cost and effort.

Conclusion

Use cases are a valuable vehicle for reducing costly requirements errors. Yet validating use cases � that is, ensuring that all the stakeholders agree on the correctness of the use case � is a difficult problem, made worse by the "dialect translation" issue. Models can facilitate use case validation, as various views allow stakeholders to better understand the flow and scope of what they are trying to build.

Improved communication across the cultural and language divide between business users and technologists allows organizations to focus their resources on the areas of greatest corporate relevance and payback. Solving the requirements translation challenge is an important component of an efficient process needed to accomplish this, enabling businesses to be more adaptive and responsive to competitive pressures and changing market needs. Automation has a key role to play in meeting this goal, as does an approach to requirements that respects its iterative nature and fosters accountability.

Lessons learned:

Bridging the gap between text-based and visual requirements representations is key to improving quality and reducing errors
Requirements creation and validation is an iterative process where multiple stakeholders must have a voice
Accountability means that requirements validation must include asking the question "Have we got them all?" and not just asking "Have we got them right?"

About the Author

A 35-year industry veteran, Dr. Joe Marasco has been involved in nearly every aspect of software creation, from product development and sales, to marketing and operations. His recent book, The Software Development Edge: Essays on Managing Successful Projects, published in 2005 by Addison-Wesley, delivers "in the trenches" expertise on managing software projects. Throughout his career, Dr. Marasco has been cognizant of the importance of improving requirements quality early in the development process, and his current leadership role as CEO of Ravenflow is focused on revolutionizing the way that software requirements and business processes are developed and validated.