home

Requirements as a Shared Knowledge Point for all Projects

Recently, I had the pleasure of meeting with EDev's CIO Asif Sharif. During the meeting, Asif gave me a detailed demonstration of their new requirements tool called InteGREAT. I have to admit, I was impressed.

I was impressed by the fact that it supports application of the CRRSP methodology in a way only one other tool has shown the aptitude for. I'd have to say that I have spent the last couple of weeks mulling over each of the tools and just what I liked about each of them. First, I'll have to share with you what I liked about InteGREAT.

More than just having the ability to capture requirements, this tool has the ability to make them easier to write and makes them re-usable as objects within your organizations requirements and rules repository. As Asif put it, they took the knowledge management approach to desgining the tool. This makes it unique, because once you set the specifications for components in your environment, you can re-use these to support any other development project that needs to integrate with that particular existing application.

The other piece that really struck me about it was the fact checker and the ability to define a key words glossary. This is useful not only to support future projects, and provide a degree of logical validation, the glossary can also provide a list of key word that must never appear in requirements, and the ability to create synonyms for packages with multiple names and jargon.

It's definitely worth a look.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

    Sponsored Announcements & Special Offers

view counter

Whitepaper from HP - Why Focus on Requirements Definition Management in the Application Lifecycle?

Increasingly, smart businesses are looking much closer at requirements definition (RD) and requirements management (RM) (sometimes grouped together under the Gartner-coined phrase, requirements definition management (RDM)) to streamline the entire application lifecycle. Why? Because systematic and effective RDM captures software defects earlier in the lifecycle, and it reduces the overall likelihood that defects will be introduced. That’s important. How important? According to one study, the cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirement and design phase. No business wants to be hit with that bill. Now to add to this the growing interest in agile development techniques as a way to deliver higher quality applications and we have an interesting recipe for success.

Download a Free Copy

view counter
© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group