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.
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.
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
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.
Prioritization of requirements is important for multiple reasons:
Version 3 of IIBA BABOK guide provides the following approaches to prioritize requirements:
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.
Numerous techniques are used for prioritization of requirements and they have been used in different conditions. Some of these are as follows:
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.
This is one of the simplest techniques used for prioritization of requirements. In this technique, we simply group requirements with the following prioritization groupings:
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.
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.
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
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:
Let me briefly mention two important techniques to use a constraint based approach to prioritization.
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:
You can ask these questions for every requirement and then categorize the importance based on the following matrix:
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
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.
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.
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:
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.
You can read the above blog post to know more about the key skills. But just to summarize these skills:
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 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.
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:
These two skills help in highlighting the customer orientation and the presentation skills.
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
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
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….
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.
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?
BABOK v3 has described 4 types of requirements as shown below:
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.
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.
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 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.
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.
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:
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:
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.
Transition requirements are specific period requirements. Examples of transition requirements are as follows:
A small video explaining the types of requirements is as shown below:
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.