Workflow question: UseCases from Documents - how?

[JohnDoe]

Our customer has given us an amount of Word and PDF files with hundreds of pages, which include user stories and requirements. There are NO use case numbers, NO requirements numbers in those documents, just pure text and pictures with a mixed description of technical and business aspects.

Now, we would like to transform those unstructured stories to use cases and requirements and create a list of requirements and backlogitems for our development team.

Question: how is your preferred workflow to extract and convert mass elements from existing word documents into Requirements and Use Cases ?
a) is it possible to mark passages in the document editor and transform them into UseCaes or Requirements ?
b) is it possible to have the document on the left side and a requirements list on the right side of the screen ?
c) is it possible to linke back from requirements and usecases back into the passages of the original 500+ pages documents ?

Thanks in advance !
John

[Uffe]

Hello,


It all depends.

If the Word documents are well structured you can write a script or two, either in Word or in EA, to import the Word contents. This would be one-way.

You can copy the contents of the documents into document artifacts in EA. That way you can at least trace to the documents.

You can drag-and-drop text from Word into EA, and create elements of a type appropriate to the diagram (so create a use case or requirement diagram first). Works out of the box, simple, manual, repetitive, boring, one-way.

If you've got tables in Word you can massage them in Excel and import them into EA using CSV Import. This can be used both ways; once the use cases have been re-exported from EA they've got GUIDs and subsequent re-imports will update them.

The left side / right side thing is kind of achievable using EA's specification manager, which shows you a document-style layout of a hierarchy of (requirement) elements.

As for linking into external documents, provided there are viable link targets in the documents you can create hyperlinks in diagrams as well as "file" links in elements.

You should also check out an add-on product called eaDocX, which may be of use here. I'm not affiliated but I know some of the eaDocX people are on this forum too.

Over to you, Phil.

Cheers,


/Uffe

[qwerty]

No, it's me - and yes: it depends. On SO they'd close this as too broad....

Now, you could drop all stuff in DOORS and move it over to EA. Or you can drag drop text passages from documents onto an EA (requirements) diagram where EA lets you create a requirement (first line taken as title and the rest as comment). The problem is always: how do I link a text to the document and how do I make them uniquely traceable. There are tons of different approaches. My best advice: take a reasonable good consultant and let him work out a scenario for doing that. It will take you a couple of weeks to setup a general approach that will fit. Good luck.

q.

[JohnDoe]

Thanks guys for your first comments.

My main concern is, how to link back from EA model elements (requirements, user cases) to concrete anchors in the document.

I found out, that it is possible to create a link from the document to ea requirements and usecases (mark a passage in the document and add a link to an existing Ea requirement/use case). But I am looking for the other direction.

A requirement / use case in EA should not "fall from the sky", but it should link back to 3.4.4 or 2.4.9 in the document. I would like to click onto that linkback and jump to the correct place in the document.

Is there a way, to place anchors in those documents, so that I can link back from EA elements to the original place ?

Thanks
John

[qwerty]

What I did in those case was to create document artifacts in EA that describe the source files. Using a trace relation from the requirement to that artifact you can name the page/section/what ever. Another way is to used tagged values: drop down for the documents (or using refguid) and another tag for the location in the document.

q.

[JohnDoe]

Another way is to used tagged values: drop down for the documents (or using refguid) and another tag for the location in the document.

q.

Transforming the "Table Of Contents" into a nested structure of artefacts is an excellent idea !

Will give it a try !

Thanks a lot  

[Robert Sheridan]

I have had a similar problem on a number of projects.  The way I tackled it is to transform the source data into a better format and then load it via the API.  I captured a reference to the source document in the EA element using one of the standard fields or a tag value (create a stereotype first).  What I would do if I was doing it again would be to include a hyperlink (files property of an element) to the source document if it was being held in a static location.
There is no easy way to do this and get all the data into EA.  The only compromise is to create place holders in EA with links to the source document.
It is worth doing the import exercise if you have the time and resource as when you break it down and cross reference the elements you will probably find all sorts of interesting discrepancies!

[qwerty]

Creating requirements from customer sources is an often underestimated task. The process of extracting requirements and creating use case scenarios which reflect what the customer meant should be made with the highest effort possible. So supporting the process with automation is a good idea. For one customer we created an import mechanism from DOORS (I was not able to convince them not to use DOORS; at least it takes care of making the requirement ids unique). This was expensive but finally worth the effort.

q.