All About Requirements

Free Use Case Specification Template

Download Use Case Specification Template

The template is desgned for level3 "fully dressed" use case specificatons but it can easily be tailored to your needs. Feel free to use the use case specification template free of charge with no limitations.

What is BPM, BPMS, EA, BPA? A Short Definition Introduction

Don’t you just love buzz words and abbreviations? Abbreviations come in handy in many situations but often confuse people not experienced with business process management.

 

Some of the most common concepts/abbreviations you will see are the following:

• BPM – Business Process Management
• BPA – Business Process Analysis
• BPMN – Business Process Modeling Language
• EA – Enterprise Architecture
• BPMS – Business Process Management Suite

 

BPM is an abbreviation for Business Process Management and refers to the management discipline where the approach is managing the processes. Often BPM is just an umbrella under which you handle various things regarding business processes. Usually when people talk about BPM they refer to AS-IS and TO-BE analysis of processes.

 

However, analysing your existing processes, documenting the analysis as AS-IS process diagrams and then designing the TO-BE processes is BPA -->Business Process Analysis (notice that BPA is also a part of BPM). Business Process Analysis (BPA) is about analysing the business needs and identify the business process requirements. In BPA the output is process analysis and business requirements – usually the output is captured in process diagrams drawn in modelling tools using for example BPMN as the modelling syntax.

 

BPMN (Business Process Modeling Notation) is simply a collection of graphical shapes you can use for drawing business process diagrams where the business process diagram is a sequence of business processes connected by control/message directions. Below is shown an example of a process drawn with the BPMN notation. The example is drawn in Microsoft Visio. If you want to draw BPMN diagrams in Visio a Visio BPMN Stencil can be found here (http://www.omg.org/bpmn/documents.htm)

 

 

The Visio Stencil contains BPMN figures as shown here:

 

 
 

Enterprise Architecture is a logical structure (architecture) of an enterprise. In enterprise architecture you design how the logical structure and often enterprise architecture is producing logical structural outputs of how the business structure should be – for example using UML structural diagrams such as Class diagrams and component diagrams. Usually enterprise architecture is produced using a modelling tool. In enterprise architecture you design how you business structure should be while in Business Process Analysis you analyse the “problem” and design the business processes”.

 

BPMS Business Process Management Suite is a suite of applications that can execute your designed business processes. BPMS is both a design-time and run-time environment. In a BPMS you will have a model-driven approach and you will be able to design and orchestrate your business processes and business rules and have them executed in run-time. BPMS is excellent for letting the business drive business changes and BPMS is excellent for workflows especially long workflows (more than 1 hour processing time).

 

To summarise, as you can see from the figure below the concepts are used for different purposes. When doing Business Process Analysis you are in a conceptual level designing how the processes should be outlined. When moving on to Enterprise Architecture you are on a logical level designing how the structure should be in order to support the conceptual design of business processes. Finally on implementation level you can manage and orchestrate how business processes and business rules are executed. However, please notice that there are some overlap between the various concepts - e.g. requirements are not just captured by one concept alone.

 

 

 

Why Business Process Optimisation dont bring innovation

If you want innovation don’t ask your customers - analyse your business processes instead

 

“If we’d asked our customers what they needed, they would have asked for a faster horse” is said to be a quote of Henry Ford, founder of the Ford Motor Company. What Henry Ford was referring to was the lack of good responses when asking customers for input that were true out-of-the-box innovation. Why is that? Mainly because the customers’ context is their current product, solving their current needs, and their input will most likely be adjustments or optimisation of their current product.

 

Even Apples Steve Jobs does not recommend asking the customers for input when trying be innovative. Where does that leave us? With our business processes! Simply because we have nowhere else to go. In order to be innovative you must A) Understand what your business need is B) Understand what business processes are involved C) Think out-of-the-box to design new innovative business processes to solve your business need.

 

Innovation should not be confused with process optimisation. In process optimisation you look at the existing business processes and try to find ways to improve the process by making the process either faster or cheaper. Mostly this is done by eliminating none-value-adding-processes, automating processes, or executing processes in parallel (thus eliminating waiting time and bottle necks). However, optimising the business processes does not bring you any innovation, it (just) brings you efficiency and lower costs.

 

Let’s take an example.

Suppose a National Post authority due to increased competition is looking for innovation to strengthen it’s competitiveness. First thing to do is to be aware of the business needs. The business needs to look for is the business needs in the eye of the customers. Because, by improving the fulfilment of the business needs seen from the customer’s perspective you are increasing their business value. So, 

• Changing business processes to shorten queues at the post office brings efficiency not innovation
• Changing business processes to eliminate the need for stamps brings innovation
• Changing business processes to eliminate distribution and introducing instantly delivery brings innovation

 

In order to succeed with your TO-BE business process design it is extremely important to know up-front what is the goal regarding the business process analysis. Is it business process efficiency? Is it lowering costs? Is it better customer service? Is it innovation? Is it just to document the business process?

 

Only by knowing the overall goal is it possible to design a good suggestion for the TO-BE business process.

 

Aiming for business process efficiency will probably involve:

• Automation of business processes
• Standardisation
• None-value-adding-process elimination
• Faster processing time

Aiming for better customer service will probably involve:

• Individualised processes
• Human involvement in processes
• Slower processing time

Aiming for innovation will probably involve:

• Out-of-the-box process redesign
• New technology / new systems

 

Bringing innovation is hard work. It requires established process design to be challenged by out-of-the-box thinking. Innovation is not a brilliant idea in the shower – it is business redesign continuously.

 

What To Use For Agile Projects - Use Cases or User Stories?

User Stories are a key element in Scrum projects and used to capture the high-level requirements for the Product Backlog of requirements.

 

One common misunderstanding is that user stories per definition replace use cases as a concept when developing agile solutions. Another misunderstanding is that if you are using use cases you can’t use agile methodologies for development. Both statements are wrong.

 

Let's first look at the two concepts. User Stories are an element in the agile methodology Scrum, while Use Cases origin from the UML framework for specifying requirements.

 

Similarities

There are some similarities between use cases and user stories.

1. Both concepts involve the users in order to capture the user requirements to be developed.
2. Both concepts are using plain language as the main content in order to enable the users to write or at least understand the produced output.
3. Both concepts are input to the design- and development process

 

Differences

Even though use cases and user stories are comparable there are some distinct differences:

1. Use cases capture more information than user stories. User stories are written stories in native language and often follow this structure: As a [user role], I want to [goal], so I can [reason]. Use cases capture a lot more information for example: Pre-condition, Post-condition, Trigger, Actors involved, Verbal description, sequence of actions etc.
2. User stories are usually shorter – that is by design, refer to difference#1 – than use cases.
3. User stories are slightly easier to create. The fact that user stories are shorter and includes less information justifies the statement that user stories are easier for the users to create. However, judging how much easier it is depends on how complex use cases you intend creating. Use cases can be created with various levels of complexities (See post: How to get use case success).
4. Use cases contain a sequence of actions while user stories are plain unstructured text.
5. Use cases model the behaviour of the system by defining how (usually) a user interacts with the system. User stories don’t model how this interaction should be. 
6. Use cases can be heavily detailed and used for “over-the-fence” projects, while user stories in their short form requires verbal interaction when development starts. Heavy detailed requirements can be useful when capturing very complex requirements or when creating a request for proposal.
7. Use cases are derived from a use case model. User stories are usually not derived from a model. Being derived from a model establishes an overview of the requirements structure.
8. Use cases are primarily used for capturing and documenting requirements, while user stories are primarily used for capturing high-level features and to prioritise work

 

Use cases have been along for many years. It is true, that in the past use cases were usually heavyweight specifications. I have seen 50 pages use case specifications being developed (in some cases that amount of details were needed). Today this is no longer usual. Today use cases are normally found in various levels of detail – from extremely lightweight being just a use case shape with a few sentences of description to heavyweight use cases with exact details of the business rules and requirements. I think the agile methods have influenced the way we use use cases today into a much more agile approach. That is why you can easily use cases for specifying your product backlog. In general think of a use case as containing a user story for each flow in the use case.

  

What is best – use cases or user stories?

In my opinion the best approach is what the development team is most familiar with. If the team favour one of the concepts and you can see it’s working you should not change it.

Saying that use cases or user stories in general are always a better choice is, in my opinion, nonsense.

 

Personally I find it easier to identify use cases from a use case model than to identify user stories. In addition I find it difficult to understand how the selected user stories adds up to be the complete system - looking at a use case model is easier that looking at hundreds of user stories.

 

After all what requirements specification is all about is lowering risk. Lowering the risk that something wrong or incomplete is being developed. How much effort you should put into lowering that risk depends on the impact and the probability that it will happen. What is enough? It depends on the risk assessment – but I think for agile projects a good rule of thumb is that you need enough details to be able to sign-off on a sprint.