Category: Waterfall Software Development Life Cycle

Let us discuss and observe about Waterfall Software Development Life Cycle.

What is Classical Waterfall Model

What is classical waterfall model

The classical waterfall model is a sequential and linear software development methodology. It is one of the earliest and most traditional approaches to software development, and it follows a step-by-step process in which progress is seen as flowing steadily downwards (like a waterfall) through several phases. Each phase must be completed before the next one begins, and there is minimal overlapping or iteration between the phases.

Continue reading “What is Classical Waterfall Model”

What is waterfall model in software engineering ?

What is waterfall model in software engineering, let us discuss in details what is waterfall model and how waterfall model works .

Topics covered in this Article.

  1. What is waterfall model in software engineering ?

  2. Requirements Gathering.

  3. Requirements Analysis

  4. Design

  5. Coding

  6. Testing

  7. Deployment.

  8. Important Articles 

waterfall model in software engineering
 

1. What is waterfall model in software engineering ?

 In software engineering, a waterfall model is a conceptual model for developing, testing, and deploying computer software. The model starts with defining the problem or requirement that the software is to address, then creating a high-level design of the system. Next, an implementation plan is created based on the design and specified using specific programming codes. Finally, units of testing are conducted to verify that the program works as it should. The entire process is repeated throughout the software development life cycle to ensure that all subsystems work as planned and that any bugs are fixed before launch into the production environment.

In software engineering, a waterfall model is a model of software development (also known as product development). It is a sequential, staged process in which each phase of the process is completed before moving on to the next. The waterfall model is most commonly used for large software projects, where it provides a well-defined and structured approach to writing, testing, and deploying releases.

The four major phases of the waterfall model are requirements gathering, design, development, testing, and maintenance. The requirement gathering phase involves getting all the relevant information about the project. This includes understanding what is being built and understanding the user’s needs. The design phase creates the overall structure of the software and determines how it will be implemented. During this phase, developers may create user interfaces or codebase components. Finally, development takes place during which the actual code is written. Testing ensures that the software functions as intended and is error-free. Once it meets these standards, it is released to users for maintenance. Depending on the size and complexity of the project, this might involve fixing bugs or adding new features

In software engineering, waterfall model is a development process that starts with requirements gathering and progresses through design, testing, and deployment. The goal is to achieve software quality levels before deploying the code. The process is divided into five phases: requirements gathering, design, coding, testing, and deployment.

2. Requirements Gathering / Analysis

Requirements gathering occurs during the early stages of project when stakeholders are gathered together to discuss their needs and goals for the project. This is where requirements are clarified, refined, and may be changed. Requirements should be concise but detailed enough to allow for proper planning.

3. Design

Design occurs after the requirements have been collected and a plan has been created for the project. It includes developing a low-level specification of what will be implemented. Design also determines how the code will be coded and how it will be tested.

4. Coding

Coding takes place once the design has been completed and code is written in an appropriate language for the project. It involves creating individual modules that work together to implement the design specifications. Code should be well documented so future developers can understand it easily.

5. Testing

Testing begins once the code has been written and goes through various levels of testing to make sure it meets all the requirements set forth in the design phase. Once tests have been completed, it’s ready for deployment onto a real or simulated environment.

6. Deployment

Deployment begins by pushing the new code to a staging area so that it can be evaluated before being released into production settings. If all goes according to plan, finally production environments can be updated with the new code.

7. Important Articles related to Waterfall Model.

  1. What are the Advantages of Waterfall Model?
  2. Agile vs Waterfall or Difference between waterfall and Agile
  3. What is Waterfall Methodology or Model in SDLC

We hope this article provided you an overview on what is Waterfall model in software engineering.

What is RACI Matrix?

I want to discuss about RACI Matrix, what RACI Matrix is and what the advantages are by using this in this article.

What is RACI Matrix
What is RACI Matrix

Topics Covered in this Article:

  1. What is RACI matrix?

  2. What is a RACI chart?

  3. What does RACI stand for?

  4. RACI definitions

  5. Advantages of a RACI chart

  6. When to use a RACI matrix

  7. How to create a RACI matrix: Example & template

  8. RACI matrix rules

What is RACI matrix?

I will try to explain in simple words, when we are working in an organization or in a project, we should know who Responsible is for what tasks and who is Accountable. It helps to track the project that particular task is pending with whom or assigned to whom. So to understand that,  will prepare RACI chart.

What is a RACI chart?

A RACI chart is a simple matrix used to assign roles and responsibilities for each task, or decision on a project. By clearly mapping out which roles are involved in each project task and at which level, you can eliminate confusion and answer the project question,  who’s doing what?

What does RACI stand for?

RACI stands for Responsible, Accountable, Consulted, and Informed. We can observe each letter represents the tasks responsibility.

RACI definitions

  • Responsible: Team member does the work to complete the task. Every task needs at least one Responsible member, but as per project we can assign more.
  • Accountable: This member assigns the work. And this member reviews the completed task before delivery. On some tasks, the Responsible party may also serve as the Accountable We should ensure to each task should assign to one Accountable person.
  • Consulted: These members provide inputs based on their domain experience or knowledge.  They can also provide inputs on how it will impact on future project.
  • Informed: These team members simply need to be marked in the loop on project progress.

Advantages of a RACI chart

  • A RACI matrix helps us to set clear expectations about project roles and responsibilities.
  • It helps us to avoid multiple people work on same task.

When to use a RACI

If you want to know who is performing which task then RACI will help you to understand easily. It avoids the confusion in team.

  • The decision-making or approval process could hold up the project.
  • There’s conflict about task ownership or decision-making.
  • The project workload feels like it’s not distributed evenly.

And please understand we need to create RACI matrix based on the project and team. This is not same for all the projects and teams. We need to assign the roles as per our requirement and our project.

How to create a RACI 

We can create a RACI matrix easily and quickly with using Excel. We need not to learn any new software or technology to create RACI matrix. However we need to understand the roles and who is going to own that particulars tasks to prepare.

  1. Enter all project roles or team member names across the top row.
  2. List all tasks, milestones, and decisions down the left column.
  3. For each task, assign a responsibility value to each role or person on the team.

RACI chart Example

RACI Matrix Definitions

RACI Rules.

Once your RACI chart is complete, review it to be sure it follows these simple rules:

  • Every task has at least one Responsible person.
  • There’s one (and only one!) Accountable party assigned to each task to allow for clear decision-making.
  • No team members are overloaded with too many Responsible tasks.
  • Every team member has a role on each task.
  • If we have a lot of Consulted and Informed roles on our matrix, then we can share the common link to access the project.

What is Requirement Traceability Matrix (RTM)?

What is Requirement Traceability Matrix (RTM)?

What is Requirements Traceability Matrix
What is Requirements Traceability Matrix

Requirement Traceability Matrix (RTM) is a document, we can prepare in simple excel format also, it maps and traces client requirement with test cases. It captures all requirements given by the client/ Captured in BRD or FRD/FSD. The main goal of Requirement Traceability Matrix is to verify that all requirements are checked via test cases so that no functionality is unchecked during Software testing.

Why Requirement traceability matrix or RTM is required?

A Requirement traceability matrix is used to record and track the relationship of the project requirements to the design, documentation, development, testing and release of the project/product. This is done by maintaining an excel sheet which lists the complete user and system requirements for the system (in form of use cases) which are in turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc.

An RTM is maintained throughout the lifecycle of the various releases in a project and it’s a vital document to track project scope, requirements and changes in any project.

The Requirement Traceability Matrix or RTM Contains below:

  • Requirement ID
  • Requirement Description
  • Functional Requirement
  • Status
  • Architectural/Design Document
  • Technical Specification
  • Software Module
  • Test Case Number
  • Tested In

Why Requirement Traceability Matrix (RTM) is needed?

  • Requirements Traceability Matrix (RTM)is used to trace the requirements.
  • To test all the test cases.
  • To ensure all the requirements are covered and tested/verified.
  • By using Requirements Traceability Matrix (RTM), we can able to identify if any requirement is not covered.
  • It helps to cover the all the requirements and all are validated and tested as per the requirement.

What is the Advantage of Requirements Traceability Matrix (RTM):

  1. We can ensure all the test cases covered.
  2. It allows to identify the missing functionality easily
  3. It is easy to track the overall test execution status
  4. It allows updating the test cases if any change in requirements or any change request comes.
  5. We can ensure all the requirements covered and tested.
  6. It helps to improve the quality of the product.
  7. As we covered most of the test scenarios it helps to improve the client satisfaction.
  8. As we tested most of the test scenarios it helps to avoid the escalation from the client.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Why Requirements Traceability Matrix  or RTM is Important?

The main responsibility of Testers or QA team to understand the Business Requirements/ Client requirements. And they need to test the application end to end. And team responsible to deliver the product without bugs or Defects. To achieve this goal, every QA or Tester should understand the requirement clearly and create positive and negative test cases.

Requirements provided by the client should be split into different scenarios. And Team needs to prepare or write the test cases as per the requirements, Team ensures to cover all the requirements and scenarios when writing test cases. Once team writes the test cases then team starts the testing for each Test Case. Each of this Test case must be executed individually.

How testing team or QA team will ensure to test all scenarios.

Here we may think that how testing team/ QA team to make sure that the requirement is tested considering all possible scenarios/cases? How to ensure that any requirement is not left out of the testing cycle?

A simple way is to trace the requirement with its corresponding test scenarios and test cases which team already written the test cases.

The traceability matrix is simply a worksheet that contains the requirements with its all possible test scenarios and cases and their current state, i.e. if they have been passed or failed. This would help the testing team to understand the level of testing activities done for the specific product.

I hope this article helped you to provide overview on what is Requirements Traceability Matrix  or RTM.

To know more about what is Requirements Traceability Matrix you can browse on Google to get more knowledge.

In a Business Analyst view this article is enough to understand what is Requirements Traceability Matrix or RTM.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

FAQ’s

What is requirement traceability matrix with example?

Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test cases. It captures all requirements proposed by the client and requirement traceability in a single document, delivered at the conclusion of the Software devlopement life cycle

What is the purpose of the requirements traceability matrix?

A requirements traceability matrix is a document that demonstrates the relationship between requirements and other artifacts. It’s used to prove that requirements have been fulfilled. And it typically documents requirements, tests, test results, and issues.

What are the 3 types of requirements traceability?

There are three types of RTM: forward traceability, backward traceability, and bidirectional traceability

What are the four types of requirements traceability?

The Four Types of Derived Requirements Traceability
Forward to Requirements. When customer needs evolve, requirements may have to be adjusted in response. …
Backward From Requirements. …
Forward From Requirements. …
Backward to Requirements. …

Who prepares RTM?

#1) Business Requirements

It is usually prepared by ‘Business Analysts’ or the project ‘Architect’ (depending upon organization or project structure)

What is RTM tool?

In a software development project, Requirements Traceability Matrix (RTM) is a document which is used to validate that all the requirements are linked to test cases. … A Requirements Traceability Matrix is usually in tabular format as it holds multiple relationships between requirements and test cases

How do you create a requirement traceability matrix?

How to Create a Traceability Matrix in Excel
Define Your Goal. …
Gather Your Artifacts. …
Create a Traceability Matrix Template in Excel. …
Copy and Paste Requirements From Your Requirements Document. …
Copy and Paste Test Cases From Your Test Case Document. …
Copy and Paste Test Results and Issues (If You Have Them)

Is RTM required in agile?

In agile there are no requirements but stories, so traceability matrix does not exist in traditional sense. Well, stories describe requirements but when you complete story, you close it and then you close an iteration and forget about that story. It is done, accepted, and closed.

Which phase is RTM prepared?

To answer your first point, RTM is something that is prepared as and when the requirements are ready. If you plan to adopt a practice of creating RTM in your project, you can mention this point in your Test Plan irrespective of the fact that it is created or not. Test Plan and RTM are not related.

What are the Advantages of Waterfall Model?

What are the Advantages of Waterfall Model:

What are the advantages of Waterfall Model?
What are the advantages of Waterfall Model?

What are the Advantages of Waterfall Model?

  • Simple and easy to use
  • Easy to manage – each phase has specific deliverable’ s and a review process
  • Phases are processed and completed within scheduled time
  • Works well if requirements are very clear
  • It is one the easiest model to manage. Because of its nature, each phase has specific deliverable’s and a review process. In each phase we will get to know what to deliver and when to deliver.
  • Faster delivery of the project
  • Process and results are well documented and documentation plays important role in Waterfall methodology.
  • Easily adaptable method for shifting teams.
  • This project management methodology is useful to manage dependencies.
  • It works well for smaller size projects where requirements are easily understandable.

Disadvantages:

  • Handling change request is difficult.
  • Feedback from the client is not there.
  • There may be chance to no coordination between the teams.
  • Team work and coordination is not there
  • Continuous improvement process
  • This model is not suggestible for Large projects
  • If the requirement is not clear at the beginning, we can’t use waterfall methodology because every phase is dependent on previous phase.
  • Here next phase will start once previous phase completed.
  • Very difficult to move back to makes changes in the previous phases.
  • The testing process starts once development is over. Hence, it has high chances of bugs to be found later in development where they are expensive to fix.
  • There is no team work in this model.
  • Difficult to manage change requests in this model.

I hope now you got some idea about what are the advantages of waterfall Model? 

FAQ’S

What is waterfall model?

Definition: The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion.

What are the 5 stages of waterfall model?

Phases of waterfall project management differ from one project to another. But generally, you can group the activities of the waterfall approach into five stages: planning, design, implementation, verification, and maintenance.

What is waterfall model in SDLC?

The Waterfall model is the earliest SDLC approach that was used for software development. The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete.

Why is waterfall model used?

As an internal process, the Waterfall methodology focuses very little on the end user or client involved with a project. Its main purpose has always been to help internal teams move more efficiently through the phases of a project, which can work well for the software world

Where is waterfall model used?

The waterfall model is most commonly used in software engineering and product development, less often – in other projects and industries. Employ the waterfall model only if your project meets the following criteria: All the requirements are known, clear, and fixed. There are no ambiguous requirements.

What are the 7 phases of waterfall model?

The waterfall model is a sequential design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

Who is project Manager & what they do?

Who is Project Manager?

Who is Project Manager
Who is Project Manager?

Let us discuss and observe who project manager is and what he does in project.  Till now we have discussed the role and responsibilities of Business Analyst in project.  And we may have get doubt as “Business Analyst is handling the project and he is involving in every phase of the software development life cycle.

Business Analysts are usually active members of project teams and many business analysis tasks are very similar to project management tasks, but who exactly is a Project Manager?

As we discussed and observed in previous articles business analysts involves almost all the phases of the software development life cycle.

  1. Requirements gathering
  2. Requirements Analysis
  3. Design
  4. UAT
  5. Functional Testing
  6. Production Movement
  7. Maintenance and Support

Business Analyst involves in above phases based on the project and organization. Now a day’s some of the organizations expecting even technical skills from the Business Analyst.

As Business Analyst involves in all the phases of the software development life cycle but Project Manager is the person who can take decisions and who can decide how project should be and how project to be drive in smoothly to reach the customer expectations and meet the project goals.

He / She is the person who can decide which methodology to be used and project manager is the person to design the project.  Project Manager is the responsible for the entire project.

What are the skills needed to prove as a good project Manager.

  • They have to be able to manage people and develop trust and communication with the project’s stakeholders in order to ensure the project’s success.
  • He/ She has to be able to adapt to change, work well under pressure.
  • He/ She is responsible for using their skills and techniques to ensure the project’s success.

Some of the important responsibilities are below.

  1. Ensure that the project is delivered on-time, within scope and within budget.
  2. Develop a detailed project plan which is used to monitor and track progress.
  3. Set deadlines, assign responsibilities and monitor the progress of the project.
  4. Perform risk management to assess the project’s risks.
  5. Meet with clients to understand the project’s requirements.
  6. Manage the stakeholder’s relationships.
  7. Measure the project’s performance.
  8. Create and maintain comprehensive project documentation

What is Business Analyst Role in Testing / BA in testing

Business Analyst Role in Testing / BA in testing

Let us discuss here what is Business Analyst Role in Testing

Business Analyst Role in Testing

Business Analyst Role in Testing / BA in testing

As I mentioned in the main page, in a software company there will be Testing team. In industry terms we call it as Quality Assurance (QA) team or Quality Control (QC) team. Most popular terminology is QA or testing. Let us try to understand what  is Business Analyst role in Testing.

My intention of putting ‘testing’ knowledge here is to make Business Analyst aspirants to know about testing not intended for Developers and testers. As a Business Analyst it is important to know how testing is done and how testers perform in real life scenarios. Let’s see now, how and what a ‘tester’ will do in real time projects;

First let us understand why testing team is needed in Software Company or software project or why team needs to test the software application or product?

“Testing” will not applicable only for software product or application. “Testing” is applicable everywhere in our day to day life also. For example, before buying clothes we will test whether these clothes will suit to us or not.

Another example: Before buying two wheeler or four wheeler we will test the vehicle whether it will suit to us or not and all the functionalities are working or not.

Similarly testing team will test the software product/ application before releasing to client or market. Without proper testing we will not find quality product. If testing not done properly then software will have so many problems or issues. It leads to project failure, because no one will accept application with issues or problems.

So testing is very important during the project execution.

In ‘Testing’ there are 2 major types

a) Black-box testing
B) White-box testing 

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Black-box testing: Let me put in simple words, black-box testing deals mainly with the functionality testing. Here we test – if ‘x’ is input, are we getting ‘y’ as output.

White-box testing:

here also tester will test if ‘x’ is input ‘y’ is the output or not but this type of testing deals with technical things. How program logic is written? Based on the code is the input and output are proper or not? How input is interacting with backend database and how results are fetched.

In simple words you can say, black-box testing needs functional knowledge and white-box needs technical knowledge.
As you know, Business Analyst will do Business requirements gathering and prepare SRS/FSD/FRS and share the documents with Development and testing team. Testers will read the SRS /FSD/FRS and if any doubts are there then they will ask Business Analyst for clarifications. Then Business Analyst will clarify all the doubts and arrange meetings if needed.  After all the clarifications are made as first step; ‘Testing Lead’ will create high level Test Scenarios. In the test Scenario it will be mentioned – what to be tested? What all modules are to be tested and what all are the high-level expected results?

Testers will write Test-cases which will be based on the SRS /FSD/ FRS document provided by Business Analyst. Test cases will be written in detail for each field and each function.

For entire application and including all the modules ‘test cases’ will be written. Usually MS-Excel will be used to write test-cases. Once test cases are ready then a senior tester or any of the other testers will review the test-cases.

Once Developers code the functionality build will be passed to testing team. (What is Build? – Build is the terminology used. Build means – Developed code.) Build will be tested in phase wise and accordingly to test plan prepared by Testing team leader. Testing will be done based on the test cases written. Usually it is called “test-case” execution. Before testing team start testing there are some tests.

Before build is passed to testers there are some testing done. Yes!! Developers themselves do a round of testing before passing build to testing team. We call it as “Unit Testing”. Developers will write Unit Test- cases and execute unit test cases. 

After unit testing is done, there is one more testing called BVT (build Verification testing). This testing is done by developers or testers or deployment engineer. The main purpose of this test is to ensure the Build is stable or not. (note: there will be different servers like development or lab server, test server, production server) when build is deployed in different server all the path and connections need to be changed and build should be ensured working. If not working Testers will not be able to test build. Also if any major bugs (what is Bug: it is terminology again. Bug means mistake or error) testing team will reject the build form testing.

After BVT is done testers will start testing the build as per test-cases written. Any bugs found will be logged into central repository. There are some tools specifically for testing team which will act as repository and as well as tracking purpose. Any bugs can be logged into tool and assign to development team. An email will be triggered to developer on that bug. Developer will check and if it is a bug he will fix that bug. If not bug developer will write his comments for that bug and close the bugs]

When testers log bugs and it will be fixed by developers, again it will be tested. The fixed functionality will be tested – this is called “Patch testing”. Usually any patch or fixes done by developers will have impact on different functionality so again from start application need to be tested. This type of testing is called “Regression Testing”

The other testing types are;

Smoke testing: This is a sort of high level testing done on all the major functionality to ensure all the main parts of software are working. This does not do in-depth testing minute level.

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Sanity testing:

This is to ensure all parts of software are working but this testing focuses on minute level of functionality.

Integration Testing:

Software will be developed in phases or modules. Each module developed will be tested separately and at the end all the modules will be clubbed and tested. This is called Integration testing.

System testing:

This is to ensure entire software is working properly. In this test not only testers but business analysts, consultants and other people will test. This is something like preparatory exam before main exam. After system testing is done build will be deployed for UAT.

UAT:

User Acceptance testing – this is done by clients.

Beta Testing: This is done by both client and testing team or business analyst. Once UAT is passed and application is deployed for usability for some period application will be on Beta.

Now lets see bug classification:

  • Blocker bugs 
  • Major bugs
  • Critical bugs 
  • Normal bugs 
  • Trivial bugs

Defect or Bug Life Cycle

Blocker Bugs are those which blocks testers from further testing, say for example if application is having Login function and after login testers are supposed test some functions BUT if they are not able to login. i,e. some problem in development with respect to login function we call it as Blocker bug. 
other important bugs which are critical will be categorized into major and critical.
Some small bugs like not accepting numbers, telephone number is accepting alphabets are considered as normal and trival bugs.

Once bugs are raised testers will pass it to developers, once developers fix those bugs it will be passed back to testers for verification of fixed bugs. if again there is some problem with  fixed bugs testers will pass it back to developers. This cycle repeats and once bug is fixed, testers will verify and close the bugs.
There are some open source tools like Bugzilla which are used to keep track of bug status. i.e. opened, closed, verified etc..

Also there are 2 more types of bugs called Invalid bugs and duplicate bugs. If testers raise some bugs which have no problems then developers will mark it as Invalid bugs. If same bugs are repeated then developers will mark it as Duplicate bugs.

(Note Again: this article is for Business Analysts and not for testers because for testers testing document need to be in depth. This is just for understanding QA or testing cycle).

Business Analyst involves in Testing phase, so it is good to have knowledge on testing.

Depends on the organization Business Analyst participates in all the phases of SDLC except Development.

It does not mean that Business Analyst will not participate in development phase, Business analyst  explains the requirements to development team if team needs more clarity on the requirements. 

I hope this article  helped you to understand what  is  Business Analyst role in  testing

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

FAQS: Testing and UAT

What is the business analyst role in UAT?

The Business Analyst Role is central to achieving success in UAT sessions. … UAT helps stakeholders to determine whether the system can be put to use in real-life business scenarios or not. 2. The UAT session is an opportunity for users to see the solution in action and confirm that it meets their needs.

Who writes UAT test cases?

When it comes to UAT, often the UAT is composed of Business Analysts and selected end-users who will perform the actual UA testing. But QA, who have an overall responsibility to ensure the application/product works as required, should be part of the process for test definition

Who is responsible for UAT?

In summary, quality assurance is the responsibility of the business user and it therefore Party R responsible for executing the UAT. While a project manager (Party D) can help facilitate the time line and sign off process, and should support and be accountable for getting it done with Party R responsible for UAT.

Who runs UAT?

For many, UAT belongs in the hands of business analysts and corresponding business owners. These individuals collaborate to create the test plans and test cases and then determine how to implement and track their progress, all the while integrating the skills of technical experts and a quality assurance team.

Is UAT functional testing?

User Acceptance Testing (UAT) is a type of testing performed by the end user or the client to verify/accept the software system before moving the software application to the production environment. UAT is done in the final phase of testing after functional, integration and system testing is done.

Why is UAT important?

UAT is important because it helps demonstrate that required business functions are operating in a manner suited to real-world circumstances and usage. Verified and tested by the people who are going to be working with it on a daily basis. Basically you and your team are getting a better piece of software

What is UAT sign off?

UAT Sign–off: When all defects are resolved, the UAT team formally accepts (or recommends acceptance to the project manager) the software application as developed. The approval shows that the application meets user requirements and is deployable.

What are the Documents prepared by Business Analyst?

Let us see here documents prepared by Business Analyst during the project. Business Analyst will prepare so many documents as per Company standards; here we will see what the documents are mostly created by the Business Analyst during the project life cycle.

These documents prepared by business analyst to fulfill the various project needs and cater to audiences belonging to different spheres of a project.

Documents prepared by Business Analyst

As we know Business Analyst primary and most important role is to gather the requirements, analyze the requirements and document the same with proper approvals, Business Analyst should ensure not to miss any requirement. For example, if any requirement is out of scope of the project and it is not feasible then Business Analyst needs to inform the same to stake holders prior to prepare the documents and get approvals from internal and external stake holders. If any requirement is out of scope or not feasible in this project then he needs to explain the scenarios and consequences and what problems we will face because of this requirement to internal and external stake holders. Business Analyst can update the same in meetings with stake holders and it should be documented in the form of FSD or FRD.

Documents Prepared by Business Analyst

Documents Prepared by Business Analyst

The type and specifications a business analyst is expected to create in an organization depends upon many parameters like organization’s processes and policies, need and expectations of the business, and the stakeholder requirements. Detailed below are the common documents a business analyst is expected to created and they are extensively used throughout the project life cycle. Each of these documents has a specific template and it’s a part of the overall project documentation.

Let us observe what are the documents prepared by Business Analyst below

  • Project vision Document
  • Business Requirement Document
  • Functional requirement specification (FRS)/ Functional Specification Document (FSD)
  • User stories
  • Use cases
  • Requirement traceability matrix (RTM)
  • System requirement specification (SRS)/ System Requirement Document (SRD)
  • Test case

Project vision document: Project vision document will be prepared by client and project Manager, business analyst also expected to contribute to this document based on organization and project manager wish.

We will mention purpose of the product/software to be developed. We will describe what business objective will be achieved because of this product in high level.

The Project vision document contains: It may vary from organization to organization depends on organization and stake holders.

  • Introduction
  • Description of users in the system
  • Project stakeholders
  • Product Overview
  • Product Features
  • Product requirements
  • Constraints/Limitations
  • Quality/documentation requirements

Business Requirement Document (BRD)/ Business Requirement Specification Document. (BRS)

A Business Requirement Document is created to describe the business requirements of a product/process and the intended end result that is expected from the product/process. It is one of the most widely accepted project requirement document and is referred to throughout the development life-cycle for any project. A BRD mainly focuses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution’ and thus it’s mainly centered around the business requirements. A BRD is created with the help of the project team (BA, client, subject matter experts, business partners) and is also used as a communication tool for other stakeholders/external service providers.

The Business Requirement Document contains:

  • Document revision
  • Approvals
  • Introduction
  • Business goals and objectives
  • Stake holders
  • Business rules
  • Project background
  • Project objective
  • Project scope
  • In-scope functionality (Requirements)
  • Out-scope functionality (Requirements)
  • Business requirements
  • Data requirements
  • Functional requirements
  • Non_functional requirements
  • Assumptions
  • Constraints
  • Risks
  • Business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • Legacy systems
  • Proposed recommendations
  • List of acronyms
  • Glossary of terms
  • Related documents
  • Dependencies of existing systems

Functional requirement specification (FRS)/ Functional Specification Document (FSD) Functional Requirement Document (FRD)

A Functional requirement specification or Functional Specification Document describes the intended behavior of a system including data, operations, input, output and the properties of the system.

In a BRD the requirements are high level but in an FRS/FSD, they are written in much more details to capture each and every aspect of a requirement. Thus a functional specification document becomes a more technical, accurate and descriptive requirement document. Owing to their technical nature, FRS/FSD are equally used by developers, testers and the business stakeholders of a project.

Functional requirement specification (FRS)/ Functional Specification Document (FSD) Functional Requirement Document (FRD) contains

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, Dependencies and document overview
  • Methodology
  • Functional Requirements
  • Modeling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface / Integration Requirements, Hardware/Software Requirements,
  • Performance
  • Glossary
  • Requirements Confirmation
  • Client Signoff  (Client provide sign off on mail if client satisfies with the approach)

User stories:

In an agile development environment, a user story is a document describing the functionality a business system should provide and are written from the perspective of an end user/customer/client. The user stories are not very descriptive and only captures ‘who’, ‘what’ and ‘why’ of a requirement in limited detail. If any requirement is too big for a single user story it’s broken down into a number of user stories making it easier for estimation and discussion. In such cases, the main user story will act as an Epic (parent) user story.

Some examples of user stories are:

  • The system shall be able to sort the values in ascending and descending order
  • The application must allow the user to enter his name, date of birth and address.
  • The system shall verify the login credentials of the user and redirect him to the dashboard in case of successful login.

Use cases

Each and every project is an endeavor to achieve ‘requirements’ and the document which defines these requirements is a use case. A use case is a methodology used in system analysis to identify, define and organize system requirements.

A use case is created from the perspective of a user and achieves the following objectives:

  1. Organizes the functional requirements,
  2. Iterative in nature and updated throughout the project life-cycle
  3. Records scenarios in which a user will interact with the system
  4. Defines other aspects like negative flows, UI elements, exceptions, etc..

The Use Case document contains:

  • Actors
  • Description
  • Trigger
  • Preconditions
  • Normal Flow
  • Alternative Flows
  • Exceptions
  • Special Requirements
  • Assumptions
  • Notes and Issues

Requirement traceability matrix (RTM)

A Requirement traceability matrix is used to record and track the relationship of the project requirements to the design, documentation, development, testing and release of the project/product. This is done by maintaining an excel sheet which lists the complete user and system requirements for the system (in form of use cases) which are in turn mapped to the respective documents like Functional Requirement, Design Document, Software Module, Test Case Number, etc.

An RTM is maintained throughout the lifecycle of the various releases in a project and it’s a vital document to track project scope, requirements and changes in any project.

The RTM Contains:

  • Requirement ID
  • Requirement Description
  • Functional Requirement
  • Status
  • Architectural/Design Document
  • Technical Specification
  • Software Module
  • Test Case Number
  • Tested In

System requirement specification (SRS)/ System Requirement Document (SRD)

A detailed document containing information about ‘how’ the complete system has to function and enumerates hardware, software, functional and behavioral requirements of the system. This document elaborates the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.

The System requirement specification (SRS)/ System Requirement Document (SRD) contains:

  • Product Perspective
  • Product Functions
  • User Characteristics
  • General Constraints
  • Assumptions and Dependencies
  • External Interface Requirements
  • Functional Requirements
  • Classes / Objects
  • Non-Functional Requirements
  • Inverse Requirements
  • Design Constraints
  • Sequence Diagrams
  • Data Flow Diagrams (DFD)
  • State-Transition Diagrams (STD)
  • Change Management Process

Test case

Although Business analysts are not explicitly asked to create test cases but they must understand what they constitute and how to create one, as they sometimes have to test functionalities by referring to the test cases.

A test case is a document, which has a set of test data, preconditions, variables and expected results created to verify and validate whether a particular piece of functionality is behaving as intended (or as documented in the requirement documentation). Thus, a test case becomes a standardized document which should be referred every time a requirement has to undergo testing.

Business Analyst will not prepare test cases but he sits with the QA team and ensure to all the requirements covered.

The components of a test case are:

  • Test Case ID
  • Test Scenario
  • Prerequisite
  • Test Data
  • Test Steps
  • Expected Results
  • Actual Result
  • Status
  • Remarks
  • Test Environment

All the above documents prepared by business analyst and are part of the project/product documentation. These documents are constantly referred through the project’s life-cycle for communication, reference and revision.

Templates may differ to organization to organization and project. Hope this article helped you to provide overview on what are the documents prepared by business analyst .

Sample BA Document Templates

FREE DOWNLOAD

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to get exclusive content and recommendations every month. You can unsubscribe anytime.

Agile vs Waterfall or Difference between waterfall and Agile

What are the differences between Waterfall and Agile?

Differences between waterfall and Agile Methodology / Agile vs Waterfall

To understand what are the differences between waterfall methodology (Agile vs Waterfall) and Agile Methodology, first we will understand what are the advantages and disadvantages of these methodologies then we will look into Agile vs Waterfall.

Before learning Agile vs Waterfall we will discuss what are the advantages and disadvantages of Waterfall and Agile Methodologies.

Advantages of Waterfall Methodology (Model):

https://www.bacareers.in/sdlc-waterfall/

  • It is one the easiest model to manage. Because of its nature, each phase has specific deliverable’s and a review process. In each phase we will get to know what to deliver and when to deliver.
  • Faster delivery of the project
  • Process and results are well documented and documentation plays important role in Waterfall methodology.
  • Easily adaptable method for shifting teams.
  • This project management methodology is useful to manage dependencies.
  • It works well for smaller size projects where requirements are easily understandable.

Disadvantages of Waterfall Methodology (Model):

  • This model is not suggestible for Large projects
  • If the requirement is not clear at the beginning, we can’t use waterfall methodology because every phase is dependent on previous phase.
  • Here next phase will start once previous phase completed.
  • Very difficult to move back to makes changes in the previous phases.
  • The testing process starts once development is over. Hence, it has high chances of bugs to be found later in development where they are expensive to fix.
  • There is no team work in this model.
  • Difficult to manage change requests in this model.

Advantages of the Agile Methodology(Model):

https://www.bacareers.in/sdlc-agile-scrum/

  • Agile teams are extremely motivated and self-organized so it likely to provide a better results from the development projects.
  • Client involves in every phase of the SDLC, so requirements are clear and if team needs any clarifications also we can close as soon as possible.
  • Agile software development method assures that quality of the development is maintained
  • The process is completely based on the incremental progress. Therefore, the client and team know exactly what is complete and what is not. This reduces risk in the development process.
  • Change requests are welcomed at any phase of the SDLC.

Disadvantages of Agile Methodology (Model):

  • It is not useful method for small development projects.
  • It requires an expert to take important decisions in the meeting.

What are the difference between Waterfall and Agile Model?

                                               Agile vs Waterfall

              Difference between Agile and Waterfall Methodologies/ Agile vs Waterfall

                                  Agile

              Waterfall

It separates the project development lifecycle into sprints.

Software development process is divided into separate phases.

It follows an incremental approach

Waterfall methodology is a sequential design process.

Agile methodology is known for its flexibility.

Waterfall is a structured software development methodology so most times it can be quite rigid.

Agile can be considered as a collection of many different projects.

Software development will be completed as one single project.

Agile is quite a flexible method which
allows changes to be made in the project development requirements even if the initial planning has been completed.

There is no scope of changing the requirements

Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once.

All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model.

Test plan is reviewed after each sprint

The test plan is rarely discussed during the test phase.

Agile development is a process in which the requirements are expected to change and evolve.

The method is ideal for projects which have definite requirements and changes not  expected.

In Agile methodology, testing is performed concurrently with software development.

In this methodology, the “Testing” phase comes after the “Build” phase

Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer’s demands.

This model shows a project mindset and places its focus completely on accomplishing the project.

Prefers small but dedicated teams with a high degree of coordination and synchronization.

Team coordination/synchronization is very limited.

Products owner with team prepares requirements just about every day during a project.

Business analyst prepares requirements before the beginning of the project.

Test team can take part in the requirements change without problems.

It is difficult for the test to initiate any change in requirements.

Description of project details can be altered anytime during the SDLC process.

Detail description needs to implement waterfall software development approach.

The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team

In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC.

Agile and Waterfall are very different software development methodologies and are good in their respective way. Organizations will follow the methodology which suits for the project and requirements how ever it is better to know the differences between Agile and Waterfall (Agile vs Waterfall).

  • Usually Waterfall methodology will be used for small projects where requirements are clear and there is no chance to change the requirements.
  • Usually Agile methodology will be used for large projects where requirements are not clear and client is changing the requirements frequently.
  • Documentation plays important role in waterfall methodology.

I feel it helps to understand difference between waterfall and Agile (Agile vs Waterfall ) For More about Agile vs waterfall…….

Difference between Waterfall and Agile Methodologies

Difference between Waterfall and Agile Methodologies

Let us discuss and observe below in  details  what  is the Difference between Waterfall and Agile Methodologies.

difference between Waterfall and Agile
difference between Waterfall and Agile
Advantages of Waterfall Model:
  • It is one the easiest model to manage. Because of its nature, each phase has specific deliverable’s and a review process. In each phase we will get to know what to deliver and when to deliver.
  • Faster delivery of the project
  • Process and results are well documented and documentation plays important role in Waterfall methodology.
  • Easily adaptable method for shifting teams.
  • This project management methodology is useful to manage dependencies.
  • It works well for smaller size projects where requirements are easily understandable.

Disadvantages of Waterfall Model:

  • This model is not suggestible for Large projects
  • If the requirement is not clear at the beginning, we can’t use waterfall methodology because every phase is dependent on previous phase.
  • Here next phase will start once previous phase completed.
  • Very difficult to move back to makes changes in the previous phases.
  • The testing process starts once development is over. Hence, it has high chances of bugs to be found later in development where they are expensive to fix.
  • There is no team work in this model.
  • Difficult to manage change requests in this model.

Advantages of the Agile Model:

  • Agile teams are extremely motivated and self-organized so it likely to provide a better results from the development projects.
  • Client involves in every phase of the SDLC, so requirements are clear and if team needs any clarifications also we can close as soon as possible.
  • Agile software development method assures that quality of the development is maintained
  • The process is completely based on the incremental progress. Therefore, the client and team know exactly what is complete and what is not. This reduces risk in the development process.
  • Change requests are welcomed at any phase of the SDLC.

Disadvantages of Agile Model

  • It is not useful method for small development projects.
  • It requires an expert to take important decisions in the meeting.
By reading above  we can understand difference between waterfall and Agile.

Let us observe  in table in details  what  are the difference between Waterfall and Agile

Difference between waterfall and Agile Methodologies

                              Agile

                Waterfall

It separates the project development lifecycle into sprints.

Software development process is divided into separate phases.

It follows an incremental approach

Waterfall methodology is a sequential design process.

Agile methodology is known for its flexibility.

Waterfall is a structured software development methodology so most times it can be quite rigid.

Agile can be considered as a collection of many different projects.

Software development will be completed as one single project.

Agile is quite a flexible method which allows changes to be made in the project development requirements even if the initial planning has been completed.

There is no scope of changing the requirements

Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once.

All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model.

Test plan is reviewed after each sprint

The test plan is rarely discussed during the test phase.

Agile development is a process in which the requirements are expected to change and evolve.

The method is ideal for projects which have definite requirements and changes not  expected.

In Agile methodology, testing is performed concurrently with software development.

In this methodology, the “Testing” phase comes after the “Build” phase

Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer’s demands.

This model shows a project mindset and places its focus completely on accomplishing the project.

Prefers small but dedicated teams with a high degree of coordination and synchronization.

Team coordination/synchronization is very limited.

Products owner with team prepares requirements just about every day during a project.

Business analyst prepares requirements before the beginning of the project.

Test team can take part in the requirements change without problems.

It is difficult for the test to initiate any change in requirements.

Description of project details can be altered anytime during the SDLC process.

Detail description needs to implement waterfall software development approach.

The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team

In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC.

Agile and Waterfall are very different software development methodologies and are good in their respective way. Organizations will follow the methodology which suits for the project and requirements.

  • Usually Waterfall methodology will be used for small projects where requirements are clear and there is no chance to change the requirements.
  • Usually Agile methodology will be used for large projects where requirements are not clear and client is changing the requirements frequently.
  • Documentation plays important role in waterfall methodology.
I hope it helped you to understand the difference between waterfall and  agile.

In interview also they may ask what is  the difference between waterfall and agile methodology.

If you need any clarifications on difference between waterfall and agile, you can post here.

error

Enjoy this blog? Please spread the word :)