Tracing the Source of a Requirement/Feature

[Vonnie]

Hello All - -

I am a new user of EA and I've searched through the forum in case someone has already asked this question but, no luck.  So apologies if this has been posted before (and if this is a somewhat silly question)...

The organization I have just started with is completely new to the concept of tracing requirements (not to mention change control and version control).  They've already made the decision to use EA as their central repository.  I can see why - EA lets everyone use the same repository and see what's happening with the features/requirements.  It's also a darn sight cheaper than having to purchase ReqPro licenses for everyone.  

I'm setting up the initial features/requirements list for them in EA and I've figured out to how to do most things including importing my original spreadsheet from Excel (name, notes, status, complexity, requirements priority, requirement difficulty).

However to adequately trace requirements and get them into some sort of primitive change control process for their requirements, I also want to record the source of the feature and any subsequent change.  For example, the original feature came from Section 12 of the RFP dated 23 November and Bob the Architect requested a change on the 1st Jan.  This is because a) they have over 600 requirements and b) the product will undergo a LOT of change before it's released.  I want to be able to export this type of data so that we can track who's requesting the most number of changes, and how often they are being requested.  The plan is to use this data to help them move towards a more formal change control/management process.

I could just record this data as part of the Details but it's going to make the filtering difficult once I've exported the data.  I've been experimenting with using the Author field to record the source and making sure there's always a link to any supporting documentation.  I also suspect I could perhaps use tagged values but I'm not sure how to go about this.

Any thoughts on a good approach for recording the source of a feature/requirement and the source of the change, or is using the Author field the best way to go about this?

Any help would be appreciated.  Thanks!

[thomaskilian]

Yes. Simply add appropriate Tags to your requirements. You can use a profile to ease the job. You'll find a simple Profile that I published on the EA Usergroup Site (see top of the automation board).

[Vonnie]

Thanks for your help Thomas.  I have grabbed the profile from the user group site and I'll be trying it out over the next few days.  

[colmbyrne]

I have a similar need - but I need to trace each individual item in the system through the five architectural layers (Business, Processes, Information, Applications & Technology)

I'm a newbie, so I'd like to hear if this is something EA does and how.

Take an element like 'Check stock on hand'
I need to see what business requirements it comes from (high level down to detail e.g. Allow users to enter orders, down to  order entry requirements, down to 'check stock on hand'
I need to see the processes for each of these (Process)
I need to see what data is defined for each, transformations, validations etc. (Information)
I need to see what code this creates where used etc. (Application)
I need to see how it is implemented (Technology)

This connection needs to be automated and not added as a document description  - that is what Word does.

We need a high level of traceability for every element so that a) We can tell from looking at the high level of the five architecture layers and drilling down if we have every application for every process for every business requirement up to the major business processes.  i.e. so we don't 'miss' anything and it kinda shows up later in an embarrassing and expensive way.
b) and how we can match the code to the requirements. Remember that cartoon of a swingwith 'how the customer saw it', 'How the developer implemented it...
Any ideas on how EA can do this?





Regards

Colm Byrne

[Bruno.Cossi]

Hi Colm,

not sure if this is what you are looking for, but here goes: <<realize>> relationship is the answer to all your prayers :-)
What do I mean? This: You capture your business requirements. Then you go through the requirements and start building Use Cases, e.g. the "Check stock on hand". As you have built the Use Case as a direct result of the requirements you have gathered, you draw the <<realize>> relationship between the UC and all the requirements it implements. Later on you start describing the UC in detail, you create Classes etc. Once again, you draw the <<realize>> relationship between these and the UC they implement.... etc... etc... etc. This way you can follow the trace from the original requirement through all the elements it has triggered.

Hope this helps!
Bruno