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.

BRD Vs FRD, Difference between BRD and FRD Documents

BRD Document Vs FRD Document

Let us discuss BRD Vs FRD  herre and how to to  prepare the BRD and FRD.

BRD Vs FRD
BRD Vs FRD

Documentation is the most important aspect for any Business Analyst.

The documentation is useful to understand the requirements and the detailed discussion about new features and change request if any. Business Analyst will prepare many different types of documents. Some of the important ones are listed below –

  • Business Requirement Document (BRD)
  • User Stories
  • Use Case Specification Document (USD)
  • Functional Requirement Document (FRD)
  • Requirements Traceability Matrix (RTM)
  • Product Requirements Document (PRD)

Documentation helps in understanding the business process and business events throughout the project. A Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and differences between BRD and FRD.

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.

Business Requirement Document

  • BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
  • A formal document illustrating the requirement provided by the client
  • In other words it describes at very high level the functional specifications of the software
  • The requirements could be collected either by verbal or written or both
  • Created by a Business Analyst who interacts with the client
  • Entire work is executed under the supervision of the Project Manager
  • It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

  • To arrive at a consensus with stakeholders
  • To provide input into the next phase of the project
  • To explain how customer/business needs will be met with the solution
  • Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format Of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

  • document revision
  • approvals
  • introduction
  • business goals
  • business objectives
  • business rules
  • background
  • project objective
  • project scope
  • in-scope functionality
  • out-scope functionality
  • assumptions
  • constraints
  • risks
  • business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
  • legacy systems
  • proposed recommendations
  • business requirements
  • list of acronyms
  • glossary of terms
  • related documents

Now let us look into FRD…

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.

Functional Requirement Document

  • FRD highlights “Functional Requirements” i.e., functionality of the software in detail
  • Depending on the product.
  • It will describes at a high level the functional and technical specification of the software
  • Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
  • In a small and medium sized organizations a BA take care of this
  • Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
  • FRD is derived from the BRD
  • Will get sign off from the client once we prepare FRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Business Analyst will prepare the FRD after discussing with the stake holders and Project Manager. He is the person analyze the requirements, to get clarity on requirements he will conduct multiple meeting session with internal and external stake holders. And he will concentrate on below questions mostly.

  • How we develop the expected requirement(s)?
  • What are the tools and/or systems used and their dependencies?
  • What are the features and functionalities?
  • How will the customer reacts when they start using the solution?
  • Any assumptions or constraints?

Most common objectives of FRD –

  • Draw flow charts for each process flows for each activity interlinking dependencies
  • Holistic view for each and every requirements, steps to built
  • Estimating detailed risks for each new change request
  • Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format Of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

  • Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
  • Methodology
  • Functional Requirements
  • Modeling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
  • Other Requirements – Interface Requirements, Hardware/Software Requirements,
  • Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. In my company client will share the BRD, based on the BRD we prepare FSD.

I hope now you understand the BRD vs FRD

BRD Vs FRD – Business Analyst Articles, Webinars

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.

What is the difference between a BRD and FRD?

The Business Requirement Document (BRD) describes the high-level business needs whereas the Functional Requirement Document (FRD) outlines the functions required to fulfill the business need. BRD answers the question what the business wants to do whereas the FRD gives an answer to how should it be done

What is an FRD?

The functional requirements document (FRD) is a formal statement of an application’s functional requirements. It serves the same purpose as a contract. The developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the FRD

What is difference between BRD and SRS?

It is obvious that BRS is the specification of the business processes and operations. Use Cases: SRS describes the interaction between the created product and the end users. It is the reason why this specification type includes use cases. … Specification sphere: SRS describes the peculiarities of the developed system

What is included in a requirements document?

Requirements documents should include these kinds of requirements: Business Requirements: Business requirements generally come from the customer of the project. They represent the product features, or what the end outputs of the project need to provide

What are two types of functional requirements?

Requirements generally fall into two types: functional and non-functional. The difference between them is fairly straightforward, nevertheless, in the this article we’ll define the two types of requirements and provide examples of each to point out more concretely the fundamental difference between them

What is Waterfall Methodology or Model in SDLC

What is Waterfall Methodology or Model

 

What is waterfall methodology or model
What is waterfall methodology or model

Here we will discuss about traditional software methodology Waterfall and who will involve in each phase.

Waterfall or Sequential methodology: Here next task will start once previous task completed only. We will see here in detail, what are the advantages and disadvantages of this methodology. First we will observe what are phases involved here and how it works.

Software Development Life Cycle is a framework having defined set of activities performed in phases for developing a software application or a software product.
There are different SDLC methodologies like Waterfall, Agile, Spiral, RAD, iterative Development etc..

For now we will try to understand 2 popular SDLC methodologies Waterfall & Agile. Still so many companies are using water fall methodology. And now a day’s most of the companies are looking for Agile methodology, because in Agile less documentation will be there and easy to understand. First we will observe Waterfall methodology.

The below are called as phases in waterfall methodology.  Let us discuss in details what is waterfall methodology or model and what are the phases in waterfall model.

Requirements Gathering: 

This is the first phase in Software Development Life cycle.

Generally Project manager and Senior Business analyst will participate in this phase.
In this Phase, we will identify;

  • Stakeholders of the project i.,e Technical teams, testing teams, customer team and other dependant teams
  • Technology – that will be used in the project like programming language, front end, backend (which technology to use like Java or dot Net, Database)
  • Hardware requirements, software requirements
  • High level requirements
  • High level test approach
  • High level effort and cost required for the project
  •  High level schedule
  • Project approvers
  • High level assumptions
  • Identify possible risks

We will discuss these things and document it. The phase deliverable artifact  is called Project Charter or BRD (Business Requirements document).

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.

Requirement Analysis:

In this Phase, we will start discussing in-detail on the high level requirements which we gathered in previous phase.

Business Analyst,Project Manager, Technical Team , Architect , Network Engineer and Data base team will participate in this phase.

  • We will conduct multiple meetings to understand the requirements like interview, Jad sessions and Brainstorming.
  • We will use the Activity diagrams, UML diagrams and flow charts to make the document clear.
  • Usually requirements’ gathering is done though meetings, phone calls, emails, virtual meetings.
  • Once document is prepared, it will be reviewed with project stakeholders.
  • We will freeze the requirements and take sign-off from the customer.
  • The Analyze phase deliverable artifact is called (FS/FRS,SRS,RTM)

Design:

First, based on the requirements we will identify and device the flow of data in the application.

Tech leads Architect, DB architect, Network Architect and UI designer will participate in Design phase.

  • Design phase will have HDD , LDD and ADD (High level design document , Low Level design document and Application design document).
  • We will determine how many tables are needed? How tables are connected? what is the expected load on the database? And all.
  • Followed by we will go to table level mappings, defining each field, like length of field, restriction for the field, unique ID’s and validations etc.
  • We will do requirement mapping to design. i.e to ensure all the requirements are covered in design or not.
  • We will document the design of application and review with Architects and we will take signoff on the design document.

Development and Coding: 

In this phase, developers will start coding the functionalities.
Developers will create Unit test cases and perform unit testing.
Tech Leads will do code review
Once build is complete, build will submitted to QA team for testing.

Testing :

Testing team will prepare  their test strategy after Requirements Analysis Phase. Based on Test Strategy and Requirements document, testing team will create Test cases.
Test cases will be prepared before test phase so that after Development and Coding phase Testing team can start executing test cases.
If there are any defects or bugs found, testing team will assign it to development team to resolve.
Developers will fix the defects and again give it to testers.
This cycle will go on till all the defects are resolved and application is bug free.
Testing team will publish Test report at the end of testing phase and they provide sign-off. Once we receive internal sign off from the QA team then we will release to client for 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.

UAT:

User Acceptance Testing is called UAT. In this phase, customer or the business user will test the application functionality.


Customer will write UAT test cases and execute the cases.


If there are any defects found, they will communicate to the Business Analyst or Project manager. They will verify whether it is genuine bug or functionality gap.If it is genuine bug then they will ask the testing team and they will assign this defect to development team to fix the bug.

Once all the UAT cases are executed, customer will provide sign-off on the UAT.

Deployment/Go Live/ Implementation :

In this phase the test application will be deployed in production environment for live usage.
After implementation, project team will do a round of high level testing to ensure everything is working perfect.
Customer will do validation in production environment and give sign-off if everything is working.

Support and Maintenance:

After implementation, warranty period starts. There will be agreement with customer and project team on the warranty period. Like 3 years, 5 years from the day of implementation.
During this period, if there are any issues, project team will take care of the issues. Usually production support team will take care of production issues, if they are unable to look into the issues then they will raise ticket and assign to Business Analyst then he will verify and assign to Development team to fix the issue.
After warranty period, maintenance will start. It means, any changes or issues found after warranty, it will taken care at additional cost and time.
 
This is how software application is built and maintained in waterfall methodology. !!

Advantages of Waterfall Methodology:

  • Simple and easy to use
  • Easy to manage – each phase has specific deliverables and a review process
  • Phases are processed and completed within scheduled time
  • Works well if requirements are very clear

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

Any questions are clarifications please ask me in comments section, will respond as soon as possible.

Currently most of the organizations are looking for Agile methodology but still as a Business Analyst we should know what is waterfall methodology or model.

I hope it helped you to provide overview of what is waterfall methodology or model.

To know more about what is waterfall methodology or model you can browse on google to get more idea and information.

If any other clarifications related what is waterfall methodology, feel free to post here.

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.

SDLC Waterfall : FAQs

What is waterfall SDLC?

Waterfall Model is a sequential model that divides software development into different phases. Each phase is designed for performing specific activity during SDLC phase. It was introduced in 1970 by Winston Royce.

Is SDLC waterfall or agile?

In Agile process, requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst. In Agile Description of project, details can be altered anytime during the SDLC process which is not possible in Waterfall method

What is difference between SDLC and waterfall model?

Different phases of the SDLC model are Requirement, Design, Implementation and Testing. Waterfall model is one of the most popular SDLC models. … This model has different deliverables from each phase.In a waterfall model, each step follows in a sequential manner without overlapping or iterative steps.

Why waterfall model is best?

Advantages of waterfall model
This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. In this model phases are processed and completed one at a time.

Is waterfall iterative?

In traditional, full waterfall development, a team does all of the analysis for the entire project first. … This is an iterative waterfall process, not an agile process. Ideally, in an agile process, all types of work would finish at exactly the same time

Why should I use waterfall methodology?

The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

What are the disadvantages of waterfall model?

Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. No working software is produced until late during the life cycle. High amounts of risk and uncertainty.

Bug Life Cycle / What is Defect Life Cycle ?

Defect/Bug Life Cycle

Defect/ Bug Life Cycle

Defect life cycle also known as bug life cycle. Defect life cycle/ Bug life cycle is the journey of bug from initiation to closure during its life time. It may different from organization to organization and may project to project.

Business Analyst/ Scrum Master will monitor till closure of the defect, it may different from organization to organization.

New : During testing of the application if tester find/observed any issue then tester will raise the issue(Bug/Defect)

Assigned : Once tested raised the defect it will be assigned to the development team to fix/resolve  the defect.

Open : Development team will open the defect.

Review : Development team will review the defect, whether it is genuine issue or not.

Rejected : If development team feels it is not a genuine defect then they can reject the ticket with mention their comments.

Deferred – When a defect cannot be addressed in this cycle then it is deferred to future release.

Duplicate: Development team will mark as a duplicate if it is duplicate defect means which is already raised previously.

Fixed : If development team identifies as it is genuine bug then team will fix the issue. In some organizations once, developer fixed the code development manager/team lead will review the code, whether it is impacting any other functionality or not. And they fixed the issue again they will assign to testing team for testing.

Retest : Testing team will test the defect which is assigned by development team.

Close : If testing team feels defect is resolved then they will close the defect ticket.

Reopen : If testing team feels still issue/defect not resolved then again they will reopen the ticket and assign back to development team to resolve the issue, again same cycle will follow.

I hope it helped you to understand  Defect Management Life Cycle 

Defect/Bug Life Cycle in Software Testing

 

error

Enjoy this blog? Please spread the word :)