End-to-end modeling

[ChrisF]

I'm not new to UML but new to EA. After I capture my requirements, what is "a" logical (not "the" logical, since there may be more than one) of modeling the system to meet the requirements. Do you start with use cases, then class diagrams, then...? I realize this may be iterative too. What's your process?

[son-of-sargasso]

1. Capture requirements
2. Confirm the budget
3. Release half the requirements
4. Start modeling the solution

OK, trite.  But.  If it were me, I'd really be starting along those lines.  Since I'm a big fan of usecases and UC estimation I tend to take a quick look at those requirements in the corral, herd em up, cut em out, brand em as essential, good-stuff and hahahaha!  Build a broad picture of the high level use case definitions, figure out what benefit is really possible to deliver in a really rational time frame, evolve and cost those use cases, develop a domain model,  poison the coffee in the architecture department, sort out the business object model, drown the steering committee,  gather some really interesting people together who really know how the company works i.e. the ones that actually do the work and start figuring out what really is necessary to deliver, strangle the project manager and finally hire a really good test manager (Hello!) to prove that whatever you deliver is actually compliant with the requirements.  
Anything else? Oh, yeah!  Did I tell you what to do with auditors?

bruce
p.s. I'm not kidding, that is MY process.

[Geert Bellekens]

Chris,

There is something I don't get, you say "After I gather my requirement" then you start with the Use Cases?
Aren't the usecases themselves meant to capture (and validate) the requirements?

Here the process is: (in theory, some steps are sometimes often skipped)

• Model the businessprocess
• Model the Business Information Model
• Model the usecases
• Model services on the system interfaces
• Model the GUI (if applicable)
• Model the System Information Model
• Model the implementation of the services down to the lowest level operations
• Write lots and lots of pseudocode in the lowest level operations  :-/
• Start programming (= translating the pseudocode into C#)

Geert

[NeilS]

Chris

The following link may be of help http://community.sparxsystems.com/whitepapers/Requirements%20Management%20with%20Enterprise%20Architect/Requirements_Management_in_Enterprise_Architect.pdf

As Geert states there are a few preliminary steps to take before you get to use cases - which UML ignores.  Closest I've seen diagramming wise is sysml - where the ea diagrams for requirements appear to have come from.  You must abstract your requirements from your use cases - otherwise they tend to get buried very fast.

Then I'd follow Bruce's steps to the letter...

Neil

[fwoolz]

Neil et. al.,

Actually, EA had Requirements elements and diagrams years before SysML was a gleam in OMG's eye... in fact, I did a good part of my Master's thesis back in aught-3 using EA, requirements diagrams and class diagrams...

Having said all that, I would start out with SysML requirements diagrams to capture basic text requirements (call it the system "brainstorming" phase). Use cases would come during the process of requirements synthesis, where the requirements are organized into meaningful units of behavior (dare I say "functions"?). Use cases could then be mapped to collaborations, which would be realized by instances of the various classes as they are identified. Alternatively, SysML blocks could be used instead of collaborations.

The class architecture could be developed in parallel with the requirements synthesis process, as some objects will no doubt fall out of the use case synthesis process.

Of course, as you stated, the process is iterative, and there is no single "right way" to do it. I have even committed heresy on occasion and mostly bypassed the use case step, going instead straight to activity diagrams to sketch out the scenarios, but this only works with relatively small systems where you can keep the basic functional organization in your head.

Good luck!

[paddler]

 Wooo..tricky

 This should be a straightforward process but - due to constraints in time and budget - the ability to model the business is not always possible. Therefore, you may have to take it from scratch..... The first thing I like to do is develop a "Systems Analysis" estimate in Excel that lays out all your assumptions as well as rough sizings / functional area. Present this to your PM and have THEM prioritize ( with the client's help) what areas to analyze first

 Assuming you have requirements that were handed to you I would (personally)

 1. Talk to the Project Manager and find out what the deadline is to have "developer ready" artifacts

1a> Validate with the developers exactly what these artifacts are?? Is it ONLY use cases or do they expect more stuff? Where is the line between you and the coders?

1b. UPDATE YOUR SIZING ACCORDINGLY

2. validate there is money to actually BUILD something (again from the PM)

3. Have an open session with real end users to validate which of the requirements are the most important ( what is their "wish list")

3a> Now that you have their "optimal list" , ask them what they are willing to sacrifice if "push comes to shove" budget-wise

3b> Assuming this is a Rebuild ( and not a new system) ask them what functionality must not be lost!!!

4. Now that you have prioritized requirements, it'll be important to figure out what the use  cases should be. In geert's example ( and my current situation) I am using business process models to identify means of automation. These points in the process model will now link to a System Use Case

 If this is not possible, ask the PM and/or steering committee what their functionality priorities are whilst highlighting to them what the users brought up.

5. Now that you ahve Management and User priorities, start scratching out User Interface prototypes. You can do this by looking at an OLD system / observing users OR start from scratch.

6. In looking at the UIs, you will find users can perform functions (add, delete, modifies) which should be captured in System Use Cases.

7. Develop those Use Cases which are in the "areas of priority" and link any user requirements to them ( so none get lost).

8. Develop any supporting artifacts that the coders indicated that they needed.

9. Keep everyone in the loop on progress and risks

 Have fun!
 

p.s. bruce is not far off the mark in several of his observations!!!

[paddler]

...sorry, one last thing.,...

 this is iteractive so the notes above apply to "Priority 1 Requirements". After the development there should be something for the user to play with...take their feedback and any "Pri 2 Requirements" and start over....The shorter the iterations the better!!

 And get testers! Lots of em