Storing Use Case Specifications in RM or in CCM?
This question is not a technical one, but more one about the purposes of the different applications.
We will implement the Jazz tooling in our company and I am investigating how we can employ the tools in our existing processes.
We are developing using RUP and therefore we write use case specifications to capture the functional requirements.
While we are writing and changing the use case specifications, we need to apply version control to them, just as with the rest of our documentation.
What should be the appropriate place to store the use case specifications?
I was first opting for the RM app. But this app doesn't seem very appropriate for this role. Word documents can be uploaded, but afterwards they can't be edited from the RM app nor can the content of Word documents be pasted in a RM artifact. (Pasting as plain text or typing over all the existing use cases is not an option in our company). And it seems that there is no real version control over the content of the requirements artifacts.
Besides that, the names given to the applications (my compliments for this idea by the way!) suggests strongly the connection with the life cycle management processes. So the place for use case specifications would rather be in configuration management then in requirements management.
So my idea is that, assuming your company is practizing RUP, you store the needs, features, supplementary specifications, use cases (but only the names, not the specifation content!), business rules, terms, etc in RM and establish trace links between them, for traceability.
Then you store your use case specifications, as well as other documentation, in CCM, so that you can apply version control to them.
C/ALM linking can be used to establish the traceability between your requirement artifacts in RM and the use case specification documents in CCM.
Does this suggestion match with the purposes that the developers of the Jazz tooling had in mind?
We will implement the Jazz tooling in our company and I am investigating how we can employ the tools in our existing processes.
We are developing using RUP and therefore we write use case specifications to capture the functional requirements.
While we are writing and changing the use case specifications, we need to apply version control to them, just as with the rest of our documentation.
What should be the appropriate place to store the use case specifications?
I was first opting for the RM app. But this app doesn't seem very appropriate for this role. Word documents can be uploaded, but afterwards they can't be edited from the RM app nor can the content of Word documents be pasted in a RM artifact. (Pasting as plain text or typing over all the existing use cases is not an option in our company). And it seems that there is no real version control over the content of the requirements artifacts.
Besides that, the names given to the applications (my compliments for this idea by the way!) suggests strongly the connection with the life cycle management processes. So the place for use case specifications would rather be in configuration management then in requirements management.
So my idea is that, assuming your company is practizing RUP, you store the needs, features, supplementary specifications, use cases (but only the names, not the specifation content!), business rules, terms, etc in RM and establish trace links between them, for traceability.
Then you store your use case specifications, as well as other documentation, in CCM, so that you can apply version control to them.
C/ALM linking can be used to establish the traceability between your requirement artifacts in RM and the use case specification documents in CCM.
Does this suggestion match with the purposes that the developers of the Jazz tooling had in mind?
5 answers
There is more than one way to do most things, but from the point of view of the team developing the RM capabilities, use case specifications are key requirements artifacts, and it's our aim that you and others would find that they are most effectively managed using the Jazz RM capability.
I think it would help to distinguish between the capabilities available today in beta 2 versus what we plan to deliver in the future. You can check out the RRC/Requirements Professional plans on jazz.net for a glimpse into this.
Let me make some vision-oriented comments here.
Use case specifications (and other requirements artifacts) have a lifecycle that typically includes the following:
* numerous drafts
* lots of reviews to gather input/feedback/validation
* agreement and approval (formal or informal) for a particular release or iteration
* relating use case flows to specific requirements targeted for delivery in specific iterations/releases
* elaboration over time and over iterations/releases (e.g. basic flow elaborated in iteration 1, various alternate flows in later iterations; modification of the use case specification in later projects) this process involves all the above steps repeated many times
There are a number of ways to make teams more productive and effective in managing the use case specification lifecycle, for example:
A. Improve the initial collaboration around the creation, review and approval of the use case specification.
B. Make it easier to relate the use case to other requirements and target specific versions of the use case specification and specific flows to iterations and releases
C. Make it easier to visualize these relationships and report on them (including development and test status against their fulfillment)
We are addressing (A) through the capabilities you see in Requirements Composer: use case diagram tied to use case specification, group commenting, review and approval process. Imagine these capabilities combined with the RM capabilities in beta 2. The use of MS Word has both advantages and disadvantages; we'd like to embrace but then help teams go beyond MS Word, e.g, collaborating around new versions on the server, or referring to specific, approved versions of the use case specification, which bring me to ...
(B) Versioning: consider how you can use snapshots and collections in RRC to define a set of artifacts for a specific iteration or releaseat specific versions of those artifacts
And we are addressing (C) visualization/reporting in the near term through dashboards, common reporting, and OSLC-style linking, rich hovers, etc.
It's possible you might decide that at this point in time, given capabilities delivered, that storing use case specifications as MS Word docs in using the RTC CCM capability makes the most sense for your teams, and you can live with the resulting limitations. But I hope over time we will deliver capabilities that persuade you otherwise.
Daniel
I think it would help to distinguish between the capabilities available today in beta 2 versus what we plan to deliver in the future. You can check out the RRC/Requirements Professional plans on jazz.net for a glimpse into this.
Let me make some vision-oriented comments here.
Use case specifications (and other requirements artifacts) have a lifecycle that typically includes the following:
* numerous drafts
* lots of reviews to gather input/feedback/validation
* agreement and approval (formal or informal) for a particular release or iteration
* relating use case flows to specific requirements targeted for delivery in specific iterations/releases
* elaboration over time and over iterations/releases (e.g. basic flow elaborated in iteration 1, various alternate flows in later iterations; modification of the use case specification in later projects) this process involves all the above steps repeated many times
There are a number of ways to make teams more productive and effective in managing the use case specification lifecycle, for example:
A. Improve the initial collaboration around the creation, review and approval of the use case specification.
B. Make it easier to relate the use case to other requirements and target specific versions of the use case specification and specific flows to iterations and releases
C. Make it easier to visualize these relationships and report on them (including development and test status against their fulfillment)
We are addressing (A) through the capabilities you see in Requirements Composer: use case diagram tied to use case specification, group commenting, review and approval process. Imagine these capabilities combined with the RM capabilities in beta 2. The use of MS Word has both advantages and disadvantages; we'd like to embrace but then help teams go beyond MS Word, e.g, collaborating around new versions on the server, or referring to specific, approved versions of the use case specification, which bring me to ...
(B) Versioning: consider how you can use snapshots and collections in RRC to define a set of artifacts for a specific iteration or release
And we are addressing (C) visualization/reporting in the near term through dashboards, common reporting, and OSLC-style linking, rich hovers, etc.
It's possible you might decide that at this point in time, given capabilities delivered, that storing use case specifications as MS Word docs in using the RTC CCM capability makes the most sense for your teams, and you can live with the resulting limitations. But I hope over time we will deliver capabilities that persuade you otherwise.
Daniel
Hello Daniel,
I like very much to hear your vision about the application of Jazz like you did here above.
I see a great potential in the Jazz tools for our organization. Last week I had to make a traceability scheme as a preparation for our next CMMI assessment, and it is practically like designing the CALM architecture. The Jazz tools will provide a great support for this.
I have another question about vision of the future form of the Jazz tooling.
In RUP the step following the creating or refining the Use Case Specifications (requirements discipline) is creating or refining the Use Case Realizations (Analysis & Design discipline).
Use Case Realizations consist of Class Diagrams in combination with Interaction Diagrams (being Sequence or Collaboration Diagrams).
These diagrams we make at the moment with the tool Rational Software Modeller. We then save the diagrams as gif or jpeg files and include them in Word documents :?
As you probably feel, my dream would be that a RSM-like modelling tool could be integrated in the Jazz platform, permitting to create Class and Interaction diagrams inside a Jazz repository so that they can be linked to and included in other artifacts in the same or another Jazz repository.
Is there a vision about this as well?
I like very much to hear your vision about the application of Jazz like you did here above.
I see a great potential in the Jazz tools for our organization. Last week I had to make a traceability scheme as a preparation for our next CMMI assessment, and it is practically like designing the CALM architecture. The Jazz tools will provide a great support for this.
I have another question about vision of the future form of the Jazz tooling.
In RUP the step following the creating or refining the Use Case Specifications (requirements discipline) is creating or refining the Use Case Realizations (Analysis & Design discipline).
Use Case Realizations consist of Class Diagrams in combination with Interaction Diagrams (being Sequence or Collaboration Diagrams).
These diagrams we make at the moment with the tool Rational Software Modeller. We then save the diagrams as gif or jpeg files and include them in Word documents :?
As you probably feel, my dream would be that a RSM-like modelling tool could be integrated in the Jazz platform, permitting to create Class and Interaction diagrams inside a Jazz repository so that they can be linked to and included in other artifacts in the same or another Jazz repository.
Is there a vision about this as well?
http://jazz.net/forums/viewtopic.php?p=43510#43510
Yes. I suggest you look at Architecture Collaboration capability beta 3 for IBM Rational Software Architect.
This will give you an early look at how we envision you may be able to use models created in RSM/RSA, collaborate around them, link them with other artifacts, report on them, etc. using the Jazz approach to collaboration and linking.
As you probably feel, my dream would be that a RSM-like modelling tool could be integrated in the Jazz platform, permitting to create Class and Interaction diagrams inside a Jazz repository so that they can be linked to and included in other artifacts in the same or another Jazz repository.
Is there a vision about this as well?
Yes. I suggest you look at Architecture Collaboration capability beta 3 for IBM Rational Software Architect.
This will give you an early look at how we envision you may be able to use models created in RSM/RSA, collaborate around them, link them with other artifacts, report on them, etc. using the Jazz approach to collaboration and linking.