Author: LN Mishra

LN Mishra (LN) CBAP, CBDA, AAC, CCA Helping BAs to Improve Their Careers: Guided 1000+ BAs to be IIBA® Certified World’s 1st BA to hold all 6 IIBA certifications Practicing BA for 25+ years, Acclaimed Author, Versatile Trainer and Consultant Co-founder and COO @ Adaptive US I have 25+ years of professional experience in agile software development, requirements analysis, business analysis, IT GRC, and management consulting. I currently play the role of business analysis thought leader and product owner, SuXeed, Adaptive’s flagship learning solution. He has been part of multiple large system developments, In-country Value System for PDO Oman and the Color Data Management System for AkzoNobel. I was also involved in multiple large ERP implementation projects and was involved in one of the world’s largest change management programs in PricewaterhouseCoopers, for a large utility agency. I have conducted 300+ workshops in business analysis, requirements management, agile, software project management, Six Sigma, CMM, ISO 9001, and ISO 27001. I have guided 30+ six sigma projects in iGate, MACH, and Akzo Nobel. I hold Post Graduate Diploma in Management (PGDM) from IIM Ahmedabad and BE (Honors) in Electronics.

Requirements traceability: What, why and how

Written by LN Mishra on June 21, 2018. Posted in Articles.

Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated.

This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with the help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirement changes, cost, and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

Satisfy

The relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store.

Requirement

To list products in the e-commerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Storefront end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

10 Most Useful Business Analysis Tools

Written by LN Mishra on June 14, 2018. Posted in Articles.

https://www.linkedin.com/pulse/struggling-user-interfaces-try-little-secret-tool-dreamer-and-doerAs a practicing business analyst, trainer and consultant for last 25 years, I have come across many business analysis tools.

I was forced to use some of these tools because my clients and organization mandated some of them. I do read about a lot of blogs and articles about which business analysis tool is used extensively by industry. Many of them appear to be simple marketing propaganda by the tool vendors (or copy paste from someone else’s blogs) saying the particular tool is the greatest tool for business analysis.

Fundamentally, we need following types of business analysis tools:

To track requirements
Describe requirements in certain detail
Model requirements wherever feasible
Collaboration tools

One can get a toolset literally free for all these 3 types of requirements. Here is it true list of the tools that I have used extensively. I have no intent to please or promote any specific tool or organisation.

I am going to start with number 10 and go down to number 1.

10 Star UML

The tool I look forward to for any UML diagram is StarUML. I have a version on my system which is free which I believe is no longer free on the net. StarUML is a pretty simple software to learn to draw use case diagrams such as the Class diagram, State diagrams etc. In case your company is still in the waterfall world, you will find StarUML pretty useful tool to develop any kind of UML diagrams.

YouTube video links on Star UML:

https://www.youtube.com/watch?v=QWcbyturXVI&t=3s
https://www.youtube.com/watch?v=xObBewqkdk8&t=2s

9 Google Voice typing

Google voice typing is indeed a boon for me. I am a pretty bad typist and I used to have a terrible experience in trying to create documentation. With Google voice typing that pain is gone. In fact, this blog you are reading was created using Google voice typing. The same amount of documentation if I would have tried to do using MS word or any other tool, probably would have taken me 4 times more time and 10 times more pain.

8 Google drive

Another neat software from Google which allows us to share documents in a secured manner. It practically offers unlimited storage capability and for about $3 per month. You get humongous space to store and share your project artefacts.

7 Screencast-o-matic

Screencast-o-matic is a very little known tool but I found it extremely helpful. As business analysts, we need to ensure that all the discussions that we have with our stakeholders are recorded and kept for future reference. Screencast-o-matic does a fantastic job of recording our discussions and keeping them stored in a place like YouTube which we can access anytime later. One can make the YouTube videos private so that only your team members and stakeholders are able to access the videos. No more missing discussion points and no more worrisome fact that we missed something to note down during a discussion.

6 Skype

Skype is again a wonderful tool for remote working and collaboration with stakeholders. Today end users, developers could be in any part of the world. A tool like Skype allows us to coordinate and collaborate seamlessly irrespective of where we work.

5 BizAgi

BizAgi is another free tool that I really love. It’s very simple to use and is extremely powerful when you wish to draw business process models. The good part about BizAgi is, it also generates a fantastic documentation in MS Word.

4 MS PowerPoint

You will read lot of people saying death by PowerPoint and all kinds of stuff as how evil PowerPoint is.The fact is MS Office is not going to go away from corporate life in near future. Businesses need communication and presentation. Nothing beats PowerPoint at this time to share our ideas to our stakeholders.

3 MS Word

Among the Microsoft tools, I possibly hate the most is MS Word. I somehow find it extremely hard to work as effectively with MS Word is I can work with MS Excel on MS PowerPoint. StillMS Word is the most popular word processor that are stakeholders continue to use and hence we must be familiar in creating documentation using MS Word. The amount of BA documentation that we do using MS Word has come down dramatically over last 20 years but still there will be enough times when MS Word will be a good tool capture ideas, notes and discussions.

2 MS Excel

This is my most favorite MS tool. I do my entire BA documentation using MS Excel. I create wireframes using MS Excel. I use extended data matrix to understand UI requirements. If you learn use Excel well, I bet you definitely fall in love with Excel. It’s quite a powerful tool for many things that anyBA wishes to do including requirements management, user interface development, traceability matrix etc.

Article on Excel Prototype :https://www.linkedin.com/pulse/struggling-user-interfaces-try-little-secret-tool-dreamer-and-doer

Video on Excel Prototype:
https://www.youtube.com/watch?v=2iS7UVY4yXs&feature=youtu.be

1 Google search

Finally nothing beats Google search. Anytime you get stuck as a BA, you need some help, you need a particular template, just do a Google search. Anyone who learns to leverage Google will be a Super BA.

Requirements traceability: What, why and how

Written by LN Mishra on May 31, 2018. Posted in Articles. 1 Comment on Requirements traceability: What, why and how

Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated.

This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

Satisfy

Relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

Requirement

To list products in the ecommerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Store front end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

Identity crisis. Thy name is Business Analyst.

Written by LN Mishra on April 10, 2018. Posted in Articles.

Business analysts are truly a diverse community. I do not see any other profession which has so much confusion regarding what they should know and what should they do.

Ask a Project Manager. Everyone knows, project managers ensure projects are successful.

Ask a Technical Architect. Everyone knows, technical architect design robust solutions.

Ask a BA. Nobody is quite sure.

We business analysts do lots of things. We do often develop requirements, but that may not be true for some BAs. Business analysis often overlaps largely with consulting as well. Remember, many often BAs are considered as internal consultants.

Recently I met a very senior consulting professional in whose opinion, BAs are junior professionals who are asked to do documentation as no senior professional will agree to do that.

Why is this confusion for us?

Let’s understand how conveniently we roll 3 different types of roles into 1. That’s the culprit.

As per BABoK V3, BAs are change enablers. This is quite true.

However, change is a nebulous term and it can come in quite different shapes and sizes.

I have been lucky enough to participate in types of change projects, and based on the same, I have created a simple framework for understanding different types of changes.

Three different types of changes are:

Application changes:

Most organizations have tons of existing applications. They also may build new applications to support business in terms of analysis (reporting), minor or major changes. Majority of IT projects fall into this.

Changes done here may have limited impact on process or strategy.

Process changes:

Most organizations wish to improve their processes continually. They use various methodologies such as Lean, Six Sigma etc. to improve their processes. Process improvement and re-engineering projects fall into this category.

Changes done here may have limited impact strategy but can have good impact on applications.

Strategic changes:

Organizations need to make strategic changes to stay relevant. Competitors bring in new products and services. Technology changing quite fast.

So organizations need to introduce new products. They explore opportunities for mergers and acquisitions. They may also under major changes to organizational structure to stay relevant.

Strategic changes usually have large impact on processes and applications.

As a business analyst, depending on your competence and experience, one will perform one or more of these roles. However, it is unlikely that one will work on strategic and application changes as they are usually distantly placed with each other.

The skills required for different types of changes are also quite different.

For an application BA, knowledge of software can be very helpful.

For a strategic BA, understanding markets, competition and finance is essential.

Maybe it will be good if we specify what kind of BA we are and the organization also can specify what type of BA they are looking for.