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.
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.
What is waterfall model in software engineering ?
Requirements Gathering.
Requirements Analysis
Design
Coding
Testing
Deployment.
Important Articles
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.
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
Topics Covered in this Article:
What is RACI matrix?
What is a RACI chart?
What does RACI stand for?
RACI definitions
Advantages of a RACI chart
When to use a RACI matrix
How to create a RACI matrix: Example & template
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.
Enter all project roles or team member names across the top row.
List all tasks, milestones, and decisions down the left column.
For each task, assign a responsibility value to each role or person on the team.
RACI chart Example
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.
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):
We can ensure all the test cases covered.
It allows to identify the missing functionality easily
It is easy to track the overall test execution status
It allows updating the test cases if any change in requirements or any change request comes.
We can ensure all the requirements covered and tested.
It helps to improve the quality of the product.
As we covered most of the test scenarios it helps to improve the client satisfaction.
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:
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:
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.
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.
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.
Requirements gathering
Requirements Analysis
Design
UAT
Functional Testing
Production Movement
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.
Ensure that the project is delivered on-time, within scope and within budget.
Develop a detailed project plan which is used to monitor and track progress.
Set deadlines, assign responsibilities and monitor the progress of the project.
Perform risk management to assess the project’s risks.
Meet with clients to understand the project’s requirements.
Manage the stakeholder’s relationships.
Measure the project’s performance.
Create and maintain comprehensive project documentation
Let us discuss here what is 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:
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:
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.
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:
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.
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
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
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)
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.
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:
Organizes the functional requirements,
Iterative in nature and updated throughout the project life-cycle
Records scenarios in which a user will interact with the system
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 .
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.
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.
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.
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 AgileAdvantages 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.
Let us discuss BRD Vs FRD herre and how to to prepare the BRD and 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:
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:
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.
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
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:
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:
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. !!
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:
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.
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.
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
