13
« on: December 12, 2003, 01:52:19 pm »
Hi Gil,
RM in EA is something we have spent a good deal of time looking into. We have EA and DOORs inhouse, and have looked at DOORS/Analyst, Caliber RM and iCore as possible replacements.
We generated a number of criteria to consider in tool selection and have found none of these tools really meets all criteria.
So, to answer your question - "Can it be done?" I think the answer is yes, especially when considering the #1 requirement management tool in use today is MS-Word, and the #2 is MS-Excel.
The weakest aspect of EA in our search criteria lies in version control, and identification of requirement deltas. Often in the course of developement, a set of requirements undergoes an evolution of revisions. In EA, (at least to my knowledge) there is no way to look at a single requirement and easily query what it may have been a couple of versions ago. Moreover, there is no way to look at a complete set of two requirement baselines and determine which requirements have change in the complete set.
It is true that XMI versions of a requirements package can be stored in a revision control system, but it is not trivial to determine the difference between the two.
EA does have some nice feature though that other tools do not. First and foremost is its price. This should not be overlooked since the cost of placing a DOORS or Caliber RM product on everyone's desk is quite prohibitive. This may hinder accessibility of the requirements to the people within the organization. We are a 30 person organization. Placing DOORS on everyone's desk is around a $75000, whereas placing EA on everyone's desk is only about $3000.
When considering this price difference, you can begin to consider customizing EA onself through Acitive X plugins. With that in mind I am considering hiring an intern to build a requirements delta tool that looks at two configuration managed XMI versions. I can pay this intern for 2-3 years to develop this feature for the price difference.
One of EA's strong points is in traceability. Most requirement tools have traceability features, however, the elements that you are tracing the requirements to must be available within the tool. So for example, if you believe that requirements should be traced to use cases, and your requirements tool does not model use cases very well, then you have to create some sort of placeholder for the element you are tracing it to. This is probably such an inconvenience that it ends up not being done, unless your organization can afford some QA police to ensure that it does.
Since virtually all elements that one would wish to trace to are within EA itself, tracing is much easier. Those like ourself grasping towards SEI CMMI level 3 can appreciate this feature.
Another feature we find very useful from an RM perspective is the GUI mockup capability within EA. If your organization is involved in some way with GUI development, you can mockup a GUI, and link requirements to elements within the GUI. A requirement such as "There shall be a means to control the lights on a vehicle" can be connected through a realization link to the GUI button that performs this function. Requirement management purists will argue that this is more GUI design and should be separate from requirement elicitation, however, our experience has been that the process of GUI design space exploration goes hand in hand with requirement elicitation. Our customers also relate to a GUI mockup much better than a bunch of 'thou shalls'.
Hope that helps.
Rob