Book a Demo

Author Topic: Track changes in requirements  (Read 4663 times)

Zatak

  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Track changes in requirements
« on: May 13, 2006, 09:48:36 am »
I have a Use case [User Login] which has some activity diagrams like [Database Login] and [Windows Authorisation].

Now after some months the business wants changes to the [Database Login] activity diagram.
How do I track this change in activity diagram.

This change can be in an activity diagram or a requirement etc. How can this be tracked?

Any suggestions welcome.

thomaskilian

  • Guest
Re: Track changes in requirements
« Reply #1 on: May 14, 2006, 11:14:09 am »
Depends on what purpose this change shall be tracked. So I can only guess some answers:
- Make a note and place it inside the diagram. Write in plain words: Change - blabla. Color the note to make it obvious. This is recommended to make people aware of a recent change. The note would normally vanish after some time.
- Use souce code control to track changes over time. You will be able to go back to a former version at any time.
- Keep a "History" package. You can make use of version numbers or dates. The disadvantage would be that you have many instances of the same thing and might get confused.

Maybe you could indicate what's the real purpose of this tracking.

jaimeglz

  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Re: Track changes in requirements
« Reply #2 on: May 15, 2006, 06:42:26 am »
Hi Zatak,

Here is another possible solution.

Under the package that contains your use cases, or even as a high-level package in your model, you can create a package called "Model evolution", or whatever seems appropriate. In that package, you can create a diagram for your particular package or use case, where you will relate the old package (or the old use case, activity, or whatever...) with the new one. UML has the <<trace>> dependency relationship stereotype, which is defined by Rumbaugh as "a dependency that indicates a historical relationship between two elements...".

Keep the old elements in the "Model evolution" package, and place the new behaviour elements in your use case (or whatever) model. You can now create a matrix with the dependencies between the old and the new, and keep a very neat history of your model evolution.

Hope this helps,

Jaime