Category Archive Articles

Why would I need a business analyst? Can’t a developer gather the requirements?

Why need business analysts-2

Why would I need a business analyst? Can’t a developer gather the requirements?

Recently came across this question on Quora. I thought that this question needs an answer as this is a pertinent question. Let me answer this by explaining the developer’s paradigm.

Developer’s paradigm

What Vs How: The strength of a developer/programmer is to write great piece of code. To write great piece of code, one must be good at understanding algorithms and must focus on “How things can be done?”. A developer must think about – “How can I write the best algorithm to achieve the results in the least possible time?”. Developers always think about solution.

Requirements gathering focuses on “What needs to be done? What is the current process and what needs to be done to improve the process efficiency?”. Requirements gathering process requires you to focus on “What” rather than “How”. You need to be more open-ended rather than close ended. This is one of the major factors as to why we need a specialized role like business analyst to gather requirements. Requirements gathering is always about focusing on problem and not solution. If you don’t focus on problem, you may be solving the wrong problem.

Language problem: Of course, I am not talking about English or French. I am referring to the gap between the language of business and language of programming. Java/Python like languages are very different from languages of describing business processes. A developer, who is great at understanding multi-threaded lingo, may find him/her at a loss, if the business is talking about derivatives or debit/credit. There is no superiority or inferiority but these require two different skill sets and learnings.

I am not, even for a second, suggesting that developers can’t do requirements gathering or perform the role of a business analyst (I have done precisely that in my career) but that requires some unlearning & re-skilling.

Cheers

Prioritization of Requirements

Prioritization of Requirements

One of the most important aspects of software planning and release management is prioritization of requirements. In this post, we are going to look at the the importance of prioritization, approaches of prioritization and challenges of prioritization.

As per IIBA BABOK Guide:

Prioritization provides a framework for business analysts to facilitate stakeholder
decisions and to understand the relative importance of business analysis
information.

Prioritization of requirements refers to development of an ordered list of requirements in order of their release order. This exercise is conducted in the presence of stakeholders, who are in a position to take a call on the priority of requirements.

Why do we need to prioritize requirements?

Prioritization of requirements is important for multiple reasons:

  • It helps in providing maximum business value withing given constraints like cost, timelines and resources. Most of the times, customer expectations are high, timelines are short, and resources are limited. In these cases, the best option is to deliver the product in the order of business importance.
  • Prioritization of requirements can also be done to minimize risk associated with the product development. Product components or modules with highest risk can be put in the high priority list. This helps in eliminating the risks and carrying on with the remaining project without any unknowns.

Approaches for prioritizing requirements

Version 3 of IIBA BABOK guide provides the following approaches to prioritize requirements:

  • Grouping
  • Ranking
  • Time boxing/Budgeting
  • Negotiation

Grouping/Ranking based approach: In these methods, the focus is on to assign a ranking or priority indicator to each requirement based on the discussion with the stakeholders. So, we can assign high/medium/low or numerical values to the requirements. Examples of these methods are Ranking, Voting, MoSCoW etc. We are going to discuss a couple of them.

Time Boxing/Budgeting approach: This approach is taken based on availability of resources. In a way, this is a constraint based approach. Based on availability of resources like team size, time frame and budget, the prioritization of requirements is decided.

Negotiation based approach: This is a consensus based approach, where stakeholders are engaged in a discussion. They brainstorm and agree on an ordered list of requirements.

Techniques for prioritizing requirements

Numerous techniques are used for prioritization of requirements and they have been used in different conditions. Some of these are as follows:

  • MoSCoW Technique
  • Hundred Dollar method
  • Voting
  • Ranking
  • Kano Analysis
  • 100-point method
  • Requirements triage
  • Binary Search Tree
  • Bubble sort technique
  • Analytic Hierarchy Process (AHP)
  • Minimal Spanning Tree (MST) & More…

This can be a long list, you can find more methods if you search. In this post, we can’t discuss all of them. I have selected couple of techniques based on their applicability in most of the scenarios.

MoSCoW Technique

This is one of the simplest techniques used for prioritization of requirements. In this technique, we simply group requirements with the following prioritization groupings:

  • Must Have
  • Should Have
  • Could Have
  • Won’t Have

That’s how the acronym MoSCoW originated. It’s a simple to understand technique and simple to implement. All the stakeholders discuss and arrive at the prioritization of requirements.

Ranking Technique

In this technique, a numeric rank is assigned to each requirement. The numeric values could be 1 to 10. Requirements with highest numeric value are then arranged and become the prioritized list of requirements.

There are other techniques which are based on prioritization by categorizing the requirements as high, medium, low essentially. There could be many variations of these technique but essentially the approach remains the same.

Challenges of these techniques

Even though voting, ranking and MoSCoW techniques are simple techniques, there are some practical pitfalls. These can really create difficult situations for every business analyst.

I would like to highlight one of the challenges, which is critical and can spoil the prioritization effort. While discussing the relative importance, you can run into the following issues

  • Customer stakeholders saying that all the requirements are high in priority, that’s why we have hired you
  • Customer stakeholders not able to decide priority
  • Ego clashes and internal politics leading to a conflict and you can’t decide on the prioritization
  • Customer team is large enough and prioritization meeting is not going to work

Handling these challenges

These are real challenges and as a business analyst or a project manager, you will definitely end up in these situations. So how do we handle them?

One of the important aspects is to add a constraint to our prioritization techniques so that customer stakeholders have a better way to decide on the priority.

What could be this constraint? These constraints can be time related, cost related or penalty related. So if we can ask the following questions, the task of prioritization of requirements become easier:

  • What is the benefit of developing this features? What is the business loss or penalty, if we don’t do it?
  • The budget is defined and within this budget as indicated against each requirements, let’s decide the priority
  • Similar constraint can be timeline as well

Let me briefly mention two important techniques to use a constraint based approach to prioritization.

Kano Analysis

Kano analysis was designed by Prof. Noriaki Kano in 1980. It was not designed for software industry but is being used quite effectively in all iterative methodologies like SCRUM. In this methodology, a question based approach is used. All the participants are asked questions to answer questions based on importance:

  • Rate your satisfaction if you have this feature
  • Rate your dissatisfaction if you don’t have this feature

You can ask these questions for every requirement and then categorize the importance based on the following matrix:

Prioritization of requirements - Kano Analysis

As you can see, the left side of the image actually shows the prioritization category. This technique is quite relevant if number of stakeholders is high or they can’t agree on the prioritization

Prioritization Based on Value, Cost, and Risk

This technique is mentioned in this article on process impact website. This article is written by Karl E. Wiegers. He talks about this quantitative approach. He has used a cost and penalty based approach. In this technique, each of the requirements is assigned numeric values to penalty, cost and risk. The final chart is shown in this article, which has a quantitative prioritization value for every requirement.

Conclusion

Prioritization of requirements is an important aspect of software development in the modern world. It helps in helping customer realize the business value quickly. It’s an important arsenal in the armor of every business analyst or project manager.

 

About Techcanvass

Techcanvass is an IT training academy for professionals offering courses in Business Analysis, automation testing and analytics. We are an IIBA Endorsed education provider (EEP) for providing IIBA certification programs.

Our business analysis courses are:

Business Analyst Training - ECBA Certification

Business Analyst Training – ECBA Certification

Business Analyst Training - CBAP Certification

Business Analyst Training – CBAP Certification

 

 

 

 

 

 

 

How do I need to prepare a business analyst resume with testing experience?

Preparing business analyst resume with testing experience

A testing professional can become a business analyst upgrading his/her skills needed at the entry level. But to get shortlisted for interview, your resume must align with the HR/Recruiter’s expectations. So, how should you prepare the resume for the business analyst role.

Which are the required skills for becoming a business analyst?

You can read the above blog post to know more about the key skills. But just to summarize these skills:

  • Requirement Elicitation Techniques
  • Requirements Analysis and Modelling
  • UML Modelling
  • User Stories Modelling
  • Writing Requirements Specifications (SRS, FSD etc)
  • SELECT queries in SQL for ad-hoc reporting and testing

These skills should get reflected in your resume. Let’s try and see how to incorporate them and build a winning resume

Pick up a good template

Pick up a decent looking template from the web. The best resource is Microsoft Word itself. You can pick up from the existing ones or search the web resources to get one.

Important thing about any resume is that it should not be too long or too short. One page resume is not for experienced professionals. You should also not create a 6 page resume. Ideal size of the resume should be 3 pages.

Highlight relevant skills

Focus on what might be expected from an entry level business analyst. I have already highlighted some of the key skills. So, you can highlight these business analysis skills on the first page using bullet points.

There are other areas of expertise, which are important for a BA. These are relating to customer interactions and communication skills. For example:

  • I was involved with the UAT co-ordination in the ………project. During this period, I co-ordinated with the development team to get the defects fixed and deployed.
  • I conducted the user training before the UAT phase. There were 30 people in the customer team.

These two skills help in highlighting the customer orientation and the presentation skills.

Showing Project experience

As a testing professional, you must have worked on projects to conduct functional testing. You must have good understanding of the project. Leverage that understanding to showcase your role.

In the role section for the project, you should mention the responsibilities so that the recruiter gets a semblance of your familiarity and exposure to business analyst.

The format of the project section should be as shown below:

Project:                 Project Name

Location:                Mumbai, India

Period:                   Dec’12 to Jul‘14

Role:                        Junior Business Analyst

Platform Used:    C#.NET, ASP.NET, LINQ, jQuery, JavaScript, XML, PL/SQL and SSIS

Technology:          Ektron CMS, Visual Studio 2010, SQL Developer, SQL Server Management Studio (IDE), Tortoise SVN, Plateau and WinSCP

Tools:                      Oracle 10g, SQL Server 2005/2008 (Database) and SSIS Packages (Data Warehousing)

Description:          The project focused on test preparation & admissions consulting company with three major modules on product development, student enrolment and finance management & development of 8 medium scale applications

My Responsibilities:

  • Responsible for requirement gathering & analysis from client
  • Maintained and improved existing system for better productivity
  • Handled bug fixing, performance testing, monitoring and reporting of the site
  • Developed and implemented automation tool for timely delivery of project activities
  • Prepared status reports, software requirements specification and scope document regarding project activities

Master your resume and work experience

Last, but not the least, you must be good in explaining all the information provided in the resume as a considerable time is spent by the interviewer on your resume.  Since I have conducted many interviews, this is what I prefer to do.

All the best….

About Techcanvass

Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.

We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.

Business Analyst Course | ECBA Certification training

Business Analyst Course | ECBA Certification training

Business Analyst Training with Banking Domain

Business Analyst Training with Banking

Business Analyst Short Courses

Business Analyst Training Self-learning Course

 

 

Cheers

Types of requirements as per BABOK

Types of requirements as per BABOK v3

In this article, we are going to discuss about the types of requirements as per BABOK v3. Business analysis body of knowledge (BABOK) guide is published by IIBA.

BABOK guide is also the reference book for all the 4 levels of business analyst certification – ECBA, CCBA, CBAP ad CBATL. If you are looking to go for a business analyst certification, you would like to know – which is the right certification for you?

Which business analyst certification is right for me?

 

What are the types of requirements as per BABOK

BABOK v3 has described 4 types of requirements as shown below:

  • Business Requirements
  • Stakeholders Requirements
  • Solution Requirements
  • Transition Requirements

Business requirements represent business objectives, stated by the customer. Stakeholders requirements represent the requirements of individual stakeholders. Features and characteristics expected of developed software application represent solution requirements. The transition requirements are the requirements needed to implement the software application successfully. Let’s look at these types of requirements in details.

Business Requirements

As per BABOK guide, the business requirement is defined as:

Statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

Every software application, conceptualized and initiated by an organization is meant to achieve a business goal like automating customer relationship management, sales and marketing etc. Business requirements are typically high level business goals.

An example of business requirement

A typical business requirement example is as shown for a customer relationship management system.

We would like to automate our customer relationship management system so that we can offer better customer services to our existing customers and can also cross-sell and up-sell to improve revenue.

Stakeholder Requirements

Stakeholder requirements as per BABOK guide:

Describe the needs of stakeholders that must be met in order to achieve the business requirements.

Stakeholders requirements are more individualistic. They may serve as a bridge between business and solution requirements. Stakeholders may specify their requirements specific to the project as per their perception.

Example of stakeholder requirements

The customer service department head may ask for implementing the project in a phase wise manner.

The customer service manager may ask for a mechanism to monitor the response time for each and every customer support request on a daily basis in order to improve the response time.

Solution Requirements

These requirements refer to the expected features and behaviour of the system. Solution requirements as per BABOK guide:

Describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution.

Solution requirements are the detailed set of requirements. These requirements will be used by the development team to develop the system.

Solution requirements are of two types:

  • Functional requirements: Functional requirements are the expected features of the system. Features like registering a user, making an online purchase etc.
  • Non-Functional requirements: Non-functional requirements are the requirements which are related to the behaviour of the system. Every page should load in 5 seconds is an example of non-functional requirement.

One of the important part of requirements gathering activity for every business analyst is to write the requirements well. Well written requirements should follow guidelines. We have discussed these guidelines in another post as shown below:

Top 6 characteristics of Well written requirements

 

Transition Requirements

Transition requirements refer to the requirements to enable successful implementation of a project. As per BABOK,

Describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.

Example of transition requirements

Transition requirements are specific period requirements. Examples of transition requirements are as follows:

  • The users must be trained to be able to use the system effectively
  • Previous years data must be migrated to the new system to generate comparative report

A small video explaining the types of requirements is as shown below:

Mythical Man Months in Software Projects

Man Months is one of the most misunderstood words in software industry. It’s used to refer to the effort required to execute a software project. Simply speaking, a man month refers to the effort of one developer working for a month.  However, the concept goes beyond this simplicity.

Frederick Brooks’s The Mythical Man-Month: Essays on Software Engineering, published in 1975, is one of the most influential books on software engineering. Amazon website says

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects.

This book has made the term “Mythical man months” extremely famous term though relevant. The basic premise of the book, also referred to as Brooks’ law:

Adding manpower to a late software project makes it later.

Which essentially means that man months is not a mathematical concept. So, if we estimated that a project is going to take 35 man months to complete, does not mean that putting 35 people on the project, will finish the project in 1 month.

Extending this concept further, if a project is getting executed, which was supposed to be 45 man months of effort, started with 5 members. After 3 months of work, we can say that 15 man months of effort is spent and the remaining effort is 30 man months. But this project had a deadline of 5 months. Now how do you finish the project in 2 more months (remember, 30 man months of effort is still pending)?

One may say, put 10 more people, making the team size to be 15. So 15 people working for 2 months will be equivalent to 30 months, done deal. Not True, this is what Brooks’ has discussed in great details in his book.

Sue Kim, in the blog post Mythical Man Month – The Cliff Notes mentions that:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.

This points to an important aspect of human communication in a team. More people open up more channels of communication leading to errors and delays. Any business communication text will explain that 15 members in a team, will have 15 *(15-1)/2 = 135 possible ways of conversations amongst them, leading to confusion and errors.

In the blog post titled Modeling the Mythical Man-Month, a mathematical model has been mentioned to explain Books’ law. Another mathematical model namely Putnam Model was published immediately after Books’ book to provide a mathematical model.

Cheers