Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  General  Use Case Extension Points and Alternative Flow
Previous Previous
 
Next Next
New Post 12/22/2011 2:16 PM
User is offline Kimbo
450 posts
5th Level Poster


Re: Use Case Extension Points and Alternative Flow 

 Tony,

So when you're running a workshop, what types of information are you looking to elicit. For instance do you start with say the purchase order and follow it through its life? How do you go about it. I'm curious and I expect others are as well.

Kimbo

 
New Post 12/23/2011 5:17 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Case Extension Points and Alternative Flow 

Kimbo:

I prefer an "interview the data" (i.e., follow the flow of data, such as  PO info), focusing on the unchanging business essentials, and proceeding in as top down a fashion as possible.  Ideally, this would be to first create a Context Diagram; but, as it is basically impossible to find people who can readily give me adequate info at this of abstraction, I start with lower level DFD's (that are still higher in abstraction than like BPMN diagrams.).   I later summarize upwards to create a Context Diagram to verify scope.

In doing the above, proper partitioning is needed for effective decomposition.  And effective decomposition is needed to handle complexity.

Important:  The real challenge in requirements analysis is not to just gather standalone requirements.  It is to discover the essential interrelationships (i.e., the data flows) between the requirements.  Only data flow diagrams enforce such analysis. If the BA wants an upfront large group brainstorming session to discover initial standalone requirements, that is OK.  Just be keenly aware that, ultimately,  it is all about understanding the interrelationships - not just stand alone requirements.

 I sometimes elicite requirements and their interrelationships working  with one or a few users, sometimes with a larger audience.   Workshops have their limitations.  For example:  Especially for the first couple of iterations, the diagrams are a bloody mess.  (It is real important to feel comfortable with such - alot of BA's are not - they need order as soon as possible.)   I do not walk through a bloody big picture in front of a larger group.  It is too hard to maintain control.   

Typically, by maintaining control, I mean ensuring that the conversation does not get technical - thereby taking the focus off of the business essentials.  It also means controlling to ensure that the discussions do not get too detailed. It is easy to, as Yourdon used to say "drown in an ocean of detail."  (Tech and detail requirements are addressed at the appropriate time - in later phases of analysis.)

In documenting detailed process/functional requirements, I transition from DFD's to sequence based techniques (BPMN like techniques).

Key things are  to maintain a high level of initiative to "keep the door open" with the end users to do multiple iterations, and to be pragmatic as to whether a group elicitation session or a smaller session is appropriate.   Typically, the way to go for the situation at hand seems fairly evident.  

Tony

 
New Post 12/28/2011 1:27 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: Use Case Extension Points and Alternative Flow 
Modified By Kimbo  on 12/28/2011 4:34:14 AM)

 Hi Tony,

Interesting to read that you actually draw diagrams in workshops. I've found that it doesn't work for me. I prefer to mostly ask questions and right key points up on a white board as I go. Might put a simple "happy path" diagram on the board but don't generally show alternates or error paths. I always try to keep workshop numbers to below 10 and preferably around 5. Any more than 10 is very hard to get consensus as you say. Can work sometimes though.

Did I understand what you said correctly? Do you put your diagrams on the board as you're going? I know a lot of people have success with this technique.

Note for the audience out there about BPMN. It can be as high level as you want - at an abstract business / company level - or as low level as you want - technical definition that generates code out the back end (if you use a tool). Very flexible and expressive. I'm about to start a 6 month project modelling the business processes for a small to medium size organisation here in Australia. I'll be using BPMN. My high level diagram will be very simple. Might even look a bit like a context diagram.

Agree with your comment about not just gathering stand alone requirements btw. Another common problem I see is BA specs with beautifully defined functions but without any indication of how they work together. This often gets perpetuated in testing which means you have a system with lots of perfectly working bits that doesn't actually work as a system. 

Another question for you Tony. Can you please explain this comment:

"In documenting detailed process/functional requirements, I transition from DFD's to sequence based techniques (BPMN like techniques)."

Not sure why you think DFD's are superior because BPMN is sequence based. I've modelled businesses based on DFD's and on BPMN/use cases. I think they are just a different way of looking at the same thing. Genuine question mate. You make this point a lot in your posts and I've never understood it.

Kimbo

 
New Post 12/28/2011 7:44 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Case Extension Points and Alternative Flow 

Kimbo:

Yes I have created DFD's on a whiteboard in front of an audience: but I need to be really quick to be effective.   Look at the Yourdon DFD technique.  Ever wonder why the technique uses circles and curved lines?   Answer:  This is for quick rapid prototyping - circles and curved lines are the quickest to draw.  Also, I just focus on main flows, not, as you mention, alternative  and error paths.  Qucikly draw (only) the essentials , erase for mistakes, quckly redraw - rapid iterations.  If I miss stuff, no problem, I approach individuals later.  The key is that creating a diagram that focuses on the essential (i.e., the  data flows) - even with errors - is going to get one alot further along than diagramming without a focus on the essentials.

To illustrate my point about systems being non-sequential, look at the BABOK 2.0.    A system can be manual, automated, or combo there of.   And a  requirements spec specifies the behavior of a system.   The BABOK 2.0 is in itself a requirements spec!   It specifies the behavior of a system of one or more BA's performing tasks to create a requirements spec.  It is a requirments spec on the processes to be used to create  requirements specs.

Read what the BABOK 2.0 says about the conventions used in its creation:  There is no defined sequence to the BA tasks; any task/process  can kick-off at any time, provided it has it's required inputs.   This is exactly what I am talking about:  The non-sequential nature of systems (especially true at higher levels of abstraction). 

Key point:  The system that the BABOK models is not all that complex.    The non-sequentiality of systems becomes much bigger issue with larger scale system.   It is not possible to use a sequence-based technique such as BPMN with such.

Now, in order to handle the non-sequential nature of a system of BA's performing tasks, the BABOK utilizes non-integrated input/process/output diagrams.    This is very problematic as none of the diagrams tie together well.  It is impossible to systematically understand what the BABOK is saying.   The should have used INTEGRATED input/process/output diagrams (i.e., data flow diagrams.)

At the detail level, I use a sequence based technique to document tasks/processes.  Such is necessary to capture logical rules.  I decompose my DFDs down to a point where processes can be described using a sequence based technique that will fit on a single page or so of paper.  Note that each bubble on a data flow diagram can be considered as a mini context diagram.   A DFD can be viewed as a set of mini context diagrams integrated together.   You agree that a BA can start with a context diagram and then switch to a sequence based approach.   In the same way, individual processes on a DFD can be described using a sequence based approach. 

Tony

 

 

 
New Post 12/28/2011 2:44 PM
User is offline Kimbo
450 posts
5th Level Poster


Re: Use Case Extension Points and Alternative Flow 
Modified By Kimbo  on 12/28/2011 5:45:03 PM)

 Tony,

Still don't see why you think DFD's aren't sequence based? There is a sequence based on the arrows between the circles. The sequence flow is data based but its still a sequence? What am I missing?

Kimbo

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  General  Use Case Extension Points and Alternative Flow

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC