News Stay informed about the latest enterprise technology news and product updates.

Developer requirements for agile SOA projects

SOA applications done with agile-style programming techniques still need requirements management, but they do not need the heavy documentation that traditional software development required, says Paul Raymond of Telelogic.

Documenting requirements for a service-oriented architecture (SOA) application is probably the last thing most programmers want to do, as Paul Raymond, vice president for requirements management tools at Telelogic AB, knows well.

The idea is to do requirements on an as-needed basis.
Paul Raymond
VP for Requirements Management ToolsTelelogic AB

Writing a requirements document is the equivalent of getting your teeth cleaned. It's something you need to do, but it's not something you want to do. Although requirements management defines his career, Raymond understands that on development teams there is often very little passion for it. For coders working on applications where the emphasis is on agility and speed, doing requirements can seem like a boat anchor.

"Sometimes it's just considered to be a check in the box," Raymond says. "Have we written the requirements spec? Yes. Now we can get on with the engineering. And so the two diverge. You end up with a situation where you've got a nice requirements doc, but the end product doesn't match it."

Since, ideally, business users would have major input into requirements for any SOA application, this check box practice is counterproductive. Raymond believes that for SOA applications, especially those developed for mid-range businesses, there is no requirement for the voluminous documentation that might be needed by a defense contractor or aerospace firm. But, he argues that they still need something.

"People who are developing services, it's all about getting to market quickly," he said. "These are exactly the kinds of projects being developed faster and faster, but you still need to keep some kind of control of what's going on in the project. In terms of agile development, people sometimes think that means no process. Of course, that's not correct. What it simply means is the process is much lighter."

So Raymond has focused on developing lighter requirements management tools.

Telelogic for years has offered a client/server based requirements management product called DOORS, used to do heavy lifting documentation for major projects at customers including Airbus, BMW Boeing, DaimlerChrysler, Deutsche Bank, Ericsson, General Electric, General Motors, Lockheed Martin, Motorola, NEC, Philips, Samsung, Siemens and Sprint.

But Raymond said the company realized that this product was not what agile programmers needed to fast-track projects. So Telelogic developers set out to design a lightweight requirements management product. The result is this month's release of DOORS Fastrak, which is Web-based with Rich Interent Application (RIA) features and is offered in a Software as a Service (SaaS) as well as the more traditional package model.

For more information
Check out our SOA Learning Guide

Telelogic looks to bring modeling to SOA

Noting that a typical agile project might only have a limited number of requirements to begin with, Raymond said the product was designed to provide developers with a Web page where initial requirements can be entered in minutes, so they can quickly move on to coding the application.

"If you are going to be doing agile development, you're probably only going to collect a few requirements on day one," he said. "Then those requirements will evolve as you develop and you learn more about what you need to know. That's usually how agile development works. You can enter 10 or 20 requirements in a matter of minutes. You just put in your requirements, tag them with attributes and they get managed through the system based on those attributes."

To bridge the gaps between business users and development teams and what's required and what's developed, the tool provides business users with their own Web page to transparently view what's happening with the project, make sure it's on track and make changes where necessary, Raymond said.

Rather than bog a project down trying to include every conceivable requirement, he said, "The idea is to do requirements on an as-needed basis."

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.