Tag Archive Business Analyst Tutorial

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

Software Estimation Techniques for New and Maintenance Projects

Multiple Software Estimation Techniques are available for estimating the efforts of a software project. However, not all techniques can be used for all kinds of projects. In this post, I am going to talk about 3 project scenarios and the appropriate estimation technique to be used for each.

New Software Project (medium to large sized)

Typically estimations are done at the pre-sales stage for bidding. The availability of information about requirements is limited. This makes the task of estimation very challenging and naturally it is error prone.

Pros – FPA estimation Technique

The ideal estimation technique could be function point analysis (FPA), which is an algorithmic estimation technique. FPA is a size and effort estimation technique based on features.This technique covers all aspects of software development like:

  • Number of interfaces
  • Number of screens
  • Data stores and interactions & more…

FPA also considers environmental factors such as type of application. A mid-sized project with 1,00,000 concurrent users expectations will have need more effort than 100 concurrent users expectations. This aspect is often overlooked in the other estimation techniques.

There are multiple environmental factors which can be useful for different scenarios.

Cons – FPA estimation Technique

It has a learning curve and requires some experience to be able to estimate using this technique.

Learning FPA

Here are some of the picks for learning FPA

IFPUG Documentation (Though a little dated)

FPA in Agile

FPA with examples


Maintenance Projects

I include change requests for enhancements and bug fixing in maintenance projects. These are characterized by much better availability of information. The system is already in place.

A WBS (work break down) based estimation technique is an ideal choice. it’s possibly one of the simplest estimation techniques.

In this estimation technique, we decompose the requirements into smaller units of work (by creating work break down structure). Each unit of work is then estimated for effort in days or hours. A sample break down structure is shown below:

Once the coding effort is estimated, you can roll it up to estimate the total effort including testing, requirement study etc.

Pros – WBS Estimation Technique

It’s a simple to understand estimation technique and can be easily learned.

Cons – WBS Estimation Technique

Just like any other estimation technique, it is also dependent on individual’s assessment and is prone to being biased.


New Software Project (Small Project)

We can use WBS estimation technique for small projects as well as discussed above.


Subjectivity in software Estimation Techniques

Software estimations are conducted by individuals and they are prone to being biased (not intentionally though). The reasons could be:

  • An expert developer estimating for programs, it will always be on lower side
  • A domain expert estimating the functionality
  • A normal professional typically underestimates

These reasons can be eliminated by simple modifications to any of the estimation techniques.

Eliminating subjectivity – Method I

In case of WBS estimation technique, we can ask two developers to give their estimation. This will average out the subjectivity without too much of effort. The estimation sheet will look as shown below:

We can easily take the average to arrive at better coding estimate. In case of FPA (typically done by project managers), we can ask two project managers to create FPA estimations and then take average.

Eliminating subjectivity – Method II

This is a more accurate technique to eliminate subjectivity. In this technique, a simple weighted average is calculated to arrive at the most likely estimate.

The estimation needs to created for the following scenarios:

  • Minimum time to finish (a)
  • Maximum time to finish (b)
  • most likely time to finish (c)

Then use the formula, best time to finish = (a+4b+c)/6

Conclusion

Software estimation technique has always been dependent on individuals. Many experts feel that software estimation is an art rather than a science. In my more than two decades of experience, lot of my estimations proved to be wrong. But I used the learnings to improve my next estimation. If you are expected to estimate, always be open to ask questions and learn from previous mistakes.

It’s also a good idea to refer to estimations of similar types of projects or ask your colleagues who have been involved in similar projects.

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.

 

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

Business Analysis Tutorial for beginners

Business Analyst Tutorial for beginners

Business Analyst Tutorial for beginners

In this business analysis tutorial for beginners, you will learn the basics of activities conducted by a business analyst. These tutorials are recorded in simple to understand language so that almost anyone can understand.

These videos are the recordings of our Business Analyst course for ECBA Certification.  This course is designed for IT & Non-IT professionals.  These videos are uploaded on our Youtube channel as well but in this tutorial for beginners, they have been arranged in a sequence.

Business Analyst Tutorial topics

In this business analysis tutorial for beginners, following topics are included:

Tutorial I:  Software development process for beginners (Non-IT professionals)

Tutorial II: Understanding Software development process with a case study

Tutorial III: Software Development Life Cycle methodologies (SDLC) basics

Tutorial IV: Requirements Analysis and Modelling with UML diagrams

Tutorial V: Verification and Validation

 

Software development process for beginners

In this video, we have used construction of a house to explain the software development process. You will find it pretty simple to understand the concepts explained in this video. This class recording is a representative of our approach to teach.

Understanding Software development process with a case study

The second part of business analyst tutorial series discusses the phases of a software development methodology with the help of a simple application. Explained in a simple of understand language, it familiarizes you software development process using industry jargons.

Software Development Life cycle Methodologies (SDLC Basics)

In this video, you will learn the basics of software development methodologies including waterfall, Agile and others. These methodologies are used to develop software applications and understanding their pros and cons is an important part of every business analyst skills.

 

Requirements Analysis and Modelling with UML diagrams

In the previous tutorial, we discussed the some of the most used SDLC methodologies. Having understood that, the next step is to discuss, how do business analyst gather, analyse and model the requirements.

A business analyst can make use of multiple diagrams like Use cases, Activity Diagrams and Sequence diagrams. Using these diagrams along with prototypes, a business analyst develops the System Requirements Specifications (SRS) document.

Verification and Validation

Verification and validation are integral part of software development process. Business analysts play an important role in these activities.

In this tutorial, you will learn about the verification and validation activities. You will also learn how are they conducted?

 

Techcanvass Youtube Channel

These videos are published on a regular basis on our youtube channel. If you would like to be notified of these video releases, please subscribe to our youtube channel.

Techcanvass on Youtube

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

 

SQL tutorial | DECODE in ORACLE

SQL Basics tutorial on DECODE

In this SQL tutorial on DECODE, we are going to learn about Decode command in SQL (only applicable for Oracle). Every database system has some special and useful SQL commands. Oracle has an extremely powerful command known as DECODE. Please note that, using DECODE command is only possible in Oracle.

Implementing DECODE

How do you implement IF-THEN-ELSE in an SQL query in ORACLE? Let’s take an example to understand the problem first?

You have a table named “Employees”. The “Employees” table has the following fields:

  • Emp ID
  • Emp Name
  • Designation
  • Address
  • Contact No 1
  • Contact No 2
  • Basicsal

The company decided to pay the bonus as a multiple of base salary. This will be calculated as follows:

If Designation = “Project Manager” then

Bonus = 2.3 X Basic Salary

Else if Designation = “Program Manager” then

Bonus = 3.6 X Basic Salary

Else

Bonus = 1.2 X Basic Salary

End If

If you are going to use a programming language, you can use If-Else-Then statements to code but SQL queries don’t support these so How do you fetch the data using a single SQL query but still using the above conditions?

The solution is to use DECODE, here is the query?

SELECT EmpID, EmpName,

DECODE (Designation, ‘Project Manager’, 2.3 X Basic Salary, ‘Program Manager’, 3.6 X Basic Salary, 1.2 X Basic Salary)

FROM Employees;

Alternative to DECODE

Is there any other way to achieve the same result in ORACLE? Of course, yes, using CASE.

Using CASE:

SELECT EmpID, EmpName,

CASE Designation,

WHEN ‘Project Manager’ THEN 2.3 X Basic Salary

WHEN  ‘Program Manager’ THEN 3.6 X Basic Salary

ELSE 1.2 X Basic Salary

FROM Employees;

This article was in series of articles, we have been publishing under “SQL tutorial for beginners”. Here are links to a 3-part SQL tutorial series:

SQL tutorial for Beginners Part 1

SQL tutorial for Beginners Part 2

SQL tutorial for Beginners Part 3

 

Cheers

 

What is requirements analysis and modelling?

What is requirements analysis and modelling?

Requirements analysis and modelling is probably the most important skill for a business analyst. The success of any software project depends on the this task. Requirements analysis and modelling involves multiple tasks:

  • Understanding business requirements
  • Decomposition and analysis of requirements
  • Categorization of requirements
  • Modelling of requirements

The basic objective is to make sure that you understand the requirements from the customer perspective, translate it into requirements, which software development team can understand. Requirements understanding has been one of the key factors for software projects’ poor record. Read the post below:

Why do we go wrong in Requirements gathering?

Requirements Analysis and Modelling Techniques

Several requirements analysis and modelling (RAM) techniques are practiced to conduct this activity. Some of these techniques are as follows:

  • Structured RAM with DFD and ER diagrams
  • RAM with UML diagrams
  • Using BPMN and other similar techniques
  • Custom Technique

As a business analyst, you should learn at least couple of techniques and when to use them? It will help you in having a better perspective and use of correct technique in a given context.

In this video, I have explained some really basic concepts and a completely custom technique for requirements analysis and modelling. You don’t need to have any prior knowledge to understand it.

What’s in the video

In this video, I have explained the basics of Requirements analysis & modeling. Some of the important topics covered in this webinar are as follows:

a) What are C & D Requirements?

b) What & Why of Modeling

c) What is process modeling?

d) Techniques of Process modeling

What’s next?

If you wish to also learn about requirements analysis and modelling with UML diagrams, you can go through the following article:

Object Oriented Analysis with UML

If you would like to be notified of the future webinar recordings and new videos, please subscribe to our channel on Techcanvass by clicking on the following link:

Techcanvass on Youtube

Basics of SCRUM and Kanban

In this webinar, the speaker explains the basics of SCRUM and Kanban. It’s a good starting point to learn these AGILE methodologies.

SCRUM and Kanban are two of the most used Agile frameworks in the market today. Organizations are increasingly adopting Agile to develop software projects. In this webinar, the topics covered are as follows:

  • Basics of Scrum
  • Basics of Kanban
  • Sizing for these projects

Here is the recording

Techcanvass conducts these online sessions on topics relating to Agile, Business Analysis, Selenium etc. If you would like to be updated always, please subscribe to Techcanvass channel on youtube

Techcanvass on Youtube

Object Oriented Analysis with UML

Object Oriented Analysis and design is one of the modern approaches for software projects. Object Oriented approach was developed as it is capable of representing real life situations like classes and objects.

Requirements Analysis is an important activity of every bespoke project to be performed by Business Analysts. UML modeling is one of the techniques for requirements analysis. In this webinar, the speaker discussed the requirement analysis approach. With the help of case studies, the steps for Object oriented methodology has been discussed in this webinar.

You can watch the video below:

 

Techcanvass conducts online webinars on a regular basis on topics ranging from Business Analysis, Problem solving, Agile Business Analysis etc. If you would like to be updated on these videos on a regular basis, please subscribe to our channel.

Techcanvass on Youtube