Many analysts skip the identification of business processes and move right to the Use Cases. Some call these “Business Use Cases” and view them as logical, business requirements. I recommend that both business processes and system Use Cases are important components. They are two different requirement constructs representing two different perspectives with two different purposes.
| Business Process | Use Case |
| business area perspective | actor or use perspective |
| business activity or need | software function |
| independent of technology | describes the behavior of the technology |
9 Comments
Great post Barbara!
It’s all about perspectives. That’s why I love the Zachman framework. Business processes captures the “HOW” from the Business owner’s perspective. It’s the Business Owner desire to increase effectiveness and efficiency. Once you map out the business process (the things the business does and how it does it), it become easier to satisfy the Business owner desires for effectiveness and efficiency. Use cases captures the Architect’s view of “WHO” and the functionalities of the system.
Jumping right into the Use Case is a huge mistake. Though you may understand actors and functionalities, you will miss out on what the Business Owner really want to achieve and may end up with missing requirements.
I agree. Those are two different levels of abstraction and when you jump right to the use cases you are assuming that the high level requirements are known.
Those are different levels, but they are related and to make it clear I like to use a PUCs diagram (Process – Use Cases), where you model the process and hang the system use cases were they apply.
I try to keep an open mind on each project but I always find that understanding the processes is critical for success on all but the smallest projects.
I am just planning for the process modelling on my current project. Timescales mean that there is a desire to shortcut this and go straight to the use cases.
My question would be – if the business can’t see the whole end to end picture (where the use cases and system behaviour are only part) how can you expect them to provide quality requirements?
Failure to tackle them up front will reap the rewards of EXPENSIVE change downstream.
I wrote an article on my blog a while back which relates closely to how business processes and other artefacts should be identified before use cases – http://businessanalystmentor.com/2008/12/17/use-cases-business-case-business-processes/
I couldn’t agree more.
In some cases, I would even argue that there is an intermediate level of model, which is the workflow diagram.
In common with the use case, it would describe the behaviour of the solution, but at a higher level. The internal workings of each stage of the workflow would be described within use cases.
I would not start modelling a workflow before understanding the business process within which it belongs.
Regards,
Declan
Hi There All,
I think there is always something before a use case, I have found it useful to aggregate use cases and actors and then use those as the top level process. This just extends the model and can give you a good reference for top-level processes and decomposition. However what I think is important is to separate the initial analysis from the designed use cases. The business case, which is probably the place to do this, should focus on the motivation of the business and what needs to be achieved, the ends. These are the business requirements, which may be referred to as non-functional requirements. The design, the ‘to be’ document, should have the new processes and the use cases, which are the means of achieving the ends defined in the business case.
Just thinking out loud there, but these are real issues, as Alex pointed out, poor requirements means low quality and high residual risk.
Regards
Mike
Hi all,
This discussion is on a very interesting topic.
I have a couple of comments about the previous posts.
Barbara’s post summarizes a use case as being:
- actor or use perspective
- software function
- describes the behavior of the technology
It is important to say that this may apply only when dealing with ’system use case’, but not for all types of use cases.
I used to write user goal use case or summary use cases (referred here as business use case) and it is very rare to detail anything about software or technology used. Indeed the theory says to describe interactions with the ’system under discussion’ which in practice is not limited to a software system. It is generally a black box from the use case perspective.
Mike, your post is a good reminder that a project does not start with the use case writing but with a vision and scope analysis.
My only comment is not to confuse business requirements and non-functional requirements. These are not artifacts at the same level. A business requirement is obtained from the business people and says things like ‘we must reduce our loss by 5% within 3months’. The non-functional requirements are the requirements supporting the functional requirements (requirements on the system under discussion functionalities). They include but are not limited to the UI, performance and security requirements.
Often people ask, which model should we use, use cases or business process?
Use cases are more detailed. They focus on the WHO and WHAT dimensions. The use case objective is not to present the activities in a flow but describe scenarios from the user perspective. Complex use case can be cumbersome to understand in term of sequencing.
Best tool to get the user requirements in a work flow is the business process diagram. It still presents the WHO and WHAT dimensions but with fewer details and in a goal achieving stream.
As both techniques are time consuming, if you have to choose one, always opt for the tool which is the most understood in your organization. Some will prefer diagrams which is worth a thousand words… some others will prefer prose texts because it is closer to text instructions…
Both techniques are complementary not mutually exclusive. In the ideal world, it is always useful to use them both. You will see:
- improved communication to the business and the technical teams
- Better hidden requirements elicitation
To go further I suggest the following readings:
- Write effective use cases, Alistair Cockburn
- Software requirements second edition, Karl Wiegers
Great comments Cedric,
One other thought:
WHO does the work is actually part of the technology! When I am capturing true business requirements I try to remove the WHO because who does the process could change in a new solution design. Essential business process modeling also doesn’t acknowlege sequence because often processes could be designed to be completed in a different order. Business Use Cases are OK but they lead analysts to re-design the same sequence and personnel involvement as in the current system. Looking at essential business independent of HOW, WHO, and WHEN gives us the best flexibility for designing a better way.
Barb
In my experience, they are dependent components in a requirements specifications. In a use case specification, prior to describe the use cases I always add one section of “business process” section to help stakeholders understand the context of the to be solution. Activities in the business process are high-level, some of them are in flows in use cases others may be pre or post conditions for a specific use case.
In use case sections, only activities which will be implemented by the to be solutions will be described. the activities in the use case flows will be more detailed than that in business process.
I need to know on this!!!