All requirements in EA - doable? Advisable?

[frank]

A few weeks ago I introduced my current client to EA, and we have been using it both for domain modelling and for documenting use cases.

It is our hope at this time that we will be able to use EA as the sole respository of requirements.  I would like to hear from other EA users who have tried this (successfully or not) or who chose not to try this.

What did you try?  What worked?  What challenges did you face?

Under what circumstances would you or would you not advise somebody to try this?

Frank.

[jaimeglz]

Hi Frank,

I hope we can have a more fruitful exchange on this topic, but here are some preliminary comments on requirements in EA.

For most projects, I create a "Project definition and requirements" package as the first package in my EA projects. I'm currently experimenting on having this requirements package as part of a more general "Subject matter area analysis" package, together with the area's org chart package, the processes package and the domain structural model; but this not essential, and is only a matter of how you organize your project tree.

In this project definition and requirements package I create a diagram with the relationships between requirements and goals. I got the idea from Eriksson and Perker's "Business Modeling with UML" (see "Goals", under chapter 3: "Modeling the Business Architecture"), though I add requiriments in addition to these author's quantitative and qualitative goal diagrams.

Why is this useful? 1. Because I get a visual diagram with a model of project goals and requierements; 2. EA can generate a pretty nice RTF from this package. The RTF contains a description of each goal and each general requirement, the org-chart, the process diagram and the domain structural model (formerly called "Logical business model", and that contains the "real world" objects you first discover in the subject area; sort of a pre-structural-class model). You can add, also, a preliminary technical architecture package, which will also be part the RTF (or, if you preffer, of the HTML) doc.

In the diagram, all major requirements and goals are associated with the project's  central goal; for instance: "Design, develop, test and put into production a system for capturing, storing, concentrating and analyzing individual and community data, in order to support decision making by municipal and state authorities". The general requirement to put this systems into production "depends on" adequate testing, which "depends on" building the system, which "depends on" design... and so forth. It is simpler to display these relationships visually that to explain them in the text.

The RTF I generate with these packages (including diagrams) is the heart of the project's scope document, which is the most important specification you need the customer to agree on --in order to mitigate scope creep-- before you embark on further analysis (for instance, before you embark on the use case model) or design. It is also an extremely useful document to reference in a formal contract.

If I model and base-line goals and requirements this way in EA, then I do not need to write and maintain a separate scope document; instead, I have a single place where I introduce new general requirements and goals, objects in the org chart, etc. In other words, I can control project scope (largest single source of project headaches) in a the same project file where analysis and design are contained.

I guess we can add this scope document deliverable to the PUP (Phil's Unified Process, which I propose to be built by EA forum members as our alternative to the proprietary Rational Unified Process; and, believe me, people here in Mexico will get a kick out our process being called PUP).

Jaime Gonzalez

[PhilR]

OK I give up  .  What does PUP mean in Spanish?

On the subject of EA and requirements, I agree with Jaime's comments on the value of having then in EA but find the data entry rather tiresome.  I tend to use MS Word tables to organise requirements becasue all clients have it, its infinately flexible and I know how to use it.  However, I know there are much better tools out there.  I used to use Lotus Agenda (an old DOS program) but street-cred no longer permits.  I have payed about with InfoHandler http://www.mdesoft.com/ but have never used it on a real project.  Of course there is always ReqPro, Doors etc

There is actually an "RQML" (Requirements Markup Language) http://www.raqoon.is/rqml/rqml-spec.htm which I have recently discovered.  This site is definately worth a look.  I can imagine a RQML -> EA import would be really useful.

Back to PUP.  I have wondered about the idea of an "open source" process for sometime.  The OPEN framework (see http://www.donald-firesmith.com) is close to such a thing but it is really more of an extensive framework for people who are clear about their process requirements.

You might find a presentation I did recently interesting http://members.iinet.net.au/~lonsdale/docs/htdalcp.pdf It talks about how to design a process based on a couple of standards OMG's SPEM and ISO 12207.

I second Jaime.  Lets get a lively debate going on this subject with perhaps a view to collaboration.

[andyd]

Hi Guys,
We've recently started a new project which involves a lot of analysis effort.  We have opted to use the Requerments modeling features of EA because:
1) we have an existing set of requirements that need to be imported.  It is useful to include relationship information, i.e. dependencies, between different requirements. e.g. for planning iterations in later stages.
2) realisation links can be made between functional reqs and use cases to aid in tracability and assessing impact when requirements change.
3) The RTF documentation is good to verify completeness with the customer.

I've heard of a tool called EAReqPro that is currently under development.  Maybe it would be a good facility to be able to import and export Reqs between EA and EAReqPro using the markup language that you have mentioned.

Andy.

[Steve_Straley]

Andy,

You can imagine that I have been watching and reading this thread with some interest.

When we first started using EA, we, too, created an ENTIRE set of Requirement Objects in separate packages that eventually paralleled the packages that held the actual USE CASE objects.   From there we started to build the rest of the UML diagrams that would eventually be the base of our product line (at that time).

Because of the DOT COM stuff, a few of us had to go get consulting jobs to keep going and many of us actually went to work for large corporations that had, from our perspective, some archaine <spelling> rules.   For example, for me at GE, I discovered a strong ANTI-EA bias not because of EA's power or pricing but because they felt that the RUP process that they developed paralleling their Six Sigma process should be handled OUTSIDE of the modeling tool.   Maybe it was a case where they didn't like the idea of being financially screwed by Rational and maybe this allowed Visio-Word-Project associations to be allowed in certain branches of the company.  Whatever the reason, we faced this <ahem> point of view repeatedly.

Having said this, that's where a couple of us at World-eIT decide to buck up EA and stick up the competition by for the first set, building EA-ReqPro.  So, having said all of that (and I will certainly say more on it and others later on), let's tell you want we do with regards to EA and Requirements.

EA-ReqPro allows you to add Functional Requirements as you would do any other type of requirement (as is, use case, stakeholder, deployment, vision, critical step, et cetera).   These requirements can be arranged in a template to then generate the "UP-based document".

However, Functional Requirements and USE CASE items can also be DIRECTLY associated (in the case of USE CASE, the picture can be separately associated) to a requirement "entry" in EA-ReqPro.  You then design the document with all the requirements you've accumulated and generate the appropriate document.  You can also do a massive IMPORT of requirements and/or use cases from EA into EAReqPro.

The TO / FROM associations as well as sub-requirements can also be maintained in EA-ReqPro so you can trace through the process.   But you can tie AS IS requirements to Functional Requirements and then to USE CARE requirments and you can create VIEWS of your collection.   Those who have used either Requiste Pro or Cailber will find these options similar if not down-right familiar <evil grin>.

I'm finishing up Chapter 3 of the user manual that talks about the various types of requirements, folder, packages, and other features.   I'll be working on the TO DO, Discussions, Views, and Revision Histories over the weekend.   Anyone can go to our web site and download the EA-ReqPro user manual.  I also suggest if you are interested in the progress of the project to check there often: we'll upload new chapters as we finish them (un-edited for your pleasure <lol>).

Once we release we'll be anxious to follow the tradition of Sparx and give y'all new features as we go along.   Of course, this now begs the question on "release".

Well... we'll make a formal annoucement in a day or so but we are going into FULL BETA on December 2nd, 2002.   Our goal is to release on January 1, 2003.   We'll know more about that later point once we start getting feedback.

If you have ANY questions on EA-ReqPro, just hollar and I'll see if I can answer them.

Thanks again,

Steve

[jaimeglz]

Hi Phil,

As part of our high-level methodological discussion, I would like to clarify a bit what PUP means down here. A very wise street-philosopher discovered that, nothwithstanding their political preferences, Mexicans are divided into two political parties: the PUP, Universal Party of P....s (pretty strong word, which net-etiquette prevents me from printing here, but basically meaning dumb, error-prone person); and the PyP, the party of Presumptous and P...s (that is, the party of those that do not have the humility of recognizing themselves as error prone, but who are so anyway).

(Apologies to those not interested in vulgar humour.)

Great presentation! Thanks for sharing it, Phil.

Jaime

[PhilR]

Jaime,

Mexico sounds remarkably like Australia!  Also thanks for correctly refering to Mexico as being "down there" relative to Australia.  Most maps incorrectly show Australia on the bottom of the globe see http://www.latitudesmapstore.com/graphics/w6.jpg for the correct perspective  

Glad you enjoyed the presentation.

Phil

[Jon Clyne]

Steve

I am very interested in EA-ReqPro and seeing the beta. I also want to keep all my requirements in the tool. Unfortunately I cannot find the World-eIT site to download some more details.

thanks

jon

[PhilR]

My exuberant humour in my last post is due to the fact that I am starting six weeks holiday tomorrow  

However, I plan to find some time to check this board and am interested to hear more responses to Jaime's suggestion that we develop a method via this forum.

According to this article it looks like we need it more than ever

http://www.it-analysis.com/frame.php?name=The+Register&url=%20http%3A%2F%2Fw
ww.theregister.co.uk%2Fcontent%2F7%2F28299.html

Phil

[Steve_Straley]

Jon,

Steve

I am very interested in EA-ReqPro and seeing the beta. I also want to keep all my requirements in the tool. Unfortunately I cannot find the World-eIT site to download some more details.
 

Thanks for the message.   I'm still trying to get some additional fact sheets up on our web site http://www.world-eit.net/ea/index.shtm in the coming days.   I've posted the first 100 pages or so of the beta use manual with screen shots and all.   I've got to finish up on the USE CASE integration with EA this evening and then make the install base before I go to formal BETA.   There is an ALPHA/BETA agreement also available off our web site.   Just go up there and look around and if you have any questions, just fire me off an email or post it here and I'll get back with you ASAP.

Thanks,

Steve

[Steve_Straley]

Phil,

However, I plan to find some time to check this board and am interested to hear more responses to Jaime's suggestion that we develop a method via this forum.
Phil

I would love to see an EUP thing developed and would be more than happy to incorporate it into what we are trying to do.   I'm trying to add the Tollgate stuff for Six Sigma (do a google search for that) as well to blend business plans, project plans, and project measuring guidelines into our current efforts.

Have fun on holiday... we need a long one here for sure!

Cheers,

Steve

[MartinP]

Just my 2 cents....but I've recently started looking at this - we have a client provided requirements document with approx 800 numbered requirements.  Eventually we will track all these in DOORS (another client requirement), but for now I have imported them into EA.

I used the automation feature to run through the client's requirements document (in Word 2000), adding each requirement into the EA repository.  The script is written in Word VBA, and once I've ironed out the final bugs I will happily post further details/code here if anyone is interested.

Anyway, I was somewhat concerned that EA would grind to a halt under the weight of all of these new "objects" in the model, but was pleasantly surprised!  All 800 went in without a problem, and there is no noticeable slow down in the EA project browser when you open up the requirements package in the model.

I should add that the client's requirements are hierarchically structured, going down to about six levels, and that I have organised them in that way when importing to EA.  Each level has a title (which I have represented as a package in the model), with all requirements of that level inside the package.  Sub-packages are used to represent level 2, 3 etc. requirements.

I've found that this works really well - the client's requirements document is literally a single Word table, so it's difficult to see the structure.  Conversely, the EA import makes it very easy to see and navigate through the structure because of the package hierarchy we've used.

Ultimately we will use this to trace the requirements to other elements in our model (e.g. business processes and use cases - probably using the relationship matrix), but the immediate benefit is that the requirements are that much easier to work with (i.e. browsing, searching etc.).

Martin.