Documenting requirements for a service-oriented architecture (SOA) application is probably the last thing most...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
programmers want to do, as Paul Raymond, vice president for requirements management tools at Telelogic AB, knows well.
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.
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."