All About Requirements

Look at Your Need For Accept Criteria To Determine the Need For Requirements Details

How much should we do? Should we do both business analysis and requirements specification? Questions like these, are present all the time in software projects. The answer really depends on what you would like to achieve see Top-10 reasons to start with business process analysis before specifying requirements.

 

A fast track method for determining the need for details is illustrated in the figure below. The method focuses on the accept criteria in your project.

 

If you need the final delivery to only be accepted, if it fulfills specific functionality details, you must specify the detailed requirements – if not, you might be able to settle with the high-level requirements. The method is a great way to initiate the discussion about what details are needed.

 

 

Top 10 Reasons To Start With Business Process Analysis Before Specifying Requirements

 

A question (or even discussion) often heard in projects is, if we should start the project doing business process analysis or jump directly to specifying requirements for the system. Often it is not an either or question, and it really depends on what you want to accomplish.

 

In short you can say that Business Process Analysis is about: understanding the problem/context while requirements is about: specifying what is needed in order to solve the problem (what must the system do?).

 

 

So, the question is what you need the most; understanding the problem or specifying the requirements in order to solve the problem?

 

Below, I have outlined what I find are the top 10 reasons why Business Process Analysis should be considered before digging into the requirements specification:

 

1) You don’t fully understand the problem or the context you are dealing with

One of the most likely reasons to fail with your requirements specification is, if it is build before you fully understand the underlying problem. Sometimes time pressure pushed you in that direction. The result is very likely a vague requirement specification that doesn’t fulfill the desires and expectations.

 

2) You want to procure a standard system

If procuring a standard system you don’t want to specify every detail. Instead it will be better to specify the processes and functional requirements the system must support. For example when procuring a standard system you will not specify the screen mock-ups involved with fields and features needed. It will be must better to specify what processes the system must be able to automate, and what key functional requirements must be fulfilled.

 

3) You want to optimize the existing processes

If optimizing the current business processes you obviously need to start analyzing the business processes.

 

4) If it is important that the system fits the business processes

If it is important for your project success that the system supports you business processes and not enforces changes to your business processes, you need specifying what processes must be supported.

 

5) If the business area or system to develop is representing a competitive advantage

If the system you are going to build is supposed to bring a competitive advantage to your business it is most likely that the competitive advantage has its offset in the business process design – for example by doing things faster, cheaper, in better quality, or by determining manual processes that must be automated.

 

6) If it is unclear what main functionalities the system should have

This related back to reason number 1.

 

7) If it is unclear what processes the new system should automate

This is partly related to reason number 1, but also a question of knowing which processes it makes sense to automate and relate this to a business case.

 

8) If you already know the business process model

Then you are all set.

 

9) If the business processes can be derived very fast

If the business processes can be derived very fast – for example by taken advantage of business process mining – then, why skip it? It might bring valuable information

 

10) If you want to know what changes a system enforces to your processes

New system either supports the processes in place or enforces new processes to be followed. If you need to know the impact on your processes of a new system, you need to know you own current processes.

Expanding the Cloud – The Amazon Simple Workflow Service - All Things Distributed

Today AWS launched an exciting new service for developers: the Amazon Simple Workflow Service. Amazon SWF is an orchestration service for building scalable distributed applications. Often an application consists of several different tasks to be performed in particular sequence driven by a set of dynamic conditions. Amazon SWF makes it very easy for developers to architect and implement these tasks, run them in the cloud or on premise and coordinate their flow. Amazon SWF manages the execution flow such that the tasks are load balanced across the registered workers, that inter-task dependencies are respected, that concurrency is handled appropriately and that child workflows are executed.

A growing number of applications are relying on asynchronous and distributed processing, with scalability of the application as the primary motivation. By designing autonomous distributed components, developers get the flexibility to deploy and scale out parts of the application independently as load increases. The asynchronous and distributed model has the benefits of loose coupling and selective scalability, but it also creates new challenges. Application developers must coordinate multiple distributed components to get the desired results. They must deal with the increased latency and unreliability inherent in remote communication. Components may take extended periods of time to complete tasks, requests may fail and errors originating from remote systems must be handled. Today, to accomplish this, developers are forced to write complicated infrastructure that typically involves message queues and databases along with complex logic to synchronize them. All this ‘plumbing’ is extraneous to business logic and makes the application code unnecessarily complicated and hard to maintain.

via www.allthingsdistributed.com

Amazons workflow service. New approach for developers? The business process automation is more often a main driver...

Will Business Analysts Be Out of Work When Introducing Automated Business Process Discovery

When optimising business processes or analysing business processes in order to produce a business oriented requirements specification, you need to analyse and produce a process map showing the as-is process situation. in order to do that you probably conduct interviews with stakeholders, read documentation, facilitate workshops and so on. As we all know that can be a time consuming task.

 

Why not let a robot do the hard work and produce the process map for you?

 

The answer to this dream is Automated Business Process Discovery, which is an automated approach to create a business process model. In short, you let an IT system analyse your data (anyone saying Big Data and BPM?) for instance audit trails, message systems, transactional systems, databases, integrations, service busses etc. The ABPD system then looks for patterns in your data and the output is process models created from scratch.

 

Advantages are, among others:

 

1) The processes found and modelled are the processes actually processed. How often haven't we documented the processes the business thinks (or wish) they have and not the process they actually are having?

 

2) Inter-department / inter-organisational touch points are included in the process model and those are often hard to document correct

 

3) Bottleneck analysis can be analysed on real life data

 

4) The events and handshakes between systems are analysed and documented

 

 

Will the business consultants all be out of work then?

 

No, I don't see that happening. What I do see is that in the near future we will start using ABPD as a tool for speeding up the process mapping task. I say "in the near future" because very few companies uses ABPD at the moment. When I say we will not all be out of work it is because:

 

1) ABPD only captures the structured automated processes. The processes not automated you still need to discover yourself.

 

2) ABPD gives you a button-up approach to process modelling while traditional BPM techniques gives you a top-down approach. My guess is that you need both approaches.

 

3) Grouping of the user interactions is still needed

 

4) Documenting the formal process and not the process that happens to be processed still needs manual documentation

 

 

At the end of the day we will use ABPD for accelerating process modelling, not for getting rid of business process analysts.

 

"Create more value than you capture" that is Tim O’Reilly’s key to creating the next big thing.

An article I just stumbled upon.
(see article: http://www.wired.com/business/2012/12/mf-tim-oreilly-qa/ ).

It made me think: This it exactly what requirements should be all about - create more value than you capture. Why not just go on coding right away?

Because we'll wait as long as we can put in more value than the information we capture, because digesting desires, feature wish lists, rules etc. in a structured way generates more value than what is captured.

Digest, document, analyse, and make sure requirements generates more spot-on solutions.

"Create more value than you capture"!

Free Use Case Point Estimation Template In Excel Format

 

Download Use Case Point estimate - Template - Click here...

For introduction see the post use case point estimation

 

Use Case Point Estimation – Estimate Your Project By Looking At Your Use Cases

Estimating what effort is needed to develop an IT solution is not an easy act. The pitfalls are multiple and chances are that you end up guessing.

 

In this post I will outline how to estimate projects based on the use cases. In addition I will show you how you can use Use Case estimation to negotiate with suppliers.

 

Estimation can be hard. Luckily a number of techniques exist that can give you a qualified (gu)estimate.

 

Among others, the following popular estimation techniques for estimation IT development exist:

 

1. Expert Judgment
2. Lines of Code (LOC)
3. Function Point Estimate
4. Use Case Point Estimate

 

 

Expert Judgment is when you rely on an estimate based on talking to experts. Especially valid when talking to experts experienced in the domain and with experience from developing similar solutions. Investigations shows that expert judgments can be fairly valid and almost as valid as more proven methodologies. Challenges are for example how to find the right experts and to evaluate their expert level. Furthermore, it can be hard to convince others (for example your supplier) that your estimate is valid, because it is a subjective evaluation.

 

 

Lines of Code (LOC) are a technique that is fairly reliable in the hands of an experienced team. The technique says, as a rule of thumb, that it takes X number of hours to develop Y lines of code. For example 100 hours per 1000 lines of code. An disadvantage of this technique is that you need to know how many lines of code you are going to produce – this can be estimated for example for a 1:1 conversion of an existing system, but can be hard to determine in other situations. Another disadvantage is that you need an experienced team to do the estimation, and you need to compare with similar systems – the amount of lines of code in a from-scratch-developed-system might differ from a similar system developed using a industry-standard-solution or framework.

 

 

Function Point Estimate, is an estimation technique developed by IBM. It counts the elements of the functional requirements and based on that calculates an estimate.  The technique is very usable and accurate. The advantage of this technique is that it is fact based and can be used by teams not experienced in the domain of the solution. Another advantage is that the cost of the project can be based on previous/other projects, and that other estimates using Function Point Estimation within your organization can be used as baselines. A description on how to use Function Point Estimation can be found here: http://en.wikipedia.org/wiki/Function_point

 

Use Case Point Estimation is a technique developed by the Swede Gustav Karner in 1993. The Use Case Point estimation technique is based on the same principles of Function Point estimation and has the same advantages. It has turned out that Use Case Point (UCP) estimation is as reliable as Function Point estimation. 

 

An explanation of the content of Use Case Point Estimation can be found here: http://en.wikipedia.org/wiki/Use_Case_Points

 

“What makes this technique particular interesting is that by using UCP estimation you are able to produce a reliable estimate very early in the development cycle.”

 

 “Actually even after sketching the use case model you are able to produce an estimate, apply it to the business case and consider stopping the project at this early stage, if the business case is not positive. That is a strong asset”

 

 

The figure below outlines where in the development cycle the various estimation techniques apply.

 

 

 

 

Lets have a look on a practical example on how to use the UCP estimation technique:

 

Lets say you’ve created the following simple use case model:

 

 

 

In this use case model there are seven use cases and two actors. The UCP technique involves ten calculation steps. Once learned they are easy to follow and your UCP estimate can be calculated within minutes.

 

The very first step is to calculate the Unadjusted Use Case Weight (UUCW). For calculating the UUCW you look at the number of use cases in your use case model, categorise them and calculate a UUCW score. The UUCW score will be used in other calculations as we move forward. So, we already know we have seven use cases. Those seven use cases needs to be categorised into Simple Use Cases, Average Use Cases, and Complex Use Cases.

 

In the table below you can see how each Use Case Category is described. Simple Use Cases are those having 1-3 transactions, and so on.

 

 

 

 

You just need to determine for each use case how many transactions they have in order to categorise them. To do so, you could have a look at the activity diagram and count the number of times the flow control switches from actor side to system side and vice versa.

 

For example in use case #1 the activity diagram could look like the one shown below (Notice: The activity diagram could as well be represented by a table showing the steps):

 

 

 

 

 

When looking at the activity diagram you can see that the control flow starts in the User side where the user is on a screen typing in some details. At some point in time the User chooses to save the input and clicks “Save”. By doing that, the control flow switches to the System side where the system validates the input.

 

When counting the transactions you should count the number of times the control flow switches lane (crosses the lane line) – except for error handling – those should not be counted.

 

 

So, in the activity diagram above I count three lane crossing – when I subtract the one involved in error handling, I calculate a total of two transactions for that use case.

 

 

Imagine doing this for all seven use cases in the use case model, we might end up with following categorising and a total UUCW score of 45:

 

 

 

 

“As you might have noticed you are now taken advantage of having documented your use cases properly by using activity diagrams with clear division of actor lanes!”

 

 

So far, so good.

 

 

The next step is to calculate the unadjusted Actor Weight (UAW) score. The UAW score tells something about the complexity of the solution. The Actor categories shown in the figure below doesn’t need much explanation.

 

 

 

 

When looking at the use case model shown in top (above) of this post, let’s assume that the two actors are human beings. The UAW score is then ‘6’ as stated in the figure above.

 

 

The next step in calculating the UCP score is to calculate the Technical Complexity Factor (TCF). The Technical Complexity Factor is often the most confusing part. In short, the TCF score adds an overhead of complexity to your score – the more complex the technical part of your solution is the higher score. Lets have a look at the TCF below:

 

 

 

 

By filling in the 13 factors above you’ll reach a score of 0,8 (TCF). Notice that the Complexity Factor (not to be confused with TCF) is 0.6. The formula to get to the TCF is just to multiply the Complexity Factor by 0.01 – don’t ask! it just happens to be the formula.

 

 

The final calculation to do is calculating the Environmental Complexity Factor. This factor is even more confusing than the TCF score. As you can see from the figure below the impact of various factors are rated. This gives you a sum (ETF) that goes into the ECF formula:

 

 

 

 

So far the following calculations has been performed:

 

Unadjusted Use Case Weight : UUCW

Unadjusted Actor Weight: UAC

Complexity Factor: CF

Technical Complexity Factor: TCF

Environmental Technical Factor: ETF

Environmental Complexity Factor: ECF

 

 

By having those six formula results you are now able to calculate the Use Case Point result. The Use Case Point for your solution is based on the following formula:

 

 

UCP = (UUCW + UAW) x TCF x ECF

 

Here is what the calculation from the example in this post looks like:

 

UUCW = 45

UAW = 6

TCF = 0,8

ECF = 1,085

 

UCP = (45 x 6) x 0,8 x 1,085

 

UCP = 44,268

 

 

Now, what use do you get from that?

 

Knowing that this project or this solution equals 44,268 worth of Use Case Points tells you a lot about the size of your project/solution. For example if you previously developed a solution worth 88 Use Case Point you now know that (with all other things being equal) this project is about half as big. This is valuable information in estimating the effort.

 

If you know that the previous solution you developed (the one worth 88 UCP)  demanded you 1000 hours of development, then it is likely that this new solution will take you about 500 hours to develop. That is, what the final calculation is all about: The Productivity Factor (PF).

 

The Productivity Factor (PF) is the hours of development per use Case Point. If the PF equals 10 then; (from the example above) the project estimate is (10 x 44,268) 442,68 hours.

 

Using the UCP method for creating estimates and discussing those estimates with suppliers can involve a lot of arguing about what the right PF factor should be. The supplier of course, will argue that the PF factor should be fairly high – e.g. 20 or 25. You, on the other hand, might argue that the productivity factor should be way lower – e.g. 9 or 8. So, what is right then? Reading materials explaining UCP estimation often suggests that a productivity factor of 20 is correct. The thing is though, that it depends.

 

 

Building your own baseline of PF Factor documentation

 

 

What you should do is to start collecting knowledge about your projects and the realised PF calculated. Let’s say you have completed a project and that the UCP point calculated for that project was 120. Now, if you spend 1800 hours developing the solution then your realised PF is: 1800/120 = 15

 

Imagine doing this for all your projects the result could look like illustrated below.

 

 

 

 

Now, by tracking your realised PF you can calculate a baseline by calculating an average PF of 12,6.

 

What the average PF of 12,6 tells you is that in average, when developing solutions in your organisation, using your IT environment, dealing with your business complexity, you spend in average 12,6 hours per use case point.

 

You could take the UCP baseline calculation a step further. For example if Project1 and Project2 are infrastructure projects and Project4 and Project7 are ERP projects you can create various Realised PF baselines depending on the project type ….. or depending on the suppliers, or in-house / external development, or, or….. The possibilities go on. It only requires a solid base of project tracking.

 

 

Using this information to control your suppliers

 

By having an average PF calculation you are able to create a documented fact based estimate. With a fact based estimate you have a better position when negotiating with suppliers.

 

-       Why can’t you deliver on a PF of 12,6, when all our other current suppliers in average delivers on 12,6 PF?

 

-       If your offer is based on a PF of 30 we believe you are charging too much based on the performance of our other suppliers/projects

 

-       If your offer is based on a PF of 4 we fear that you have not understood the complexity of our project, or that you under-charge just to get your foot in.

 

-       All right, we’ll accept your offer based on a PF of 20 once again, but you must document a strategy on how to optimise your performance to match our other suppliers.

 

 

Warning

 

Remember that UCP estimation and PF calculation are not absolute truths. What you get is an estimate based on facts and an estimate that gives you a feeling of what end the “real” estimate should be in.

 

 

Funf - Open Sensing Framework is That Part of Future BPM

Funf | Open Sensing Framework. is a very interesting framework that in it's own words "...is an extensible sensing and data processing framework for mobile devices, developed at the MIT Media Lab. The core concept is to provide an open source, reusable set of functionalities, enabling the collection, uploading, and configuration of a wide range of data types."

 

The interesting part is that it opens up for gathering all sorts of data - movement and communication. 

 

It then struck me; this trend will be part of what can be game changers for the BPM environment in the future. A trend in BPM that is already very present is the need to be faster in adopting new/changed business rules and business processes - to maintain the competitive edge - to survive.

 

In the future key employees and management will be monitored. Even competitors will be monitored. Key influencers from the industry will be monitored.

 

BPM teams will be required to analyse and react on the data gathered. And do it fast.

 

BPM teams will start analysing and preparing consequense assessments.

 

I think this might be something that can have impact on BPM in the future.

Project Management in Business Process Management Projects

Projects involving business process analysis or business process redesign needs people with different sets of competences. In fact you need to map characteristics from the following three domains to success with business projects:

The skills domains involves different sets of underlying skills

 - a few examples are given below:

1. Management (in general)
   1. Management skills
   2. Team management
   3. Conflict solving    
2. Project Management
   1. Project Management Methodology
   2. Project Management best practices
   3. Planning techniques
   4. Project Governance
   5. Project Management tools
3. Business Process Management
   1. Business Process Analysis
   2. Business Process Methodology
   3. Business Process re-design
   4. Business Process mapping

 

Of course there are overlaps in the three skills mentioned above, which is illustrated below.  Often the focus is on ensuring that the right management skills are present, by allocating a strong project manager with the skills: general management skills and project management skills. But so succeed with business oriented projects you need to cover the sweet spot in the illustration below: ensuring that all three management skills needed are present in the project team.

 

 

 

 

 

Checklist for your projects resource situation:

1. Do you have a project manager allocated to the project, and is she having the basic general management skills?
2.  Does the business impact on the project reflect the allocated business management skills?
3. Is the project manager aware of the need for business management skills?
4.  Does the project plan include a documented business process method approach?
5. Is the project board aware of that business process management and project management are equally important in business oriented projects?

 

Answering 'No' to questions on the checklist above should raise corresponding risks on the projects risk log. 

 

 

Business Rules, Pseudo Rules, Union Agreements - How to Document Such Business Rules

The importance of business rules is obvious for business analysts. However, how to document the business rules identified is often not that obvious. The truth is that it can be done in many different ways.

 

A lot of great tools exist for documenting business rules, managing business, simulating business rules etc. Elaborating on the business rules tools is the scope for another post. In this post I will describe some tips on how to document the business rules e.g. by using Microsoft Excel. The advantage of using Microsoft Excel is, that it is easy to use, probably already installed on your machines, and most important; both the business analysts and the end users are familiar with Excel.

 

Before digging into the process of documenting the business rules some concepts needs to be in place. Business rules is an integrated part of specifying use cases and the business rules as such are documented directly in the use cases. If you are using word for specifying use cases you need

 

1) business rules documented with a unique ID, and placed at the relevant use case steps as shown below (use case specification screen dump):

 

 

 

 

…. and

 

2) You need an overview of the relationships between use cases and business rules. In the above picture it is documented that, that specific use case is using/related to business rule FR1, FR2, FR3, FR4. However, it might be that another use case is also related to e.g. FR2 and FR3. 

 

 

 

Creating a Use Case ß à Business Rule Matrix in Microsoft Excel could look like illustrated in the picture above. 

 

The Use Case ß à Business Rule Matrix gives you an overview of which business rules are used in a use case and in which use cases a specific business rule is used. An overview like that is a must have, if the number of business rules is high and/or if the business rules are likely to change frequently.

 

 

If your business rules are facilitated during requirements workshops and the business rules are relevant for the use cases only, you are probably all set with the approach described so far. However business rules management is sometimes a complicated act.

 

If the business rules are extracted from plain text e.g. from guidelines, law text, union agreements or similar, it is necessary to document traceability from the plain text to business rules to be implemented and finally to a business rules matrix.

 

Let’s look at an example. Imagine having a law text, a union agreement or another document describing rules in a plain text unstructured manner.  One way to extract the business rules from such a document is to simply cut ‘n paste the text in small pieces one piece at a time and label each piece with a unique ID. For example you could end up with the rules “Plain text – X”, “Plain text – Y”, “Plain text – Z”, and “Plain text – Q”.

 

Those plain text rules are not ready to be implemented by the developers. First, they are probably ambiguous or hard to interpret. Second, it might be, that the rules “Plain text – X”, “Plain text – Y”, and “Plain text – Z” and all saying the same thing, just in different words or even in the same words captured from different places in the original law text document.

 

What needs to be done in order to document the business rules is to map the pseudo rules to (implementation) Business Rules. This needs to be done because the pseudo rules might be redundant and not probably defined for implementation.

 

In the figure below the business rules copied from plain text (orange) are individually mapped into pseudo rules (described like pseudo code – e.g. “If date = 1/5 Then Salary Supplement X is granted”). The Pseudo rules then needs to be mapped into Business Rules ready for implementation. If “Plain text – X”, “Plain text – Y”, and “Plain text – Z” and all saying the same thing they are all mapped to the same Business Rule (in this case Business Rule -1). By doing it this way you’ll get the following advantages:

 

1)   If a pseudo rule changes, it can be documented even if the change has no impact on the Business Rules.

2)   If a pseudo rule is deleted the implementation is still valid

3)   If several pseudo rules are saying the same thing, you only implement the Business Rule realization once

 

 

 

When the pseudo rules are mapped properly to Business Rules, the next step is to document the rule flow. The rule flow specifies in what sequence the business rules are triggered, and if business rules can co-exist or excludes each other. For example if Business Rule – 1 is specifying a supplement being granted for each hour worked on Sundays and Business Rule – 2 is specifying a supplement being granted for each hour worked on the date 1/5. The question is then; If an employee is working 1/5 and it just happens that 1/5 is a Sunday, should the employee have Business Rule -1 triggered, Business Rule – 2 triggered, or both Business Rule -1 and Business Rule – 2 triggered?

 

The answer to such questions should be documented in rule flows. An example of a rule flow reflecting the example is illustrated below.

 

 

 

To summarise, the following rule of thumbs exist:

 

 

1)   Business Rules must be documented

2)   Business Rules must have a unique ID

3)   Business Rules usage must be documented e.g. in a matrix

4)   Business Rules originating from plain text must be documented if plain text, pseudo rules and mapped to business rules

5)   Business Rules involving context conditions must be documented in rule flows