Borland CaliberRM

The process of capturing business requirements is still done mostly the old-fashioned way. Business analysts usually sit down with users to discuss the business functions they need. That information is then divided into single requirements and organized by business function.

While requirements gathering tools can improve this process, few can do it as well as Borland's CaliberRM. CaliberRM arrives with a robust server and database engine that can support hundreds of simultaneous users. Borland's tool places annotations into its version control engine to track ongoing changes. CaliberRM's multiuser system does not lock any user from entering requirements in a project. Rather, locks only occur as a requirement is being changed.

CaliberRM can maintain a complete audit trail of all changes made to requirements, including a history of the users who made the changes. Audit trails also alert architects about low-level requirement paths that are impacted by any changes. That's because new low-level functional requirements have to be inserted into the old connections to satisfy new business requirements that are dependent on old ones. In addition to adding new requirements, architects can also update existing requirements.

The software can only take users so far. Since it cannot regulate what parts of the low-level requirements need to be updated when a higher-level change is made, developers have no immediate way of finding out if updates are correct. What's more, CaliberRM does not parse words in the requirement descriptions for traceability, so it cannot determine if new activities added to the functional requirements have been satisfied. In the end, it is up to architects, business analysts and project managers to create effective requirement plans.

Still, CaliberRM is a powerful tool. In addition to flagging suspect changes, it arrives with a specialized word checker that identifies vague words used in describing requirements. The word checker prevents business analysts from entering ambiguous terms. CaliberRM's glossary of ambiguous words can also be augmented.

Because architects must follow up adjustments made by business analysts and developers, CaliberRM's requirement-change mandates are not bidirectional. Simply put, if a user recommends that a low-level requirement needs a change, every requirement in the project that is connected to that change must be checked manually by the architect. Too many changes made to poorly designed low-level requirements can dictate a new review of a system.

If code created from function requirements does not match the original specifications, architects can order new changes to the code or adjust requirements associated with particular low-level function requirements. Architects provide safety buffers when technical roadblocks occur throughout a life cycle of a system.

The impact analysis that can be gleaned from CaliberRM's traceability mechanisms is useful to business analysts and developers. Audit trails, for instance, help analysts determine what implementations have been completed downstream and what impact a new requirement could inflict on work already done.

Once a design is created, code is written and test cases have been approved, developers can use CaliberRM to determine the cost of any changes made in midstream. Based on requirement updates in CaliberRM's traceability feature, developers can work out more accurate timelines and provide better feedback to architects. After a system goes into production, CaliberRM can also be used to capture subsequent versions of applications and provide change-management updates to developers as new versions of applications are written.

Requirements can also be demoted at any stage in the design process. CaliberRM provides an orderly way to postpone requirements between application versions, so developers do not have to make any adjustments in code to circumvent unneeded features in a current version. Architects also can extract features from designs and hold them for future use.

CaliberRM provides an inheritance model that standardizes and manages commonly used requirements. By separating often-used requirements, architects can reuse them at any point in a project. Moreover, these requirements act like templates and can be inherited across multiple projects. This mechanism is extremely powerful because changes made to these requirements can help architects revise multiple systems at once.

To some degree, gathering requirements is still more of an art than a science. Although CaliberRM closes that gap by integrating with Borland's and Microsoft's development products, it does not collect metrics from these products. Since hard metrics that are picked up during the development and implementation cycles are not used, CaliberRM's project-estimation algorithms are based on personal insight from architects. The software uses COCOMO II to predict schedules, but that information is only based on data that comes from inside the tool.

Borland's three-tier channel program provides partners with rebates, MDFs and marketing support. Tier one and tier two partners receive in-person sales training on a quarterly basis, while tier three members rely on material from the company's sales portal. Borland offers channel account managers and inside sales representatives to support partners, including system engineers, whenever they are needed. CaliberRM's price starts at $2,000 per user license, but Borland declined to disclose the margin resellers can make on selling the product.