Lost in translation

By Tina Gasperson

October 15, 2008 —

Requirements and specifications are essential elements of any project that involves software development and testing. But they spring from very different worlds, and every time a customer approaches a developer for an application, those realms are poised to collide.

Requirements “define necessary objectives” on the part of the end user, according to technical essayist Derek Sisson. Requirements let everyone know what the program is supposed to do—critical information for developers and testers. Author Cem Kaner wrote in “Testing Computer Software” that “a requirement is an objective that must be met. Planners cast most requirements in functional terms, leaving design and implementation details to the developers.”

The requirements world is a fluid, somewhat fuzzy space where users know what they want but struggle to express it clearly enough for developers and testers to produce applications that meet the users' needs. Contrast that with the rigidly structured world of specifications, whose inhabitants converse in tech speak, execute tasks in narrowly defined ways and deal in specialized knowledge that outsiders find difficult to grasp.

“Specifications provide formalization and detail around a specific requirement,” observed Bola Rotibi, an analyst with MWD Advisors. But important details can be lost in translation from the customer’s concept to the developer’s spec.

“The customer doesn’t know all the technology required; they just have a need, which they express in the language you and I communicate in,” Rotibi said. Because the customer doesn’t know all the technical aspects of creating an application that meets the need, requirements are often “too loose and vague,” she said. “But there are a lot of conditional Boolean expressions that need to be met should something fail.”

Globalization complicates the process. “Words are imprecise, especially from an engineering perspective,” said Wayne Hom, CTO of Augmentum, a contract software development provider with offices in California and China. “Even among native English speakers, different people can interpret the same set of words in different ways. Expand this to a global scope of international English, and the problems are worse.”

Users and developers think differently, Hom said, and the level of detailed thought required to develop software is “quite daunting” to most users.

Users sometimes neglect to tell developers about “nonfunctional requirements,” said Mark Eshelby, director of product management at software giant Compuware. An example is “performance at peak usage times; people forget to state this up front. Then development goes down a path not knowing a key need: The app must scale for thousands of users.”

Bj Rollison, testing architect for Microsoft, said the problem boils down to design. “I think [there’s a difference] between what the customer wanted and what they actually get—basically fundamental design flaws,” Rollison said. “I suspect this problem exists for a variety of reasons, but one leading cause may be that many companies overload developers and testers with the added responsibility—and burden—of pretending to understand the customer’s needs as well as the marketing people or program managers [do].

“To paraphrase Bill Gates, it is important for testers and developers to have exposure to customers, but it should be different from the program manager’s exposure.”

Into the breach
The gaps in communication and understanding can result in frustration on both sides of the fence. Users get frustrated because their requirements are not being met, or the requirements they communicated really aren’t the requirements, or the act of meeting the requirements produced unexpected and unpleasant side effects. User dissatisfaction in turn lengthens the development cycle and raises costs, since developers have to write and rewrite code, and testers have to scrap test specifications and start from scratch to comply with a moving target.

So how can developers and customers bridge the divide between requirements and specifications? It takes open communication, sharing of information and plain old accountability. “If a customer says, ‘I would like to do X,’ that’s fine, as long as they are aware of the potential risks and what needs to be in place,” said MWD’s Rotibi.

Rollison said Microsoft relies on program managers to translate customer needs into reasonably unambiguous requirements and build prototypes early in the design phase. “Relying on developers to design a software program would be similar to relying on an engine mechanic to design a car,” Rollison said. “Engine mechanics could probably design a car with some really cool bells and whistles, but the only truly satisfied customers would be other engine mechanics.”

Testers shouldn’t be expected to identify design problems after implementation, either. “Too costly,” Rollison said. “It is probably similar to a sculptor casting a bronze statue of a man and then realizing that pieces are missing and there are too many fingers and the facial features resemble those of a woman. The sculptor can braze on the extra pieces, cut off the excess fingers and possibly reshape the facial features with a hammer. But in the end, you have weaknesses in the casting, and the ultimate result is really not what was intended.”

Imad Mouline, CTO of Web performance monitoring solution provider Gomez, said the definitions are changing for those who work with specifications and requirements. “The application is no longer what the software developer puts together in the lab; the application is what the user sees. And what the user sees and what the developer does are two very different things.”

The move to cloud computing is driving end-user expectations to new highs, Mouline said. “Know your customer and what your user is going to see. Look at the application from the outside as early in the cycle as possible. Things perform differently with client-side processing; are you taking that into account when doing performance testing? The response time of an application is influenced more by the client-side rendering time than by the network or server.”

Thomas Christel, vice president of marketing at Yooplus, a developer of Web 2.0 platforms for enterprise social networking, advises appointing a project leader for each project to bridge the gap between requirements and specifications. “Create a project charter that outlines everyone’s roles and responsibilities. Pay close attention to scope and scope creep. Yes, you will obtain new ideas, features and functions along the way, but capture them for version 2.0. Don't let your project grow on its own.”

Agility to change
To increase customer satisfaction, many developers are moving to agile software development methodologies. Agile’s manifesto states that it values responding to change over following a plan, and that developers should welcome changing requirements, even late in the development cycle. Agile development counts on iterative production that delivers working software frequently.

“We need to develop agile systems that have some ability to deal with change,” said Ron Schmelzer, senior analyst at ZapThink. “If you design a system so rigid that you have to get it right the first time, it’s guaranteed to fail. Developers would much rather the requirements be well defined and not change. It would make life so much easier. But that’s just not the reality.

“The best way to act is incrementally, meaning that you design bits; you don’t design a huge system. You plan to go back and revise the things you’ve designed, in an agile way, to reduce the penalty of being wrong. The cost of each change has to be low. We have to be judicious. The dollars we spend can’t just be ‘pay and pray.’ We have to be cost-justified in this environment.”

In the case of agile development, focusing early on mismatches between requirements and specifications is a good thing, said Augmentum’s Hom. “Accept that development is iterative. As development proceeds, it is imperative to have fairly frequent software builds for users to validate that progress is happening as expected. One reason is to enhance confidence. But also there is benefit to finding any misinterpretations or implementation deviations in smaller chunks, so the corrections are manageable, instead of at the end in the ‘big bang’ final user acceptance release."

For Hom, simulation is the way to bridge the gap between requirements and specifications. “If you look at most development, requirements are viewed as an input into the development process. What we need to do is simulate, as early as possible, the software experience for the users.”

That “virtual reality” experience of the software before it is ready lets users refine their conceptualization of requirements and provide feedback to QA so that all the “bad news is vetted out early,” Hom said. Making the user experience the driving process of software development rather than a support process is the key to creating the simulations quickly and cost-effectively, he said.

“For example, one can quickly simulate the software experience by capturing a definition of user profiles, constructing user-perspective use cases, constructing paper-and-pencil-based prototypes of those use cases, and presenting a storyboard animation of those use cases to let users quickly see what the software would look like and feel like. There is even an area of tools focus now called requirements definition tools; these visually define the simulation. While tools are nice for more polished simulations, the real value is the change in mindset for the development process framework, to be focused on user [perceptions] as the driving factor."

Hom said that with simulation use cases, the customer can now participate in the software creation process. “The software system can be user validated and accepted before any software is ever created. And doing it early in the process takes the place of the unpleasant discussion at the user acceptance test that usually goes something like this: User: ‘This feature isn’t working the way I thought it would when I wrote the requirements.’ Developer: ‘But we don’t have any time left in the schedule to make any changes, and the architecture doesn't support that.’ ”

Compuware’s Eshelby also recommends a collaborative environment. “You do this by helping everyone to sing from the same sheet,” he said. “You’re not asking QA to weigh in and say, ‘I don't think the button should be here,’ but you're giving them an opportunity to say, ‘Did you think through all the details?’ If QA is a part of the communication beforehand, they can help figure that out.”

Bringing in QA at the beginning of the project also lets the team get a jump on testing. “They now have extra time to generate test plans for validating the requirements,” Eshelby said, so that tests are ready and available earlier in the development life cycle.

Yooplus’ Christel echoed Eshelby’s sentiment on teamwork. “Include your customer in the entire process, including requirements gathering, focus groups and beta testing. Include your IT project manager. Create an open collaboration, with project transparency.”

Using a social enterprise platform with shared calendars and files, milestones, project blogs, and wikis can make collaboration easier, Christel said.

Technology writer Tina Gasperson focuses on enterprise software and applications development. Read her blog at www.gasperson.com.

Related Search Term(s): agile development, software development, testing & troubleshooting

Share this link: http://www.sdtimes.com/link/32967

News Briefs: July 15, 2008 Enea is named to the board of CP-TA, Teradata introduces a new version of its data warehousing tool and SOA Software upgraded its Repository Manager to accommodate its Policy Manager software.

Rhodes framework brings agile to mobile development Tools for test-driven development and the ability to write interfaces in HTML facilitate the agile methodology

Third-party tools showcased at Professional Developers Conference ComponentOne has a new development kit for the iPhone and the iPod Touch, while Infragistics created a version of NetAdvantage for Silverlight. Also, Developer Express and Microsoft announced a joint code-quality effort for C#.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST