|
|
|
|
Hi David,
Can't help myself. I just have to reply. Had a few glasses of wine and its sunday evening here in Sydney. Most amazing hailstorm earlier...
I have to disagree with your last statement. Use cases by themselves are not really what you need for a functional spec. You need something to tie them all together and give an overview. In my experience, users don't really get or appreciate the value of use cases. I need to give them a process explanation or some form of overview to get them to understand what's going on.
The UML or maybe its RUP, I forget, talks about a functional spec as:
1. Vision document
2. Use cases and use case diagram
3. Supplementary requirements (non-functional)
4. diagrams such as activity and state chart as required.
I think we, as relatively experienced BA's, need to point up and comers at the things that are in current use and acceptance in the industry. I totally agree that there are many ways to define systems all of which are acceptable but people new to the BA world should be using the techniques that will get them a job and a career. Not old style stuff that is dying out e.g. IDEFO. I'm being completely pragmatic here.
Enjoyed this thread immensely and I promise to post no more - unless provoked ;-)
Kimbo |
|
|
|
| |
|
|
|
Hi Kimbo,
Functional Spec? I don't think that is what I am discussing here. I use multiple artifacts in various combinations that are organized in 'containers' as required by methodology or client, like "Requirements" or "Functional Spec" etc. Use Cases are are one artifact I use, most commonly integrated with data models, process models and business rules. I don't use UML artifacts like Class Diagrams, Sequence Diagrams, etc.
IF UML artifacts work for you, great. I just don't agree that BAs, new or experienced, need to use them to be effective. I believe we will both just have to be satisfied to agree to disagree. David Wright |
|
|
|
| |
|
|
|
Well, this thread has provided more information regarding IDEF0 vs. UML (I restricted it to "Use Case" in the initial post due to ignorance) than I ever dreamed of obtaining. Thanks so much for the insight, opinions, and information, you all! Here's what I've gathered thus far:
a) IDEF0 is to UML as FORTRAN is to C#
b) Despite IDEF0's age, it still could be used as a tool if it's the optimal tool for the situation
c) BPMN is an accepted, albeit up-and-coming and in-development, notation for business modeling, but not necessarily the best modeling tool for all jobs.
Now, a question for dww (or anyone else who'd like to provide input):
What are alternatives to "artifacts" such as Class Diagrams and Sequence Diagrams?
TIA, and thanks to you all for engaging in this discussion. |
|
|
|
| |
|
|
|
dwwright99 wrote
Ok, its time we had this discussion on Modern Analyst...
I have not used IDEF either, but I gather its focus is Requirements. UML, on the other hand, was created as a software modeling language, a tool for design. I know, I know, people use it for Requirements, because its popular. Well, I like to use the proper tools, not the popular ones, as the proper tools do a better job.
I also know I will not convince anyone using UML for Requirements that they would be better off not using it, but for people new to our profession, you should know what UML really, and know you can do your job effectively without it.
I have drawn the line in the sand.... Dave Wright, see me at http://www.ittoolbox.com/profiles/davidwright?pv=1 as well...
|
I found particularly attractive of IDEF0 the ability to compartmentalize, very explicitly, inputs, controls, mechanisms, and outputs. I never could seem to find a way to effectively and cogently diagrams these qualities using basic flowcharts. I wanted a way to show the major functionality of a business process (both on part of the LOB and the system) without getting into the decision details. With IDEF0, no decisions are modeled, only the aforementioned qualities. Then, what I was doing was flowing out the business logic of each major function in a regular old flowchart. For instance, I could show the state of current data flowing into a function, show what controls were in place, the 'actors' involved, the mechanism used to perform the function, and finally the state of the data after being affected by the function.
I am ready and willing to move on to UML and BPMN, but even after building a couple of Use Case and Activity models I'm not seeing a tremendous benefit over IDEF0, quite frankly (can't seem to find where to speficy inputs and outputs in Activity diagrams, for example). Of course, I've only been practicing with Use Cases and Activity models for a few days now, so that should definitely be taken into account. |
|
|
|
| |
|
|
|
"What are alternatives to "artifacts" such as Class Diagrams and Sequence Diagrams?"
It depends on what you are using them for now. Some people like to use Class Diagrams for data modeling, but I would use an actual data model, either Entity-Relationship ala Information Engineering, or Chen. The shape of some objects is different on each, but they do the same thing. David Wright |
|
|
|
| |