Book a Demo

Author Topic: Requirements Management  (Read 5927 times)

gilv

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Requirements Management
« on: December 11, 2003, 04:25:26 am »
Being relatively new to EA I am not sure if it has a Requirements Management(RM) tool build in or not. If it doesn't it would be extreamly useful if EA could handle RM either directly or though a seamels connection with third party RM tools. If there is a way to do RM in EA I would appreciate some guidance on how to do it.

Thanks

Gil V.

Rob_M

  • EA User
  • **
  • Posts: 58
  • Karma: +0/-0
    • View Profile
Re: Requirements Management
« Reply #1 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

gilv

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: Requirements Management
« Reply #2 on: December 15, 2003, 05:02:37 am »
Rob

Thanks for your post. Now for the next question. How are requirements set in EA. How do you trace them back to a given elemet. Sorry if this question seems to be too basic.

Gil V.

CJ

  • EA User
  • **
  • Posts: 288
  • Karma: +0/-0
    • View Profile
Re: Requirements Management
« Reply #3 on: December 15, 2003, 08:38:28 am »
G'day,

Just so we have a common reference point, I'd say take a look at the help file, specifically:

- Using UML : UML Elements : Other Elements : Requirements;

- Using UML : Requirements Management

And, from Sparx' web site:
http://www.sparxsystems.com.au/Traceability.htm

Hope these help.
Cheers and best regards.

Rob_M

  • EA User
  • **
  • Posts: 58
  • Karma: +0/-0
    • View Profile
Re: Requirements Management
« Reply #4 on: December 15, 2003, 04:15:23 pm »
Sparx has decided to extend the UML with some custom elements like Requirements, Test Cases, GUI Elements,  Issues.

The packages in the project view can be used to create a hierarchical breakdown. Of course that hierarchy can be anything you wish, however, I think most would agree that a breakdown into various subsystems works quite well. This is not so different from hierarchical breakdowns in pure requirements based tools.

Traceability can be achieved by linking the requirement to another object - perhaps a test case, perhaps a use case, perhaps a GUI element, perhaps a software component. This trace can really be any stereotype link (even your own), but we tend to either use a 'trace' stereotype, 'derived' stereotype or a 'realize' stereotype.

The trace can be drawn in diagrams thereby giving a graphical representation, or the trace can be performed simply by linking one object to another from the project browser - the diagram does not have to be present to create a link.

Links between the objects within packages can seen with the relationship matrix view from the view menu. One can place requirements along one side and test cases along the other, then it can be easily determined by observation that all requirments have an associated test case. (Although it would be nice if one could filter on elements that do not have a link -  AFAIK this is not possible.)

Unfortunately, the relationship matrix can only show direct links but not indirect ones. For example, if some use cases are linked to requirements and these requirements are linked to test cases, I can't place use cases on one side of the matrix, and test cases on the other and be able to observe the the indirect links through the requirements. This would be nice to have especially if one is deriving functional requirements from user requirements, and you want to see if all of your user requirements are addressed with test cases.(DOORS can do this indirect tracing.)

That's pretty much in a nutshell how one can use EA to manage requirements, and do tracing to other elements.

Rob