Category Archive Articles

A list of Free Business Analyst training online

A list of Free Business Analyst training online

This article lists down a list of free business analyst training online. These courses are mostly video based except one of the them, which is text based.

In my research, I could not find a complete business analyst training course anywhere in a structured manner, chapter wise. But some websites did have multiple business analysis related videos and I have tried to put them in a sequence for easy viewing and comprehension.

This list of Free business analyst training online is compiled for professionals, who wish to become business analysts. These courses are no way comprehensive (Freebies can’t be), but they are good resources to get started.

IIBA Business Analyst Training resources

International Institute of business analysis (IIBA) is a leading certifying agency based in Canada. It conducts online webinars on business analysis topics. Some of these webinars are Free for everyone. I have selected a few of them. Go through these  in a sequential manner:

Becoming a Business Analyst

Seven steps to mastering business analysis

Capturing Requirements

Understanding Use cases

Prototyping

Modelling Data

Validating Requirements

LinkedIn Business Analyst Training resources (1-month Free Trial)

I found these videos to be well made with good explanations. There are multiple free videos and you need to scout through them to figure out, which ones are meant for entry level business analysts. So, I have made the list for you, which will get you started.

Start with: What is business Analysis?

Next: Requirements Elicitation & Analysis

Next: Handling Requirements in Agile Projects

There are many more videos available but you can access these videos for Free with 1-month trial only. I feel one month should be good enough to go through these videos.

Smart-BA Business Analysis training resources (PDFs and PPTs only)

Smart-BA has a resource page providing a list of business analyst training materials. These are PDFs or powerpoint presentations. The PDF documents are arranged in 3 chapters and are useful.

Module 1: Objective Analysis

Module 2: Scope and context analysis

Module 3: Functional requirements analysis

There are other resources as well on this page.You can visit other resources here.

Srinivas S’s business analyst training videos

This business analyst training is a 6-part series and is a recording of a classroom session. But recording is good and you can also view the presentation.

Video 1: https://www.youtube.com/watch?v=aGCzJ5HRqUs

Other videos are linked to this video and you can find links on Youtube page.

BAExeprts Business Analyst Training online

This page has more than 30 videos but again they are not listed in an order. So I have selected a few of the videos. Here is my list of business analyst training videos from this website.

Start with: Overview of Business Analysis for Information Technology

Next: An introduction to business analysis Techniques

Next:Business Analysis and System Development Methodologies (SDM)

Next:Business Analysis and Waterfall Methodologies

Next: Business Analysis and Agile Methodologies

Next: How to Identify stakeholders

Next: Business Process Analysis

Next: Business Data Modelling

Next: How to write data and process specifications

You can go through other videos as well once you have gone through these videos.

Bridging-the-gap Free business analyst training course

Laura Brandenburg, the founder of Bridging-the-gap offers a short course on business analysis providing guidance on business analysis career and some free tips.

This course requires a registration and you will receive the video links in the email.

Bridging the Gap Business analyst training page

TECHCANVASS’s Free Business analysis Fundamentals Course

Techcanvass also offers a free business analyst training online. These videos are recordings from the online training on business analyst certification course. These videos are listed on our Blog page in a particular order for better understanding.

I am reproducing the list here with links:

Module 1: What is business Analysis?

Module 2: Business Analyst role & responsibilities

Module 3: Understanding software development process Part-A

Module 4: Understanding software development process Part-B

Module 5: Software Development Process (SDLC Methodology) basics

Module 6: Understanding requirements, its types and common technoques

Module 7: UML requirements Modelling

Module 8: Verification and validation

This list may not be the most exhaustive list but I have tried to provide you a list of Free business analyst training online, which will help you in kick starting your BA career.

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 Training - ECBA Certification

Business Analyst Course

Business Analyst Training with Banking

Business Analyst Training with Banking

Agile Business Analyst Training

Agile Business Analyst Training

Business Analyst Training with Trade Finance

Business Analyst Training with Trade Finance

ECBA Exam Simulator

ECBA Exam Simulator

BA Training with Healthcare Domain

BA Training with Healthcare Domain

BA with Investment Banking Domain

BA Training with Investment Banking

How important is domain knowledge for a Business Analyst?

Importance of domain knowledge for a Business Analyst

How important is domain knowledge for a business analyst? Let’s examine this in this post. I am going to look at the domain knowledge from at least two perspectives:

  • What is the level of expertise needed?
  • Is it a pre-requisite to start as a business analyst?

I am also going to leave you with some resources to learn basics of a few domains.

What is domain knowledge?

Domain is a specified sphere of activity or knowledge.

The literal/dictionary meaning is very clear and obvious. In the IT industry, the domain knowledge is used to refer to the knowledge and understanding of the business sector or specific business process of a project/product.

So, a domain could be Banking, Insurance, Trade finance at a higher level or could be retail lending process, funds transfer at a more specific level. A domain knowledge refers to the understanding of the specific domain area. So, what does it include?

  • Understanding of the of the sector/industry/segment
  • Understanding of the key concepts/vocabularies
  • Understanding of the business processes
  • Understanding of the implementations and its challenges

For example, If you would like to be good at understanding retail banking, you need to understand the following, for example:

  • Customer acquisition, cross-selling and up-selling
  • Unified customer view
  • Retail banking operations like account opening, funds transfer, deposits etc
  • The back end processes
  • Integrations with external entities like bank transfer, SWIFT payments etc

Which domains are relevant and important for IT industry?

Some of the important sectors for IT industry and for business analysts are as follows:

  • Banking, Financial Services and Insurance (BFSI)
  • Manufacturing
  • E-Commerce
  • Internet Services (Online apps for travel, cab booking etc)
  • Telecom

The importance and relevance is based on the simple fact – Which of the industries provide substantial business to the IT industry. BFSI (Banking, Finance services and Insurance) has always been the top sector for several decades.

Why it’s important for Business Analysts?

Let’s consider the scenario of working in BFSI domain as a business analyst or for that matter Telecom or healthcare? As a BA, you need to interact with the customer to understand the business needs/requirements.

During the requirements discussions, the customer will be stating their expectations in a language, which will comprise of:

  • Domain specific terminologies
  • Process steps specific to the project

Example: You are discussing the funds transfer process for developing a mobile banking application for an India bank. You may come across the following statements:

The funds transfer happen through NEFT, RTGS, UPI and IMPS using the RBI and NPCI infrastructure. Once the beneficiary is added and approved, our customer can initiate the funds transfer. These transactions are carried out the NPCI/RBI networks. The confirmation is then given to the beneficiary. Each of these networks may have specific formats for carrying out transactions

There is no way, customer is going to explain you (and you should not even ask them) the meaning of NPCI, NEFT, RTGS etc and how do they work? If don’t have a clue of these terms, you may miss out many important aspects as you may not be able to related to them (or may not be able to understand the importance).

The domain knowledge is important for business analysts, because this enable you to

  • Understand not only the stated needs but also the unstated ones as you understand the process and concepts
  • Value add by suggesting improvements, thereby improving your credibility. (This comes with experience)

Level of domain expertise for business analysts

As an entry level business analyst, you are not expected to possess domain knowledge. Understanding of requirements capturing techniques, UML modelling, requirements analysis and SRS/FS understanding are more important as an entry level business analyst. However, it is always an added advantage to have basic understanding of a domain like Banking, Insurance etc.

However, as a practicing business analyst, domain knowledge becomes important. Domain knowledge and expertise grows with experience and number of projects (of that domain), you are part of. This is a hard to replace expertise and enables you to gain more and more credibility as a professional.

A pertinent point is to consider is – specialization Vs generalization. Do you need to be an expert in one domain or you should be a generalist having broad level understanding of multiple domains. Well Jury is out on this one and it will purely depend on the business scenario. Specialization is good if the growth opportunities in that domain is substantial. One such example is banking domain.

However, generalization is like Jack of all trades and it’s pretty useful in downturns as it improves your chances of being relevant always.

Domain Basics Resources

I have selected a few resources, which you can use to learn basics of some of the domains. It is by no means the complete list:

Khan Academy –

A comprehensive course on basics of banking series. There are multiple videos in this playlist. You can watch it here.

Investment banking basics

An animated and short video. You can watch it here.

Insurance Basics

A simple explanation of insurance industry. You can watch it here.

Another insurance fundamentals video. You can watch it here.

Types of life insurance

A nicely presented video on types of life insurance. You can watch it here.

Health Insurance basics

Basics of health insurance. An animated video. You can watch it here.

About Techcanvass

Techcanvass offers IT certification courses for professionals. We specialize in Business analysis and automation testing courses.

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.

We also offer other domain training courses for business analysts. Here is the list.

Business Analyst training with Banking domain

Business Analyst training with Insurance Domain (Coming up)

Business Analyst training with Investment Banking domain

Business Analyst training with US healthcare domain

Are business analysis and analytics the same?

Business Analysis vs Business Analytics

Are business analysis and analytics the same or there is something common between them? In this post, I am going to examine the topic – business analysis vs business analytics. I will also examine if they have a symbiotic relationship with the help of a case study.

This Business Analysis is a discipline and encompasses wide range of activities. The primary objective of business analysis is to solve business problems. Business Analysis includes the following activities:

  • Problem/needs analysis or requirement Analysis
  • Requirement modeling
  • Solution analysis
    • Benefit-Cost Analysis (BCA)
    • Risk Analysis
    • Feasibility Analysis
  • Organization Readiness Assessment
  • Change Management

Organizations have to evolve and transform themselves in order to survive and remain competitive in the market. Business Analysis plays a key role in enabling the organization to transform efficiently. Business Analysts are responsible for carrying out the business analysis activities.

Let’s take an example where business analysts play an important role.

A manufacturing company is finding it difficult to meet the quality standards of the deliverables promised to the customer. This problem was solved by implementing an ERP system as well as introducing more robust processes of communicating the product specifications to the manufacturing team  by the Sales team.

As you can see, solving of the business problem, not only involved transitioning to a new software solution (ERP) but also a process adaptation. Business analysts not only help in recommending the solution but also help the organization in implementing the solution efficiently.

Would you like to know more about the Business Analysts:

Business Analyst career and growth path

What is Business Analytics

Business Analytics is defined as the scientific process of transforming data into insights for making better decisions. Using data to make decisions is not a new phenomenon. It has been into practice for a long long time. However, it was only in the 1950s that tools were developed to capture and analyze large amounts of data to enable quicker decision making.

Business analytics solutions typically use data, statistical and quantitative analysis to measure past performance to guide an organization’s business planning.

The real magic of Business Analytics is its capability to predict and prescribe future course of actions by analyzing current and historical data patterns.

Types of Business Analytics

There are four types of business analytics and they are-  decisive analytics, descriptive analytics, predictive analytics and prescriptive analytics. I will discuss these types of analytics in my next posts.

Now let’s take an example to understand business analytics.

Many of you must have used LinkedIn. LinkedIn always shows you a list titled “People you may know.

(A screenshot below)

Are Business Analysis and Business Analytics the same?

 

LinkedIn had millions of users (till last estimate it had 225 million users). The “People you may know” list involves matching 225 million against 225 millions to find common threads. The basis of this analysis could be connection of connections (1st , 2nd and 3rd degree connections) along with organizational overlap and many such parameters. Making sense of such large amounts of data is the domain of analytics (in this case prescriptive analytics). The Analytics tools use current and historical data (registered users, their connections, their organizations etc) to prescribe potential connections.

But is there anything common, afterall?

Now the Big Question – is there a relationship between Business Analytics and Business Analysis?

Why did LinkedIn use analytics to create “People you may know section”, it must have cost them a bomb (aka millions of Dollars)? The reason was to increase the number of users and hits to its website, as that was critical to its survival.

Was this a business problem? Of course, yes. The business problem/challenge was to increase the number of users/hits to the website to grow. Many solution options must have been shortlisted, “People you may know” section was one of the solution, which was found to be a recommended one. This usually comes under the domain of a business analyst. A business Analyst conducts cost-benefit, feasibility and risk analysis to recommend a solution. That’s the reason, it was chosen, implemented and actually succeeded in its objective. Since then, the number of registered users and hits have increased many fold.

So, what is the answer to the question – is there a relationship between Business Analytics and Business Analysis?

In my view, Business Analysis encompasses business analytics as one of the means to find solutions to the business problems. For Business Analysts, it may prove to be a valuable tool, especially in the cases where large amounts of data is available to predict or prescribe solutions.

I have recently recorded a video on this topic, you can view this video below:

If you are interested in knowing more about Business Analytics, here are some useful resources for you:

What is Business Analytics

More on types of Business Analytics

What is Descriptive Analytics?

Career in Business Analytics

 

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 Training

IIBA Business Analyst Training


Business Analyst Training with Banking Domain

ECBA Training with Banking Domain

Agile Business Analyst Training

Agile Business Analyst Training

Cheers

Top 4 mistakes IT professionals make which spoils their careers

Top 4 mistakes IT professionals make which spoils their careers

disclaimer: This article is purely based on my experiences as an IT professional. Purely personal experiences and may not be valid for every professional.

Being in the IT industry for over two decades, I have experienced some great moments of joy and despair. Going home at 4 AM because of a crucial release, or going for a team lunch post UAT sign off or getting a kickass email from the customer are all itched on my memory forever. Every such moment was an experience.

Talking of experience, I have had experience of working with some really high-performance, intelligent and capable people as well as some really average ones. I am in touch with most of them and when I meet them, I try and understand what made them click or fail.

Over the years, I have developed my own theory on what are the critical success factors for an IT professional. Thought to share with you. These are top 4 mistakes IT professionals make in their professional lives, which literally spoils their growth prospects

Boss is only for assigning work

In my career, I have seen people who interact with their bosses or immediate managers, only when boss calls them for assigning work. Not good. Be practical, your supervisor is not only responsible for assigning work to you but also for your role, your growth as well as your increments. You don’t need to buttress your boss but you must definitely try and build a cordial relationships with him/her.

Let me share the benefits of cordial relationship with bosses. In later part of my career, I never had to put up my resume on Naukri or Monster. Why? Because whenever, I wanted to change, I would talk to one of my ex-managers and that’s it. Moreover, it saved me a lot of search time as well as enabled me in getting better or desired roles & salary, which would have been difficult otherwise.

This is just one aspect but this can help you in many other aspects as well. If you are setting up your own startup, it can help you in getting contacts and even some deals.

So the key take away is to build relationship with your bosses.

PS: This section is meant for bosses who are not out there to make your life hell. In that case, you know what do you need to do – Leave your Boss.

I love this technology, every other technology is useless

This is something I never understood. Yesterday, I was having a discussion with a senior programmer, who had resigned from his current company. We were talking about the reasons for his resignation and it was- the company had decided to move to a different technology and he was not keen to work on that. Well had it been a move from PHP to Java or .NET to Java – I could have understood. But we’re talking about moving to Angular.JS from ASP.NET/C#. So I asked him, if the company decides against it, will he continue, he said – yes.

Excuse me!!

Technology is an enabler and as an IT professional, you must be looking at technology as a tool to solve problems rather than choosing the problem to suit a technology.

If you take this kind of an approach, you will soon become a pariah or will seriously limit your opportunities in any organization as well your own growth.

I can’t interact with people who don’t understand technology

This one is my favorite. Over the years, I have got used to this situation, however. People, with high Technology quotient (TQ), believe that it’s futile to discuss anything with low TQs or zero TQs people.

We all must understand, business software applications are developed for a customer to solve their problems. We earn our salaries because customers are paying for these software applications.

This means that to be successful in this field, we must gain experience in solving customer problems. Problems can only be solved, if they are understood correctly and for that we need to interact with customers, who may not be as tech savvy as we would like them to be.

So, do we have an option of not interacting with them?

Being a loner

Do you identify with it? No, then it’s good. Many of us believe in – doing work sincerely, leaving rest to GOD. Big mistake. You will be loosing out big time.  Two major drawback of being a loner:

  • It’s all about visibility in corporate world, dude.If you are not seen, you are dependent on somebody to help you grow. Do you want yourself to be in that situation? You are talented and hard-working, so go out and show it. Make presentations, conduct training sessions for your team mates and so on.But make sure, it is published and known to people (Use Intranet or HR website)
  • Corporate offices are becoming hotbed of politics. People manipulate, backbite or do whatever is possible to sabotage other’s careers (rather than focusing on building their own). If you are not aware of whats happening around you, you are going to be at a loss for sure…keeping abreast of office politics is important and that can only happen, if you interact – give and take policy.

These are not the only mistakes, we make as IT professionals but I chose the most important ones, as per my understanding.

Will be eager to hear about your experiences as well.

About Techcanvass

Techcanvass is an IT certifications training academy specializing in Business Analysis, Automation Testing and Project Management certifications. We are IIBA endorsed education provider, iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.

 


Business Analyst Training
IIBA Business Analyst Training

Business Analyst Training with Banking Domain
ECBA Training with Banking Domain
Agile Business Analyst Training

Agile Business Analyst Training

Cheers

Top 6 Characteristics of an effective Project Manager

Top 6 Characteristics of a great Project Manager

Top 6 Characteristics of an effective Project Manager

Project Managers play a vital role in the success or failure of a project being the captain of the ship. Every organization recognizes the importance of an effective project manager. What makes these project manager click?

We have compiled a list of 6 characteristics of an effective project manager. The characteristics are not presented in any specific order.

Follow KISS principle

“Keep it simple, Stupid” – The KISS principle was coined by Kelly Johnson while working on airplane designs for Lockheed Martin. He and his team were designing spy airplanes for war zones. His goal was to make a spy plane, which could be repaired by using simple tools and techniques, so that even average mechanic can repair it in the war zones. He was not trying to make the best spy plane but a simple to use war plane which served the functional purpose.

Warren Buffet once said: “There seems to be some perverse human characteristic that likes to make easy things difficult.”
Let’s take an example of an e-commerce website. An e-commerce website is meant to facilitate the online purchase of a product, generating revenue. You may aim to make the best looking website with lots of bells and whistles but, at the end of the day, users must be able:

  • To search the products easily and
  • To make the payment, even as a guest

If your website does not provide these two basic features mentioned above, all your effort is futile, even though you end up making the best looking e-commerce website in the world.

So the great project managers, keep it simple as much as possible to achieve the business goals or objectives.

Set the expectations rights

One of the important traits of a project manager is to set the expectations right, be it for team members or customers. We may call it as expectations management but it plays a crucial role. One of my seniors always advised me to follow a simple maxim – “Promise less and deliver more”. Instead, what most of the managers do is the exact opposite.
However, having handled many projects myself, I have to admit that it is not possible every time because sales team would have already over committed in winning the deal. Well, in that case, read the next point.

Know how to get things done

I, personally, feel that this is the most important characteristics of a great project manager. Pulling the right strings at the right time is vital. Be it a team member or a shared services in the organization, great project managers know how to get things done. If a team member is not delivering, they will sit with him at his desk to get the things done by encouraging or helping him. If a shared services group like infrastructure services, is not moving as fast as it should (for getting a piece of hardware), they know how to use a customer or senior management threat to make it faster.

So, It’s basically “horses for courses”. But just be little creative to get things done.

Know your subject

All great project managers, understand the language of the customer as well as the team members. You don’t need to be an expert in that domain, be it technology or business but be good enough to understand the context yourself. You should not need an interpreter to understand their language, if it is so, you have lost it. Upgrade yourself, there is plenty available on the internet on every subject. Take a MOOC course or watch a Youtube video, which is free. Just brush up the basics.

Review, Review & Review

One must be a systematic and periodic reviewer to be really successful as a manager. Projects can’t run on auto pilot mode, it needs to be nurtured and controlled. Managers must know, what’s happening in the project, whether right or wrong on a daily basis. A proper reviewing mechanism means setting up the review agenda as well as the frequency. For larger teams, line managers (team leads and project leads) play an important role.

Great project managers are relentless reviewers- unless you know what’s wrong with the project as early as possible- how do you fix it?

Present a calm demeanor

Can you remain calm in the midst of a crisis? Most of us can’t. It’s natural to be upset when things are not going your way. As you might know, software projects carry multiple risks and any of the risks may materialize.

Great project managers are necessarily not the bravest of the souls but they always present a calmer exterior. This is absolutely critical to keep the morale of the team intact. It also gives the impression to everyone (Team, Management and customers alike) that things can be managed, even though it looks bad. Showing calmness – is not an in-born thing, it can be learnt easily.
This article is based on my industry experience and my discussions with my colleagues and seniors in the industry. Let me know if you have any feedbacks for me at abhishek@techcanvass.com

Why do we go wrong in Requirements gathering?

Why do we go wrong in Requirements gathering?

Requirements gathering is probably the most critical phase of every software project. But empirical data suggests we are not doing well in this. So, why do we go wrong in requirements gathering?

Before getting into reasons for it, I must share with you one of my favorite videos. It’s a funny take on the requirements gathering meeting.

The video highlights a few important points:

a) Customers, sometimes, also don’t have clarity on what exactly do they want?

b) Why don’t we ask this question – Why do you want this? What is the purpose of this feature?

All the studies about the success and failure of software projects have found that lack of clarity on understanding, is one of the top reasons for project failure. In this post, I am going to touch upon top 4 reasons for  – Why do we go wrong in Requirements gathering?

Not Asking “Why”

The question “Why do you want something to be done” is one of the most important questions – a Business Analyst can ask? It not only enables you to understand the actual requirements but also enables the customer to explore and understand – what do they want and why?

It’s important to associate requirements with the business objective and goal. Every feature or function included in the system must be linked to the end objective and not because it is a fanciful idea.

One simple example will further explain this aspect. Let’s say you visit a doctor because you have fever.  Once you meet the doctor, you may tell the doctor – “Doctor, I might have viral fever as I am having nausea and headache as well?” A good doctor  never takes that statement on face value, instead the doctor asks questions to do his/her own diagnosis. These questions could be:

  • Since when you are having fever?
  • Did you measure it?
  • Are you having body ache?
  • Do you feel chill?

Based on the answers to these questions, the doctor may ask for further investigation. Unless the doctor is sure of the actual reason, he/she can’t treat it well.  Imagine doctor giving medicines based on our judgement rather than his own diagnosis.

One of the most important mistakes, we make as business analysts is to not use enough “Why”. What is stated by the customer stakeholder during requirements elicitation meetings should not be taken at face value.

Making Assumptions

Our experience teaches us a lot. Business processes understanding is just one of the skills, a BA acquires in his/her career. Over the years, working in variety of projects, build our skills about an industry, its processes and its implementations.

This helps us in a lot of ways. But many a times, we also assume that the current customer organization will also be doing this function as the previous customer. is that always true? More often than not.

Every customer is different. 

So, How can we avoid this mistake? By keeping in mind a few things:

  • Treat every customer as different and so their processes
  • Always challenge your assumptions
  • Don’t hesitate in asking questions, even though simple (Ego is your biggest enemy)
  • Validate the requirements properly

As a business analyst, we can start by using open and close ended questions at the right time. Open ended questions are asked to understand the processes and its steps. Whereas close ended questions are asked to confirm an understanding. – Ask open ended questions for understanding requirements.

Examples of open-ended questions:

  • What is your cross-selling process?
  • What do you do when the due date for bill payment is passed?
  • What is the process of account opening? How many steps are involved?

An account opening process for ICICI Bank is different from Kotak’s bank even though they may be savings bank account. The steps carried out in the back-end are completely different.

Ignoring end users as stakeholders

End users: Users or customer employees, who are the actual users of the software (once it is ready). They are not the managers, who feel that they know every detail.

Ignoring these end users can prove to be counter-productive. It can happen in a project, if:

  • Customer managers/directors/CIOs tell the IT team that they know what is needed and there is no need to talk to the end users
  • We, as business analysts, feel that the end users are not savvy enough to give us valuable details.

It’s not something, we should avoid. The end users are the actual users and they can provide us important inputs from the ground zero.

 

Not validating requirements

We are used to test the developed software thoroughly but miss out on validating the software requirements, the right way. The reason for this is that we feel that verifying the SRS/FS using a checklist is validating the requirements or sending the well-written SRS document to the customer (for going through it and confirming it). That’s far from the truth.

A perfectly verified requirements specification can produce completely useless software product. Why?

That’s because verification of requirements only look at what is written and documented. It does not check if the documented requirements will be able to help customer achieve the business goal. Most of the times, it does not.

Validation is the process of checking the requirements (It can be in any format) with respect to the business objectives/goals. How do we do it? And how we should not do it?

  • We don’t do it by sending a 300 page SRS document (Do you think customer will read it?)
  • We do it by creating prototypes, demonstrate it and get an agreement in a collaborative manner?
  • We can do it by creating demos or proof of concepts also?

In the next article, we will be discussing the difference between requirements verification and validation. You might like to look at the following post:

Top 6 characteristics of Well written requirements

Conclusion

As a business analyst, we should be aware of the factors, which prevents us from missing out on requirements. Requirements are the basis for the software development and getting them right, is our responsibility.

It’s important that we make ourselves aware of all the factors and aspects, which cause impediments in getting the requirements right.

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 Training

IIBA Business Analyst Training


Business Analyst Training with Banking Domain

ECBA Training with Banking Domain

Agile Business Analyst Training

Agile Business Analyst Training

Cheers

Top 6 characteristics of Well written requirements

Top 6 characteristics of Well written requirements

In this article, I am going to discuss top 6 characteristics of well written requirements. Requirements are key to the success of a software project.

So, how do you ensure that the requirements are well written. This is achieved by verifying the key characteristics of requirements.

Reason for failed projects

Bad or incomplete requirements have been one of the top reasons for most of the projects, which fail. Standish group publishes CHAOS Report every year on the track record of software projects. The pie chart below shows the top 10 reasons  for the failure of the projects, for the period 2011-2015.

challenged-projects

 

As you can see incomplete requirements is one of the top reasons for the failure of the projects. So, its important to understand, how can we make sure that requirements are documented correctly.

Types of requirements as per BABOK

 

Characteristics of well written requirements

Here are top 6 characteristics of well written requirements specifications:

  • Complete
  • Consistent
  • Feasible
  • Modifiable
  • Unambiguous
  • Testable

Complete

The requirements must be complete, what is the meaning of completeness? It means that all the required information to implement (read Code) the requirement. There is no need to assume anything in order to implement the same. One of the important aspects of completeness is to also have measuring units, if applicable.

In case of an error, the system must exit gracefully.

I am sure, many of you must have seen this requirement before. This is an incomplete requirement as it does not provide all the information needed to implement the exit, in case of error.

A complete requirement would be as follows:

In case of an error, the system must show an error page to the users with the following message:

Oops! We have encountered some error and working on it. In the while you can go to the home page and try other options or write to us about what were you doing, so that we can help. Our email id is support@abc.com

Consistent

Consistency is an important aspect of requirements. It means that all inputs to any process, must be processed similarly. It should not happen that processes produce different outputs for inputs coming from different sources. Consistent requirements also mean that you will not find a contradicting information in the SRS document. Let’s look at the following two requirements:

Req1: The invoices will be generated and sent automatically based on the milestones achieved with a copy to the accounts department

The second requirement mentioned in the same document

Req2: The accounts department will generate the invoice based on milestones achieved and will send it to the customer.

The requirements mentioned above are not consistent as they are presenting contradictory information.

Feasible

This is one of the crucial parts of requirements capturing. All the requirements included in the SRS must be feasible to implement. A requirement to be feasible must be:

  • Implementable within the given time frame and budget
  • Implementable using the existing and chosen technology platform
  • A feature, which will be used by the end users

Let’s look at some of the requirements below:

The developed software must be reliable and should not crash.

Next example:

The developed software must be free of defects.

Both the above requirements are not feasible. There is no software which is free of defects.

Modifiable

Every SRS document must be modifiable. In the modern software projects, requirements are never static and don’t stop coming after the SRS document is signed off.  We can’t expect the customers to stop altering the requirements or adding new requirements as we also need to look at business needs.

So the best way to manage the requirements is to manage these changes. In order to do so, we must have an SRS, which clearly identifies each and every requirement in a systematic manner. In case of  any changes, the specific requirements and the dependent ones can be modified accordingly without impact the others.

Unambiguous

Unambiguous means there could be only interpretation of the requirement. If a requirement is defined in such a manner that it can only be interpreted in one way, it means that the requirement is unambiguous. All subjective words or statements must be eliminated from the requirements.

Let’s look at this requirement:

All the screens in the system must load quickly.

Do you think, this statement is clear? Certainly not. Nothing can be understood from the word “quickly”. It must specify clearly what is the meaning of “quickly”. A better version of this requirement would be:

All the screens in the system must load within 8 seconds.

Testable

A testable requirement can be defined as a requirement, which can be tested and validated using any of the following methods:

  • Inspection
  • Walkthrough
  • Demonstration
  • Testing

In this manner, it is possible to ensure that the requirement has been implemented correctly.

Let’s take an example and examine if it is testable:

The system must be user-friendly.

If this is allowed to be part of the final SRS document, how will you test it once the software is developed and is ready to be delivered for the UAT. It is not testable. So a better example would be:

The user interface should be menu driven on the top of the website along with site index. A tool tip for all the text boxes must be provided.

Let me know if you feel, there could be any other points.

 

~Cheers

Business Analysis Basics

Business Analysis Basics

In this business analysis basics tutorial, you will learn – what is business analysis, role of a business analyst & responsibilities of a business analyst. Business analysts have been gaining importance in the IT industry, especially in the last few years. This trend is expected to become better in the coming years.

They play an important role by enabling the customer organizations implement a software solution effectively and efficiently. Business analysts work as an intermediary between the customer and the software teams to understand & capture the requirements and communicate with the technology team.

This blog post on business analyst basics is intended for any professional (IT or non-IT professional), who would like to become a business analyst.

What is Business Analysis?

International Institute of business analysis (IIBA), Canada defines business analysis as:

Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.

Business analysis is the discipline of identifying business needs, determining the best-fit solution and measuring the effectiveness of the solution. Business analysis comprises of three key elements as shown below:

Business Analysis fundamentals

Problem Analysis and Definition

The first element of business analysis is to understand the problem/needs of the customer. This is possibly the most important element of business analysis practice. Identifying the correct problem is necessary before we can attempt to solve it.

Albert Einstein once said,

“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it,”

Nothing highlights the importance of using right techniques and methodology to understand the problems or needs, correctly. Needs are high level problem statements or business goals. The needs must be detailed out to help the software development team to develop a software application. The detailed version of needs is referred to as requirements. We will discuss requirements and how does it evolve, in the tutorial later.

Solution Evaluation

The second element of business analysis is to determine – how to address or to solve the customer needs. Evaluation of a solution can be conducted on multiple parameters, some of them are as shown below:

  • Cost vs benefit
  • Risks analysis
  • Financial analysis like Net present value
  • Features of the solution & others…

Basic evaluation can be done based on cost and benefits (popularly known as Build vs Buy). How does it help the customer? This analysis helps in taking a decision to develop a solution from scratch or buy a product from the market.

For example, a customer may decide to develop a Financial accounting system from scratch or may decide to buy a product like SAP, Oracle E-Business suite or Tally.

PS: The actual development and implementation of the solution is done by technology team and is not part of business analysis practice directly

Solution Assessment

The third and last element of business analysis is about measuring the solution effectiveness. This is done by planning and implementing the ways to measure “What was supposed to be achieved as business goal?”.

For example, if the customer organization wishes to improve the revenue in a state by USD 1 million, this is a rather straight forward measurement.

Similarly, we can ascertain the metrics (the parameters to measure) and capture the data to compute the metrics, once the solution is implemented. The actual values of metrics vs the expected value of the metrics indicates the success or failure of the solution. Corrective measures can be taken to fix the problem.

In this chapter, We discussed the business analysis practice and its elements. Now We will focus IT business analyst and their role and responsibilities:

  • Who is a business analyst? Who is an IT business analyst?
  • What does an IT business analyst do? What are the roles & responsibilities of a business analyst?
  • What are the required skills of a business analyst?

Who is a business Analyst?

A business analyst is a professional who is engaged in the business analysis activities. A business analyst may not be conducting all the business analysis activities in every project or initiative. However, a business analyst must be aware of these skills.

The focus of this tutorial course is to discuss the Business Analyst role in the IT industry.

Role of an IT business analyst

An IT business analyst works with customer as well as technology team on a day-to-day basis. The diagram below shows high-level view of an IT business analyst role:

Business Analyst Role

An IT business analyst works as an intermediary between the customer and the technology team to understand the customer needs and communicate it to the technology team.

Business Analyst’s Responsibilities

A business analyst performs multiple tasks during the software development process. We can list down the key responsibilities of a business analyst as below:

  • Eliciting Requirements: One of the primary responsibilities of a business analyst is to co-ordinate with the stakeholders to gather requirements for a software system. Business analysts use one or more of the elicitation techniques to do so. Eliciting requirements involves multiple steps and we are going to discuss it in detail.
  • Preparing Requirements Specifications: Once the requirements are understood, analysed and reviewed, a document is prepared in the appropriate format for the stakeholders as well as for the software development team to take it forward.
  • Managing requirements and changes to the requirements: Requirements need to be kept up-to-date throughout the life of the software in existence. Requirements can be managed using techniques such as RTT, Backlogs etc. It’s quite common to have changes to the requirements during the software development lifecycle and business analysts handle the changes to the requirements using a defined change request process.
  • Functional Testing: Business analysts also conduct functional or system level testing, where they check the business processes and scenarios before the system is handed over to the customer for User acceptance testing (UAT). The customer team tests the software before accepting it for their usage.
  • UAT Co-ordination: During the testing conducted by the customer stakeholders, the business analyst co-ordinates with the technology team to get the defects fixed.

The diagram shows the responsibilities of a business analyst:

Business Analyst Responsibilities

In this business analyst basics tutorial, we discussed about the business analysis fundamentals, role of a business analyst and its responsibilities.

Related Articles

If you are a business analyst aspirant, you may like to know about the certifications. Refer to the article- Business analyst certification for beginners.

A list of Free business analyst training courses may also be a useful resource for you on this Techcanvass Blog. These free courses will help you to build on the learnings from this business analyst basics tutorial.

You can explore this blog for more articles, resources, videos and certification exam resources.

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 Training - ECBA Certification

Business Analyst Course

Business Analyst Training with Banking

Business Analyst Training with Banking

Agile Business Analyst Training

Agile Business Analyst Training

Business Analyst Training with Trade Finance

Business Analyst Training with Trade Finance

 

 

 

ECBA Exam Simulator

ECBA Exam Simulator

BA Training with Healthcare Domain

BA Training with Healthcare Domain

BA with Investment Banking Domain

BA Training with Investment Banking

Are BRD and SRS different or they represent the same thing?

BRD vs SRS

Business requirements document (BRD) and System requirements document (SRS) are used interchangeably in the software industry? Are they the same or they are different?

What is the purpose of creating these documents?

Business Requirements Document

Business requirements document captures business requirements, as the name of the document suggests. Business requirements are high level description of business needs. The business requirements are written using the customer stakeholders perspective.

For example, business requirements can be written as,

The visitor will be required to be a member of the website to access member-only features with proper authentication.

Another example of business requirement,

The invoice will be created by the administrator by the finance manager and will be approved by finance director.

So, who prepares the business requirements document?

Business requirements document may be prepared by a business analyst even before the project starts. The BRD document is shared with the software companies before the start of the project.

Intended Audience: Business Analysts, Business users, Project Manager etc. But this document is not prepared for developers/programmers.

System Requirements Specifications document (SRS)

System requirements document (SRS) describes the requirements for the proposed system and it is much more detailed and in-depth document than the BRD. SRS describes the requirements or the features of the software system, which is going to be developed.

The visitor can register as a member by entering the following details:

  • Name
  • Email ID
  • User Name
  • Password

The name and email are mandatory fields.

The details in the SRS document is captured to enable developers write the code for the proposed software.

Contrast it with the BRD details and you can realize that the perspectives are different as well as the detailing.

The elements of an SRS are discussed and described in one of our posts.

However, I have seen many instances where BRD is used to refer to a document, which is very similar to SRS. So, don’t get surprised but now you know the difference.

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 with ECBA Certification

IIBA ECBA Training

Business Analyst Training with Banking

Business Analyst Training with Banking

Agile Business Analyst Training

Agile Business Analyst Training

BA Training with Healthcare Domain

BA Training with Healthcare Domain