Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Do use cases really help?
Previous Previous
 
Next Next
New Post 10/12/2009 8:01 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Do use cases really help? 

Yes, bifocals can be a curse....

 

So, how do you partition?


David Wright
 
New Post 10/13/2009 1:36 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Do use cases really help? 
Modified By Adrian M.  on 10/14/2009 12:13:14 PM)

David,

your question was "how do you partition" so here is how I partition (I am not pretending this is the definitive answer, I just use these guidelines because they work):

Top level processes: Arguably the easiest level to identify as there a good set of guidelines for identifying a process:
Guideline of mutual dependency: if you conclude that Process A is always performed when Process B is performed, and that the only time Process A is performed is when Process B is performed then these processes should be combined in to one process. Example: Whenever the Process Create Customer is performed, the process Check Credit Rating is performed and the only time that Check Credit Rating is performed is when Create Customer is performed. Therefore, combine these processes.
Guideline of initiation and outcome linkage: if you conclude that whenever Process A is invoked under certain circumstances it will always result in initiating Process B (and/or outputs) and when Process A is invoked under different circumstances it always invokes Process C (and/or outputs) then it is likely that Process A has 2 or more processes combined in it and should be split out. Example: When Create Customer is invoked for a normal customer then the business rule is that the next process is always Place Order. When Create Customer is invoked for a customer who is also a company employee, then the business rule is that next process is always Authorise Employee Customer. In this case it is likely that Create Customer has another process in it (Create Employee Customer) that in turn would include Authorise Employee Customer under the rule of mutual dependency.
Guideline of user concurrency: If a process needs 2 or more different Job Roles in order to execute then it is highly likely there are 2 or more different processes in it unless there is a business rule that says this process must be executed by these job roles at the same time. Example: Suppose a company allows its employees to be customers of that company’s services, but to prevent fraud more stringent checks are made for so-called Employee Customers. If the process Authorise Employee Customer needs authorisation by Employee Line Manager role and Sales & Marketing Director role then consider having 2 processes because without doing this once the Employee Line Manager role has authorised the Employee Customer the process will wait until the Sales & Marketing Manager has also authorised it!
Guideline of meaningfulness: If Process A does not produce any meaningful (to the Business) outcome or output then consider merging with the preceding or following process.. Which process to merge with should be assessed using the other guidelines. Example: the process Record Customer Date Of Birth does not produce a meaningful outcome and can be combined under the guideline of mutual dependency with Create Customer
Any level processes and tasks
Guideline of unit of work: if it is conceivable that the process could or should be halted so that other processes can be started, then split the process. Example: The process Create Customer might contain the logic to record marketing preferences. This information is not required to Place Order so consider splitting Create Customer in to 2 processes: Create Customer and Record Marketing Preferences (which could be done at a more convenient point).
Guideline of conciseness of specification: if it is not possible to specify the execution logic on one page then consider splitting the process. This guideline is weaker than most.
Guideline of transaction steps: if a process performs only a few or one action then consider merging with other processes using the other guidelines. Example: Record Customer First Name and Record Customer Surname are probably part of the same process!
 
Note that you can swap "top level process" for "use case" as there is a 1:1 mapping between them.
And especially for you DFDers out there is a 1:1 mapping between "top level process" and process on a level 0 DFD.
 
Who says we business analysts just confuse things by having lots of words and concepts for the same thing? :-)
Guy
 
 
 
 
 
New Post 10/13/2009 7:29 AM
User is offline panofoot
11 posts
10th Level Poster


Re: Do use cases really help? 

I'm interested to see the talk on DFDs in this thread. The impression I've always had is that DFDs are a throwback to structured (and upfront) analysis, and are often too detailed for modern analysis and development. Moreover, DFDs tend to be more geared toward modelling data and functions, and doesn't suit OO A&D or Agile development. In structured development, the product after a requirements document would be a Functional Specification (or choose your term) that elaborated on the requirements, specifying a solution. Again, go back a few years to when programming languages were procedural (and function based), partitioning your application into a series of functions with inputs and outputs (i.e. functional decomposition) was a great precursor to technical design.

With the proliferation of OO development, developers now think in terms of classes, objects, methods. UML touts Use Cases as a method for defining requirements, but clearly states that Use Cases are not OO - they do not specify the system in terms of the design. Similarly, I wouldn't expect Use Cases to clearly delineate functions, it's not the point of them. Users don't think in terms of functions, they think in terms of the tasks/actions that they carry out, and this is what should be captured in requirements analysis. What the system should do in the users language, from the users viewpoint.

I don't necessarily think there is anything wrong with using DFDs, I'm just interested to see that people still use them.

 

 

 
New Post 10/13/2009 11:21 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Do use cases really help? 

How does a DFDer properly partition a system?

Key Concepts:  What works in partitioning a system at the detail level most often does not work at higher levels of abstraction.  And in order to properly partition at the detail level, the analyst first needs to properly partition the system at the higher levels.

Let me at this point, as best as I can remember, restate how Ed Yourdon (or was it Tom DeMarco?) said partitioning at higher levels of abstraction should be done:  By following the flows of data like rivulets of water flowing down a pane of glass.  When the flows of data naturally combine (like rivulets of water flowing down glass have a tendency to do), the business analyst has identified a logical function/process, as some process is necessary to accomplish the merging of the data.  Likewise, when a flow of data naturally splits apart, the analyst has flushed out a logical function necessary to accomplish the splitting.

Also per Yourdon:  When a function/process has a more than a total of about five (5) inputs and/or outputs, it is a 'dead ringer' that it needs to be split apart.  Such functions are called "functional spiders", and, if a diagram has functional spiders, it soon becomes impossible to understand it.  And if the diagram is not understandable, it will be impossible to properly proceed with further analysis.

Comparing the DFD approach with the more common approach that Guy B. presented in his last posting:

Top level processes:  It would seem that top level processes are easy to identify.  However, it has been my experience that a usable Context diagram (a data flow diagram where the entire system is displayed as a single high-level process), is very rare.  I once worked at a very large company that promoted and taught Context diagrams to everyone short of the janitors.  End result, across dozens of requirements specifications efforts that I evaluated: 0 (zero) Context diagrams.  Present party excluded of course :-)

Guideline of mutual dependency:  Basically, this is partitioning according to sequencing considerations (example: when function A always happens in sequence with function B, combine them).  But, how can a business analyst use sequencing to partition at higher levels?  At a higher level, especially for a larger scale system, there is most often many things going on at the same time.  In such cases, trying to partition according to sequencing considerations does not work - there is no sequence.  Yourdon referred to this phenomenon as the "asynchronous" nature of information systems.

Also, what if function A and function B, even though they always happen at the same time, have entirely different inputs and outputs?  Combining them may very well result in a functional spider.  Again, with functional spiders, the analyst soon reaches a point where things are too confusing to understand what is going on.

Guideline of initiation and outcome linkage:  Again, at other than the detail level, Process A is properly split apart based upon its number of inputs and outputs.  Partitioning based on sequencing considerations is for the detail level.

Guideline of user concurrency:  As I read it, this is combining processes/functions to avoid having the work wait in queue.  While eliminating queues is a valid goal, the analyst needs to look at the inputs and outputs of each process.   If combining them will result in a functional spider, then something other than a simple combination is required.

Guideline of meaningfulness:  If a process does not produce any meaningful output, a DFDer would definitely not combine it into another process.  He/she would document it on a diagram as a process without outputs - making it stick out like "a sore thumb" as something that needs to be addressed.

Guideline of unit of work:  Splitting a process into two for efficiency reasons is a very good thing.  After the analyst has partitioned the system logically and so that there are no functional spiders, this can be done.

Guideline of conciseness of specification:  Good recommendation:  If the analyst needs more than a page of specification for a function, then split it up.  Of course the way to avoid functions that are to big is to avoid functional spiders.

Guideline of transaction steps:  I agree that simple processes, like one step processes, should be combined into other processes.

 

 
New Post 10/14/2009 10:37 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Do use cases really help? 

Hi:

I don't think that it is fair to refer to data flow diagrams as a "throw back".    Data flow diagrams were popularized in the 70's as a way to overcome technqiues that employ brute-force partitioning.   Use cases are a classic example of a modern day technique that employ brute-force partitioning.   But make no mistake about it, use-case-like diagrams are alot older than data flow diagrams.   Use-case-like diagrams have been found etched into the walls of caves that the cave men used to live in :-)
 

I suggest reading of my previous post on this thread that discusses the unique power of data flow diagrams to properly partition a system to get a better understanding of how to position them relative to use cases.

Tony

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Do use cases really help?

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC