It's all about the answers!

Ask a question

Versioning requirement documents


Todd Chambery (461) | asked Apr 06 '07, 10:39 a.m.
Hi all,

I posted this accidentally as a reply, so posting again...

I'm interested in how Jazz handles document requirements. It seems that
Work Items should be the core of a requirements strategy (ie each
requirement exists exposed instead of contained in an external
document), with supporting documents attached to the relevant work item.
Most the clients I've worked with, however, use Word/Excel docs to
capture their requirements, and it doesn't appear that attachments are
versioned in the same way as artifacts checked in to the repository.

Also, the Add Attachment opened a file dialog (instead of a Workspace
dialog) suggesting attachments would be expected to live outside Jazz
source control.

I am I misusing this feature?

Thanks,

Todd

3 answers



permanent link
Randy Hudson (216243) | answered Apr 07 '07, 9:44 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Also, the Add Attachment opened a file dialog (instead of a Workspace
dialog) suggesting attachments would be expected to live outside Jazz
source control.

It seems like the requirements for requirements can go from one extreme to
the other.

"Type 0"
At the short end of the spectrum, nothing more than the "description"
paragraph of a Work Item is needed. There is no requirement captured
anywhere else outside of the work item. You could even fake some things
using workitem linking, tagging, composition, etc.

"Type 1"
Increasing in complexity (and flexibility), you have "real" requirements,
separate from the work items (at which point the description field of the
work item is redundant?). But at the end of the day, it's similar to a work
item. They are not in SCM and are not versionable as you've pointed out.
Content is limited to styled text and whatever attachments you want to
create, which you then have to download to view. This is what Jazz supports.

"Type 2"
In my opinion, you're talking about the next level of
complexity/flexibility. Some document is in "source" control, and at some
point, somehow, a work item refers to it as its "requirement".
There are real advantages to working with documents in an eclipse workspace,
and shared via SCM. In some cases, you have to do it anyways because you're
using some Eclipse-based tool to author the requirement. But this is a
significant increase in complexity, similar to the difference between using
just "Description", and using Requirements. And just like graduating from 0
to 1, biting off 2 should be optional.

BTW, I'm new to Jazz and haven't had much experience with formal
requirements (be it Jazz or otherwise), but I enjoy pretending otherwise.

permanent link
Todd Chambery (461) | answered Apr 11 '07, 7:41 a.m.
Randy Hudson wrote:
Also, the Add Attachment opened a file dialog (instead of a Workspace
dialog) suggesting attachments would be expected to live outside Jazz
source control.

It seems like the requirements for requirements can go from one extreme to
the other.

"Type 0"
At the short end of the spectrum, nothing more than the "description"
paragraph of a Work Item is needed. There is no requirement captured
anywhere else outside of the work item. You could even fake some things
using workitem linking, tagging, composition, etc.

"Type 1"
Increasing in complexity (and flexibility), you have "real" requirements,
separate from the work items (at which point the description field of the
work item is redundant?). But at the end of the day, it's similar to a work
item. They are not in SCM and are not versionable as you've pointed out.
Content is limited to styled text and whatever attachments you want to
create, which you then have to download to view. This is what Jazz supports.

"Type 2"
In my opinion, you're talking about the next level of
complexity/flexibility. Some document is in "source" control, and at some
point, somehow, a work item refers to it as its "requirement".
There are real advantages to working with documents in an eclipse workspace,
and shared via SCM. In some cases, you have to do it anyways because you're
using some Eclipse-based tool to author the requirement. But this is a
significant increase in complexity, similar to the difference between using
just "Description", and using Requirements. And just like graduating from 0
to 1, biting off 2 should be optional.

BTW, I'm new to Jazz and haven't had much experience with formal
requirements (be it Jazz or otherwise), but I enjoy pretending otherwise.



I see there's a thread called "More Information Required..." that
highlights most of what I'd like to see eventually supported in Jazz.

Regarding the Type 2 reqs, I've recently come to use (and appreciate)
ReqPro, and I think it would a huge value add for Jazz if it could
incorporate some of ReqPro's traceability from requirements down to the
machinery. I don't think there's a project management solution
currently out there that can provide this soup-to-nuts functionality.

My experience with many clients is that business users write up their
requirements in semi-isolation, then throw them over the wall to molder
in some Sharepoint document dump. Development frequently uncovers gaps
in requirements, and much effort is required (if anything is done at
all) to correct these gaps. If Jazz could "enforce" some kind of
dialogue between the technical components and business requirements that
would be project management nirvana.

Todd

permanent link
Stefan Stern (4062128) | answered May 19 '07, 4:58 a.m.
My experience with many clients is that business users write up their
requirements in semi-isolation, then throw them over the wall to molder
in some Sharepoint document dump. Development frequently uncovers gaps
in requirements, and much effort is required (if anything is done at
all) to correct these gaps.

Whow! Are we working for the same company? That sounds very familiar!

;-)

Stefan

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.