Question 1 – BPM

GOAL Procurement, Revenue

INPUT Manufacturing companies ((Fertilizers, seeds and pesticides), Farmers, Warehouse, Logistics

OUTPUT To facilitate farmers to buy seeds, pesticides, and fertilizers from anywhere through ONLINE.

ACTIVITIES Internet connectivity, Mobile number, User Id, Farmer unique number, User friendly, Easy payment.

RESOURCES Internet, Mobile, laptop, Desktop,

VALUE CREATED Discounts, Cash on delivery, Vendor Relationship, Product availability.

Question 2 – SWOT

Strength

Strong links with suppliers / Manufacturers providing subsidies.

Wide presence. High control over all the operations within the production process.
Vision is to encourage the consistency, standardize in agriculture marketplace.
Actual value sighting constructed on demand and supply.
Restructuring the measures between Farmers and suppliers / Manufacturers.

Weakness

Farmers need to be alert for online presence and need to learn about the
technologies.
Not much marketing promotions or awareness program.
Lack of Confirmed Market Positioning.
Farmers already have strong attachment to existing local marketers / vendors.

Opportunities

Whole process of selection based on quality of product.

Transparent System.
Cashless Transactions.
Timely Payment through online platform.
Timely and home delivery through online platform.
All the manufacturers and suppliers come under platform.

Threats

Participation of all Manufacturer / Supplier at one place is challenging.

Cutthroat competition.
Many current participants already contributing the undistinguishable products.
Wide arrangement of technical skill development program.
Changes in technology.
Question 3 – Feasibility study

1. Feasibility Study

1.1 Technical Feasibility

Project OAPS is a complete web-based application.
The main technologies and tools that are associated with OAPS are
The hardware technologies and tools that are associated with the OAPS are
 Server hardware for hosting the website and database.
 Networking equipment such as routers, switches, and firewalls.
 Backup and disaster recovery hardware.

The software technologies and tools that are associated with the OAPS are
 E-commerce platform.
 Version Control System (VCS): May consider using a VCS such as Git or SVN to
manage the source code and collaborate with other developers.
 Testing Tools: Consider using testing tools such as JUnit or TestNG for unit testing,
Selenium for automated testing, and LoadRunner for load testing.
 Web Server: A web server is required for hosting the online agriculture product
store. Apache Tomcat is a popular web server that is often used for hosting Java-
based web applications.
 Payment gateway integration such as PayPal, Stripe, or Authorize.Net.
 Content management system such as WordPress or Drupal.
 Development tools such as Eclipse or NetBeans. These IDEs come with a range of
features such as code completion, debugging, and syntax highlighting, making it
easier for developers to write, test and debug their code.
 Database management system such as MySQL or Oracle.

From these it’s clear that the project OAPS is technically feasible.

1.2 Resource and Time Feasibility

Resource feasibility Resources that are required for the OAPS project includes,
Resources:
 Java developers who are proficient in developing e-commerce applications using
Java technologies.
 Web designers who can create a visually appealing and user-friendly website for
the online agriculture product store.
 Database administrators who can design and maintain the database for the online
store.
 Quality Assurance/Testers who can test the website to ensure that it is functioning
correctly and meets the requirements.
  Testers: Testers who can test the website to ensure that it is functioning correctly
and meets the requirements. They should have experience in manual and
automated testing.
 Project Manager who can manage the team and ensure that the project is
delivered on time and within budget.

Time Feasibility
The length of time required to complete the online agriculture product shop project will vary
depending on a number of variables, including its scale, the resources available, and any
potential obstacles that might appear while it is being developed.

Yet, a general timeline for the project could be between 6 to 8 months. This comprises the
time spent
Generalized time frame for a medium-sized project:

 Requirements gathering: 2-4 weeks

 Requirement analysis: 2-4 weeks
 Design: 3-6 weeks
 Database design: 2-3 weeks
 Front-end and back-end development: 8-10 weeks
 Quality assurance and testing: 2-4 weeks
 Deployment and launch: 1-2 weeks

1.3 Financial/ Budget Feasibility

Being a web application OAPS will have an associated hosting cost. Since the system
doesn’t consist of any multimedia data transfer, bandwidth required for the operation of
this application is very low. The system will follow the freeware software standards.
 Hardware costs: Hardware costs: $5,000 - $12,000 (approx.)
This includes the cost of purchasing or renting server hardware, networking
equipment, backup and disaster recovery hardware.
 Software costs: Software costs: $5,000 - $15,000 (approx.)
This includes the cost of purchasing or licensing software tools such as an IDE, web
server, DBMS, e-commerce platform, payment gateway integration, content
management system, and testing tools.
 Resource costs: Resource costs: $50,000 - $100,000 (assuming a team of 7-12
resources) (approx.)
This includes the cost of salaries and benefits for the trained resources required for
the project, including Java developers, web designers, database administrators,
quality assurance/testers, and project manager.
 Development and design costs: Dev and design costs: $50,000 - $100,000 (approx.)
This includes the cost of designing and developing the website and e-commerce
platform, including coding, testing, and deployment.
 Ongoing costs: Ongoing costs: $10,000 - $20,000 per year
This includes the cost of hosting the website, maintenance and support, ongoing
development, and updates to the website and e-commerce platform.
From these it’s clear that the project OAPS is financially feasible.
Question 4 – Gap Analysis

1. Identify the existing situation (AS-IS).

In the present system being used is manual purchase through suppliers or vendors or via
market. In this farmer has to rely on the inventory of these group and the rate or quality
they provide.
Product availability and its procurement is the main cumbersome task. Currently its
through individual access to market and availability depends upon the product usage
throughout the consumer and production status from manufacturer.

2. Identify the future process (TO-BE).

This new application should be able to accept the product (fertilizers, seeds, pesticides)
details from the manufacturers and should be able to display them to the Farmers.
Each of the technologies are freely available and the technical skills required are
manageable. Time limitations of the product development and the ease of implementing
using these technologies are synchronized. Farmers will browse through these products
and select the products what they need and request to buy them and deliver them to
farmers location.

3. Analyze gap between existing and future process.

Farmers main focus is the product availability and its inventory which has been very
difficult to access since multiple factors affecting its possibility like production, supply
chain, market review for products, not possible to get specific product availability.
This can be facilitated farmers to buy seeds, pesticides, and fertilizers from anywhere
through internet connectivity. Since new users are involved, Application will be user
friendly. OAPS is mainly concerned with ONLINE system of everything.
Question 5 – Risk Analysis

There are a variety of internal and external risks in software development. Here are some different
risk factors that may be involved in business analysis (BA) risks and process/project risks:

BA Risks:
1. Incomplete or inaccurate requirements gathering
2. Misunderstanding of stakeholder needs
3. Ambiguous or changing project objectives
4. Lack of stakeholder support or buy-in
5. Insufficient resources or funding
6. Limited access to data or information
7. Inadequate communication among team members
8. Unforeseen external factors such as legal or regulatory changes
9. Unclear or poorly defined project scope
10. Misalignment between business and IT strategies

Process/Project Risks:
1. Unrealistic project timelines or milestones
2. Insufficient project resources or funding
3. Inadequate project planning or management
4. Poor project team communication or collaboration
5. Technical difficulties or system failures
6. Insufficient quality control or testing
7. Scope creep or uncontrolled project changes
8. Vendor or supplier issues
9. Budget overruns or financial issues
10. Unforeseen external factors such as natural disasters or geopolitical events.
Question 6 – Stakeholder Analysis (RACI Matrix)

* Authorize Has ultimate signing authority for any changes to the document.
R Responsible Responsible for creating this document.
A Accountable Accountable for accuracy of this document (for example, the
project manager)

C Consulted Provides input (such as an interviewee).

I Informed Must be informed of any changes.
S Support Provides supporting services in the production of this document
Question 7 – Business Case Document

Business Case Document

DATE: 15/01/2023

PROJECT NAME: ONLINE AGRICULTURAL PRODUCT STORE (OAPS)

PROJECT MANAGER NAME: Mr. Vandanam

PROJECT APPROVED BY: Mr. Karthik

Project Scope:
It includes the development and launch of our online agriculture product store. This will include the
design and development of user-friendly online platform, the procurement and stocking of our
inventory, the establishment of relationships with suppliers and manufacturers, the development
and implementation of our marketing and sales strategies, and the hiring and training of our
Technical and management team and staffs.

Analysis:

In the agricultural sector vas areas have been affected with the inventory problem and delivery of
necessary product whenever needed. About majority of the sector have indulged in the farming and
poor farming is the consequence of this.

Mr Karthik is the Delivery Head in APT IT SOLUTIONS company and he reached out to Mr Henry.
Mr Vandanam is project Manager, Ms. Juhi is Senior Java Developer, Mr Teyson, Ms Lucie, Mr
Tucker, Mr Bravo are Java Developers. Network Admin is Mr Mike and DB Admin is John. Mr Jason
and Ms Alekya are the Tester. As BA Mr Shivam joined this team.

Time:
Generalized time frame for a medium-sized project:
 Requirements gathering: 2-4 weeks
 Requirement analysis: 2-4 weeks
 Design: 3-6 weeks
 Database design: 2-3 weeks
 Front-end and back-end development: 8-10 weeks
 Quality assurance and testing: 2-4 weeks
 Deployment and launch: 1-2 weeks

Budget:
The system will follow the freeware software standards.
 Hardware costs: Hardware costs: $5,000 - $12,000 (approx.)
This includes the cost of purchasing or renting server hardware, networking
equipment, backup and disaster recovery hardware.
  Software costs: Software costs: $5,000 - $15,000 (approx.)
This includes the cost of purchasing or licensing software tools such as an IDE, web
server, DBMS, e-commerce platform, payment gateway integration, content
management system, and testing tools.
 Resource costs: Resource costs: $50,000 - $100,000 (assuming a team of 7-12
resources) (approx.)
This includes the cost of salaries and benefits for the trained resources required for
the project, including Java developers, web designers, database administrators,
quality assurance/testers, and project manager.
 Development and design costs: Dev and design costs: $50,000 - $100,000 (approx.)
This includes the cost of designing and developing the website and e-commerce
platform, including coding, testing, and deployment.
 Ongoing costs: Ongoing costs: $10,000 - $20,000 per year.This includes the cost of
hosting the website, maintenance and support, ongoing development, and updates
to the website and e-commerce platform

Risks:

There are several key risks associated with the development and launch of OAPS. These include:
 Market competition: The agriculture product market is highly competitive, with many
established players and a high degree of price sensitivity among customers. We will need to
differentiate ourselves through our quality, affordability, and convenience, and continually
adapt our strategies based on market feedback.
 Supply chain disruptions: Our ability to source and stock inventory could be impacted by
disruptions in the supply chain, such as natural disasters, trade disputes, or pandemics. We
will need to maintain relationships with multiple suppliers and manufacturers to minimize
the impact of any disruptions.
 Technology failures: Our online platform will be critical to our success, and any technical
failures or security breaches could severely impact our business. We will need to invest in
robust technology and security measures to minimize this risk.
 Regulatory compliance: The agriculture product market is subject to a wide range of
regulations and compliance requirements, and failure to comply could result in fines or legal
action. We will need to ensure that we are fully compliant with all relevant regulations and
maintain a strong understanding of any changes or updates.
Question 8 – Four SDLC Methodologies
Mr Karthik explained to Mr. Henry about SDLC.

Iterative Methodology

Iterative methodology is an approach to software development that involves repeating a series of

development cycles or iterations. Each iteration includes design, development, and testing, and
builds upon the previous one, allowing for incremental improvements and feedback.
In an iterative approach, the development team works closely with stakeholders to gather feedback
and refine the product requirements and design. This feedback is then used to inform the next
iteration, and the process continues until the final product is complete.
Iterative methodology is often used when the project requirements are not well-defined or when
there is a lot of uncertainty. By breaking the development process into smaller iterations, the team
can explore different ideas and approaches, and make adjustments as necessary based on feedback
from stakeholders.
One of the key benefits of an iterative approach is that it allows for more flexibility and adaptability
than a linear, sequential approach like the Waterfall model. It can also help to reduce the risk of
project failure by allowing the team to identify and address issues early on in the development
process.

Advantage (Pros):

1. Testing and debugging during smaller iteration is easy.

2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.
Disadvantage (Cons):
1. It is not suitable for smaller projects.
2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

Sequential Methodology

Sequential methodology is a systematic approach to problem-solving or decision-making in which a

series of steps or stages are followed in a particular order, with each step informing the next. It is
often used in fields such as engineering, software development, and research. The key feature of
sequential methodology is its structured and iterative nature, with each stage building upon the
results and insights gained in the previous stage. This helps to ensure that the final outcome is well-
informed, well-designed, and meets the intended requirements or objectives.

The popular SDLC models that follow sequential processes are waterfall model, V model. Waterfall
model is also known as the traditional model, classic model, predictive model. It follows the top-
down approach to develop the software, hence the name waterfall model.
Another popular sequential approach to develop the software is V model. V-Model also referred to
as the Verification and Validation Model. In this, each phase of SDLC must complete before the next
phase starts. It follows a sequential design process same as the waterfall model. Testing of the
device is planned in parallel with a corresponding stage of development.

Evolutionary Methodology

The evolutionary methodology, initially proposed by Boehm, is an evolutionary software process

model that couples the iterative feature of prototyping with the controlled and systematic aspects of
the linear sequential model. It implements the potential for rapid development of new versions of
the software. Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype. During later
iterations, more and more complete versions of the engineered system are produced.

Each cycle in the spiral is divided into four parts:

Objective setting:
Each cycle in the spiral starts with the identification of purpose for that cycle, the various
alternatives that are possible for achieving the targets, and the constraints that exists.
Play Video

Risk Assessment and reduction:

The next phase in the cycle is to calculate these various alternatives based on the goals and
constraints. The focus of evaluation in this stage is located on the risk perception for the project.

Development and validation:

The next phase is to develop strategies that resolve uncertainties and risks. This process may include
activities such as benchmarking, simulation, and prototyping.
Planning:
Finally, the next step is planned. The project is reviewed, and a choice made whether to continue
with a further period of the spiral. If it is determined to keep, plans are drawn up for the next step of
the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase may
be an evolutionary development that includes developing a more detailed prototype for solving the
risks.

When to use?
1. When deliverance is required to be frequent.
2. When the project is large
3. When requirements are unclear and complex
4. When changes may require at any time
5. Large and high budget projects
Advantages
1. High amount of risk analysis
2. Useful for large and mission-critical projects.
Disadvantages
1. Can be a costly model to use.
2. Risk analysis needed highly particular expertise
3. Doesn't work well for smaller projects.

Agile Methodology

The meaning of Agile is swift or versatile. "Agile process Methodology " refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and requirements
are laid down at the beginning of the development process. Plans regarding the number of
iterations, the duration and the scope of each iteration are clearly defined in advance.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

When to use?
1. When frequent changes are required.
2. When a highly qualified and experienced team is available.
3. When a customer is ready to have a meeting with a software team all the time.
4. When project size is small.
Advantage (Pros) of Agile Method:
1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages (Cons) of Agile Method:
1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

Question 9 – Waterfall, RUP, Spiral and Scrum Models

Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases: Requirements
analysis and specification, design, implementation, and unit testing, integration and system testing,
and operation and maintenance. The steps always follow in this order and do not overlap. The
developer must complete every phase before the next phase begins. This model is named "Waterfall
Model", because its diagrammatic representation resembles a cascade of waterfalls.

When to use SDLC Waterfall Model?

1. Some Circumstances where the use of the Waterfall model is most suited are:
2. When the requirements are constant and not changed regularly.
3. A project is short
4. The situation is calm
5. Where the tools and technology used is consistent and is not changing
6. When resources are well prepared and are available to use.
Advantages (pros) of Waterfall model
1. This model is simple to implement also the number of resources that are required for it is
minimal.
 2. The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
3. The start and end points for each phase is fixed, which makes it easy to cover progress.
4. The release date for the complete product, as well as its final cost, can be determined before
development.
5. It gives easy to control and clarity for the customer due to a strict reporting system.
Disadvantages (cons) of Waterfall model
1. In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
2. This model cannot accept the changes in requirements during development.
3. It becomes tough to go back to the phase. For example, if the application has now shifted to
the coding phase, and there is a change in requirement, It becomes tough to go back and
change it.
4. Since the testing done at a later stage, it does not allow identifying the challenges and risks
in the earlier phase, so the risk reduction strategy is difficult to prepare.

RUP - Rational Unified Process

Rational Unified Process (RUP) is a software development process for object-oriented models. It is
also known as the Unified Process Model. It is created by Rational corporation and is designed and
documented using UML (Unified Modelling Language). This process is included in IBM Rational
Method Composer (RMC) product. IBM (International Business Machine Corporation) allows us to
customize, design, and personalize the unified process. Some characteristics of RUP include use-case
driven, Iterative (repetition of the process), and Incremental (increase in value) by nature.

1. Inception –
 Communication and planning are the main ones.
 Identifies the scope of the project using a use-case model allowing managers to estimate
costs and time required.
 Customers’ requirements are identified and then it becomes easy to make a plan for the
project.
 The project plan, Project goal, risks, use-case model, and Project description, are made.
 The project is checked against the milestone criteria and if it couldn’t pass these criteria
then the project can be either cancelled or redesigned.
2. Elaboration –
 Planning and modelling are the main ones.
 A detailed evaluation and development plan is carried out and diminishes the risks.
 Revise or redefine the use-case model (approx. 80%), business case, and risks.
 Again, checked against milestone criteria and if it couldn’t pass these criteria then again
project can be cancelled or redesigned.
 Executable architecture baseline.
3. Construction –
 The project is developed and completed.
 System or source code is created and then testing is done.
 Coding takes place.
4. Transition –
 The final project is released to the public.
  Transit the project from development into production.
 Update project documentation.
 Beta testing is conducted.
 Defects are removed from the project based on feedback from the public.

5. Production –
 The final phase of the model.
 The project is maintained and updated accordingly.
Advantages:
1. It provides good documentation; it completes the process in itself.
2. It provides risk-management support.
3. It reuses the components, and hence total time duration is less.
4. Good online support is available in the form of tutorials and training.

Disadvantages:
1. Team of expert professional is required, as the process is complex.
2. Complex and not properly organized process.
3. More dependency on risk management.
4. Hard to integrate again and again.

Spiral Model

The spiral model, initially proposed by Boehm, is an evolutionary software process model that
couples the iterative feature of prototyping with the controlled and systematic aspects of the linear
sequential model. It implements the potential for rapid development of new versions of the
software. Using the spiral model, the software is developed in a series of incremental releases.
During the early iterations, the additional release may be a paper model or prototype. During later
iterations, more and more complete versions of the engineered system are produced.

Each cycle in the spiral is divided into four parts:

Objective setting:
Each cycle in the spiral starts with the identification of purpose for that cycle, the various
alternatives that are possible for achieving the targets, and the constraints that exists.
Play Video

Risk Assessment and reduction:

The next phase in the cycle is to calculate these various alternatives based on the goals and
constraints. The focus of evaluation in this stage is located on the risk perception for the project.

Development and validation:

The next phase is to develop strategies that resolve uncertainties and risks. This process may include
activities such as benchmarking, simulation, and prototyping.

Planning:
Finally, the next step is planned. The project is reviewed, and a choice made whether to continue
with a further period of the spiral. If it is determined to keep, plans are drawn up for the next step of
the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase may
be an evolutionary development that includes developing a more detailed prototype for solving the
risks.

When to use Spiral Model?

1. When deliverance is required to be frequent.
2. When the project is large
3. When requirements are unclear and complex
4. When changes may require at any time
5. Large and high budget projects
Advantages
1. High amount of risk analysis
2. Useful for large and mission-critical projects.
Disadvantages
1. Can be a costly model to use.
2. Risk analysis needed highly particular expertise
3. Doesn't work well for smaller projects.

Agile – SCRUM Model

The meaning of Agile is swift or versatile. "Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts
do not directly involve long term planning. The project scope and requirements are laid down at the
beginning of the development process. Plans regarding the number of iterations, the duration and
the scope of each iteration are clearly defined in advance.
Phases of Agile Model:
Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

When to use the Agile Model?

1. When frequent changes are required.
2. When a highly qualified and experienced team is available.
3. When a customer is ready to have a meeting with a software team all the time.
4. When project size is small.
Advantage (Pros) of Agile Method:
1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages (Cons) of Agile Model:
1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

Question 10 – Waterfall Vs V-Model

Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases: Requirements
analysis and specification, design, implementation, and unit testing, integration and system testing,
and operation and maintenance. The steps always follow in this order and do not overlap. The
developer must complete every phase before the next phase begins. This model is named "Waterfall
Model", because its diagrammatic representation resembles a cascade of waterfalls.

When to use SDLC Waterfall Model?

 1. Some Circumstances where the use of the Waterfall model is most suited are:
2. When the requirements are constant and not changed regularly.
3. A project is short
4. The situation is calm
5. Where the tools and technology used is consistent and is not changing
6. When resources are well prepared and are available to use.
Advantages (pros) of Waterfall model
1. This model is simple to implement also the number of resources that are required for it is
minimal.
2. The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
3. The start and end points for each phase is fixed, which makes it easy to cover progress.
4. The release date for the complete product, as well as its final cost, can be determined before
development.
5. It gives easy to control and clarity for the customer due to a strict reporting system.
Disadvantages (cons) of Waterfall model
1. In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
2. This model cannot accept the changes in requirements during development.
3. It becomes tough to go back to the phase. For example, if the application has now shifted to
the coding phase, and there is a change in requirement, It becomes tough to go back and
change it.
4. Since the testing done at a later stage, it does not allow identifying the challenges and risks
in the earlier phase, so the risk reduction strategy is difficult to prepare.

V-Model

V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must
complete before the next phase starts. It follows a sequential design process same as the waterfall
model. Testing of the device is planned in parallel with a corresponding stage of development.
Verification:
It involves a static analysis method (review) done without executing code. It is the process of
evaluation of the product development process to find whether specified requirements meet.

Validation:
It involves dynamic analysis method (functional, non-functional), testing is done by executing code.
Validation is the process to classify the software after the completion of the development process to
determine whether the software meets the customer expectations and requirements.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements understood
from the customer's side. This phase contains detailed communication to understand
customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyse and interpret the business of the
proposed system by studying the user requirements document.
3. Architecture Design: The baseline in selecting the architecture is that it should understand
all which typically consists of the list of modules, brief functionality of each module, their
interface relationships, dependencies, database tables, architecture diagrams, technology
detail, etc. The integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into small modules.
The detailed design of the modules is specified, which is known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements, a
suitable programming language is decided. There are some guidelines and standards for
coding. Before checking in the repository, the final build is optimized for better performance,
and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design
phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the
smallest entity which can independently exist, e.g., a program module. Unit testing verifies
that the smallest entity can function correctly when isolated from the rest of the codes/
units.
2. Integration Testing: Integration Test Plans are developed during the Architectural Design
Phase. These tests verify that groups created and tested independently can coexist and
communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit
and Integration Test Plans, System Tests Plans are composed by the client?s business team.
System Test ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part.
It includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.
When to use V-Model?
1. When the requirement is well defined and not ambiguous.
2. The V-shaped model should be used for small to medium-sized projects where requirements
are clearly defined and fixed.
3. The V-shaped model should be chosen when sample technical resources are available with
essential technical expertise.
Advantage (Pros) of V-Model:
1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.
Disadvantage (Cons) of V-Model:
1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the
software are produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.

Question 11 – Justify your choice

V-model

The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It is
also known as Verification and Validation model. It is based on the association of a testing phase for
each corresponding development stage. Development of each step directly associated with the
testing phase. The next phase starts only after completion of the previous phase i.e., for each
development activity, there is a testing activity corresponding to it.

Verification:
It involves static analysis technique (review) done without executing code. It is the process of
evaluation of the product development phase to find whether specified requirements meet.

Validation:
It involves dynamic analysis technique (functional, non-functional), testing done by executing code.
Validation is the process to evaluate the software after the completion of the development phase to
determine whether software meets the customer expectations and requirements.

Principles of V-Model:

1. Large to Small: In V-Model, testing is done in a hierarchical perspective, For example,

requirements identified by the project team, create High-Level Design, and Detailed Design
phases of the project. As each of these phases is completed the requirements, they are
defining become more and more refined and detailed.
 2. Data/Process Integrity: This principle states that the successful design of any project requires
the incorporation and cohesion of both data and processes. Process elements must be
identified at each and every requirement.
3. Scalability: This principle states that the V-Model concept has the flexibility to accommodate
any IT project irrespective of its size, complexity or duration.
4. Cross Referencing: Direct correlation between requirements and corresponding testing
activity is known as cross-referencing.
5. Tangible Documentation: This principle states that every project needs to create a
document. This documentation is required and applied by both the project development
team and the support team. Documentation is used to maintaining the application once it is
available in a production environment.

Why preferred by me?

 It is easy to manage due to the rigidity of the model. Each phase of V-Model has specific
deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.

When to use?
1. Where requirements are clearly defined and fixed.
2. The V-Model is used when ample technical resources are available with technical expertise.

Advantages:
1. This is a highly disciplined model and Phases are completed one at a time.
2. V-Model is used for small projects where project requirements are clear.
3. Simple and easy to understand and use.
4. This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.
5. It enables project management to track progress accurately.

Question 12 – Gantt Chart

Question 13 – Fixed Bid Vs Billing

Fixed Bid model

It is based on an estimate of the amount of work that needs to be done. Project requirements need
to be written to define this scope of work. Prototype or Wireframes also need to be created to help
the development team figure out the hours necessary to implement all features. With a fixed-price
project, the service provider and the customer both carry some scope-related risk. Any extra work
(when clients want to add a totally new feature that was not specified in the documentation) usually
goes under an additional agreement. In this case, the client must pay extra.

In this model, it’s important to discuss everything before the actual development in order to
estimate the cost of the software product. The fixed-price model ensures that a project is done and
delivered within a specific timeframe and budget.

Billing Model

It involves regularly paying for work completed. With this model, the customer plays a greater role in
the development of the software solution and carries all risks related to the scope of work. The level
of responsibility that the client carries for the whole development process with time & materials is
much higher than with fixed-price or milestone projects. The customer gets set up with a team and is
billed for the actual time spent on development.

Question 14,15,16,17,18,19,20 – Timesheets

 RG Timesheet of a BA
 RA Timesheet of a BA

 Design Timesheet of a BA
 Development Timesheet of a BA

 Testing Timesheet of a BA
 UAT Timesheet of a BA

 Deployment and Implementation

Question 21 – Audits

 An audit is an examination of the financial statements of a company, such as the income

statement, cash flow statement, and balance sheet.
 Audits provide investors and stakeholders with confidence in the accuracy of a corporation’s
financial reporting.
 Once completed, the auditor will provide an opinion on whether the financial statements
accurately reflect the financial position of the corporation.
 The audit provides stakeholders and regulatory agencies with information on how money is
earned and spent throughout the fiscal year. Depending on the size of the company, an
audit can span a few months to an entire year.

The following would probably be covered by the five quarterly audits that are scheduled for the
project:

1. Q1 Audit - Requirements Gathering

During this audit, the BA would check the requirements gathered for the project and ensure
that they are correct, complete and well-defined. Many papers should be provided to the
auditor during the requirement gathering stage of the Q1 audit. These records consist of:
Business requirements document (BRD): Functional requirements document (FRD): Use case
diagrams: Process flows: User stories: Acceptance criteria.

2. Q2 Audit – System design

The system design documents would be examined as part of this audit to make that they are
compatible with the project requirements and that they offer a clear and detailed plan for
the system's architecture and functionality. Many papers should be provided to the auditor
during the System Design phase of the Q2 audit. These records consist of:
High-level design document: Low-level design document: Data flow diagrams: Sequence
diagrams: Entity-relationship diagrams.

3. Q3 Audit – Implementation
In this audit, the BA would review the system's code to ensure that it is being implemented
according to the design specifications, coding standards, and best practices. During the
Implementation phase in Q3 audit, several documents should be presented to the auditor.
These documents include: Source code: Unit test cases: Integration test cases: Test results:
Code review report: Deployment plan.

4. Q4 Audit – Testing
This audit would involve reviewing the test cases and test results to ensure that the system
is being tested thoroughly and that all defects are being identified and addressed. The
Testing phase in Q4 audit, several documents should be presented to the auditor. These
documents include: Test plan: Test cases: Test results: Traceability matrix: Defect report:
User acceptance test plan and results.

5. Q5 Audit – Deployment
 During this audit, the BA would review the deployment plan to ensure that the system is
being deployed properly and that any potential issues are being mitigated. Deployment
phase in Q5 audit, several documents should be presented to the auditor. These documents
include: Deployment plan: User manual: System documentation: System security plan:
System backup and recovery plan: Change Request plan.

Question 22 – BA Approach Strategy

 Project Background Information

Problem faced by so many farmers. So, is has been decided to make an online
agriculture product store to facilitate remote area farmers to buy agriculture products. Through
this Online Web / mobile Application, Farmers and Companies (Fertilizers, seeds and pesticides
manufacturing Companies) can communicate directly with each other.
 The project is under agriculture domain into IT field. There are enough information
corresponding to the domain.

 What Elicitation Techniques to apply

To elicit requirements for the entire project will require a lot of time. That’s a very time-efficient
exercise.
In that case, we created a small team by choosing members from the departments itself (who
were IT enabled and understood processes). Each team was led by a leader or process
champion. Each department team was made responsible for interacting with other members of
the team to gather requirements and document it. Of course, we conducted a small session to
help them understand the formal documentation.
Once the leader or process champions, completed their work, our team of business analysts will
sit with the leaders or process champions and their respective teams for knowledge transfer and
review.
This technique helped us save a lot of time. The critical success factor for this approach is
Brainstorming:
 Make sure that Leader or process champions understand software development process
and the business processes.
 Make sure that formal documentation format is finalised well in advance and
communicated with all the teams.
 The knowledge transfer and review meetings conducted at regular intervals to ensure
better efficiency.

 How to do Stakeholder Analysis RACI/ILS.

What Is Stakeholder Analysis?

Stakeholders are all those who need to be considered in achieving project goals and whose
participation and support are crucial to its success. Stakeholder analysis identifies all primary and
secondary stakeholders who have a vested interest in the issues with which the project or policy
is concerned. The goal of stakeholder analysis is to develop a strategic view of the human and
 institutional landscape, and the relationships between the different stakeholders and the issues
they care about most.

A stakeholder analysis can help a project or programme identify:

• The interests of all stakeholders who may affect or be affected by the programme/project;
• Potential conflicts or risks that could jeopardise the initiative;
• Opportunities and relationships that can be built on during implementation;
• Groups that should be encouraged to participate in different stages of the project;
• Appropriate strategies and approaches for stakeholder engagement; and
• Ways to reduce negative impacts on vulnerable and disadvantaged groups.

We can use a stakeholder wheel technique, which contains each stakeholder that impacts the
project, such as:
 Owners: Mr. Henry, Mr. Pandu, Mr. Dooku
 Managers: senior or middle managers responsible for communication and monitoring the
progress
 Employees: developers, analysts, or testers responsible for delivering the project
 Regulators: any regulators involved that monitor adherence to rules — e.g. a regulator that
monitors HIPAA compliance
 Suppliers: any API provider or other supplier service needed that the project might need
 Partners: individuals responsible for working alongside the project that provides
complementary or supplementary products or services
 Customers: the end-users of the product
 Competitors: a potential section of users of competitive products or inputs from the
competitors themselves

 What Documents to Write

Important Documents to be Prepared by a Business Analyst

 Project vision Document
 Business Analysis Plan
 Business Requirements Document
 Functional requirement specification (FRS)/ Functional Specification Document (FSD)
 System requirement specification (SRS)/ System Requirement Document (SRD)
 Requirement traceability matrix (RTM)
 Use Case Diagrams
 Activity Diagrams
 User Stories
 Wireframes, Prototype, Mockups
 Test cases and UAT
 Sign-off documents
 Change Request Document

 What process to follow to Sign off on the Documents

 Recheck check-lists and to-do notes

 Organise walkthrough sessions
  Use a feedback log
 Ask for sign off over email with a deadline date
 Organize the project documents.
 Prepare the final report.
 Distribute the sign-off sheet.
 Transition remaining items to a to-do list.
 Review your lessons learned.
 The RASCI Model will be used to track each Deliverable through the appropriate review and
sign-off process:

 How to take Approvals from the Client

 Set Reasonable Expectations and Milestones.

 Understand What's Important to Each Stakeholder.
 Involve and Educate Your Client from the Start.
 Implement Feedback.
 Thoroughly Explain Why You Did What You Did.
 Streamlining the Review & Approval Process Makes All Parties Satisfied.

 What Communication Channels to establish n implement

Written Communication
 Memos
 Contracts
 Reports
 Manuals
  Guides
 Publications and brochures
 Letters
 Faxes

Digital Communication
 Email
 Messaging apps
 Project management apps
 Video conferencing software
 Intranet
 Blogs
 Social media
 Live chat
 Chatbots
 Press releases
 Display advertising

Mobile Communication
 Mobile phone calls
 SMS text messaging
 Messaging apps
 Video calls on mobile apps

Face to Face Communication

 How to Handle Change Requests

Key steps of a change request process

 Understand what is scope change
 Determine the impact of incorporating the change.
 Seek approval or disapproval of the change request.
 Communicate and implement the approved change request.

 How to update the progress of the project to the Stakeholders

Ways to inform stakeholders of project progress

 Understand stakeholder needs.
 Proactively listen to your stakeholders’ concerns
 Develop and execute a communication plan
 Utilize online collaboration tools to share regular progress
 Send out weekly or bi-weekly status reports
 Develop and follow a meeting cadence to meet with actively involved stakeholders
  Define a meeting cadence with project sponsors and senior leaders for steering
committee meetings.

 How to take signoff on the UAT- Client Project Acceptance Form

This form can be used to record the client's sign-off and officially bring the project to a close. Use
this form when the project outcome has been measured against its acceptance criteria and has
been formally accepted on behalf of the client.

Using this form will officially bring your project to a close and give you an opportunity to discuss
key aspects of the project with your sponsor. In the end it will give you a mutually agreed upon
outcome.

It offers a place to record:

 additional comments about the project
 key metrics achieved during the project (success criteria)
 key metrics to be tracked on an ongoing basis (to judge the long-term effectiveness of
the project)
 and a place to reference or record very high level lessons learned.

Question 23 – 3-Tier Architecture

A three-tier architecture is a client-server architecture in which the functional process logic, data
access, computer data storage and user interface are developed and maintained as independent
modules on separate platforms.
Three-tier architecture is a software design pattern and a well-established software architecture.
Three-tier architecture allows any one of the three tiers to be upgraded or replaced independently.

The user interface is implemented on any platform such as a desktop PC, smartphone or tablet as a
native application, web app, mobile app, voice interface, etc. It uses a standard graphical user
interface with different modules running on the application server.
The relational database management system on the database server contains the computer data
storage logic.
The middle tiers are usually multitiered. Since the three are not physical but logical in nature, they
may run in different servers both in on-premises based solutions, as well as in software-as-a-service
(SaaS).

Main Benefit of a Three-Tier Architecture

 It provides great freedom to development teams who can independently update or replace
only specific parts of the application without affecting the product as a whole.
 The application can be scaled up and out rather easily by detaching the front-end application
from the databases that are selected according to the individual needs of the customer.
 New hardware, such as new servers, can also be added at a later time to deal with massive
amounts of data or particularly demanding services.
  A three-tier-architecture also provides a higher degree of flexibility to enterprises who may
want to adopt a new technology as soon as it becomes available.
 Critical components of the application can be encapsulated and retained while the whole
system keeps evolving organically.

 Development cycle or upgrade times are significantly improved ensuring minimal disruption
in customer’s experience.
 Different teams can work on different sections of the application rather than on the full
stack according to their areas of expertise, improving their efficiency and speed.

The Three Tiers in a Three-Tier Architecture

Presentation/Application Tier

Occupies the top level and displays information related to services commonly available on a web
browser or web-based application in the form of a graphical user interface (GUI). It constitutes the
front-end layer of the application and the interface with which end-users will interact directly. This
tier is usually built on web development frameworks, such as CSS or JavaScript, and communicates
with other tiers by sending results to the browser and other tiers in the network through API calls.

Business logic Tier

All reusable components (logic pertaining to industry), Frequently changing Components, Governing
Body rules and regulations, Compliances should go to middle layer Ex: Printer, Payment Gateways,
mail Servers, RBI rules for banks, IRDA rules for Insurance, etc.
This tier — also called the middle tier, logic tier, business logic or logic tier — is pulled from the
presentation tier. It controls the application’s core functionality by performing detailed processing
and is usually coded in programming languages, such as Python, Java, C++, .NET, etc.

Data Tier

Houses database servers where information is stored and retrieved. Data in this tier is kept
independent of application servers or business logic, and is managed and accessed with programs,
such as MongoDB, Oracle, MySQL, and Microsoft SQL Server.

Question 24 – BA Approach Strategy for Framing Questions

1. To define your project

Before starting a project, it helps to be organised and above all, to know all the details of the project.
This questioning method is a useful tool to define all the aspects of a project before starting.

What: What is the project? What are the objectives?

Who: Who is the client? Who are the users? Who are the members of the team?
Where: Where will the project take place?
When: What is the date of the consignment? When will it start? How long will it last?
Why: Why has the project been started? What are the reasons? What is the goal?
How: Which financial, HR and technical means have been put in place to create the project? By what
means will you progress?

2. To solve a problem
The 5W1H method is a tool because this allows you to understand a potentially problematic
situation by asking the right questions.

What: description of the problem;

Who: the responsible parties;
Where: the location of the problem;
When: temporal characteristics of the problem (at what point in time, how often)
Why: reasons, cause of the problems?
How: the effects of the problem?

4. Integrating a communication or marketing strategy

In project, communication is key for effective and successful collaboration. The 5W1H method is very
useful in marketing and in communication by helping you determine the type of action plan that
should be put in place.
This type of tool allows you to define:

What: What is your problem? What are the products and services you will use to communicate?
Who: Who are your targets? To whom will you communicate? Which members of your team will
oversee various jobs?
Where: Where will you obtain the information, you need? Where are the places you would like to
communicate?
When: How often would you communicate? What is your schedule?
Why: What are the benefits of the products/services on which you are communicating? What is the
objective of this communication strategy?
How: What are the means of communication that you are going to put in place (web site, social
media, events, brochures, etc)?

SMART analysis

SMART analysis is a business analysis technique which helps a business analyst describe the user’s
expectations of a business solution. SMART analysis is a process that involves analysing, planning,
documenting, elaborating, validating and managing business system requirements.

When analysing the requirements, a business analyst checks that all the requirements are SMART:
 Specific;
 Measurable;
 Achievable;
 Relevant;
 Time-framed.

Specific
The requirement is clear and unambiguous. Explains to the project team exactly what’s expected.
Measurable
The requirement can be measured to determine whether it’s been met.

Achievable
The requirement is attainable otherwise we are sitting ourself up to fail.

Relevant
The requirement must be relevant to the business needs of the organisation and be realistic as well.

Time-framed
The requirement has a clearly defined time frame for when it will be achieved.

RACI

Responsible
 Completes task or objective, or makes decision.
 Leads due diligence process, including gathering necessary input and information.
 Responsible for the performance of the task.

Authorize
 Key decision maker(s) for the deliverable (note: Typically, a PM, business user and possible a
vendor counterpart).
 Holds final decision authority for the content of a specific project deliverable.
 Granting of approval indicates the individual has evaluated the idea/project and approves it
in its proposed form.

Consult
 Individual possessing perspective or information valuable to a deliverable.
 Perspective taken into account/used at the discretion of the Responsible. The approver does
not need to agree with decision.

Inform
 Individual who needs to know results of decision to effectively carry out existing role.
 Notified after decision is made.

3 Tier Architecture

Three-tier architecture is a well-established software application architecture that organizes

applications into three logical and physical computing tiers: the presentation tier, or user interface;
the application tier, where data is processed; and the data tier, where the data associated with the
application is stored and managed.
The chief benefit of three-tier architecture is that because each tier runs on its own infrastructure,
each tier can be developed simultaneously by a separate development team, and can be updated or
scaled as needed without impacting the other tiers.

Use cases

A use-case describes a sequence of actions, performed by a system that provides value to an actor.
The use-case describes the system’s behaviour under various conditions as it responds to a request
from one of the stakeholders, called the primary actor.
The actor is the Who of the system, in other words he the end user.
In software and systems engineering, a use-case is a list of steps, typically defining interactions
between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a
human or an external system.

Use Case Specs

Each specification includes:

 Brief use case overview
 Reference to the functional area
 Preconditions
 Actors involved
 Main flow
The flow of events in the use case specification section provides the main bulk of the use
case specification and describes what the actor does and what the system does in response.
It is phrased in the form of a dialog between the actor and the system. The use case
describes what happens inside the system, but not how or why.
 Alternative flows
The use case description alternative flows section of a use case specification is used to
describe either:
alternative processing or actions that need to occur as a result of exceptions that occur
when carrying out the basic flow or an alternative or less common way of achieving the
actor goal of the use case.
 Functional requirements for the solution
 Traceability to the business requirements
 Market or business rules applicable to the scenario
 User interface, controls and data

Activity Diagram

Activity diagrams can be used to describe the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control. Another site puts it
even more simply: Activity diagrams are used to illustrate activities. To that end, activity diagrams
may be used to describe an entire system, a use case, or an activity within the use case.
The questions are in accordance with the flow of work and its components.

Page Design

Why do you need to design your website?

What need or business goals do you have for your website that aren’t being met?
What goals do you want your website to achieve?
What kind of website does your brand need?
What will visitors accomplish on your this?
Who is this for?
What image, look, or feel do you want to portray?
When analysing your competitors’ sites, what do you like and not like about their websites?
What’s the scope of this project?
What’s the project budget?
Which functions or features are necessary to have versus nice to have?
What is the most important information your site must relay to the user, especially on the home
page?
How much traffic are you anticipating?
Will multiple levels of access be required?

Question 25 – Elicitation Techniques

Brainstorming

This technique is used to generate new ideas and find a solution for a specific issue. The members
included for brainstorming can be domain experts, subject matter experts. Multiple ideas and
information give you a repository of knowledge and you can choose from different ideas.
This session is generally conducted around the table discussion. All participants should be given an
equal amount of time to express their ideas.

Document Analysis

This technique is used to gather business information by reviewing/examining the available

materials that describe the business environment. This analysis is helpful to validate the
implementation of current solutions and is also helpful in understanding the business need.
Document analysis includes reviewing the business plans, technical documents, problem reports,
existing requirement documents, etc. This technique is useful for migration projects.
This technique is important in identifying the gaps in the system i.e., to compare the AS-IS process
with the TO-BE process.

Reverse engineering

This elicitation technique is generally used in migration projects. If an existing system has outdated
documentation, it can be reverse engineered to understand what the system does. This is an
elicitation technique that can extract implemented requirements from the system.
There are two types of reverse engineering techniques.
Black box reverse engineering: The system is studied without examining its internal structure
(function and composition of software).
White box reverse engineering: The inner workings of the system are studied (analysing and
understanding of software code).
Focus Group

By using a focus group, you can get information about a product, service from a group. The Focus
group includes subject matter experts. The objective of this group is to discuss the topic and provide
information. A moderator manages this session.
The moderator should work with business analysts to analyse the results and provide findings to the
stakeholders.

Observation

The main objective of the observation session is to understand the activity, task, tools used, and
events performed by others. The plan for observation ensures that all stakeholders are aware of the
purpose of the observation session, they agree on the expected outcomes, and that the session
meets their expectations. You need to inform the participants that their performance is not judged.
During the session, the observer should record all the activities and the time taken to perform the
work by others so that he/she can simulate the same. After the session, the BA will review the
results and will follow up with the participants. Observation can be either active or passive.

Workshop

Workshops comprise a group of users or stakeholders working together to identify requirements. A

requirement workshop is a structured way to capture requirements. Workshops are used to scope,
discover, define, and prioritize requirements for the proposed system.
They are the most effective way to deliver high-quality requirements quickly. They promote mutual
understanding and strong communication between users or stakeholders and the project team.

JAD (Joint Application Development)

Joint Application Development (JAD) technique is an extended session to the workshop. In the JAD
session stakeholders and project team works together to identify the requirements. These sessions
allow the business team to gather and consolidate large amounts of information. Identification of
stakeholders is the critical to the overall success of the JAD session. The JAD team includes business
process owners, client representatives or stakeholders, business analysts, project managers, IT
experts (developers, quality assurance, designers, and security).

Interview

This is the most common technique used for requirement elicitation. Interview techniques should be
used for building strong relationships between business analysts and stakeholders. In this technique,
the interviewer directs the question to stakeholders to obtain information. One to one interview is
the most commonly used technique.
If the interviewer has a predefined set of questions, then it’s called a structured interview.
If the interviewer is not having any particular format or any specific questions then it’s called an
unstructured interview.
For an effective interview, you can consider the 5W1H technique. When you get an answer to all
your Whys then you are done with your interview process. Open-ended questions are used to
provide detailed information. In this interviewee cannot say Yes or No only.
Prototyping

Screen mock-ups can support the requirement gathering process, when introduced at the correct
time. Mock-ups help stakeholders visualize the functionality of a system. This can be an advantage to
business analysts and stakeholders since this allows them to identify gaps/problems early on.

Questionnaire

For Survey/Questionnaire, a set of questions is given to stakeholders to quantify their thoughts.

After collecting the responses from stakeholders, data is analysed to identify the area of interest of
stakeholders.
Questions should be based on high priority risks. Questions should be direct and unambiguous. Once
the survey is ready, notify the participants and remind them to participate.

Question 26 – This project Elicitation Techniques

Prototyping

Prototyping can be used as an elicitation technique in requirements gathering to help stakeholders

and designers better understand and communicate their ideas about the desired product or system.
By creating a prototype, designers can create a tangible representation of the product that
stakeholders can interact with and provide feedback on.
During the prototyping process, designers can work collaboratively with stakeholders to explore
different design options, experiment with different features and functionalities, and test various
scenarios. This can help to uncover potential issues or challenges early in the design process and
identify areas where further refinement is needed.
Prototyping as an elicitation technique can be particularly useful in complex projects, where it may
be difficult to fully capture and communicate the requirements using traditional elicitation
techniques such as interviews or surveys. By creating a prototype, stakeholders can interact with the
product in a more tangible way, providing more detailed and actionable feedback that can inform
the design process.

Use case specifications

Use case specifications can be used as an elicitation technique in requirements gathering to help
stakeholders and designers better understand and communicate the intended usage of the product
or system. A use case is a description of a specific interaction between a user and the product or
system that achieves a specific goal or objective.
By defining use cases, designers can better understand the different ways in which users will interact
with the product or system and identify the specific requirements needed to support those
interactions. Use cases can also help to identify potential edge cases or scenarios that may not be
immediately obvious.
Use case specifications typically include a narrative description of the interaction, as well as a set of
steps or actions that the user will take to achieve the desired outcome. They may also include
information about the different roles or actors involved in the interaction, as well as any external
systems or processes that may be required.
One of the main benefits of using use case specifications as an elicitation technique is that they
provide a structured way to capture and organize requirements in a way that is easy to understand
and communicate to stakeholders. Use cases can also help to ensure that all stakeholders are on the
same page and working towards a shared vision.

Document Analysis

This technique is used to gather business information by reviewing/examining the available

materials that describe the business environment. This analysis is helpful to validate the
implementation of current solutions and is also helpful in understanding the business need.
Document analysis includes reviewing the business plans, technical documents, problem reports,
existing requirement documents, etc. This technique is useful for migration projects.
This technique is important in identifying the gaps in the system i.e., to compare the AS-IS process
with the TO-BE process.

Brainstorming

 Quantity over quality. The idea is that quantity will eventually breed quality as ideas are
refined, merged, and developed further.
 Withhold criticism. Team members should be free to introduce any and all ideas that come
into their heads. Save feedback until after the idea collection phase so that “blocking” does
not occur.
 Welcome the crazy ideas. Encouraging your team members to think outside of the box, and
introduce pie in the sky ideas opens the door to new and innovative techniques that may be
your ticket for success.
 Combine, refine, and improve ideas. Build on ideas, and draw connections between
different suggestions to further the problem-solving process.

Here why brainstorming is :

1. Brainstorming allows people to think more freely, without fear of judgment.
2. Brainstorming encourages open and ongoing collaboration to solve problems and generate
innovative ideas.
3. Brainstorming helps teams generate a large number of ideas quickly, which can be refined
and merged to create the ideal solution.
4. Brainstorming allows teams to reach conclusions by consensus, leading to a more well-
rounded and better-informed path forward.
5. Brainstorming helps team members feel more comfortable bouncing ideas off one another,
even outside of a structured session.
6. Brainstorming introduces different perspectives, and opens the door to out-of-the-box
innovations.
7. Brainstorming helps team members get ideas out of their heads and into the world, where
they can be expanded upon, refined, and put into action.
 8. Brainstorming is great for team building. No one person has ownership over the results,
enabling an absolute team effort.

Question 27 – 10 Business Requirements

BR001 – Farmers should be able to search for available products in fertilizers, seeds, pesticides.
BR002 – Manufacturers should be able to upload and display their products in the application.
BR003 – Expecting to have a login for all its users (fertilizers, seeds, pesticides manufacturers and
Farmers).
BR004 – If a farmer wants to buy any product or add them to buy-later list.
BR005 – If it is a new user, then they can create a new account by submitting their email ID and
creating a secure password.
BR006 – A Farmer should be able to browse through the products catalogue once they visit the
website.
BR007 – An easy-to-use payment gateway which should include cash-on-delivery (COD).
BR008 – An easy-to-use payment gateway which should include Credit/Debit card.
BR009 – An easy-to-use payment gateway which should include UPI options.
BR010 – A user gets an email confirmation regarding their order status.
BR011 – A delivery tracker to track the whereabouts of their order.
Question 28 –Assumptions

 User-friendly interface
 Mobile-friendly adaptation
 Website search and filtering functionality
 Registration and related issues
 Payment options
 Shipping rates
 content management
 Mobile functionality
 Proper product showcase and descriptions
 Customer support
 Payment options

Question 29 – This project Requirements Priority

Req ID Req Name Req Description Priority

BR001 Farmer Search for Farmers should be able to search for available 8
Products products in fertilizers, seeds, pesticides
BR002 Manufacturers upload Manufacturers should be able to upload and display 8
their Products their products in the application
BR003 Expecting Login Expecting to have a login for all its users (fertilizers, 9
seeds, pesticides manufacturers and Farmers)
BR004 Add product to buy If a farmer wants to buy any product or add them to 8
later list buy-later list.
BR005 Create new account and If it is a new user, then they can create a new account 9
a secure password by submitting their email ID and creating a secure
password
BR006 Browse through A Farmer should be able to browse through the 9
products products catalogue once they visit the Application
BR007 Payment through COD An easy-to-use payment gateway which should 9
include cash-on-delivery (COD)
BR008 Payment through An easy-to-use payment gateway which should 9
credit/debit card include Credit/Debit card
BR009 Payment through UPI An easy-to-use payment gateway which should 9
include UPI options
BR010 Order Email A user gets an email confirmation regarding their 8
confirmation order status
BR011 Delivery tracker A delivery tracker to track the whereabouts of their 8
order
Question 30 – Use Case Diagram
 Question 31 – (minimum 5) Use Case Specs

Registration

Use Case Registration

Actor User

The use case begins when the actor indicates the intent to register to the
Description
system. It ends when the actor is a register or cancels registration.

Pre-Condition The login exists

Post-Condition The actor registers successfully

Administration/User Login

Use Case Login

Actor Administrator/User

The use case begins when the actor indicates the intent to login to the system.
Description
It ends when the actor is log in or cancels login.

Pre-Condition The login exists

Post-Condition The actor logs in successfully

Manage cart

Use Case Manage cart

Actor User

The use case begins when the actor indicates the intent to add items into
Description
the cart. It ends when the actor enters the next

1. The Category record exists for editing/view.

Pre-Condition
2. The actor is logged in.

Post-Condition The Cart record is added or updated.

View Products
Use Case View Products

Actor User

The use case begins when the actor indicates to view the products. It
Description
ends when the actor is close to the application

Pre-Condition The login exists

Post-Condition The actor view product successfully

Use Case Place Order

Actor User

The use case begins when the actor indicates the intent to confirm the
Description
purchase of his selected items

1. The product record exists for editing/view.

Pre-Condition
2. The actor is logged in.

Post-Condition The Cart record is added or updated.

Place Order

View Order Detail

Use Case View Order Detail

Actor Admin/User

The use case begins when the actor indicates the intent to view
Description orders detail of customers and the use case begins when the actor
indicates the intent to view orders detail of itself.

1-The order record exists for editing/view.

Pre-Condition
2-The actor is logged in.

Post-Condition The actor dispatch or cancel the customer record.

Question 32 – (minimum 5) Activity Diagrams

 Activity Diagram for online browsing the
product while purchasing

Activity Diagram for online login

authentication and Admin Side
 Activity Diagram for about user product
details, ordering products, view products.

Activity Diagram for about managing

user orders, manage new product
details, accepting money payment.
Activity Diagram for User side
Question 33 – Functional Requirements

Req ID Req Name Req Description Priority

FR0001 Farmer Farmers should be able to register with the 8
Registration application
FR0002 Farmer Search for Farmers should be able to search for available 8
Products products in fertilizers, seeds, pesticides.
FR0003 The information of Include the information of the products, item no, 8
the products size, categories
FR0004 The information of Vendor or seller where they can put the 9
the products information of the products in websites.
FR0005 Manufacturer Vendors, manufacturers should be able to 8
vendor Registration register with the application
FR0006 Logins to the Logins to the system by entering valid user id and 8
system password for the shopping.
FR0007 Payment by Cash The mode of payment by Cash. 9
FR0008 Payment by Credit The mode of payment by credit or debit cards. 9
or debit card
FR0009 Payment by UPI The mode of payment by UPI. 9
FR0010 Showing the price Showing the price of the products and applicable 8
or discount discount of the products.
FR0011 Payment process is Payment process is secure and password 8
secure protected.
FR0012 Three steps of Three steps involved in the online transaction are 9
transaction Registration, Placing an order, and, Payment.
FR0013 Maintains the The system that maintains the detail of the 8
detail of the products and their hierarchy attributes (size,
products weight, cost etc).
FR0014 Send one copy of The system will send one copy of the bill to the 8
the bill to the customer’s Email-address or contact number.
farmer
FR0015 Send one copy of The system will send one copy of the bill to the 8
the bill to the system data base.
manufacturer or
vendor
FR0016 Quantity of Produce the quantity of the products available 8
product and status and status of the products.
FR0017 Listing of the List of the products that can be buy by the 9
products for farmer. Who can buy?
farmers
FR0018 Listing of the Vendor, manufacturer list their products can be 8
products for put to website, who can put to sell?
manufacturer or
vendor
FR0019 List of the products List of the products that can be delivered to the 8
that can be farmer.
delivered
FR0020 Shopping cart Registered user can go to the shopping cart and 8
put product to cart.
FR0021 Order cancellation Changes to cart means the customer after login 9
 and changes to it or registration can make order or cancel order of
the product from the shopping cart.
FR0022 Logout option for After ordering or surfing for the product farmers 8
farmers can log out if they want.
FR0023 Logout option for Manufacturer or vendors can also log put from 8
manufacturer or the system wherever they want to.
vendor

Non-Functional Requirements

Req ID Req Name Req Description Priority

NFR0101 Page Loading Time Each Page should load within 2 seconds time 9
NFR0102 WCAG 2.1. The system must meet Web Content Accessibility 8
Guidelines WCAG 2.1.
NFR0103 System growth The system should be able to quickly absorb 8
traffic growth in traffic and product numbers without
compromising performance.
NFR0104 System range The system should work with a wide range of 8
devices and web browsers.
NFR0105 System availability The system should be dependable and available 8
to clients on a constant basis.
NFR0106 System interface The system should be simple to upgrade and 9
maintain over time.
NFR0107 Design at If the website is designed for a worldwide 8
worldwide stage audience, it should accommodate many
languages and currencies
NFR0108 Unauthorised The system should prevent unauthorised access 8
access control or interference with sensitive consumer
information and transactions.
NFR0109 User friendly The system should be simple to use and navigate 9
interface for customers, with a user-friendly interface and
clear instructions.
NFR0110 System face design As a farmer login into the system, I should see a) 9
a personalized banner b) recommended products
c) recently viewed products d) new products on
the site.
NFR0111 Shipping and The product package shipping and delivery 7
delivery receipt receipt should be given to the farmers as hard
copy on paper either on 2”x 4” white paper.

Question 34–Minimum 5-page designs

Question 35 – Tools (Visio, Balsamiq)

Microsoft Visio

Microsoft Visio can be used to create simple or complicated diagrams. It offers a wide variety of
built-in shapes, objects, and stencils to work with. You can also make your own shapes and import
them if you’re willing to do all that extra work. The driving idea behind Visio is to make diagramming
as easy as possible for the user. I think Visio is on the right track for that.
Another thing Visio can do is pull in live information from an external source, such as an Excel sheet
or Access database. This makes diagrams functional and current. The most recent example I’ve seen
involved using Visio to monitor network status across a localized broadband system.

Balsamiq

Wireframing or prototype is required in order to save on time invested in understanding a software

requirement. As they say, a picture is worth more than a thousand words, Wireframing provides a
glimpse at the requirement of any feature/page by effectively visualizing the screen layout and
elements. In the end, it also helps the development teams to be oriented towards the common end
goal.
Balsamiq serves as an excellent tool, fulfilling all the requirements of Wireframing, collaboration and
creativity. Its unique set of features enables the team member to do rapid Wireframing, get a
consensus on the feature to be developed. This will eventually have the team aligned with
functionality in terms of the layouts.

Question 36 – RTM

Req ID Req Name Req Description Des D1 T D2 T D3 T D4 T UAT

ign 1 2 3 4
FR0001 Farmer Farmers should NA NA NA NA NA NA NA

Registration be able to
register with the
application
FR0002 Farmer Farmers should NA NA NA NA NA NA

Search for be able to search

Products for available
products in
fertilizers, seeds,
pesticides.
FR0003 The Include the NA NA NA NA NA NA NA

information information of
of the the products,
products item no, size,
categories
FR0004 The Vendor or seller NA NA NA NA NA NA

information where they can

of the put the
products information of
 the products in
websites.
FR0005 Manufactur Vendors, NA NA NA NA NA NA

er vendor manufacturers
Registration should be able to
register with the
application
FR0006 Logins to Logins to the NA NA NA NA NA NA NA

the system system by

entering valid
user id and
password for the
shopping.
FR0007 Payment by The mode of NA NA NA NA NA NA

Cash payment by
Cash.
FR0008 Payment by The mode of NA NA NA NA NA NA NA

Credit or payment by
debit card credit or debit
cards.
FR0009 Payment by The mode of NA NA NA NA NA NA NA

UPI payment by UPI.

FR0010 Showing the Showing the NA NA NA NA NA NA NA

price or price of the

discount products and
applicable
discount of the
products.
FR0011 Payment Payment process NA NA NA NA NA NA NA

process is is secure and

secure password
protected.
FR0012 Three steps Three steps NA NA NA NA NA NA

of involved in the
transaction online
transaction are
Registration,
Placing an order,
and, Payment.
FR0013 Maintains The system that NA NA NA NA NA NA NA

the detail of maintains the

the detail of the
products products and
their hierarchy
attributes (size,
weight, cost etc).
FR0014 Send one The system will NA NA NA NA NA NA

copy of the send one copy of

bill to the the bill to the
farmer customer’s
Email-address or
 contact number.
FR0015 Send one The system will NA NA NA NA NA NA

copy of the send one copy of

bill to the the bill to the
manufactur system data
er or vendor base.
FR0016 Quantity of Produce the NA NA NA NA NA NA NA

product and quantity of the

status products
available and
status of the
products.
FR0017 Listing of List of the NA NA NA NA NA NA

the products that

products for can be buy by
farmers the farmer. Who
can buy?
FR0018 Listing of Vendor, NA NA NA NA NA NA

the manufacturer list

products for their products
manufactur can be put to
er or vendor website, who
can put to sell?
FR0019 List of the List of the NA NA NA NA NA NA NA

products products that

that can be can be delivered
delivered to the farmer.
FR0020 Shopping Registered user NA NA NA NA NA NA NA NA

cart can go to the

shopping cart
and put product
to cart.
FR0021 Order Changes to cart NA NA NA NA NA NA NA

cancellation means the

and changes customer after
to it login or
registration can
make order or
cancel order of
the product from
the shopping
cart.
FR0022 Logout After ordering or NA NA NA NA NA NA NA

option for surfing for the

farmers product farmers
can log out if
they want.
FR0023 Logout Manufacturer or NA NA NA NA NA NA

option for vendors can also

manufactur log put from the
er or vendor system wherever
 they want to.
NFR0101 Page Each Page NA NA NA NA NA NA

Loading should load

Time within 2 seconds
time
NFR0102 WCAG 2.1. The system must NA NA NA NA NA NA NA

meet Web
Content
Accessibility
Guidelines
WCAG 2.1.
NFR0103 System The system NA NA NA NA NA NA

growth should be able to

traffic quickly absorb
growth in traffic
and product
numbers without
compromising
performance.
NFR0104 System The system NA NA NA NA NA NA NA NA

range should work with

a wide range of
devices and web
browsers.
NFR0105 System The system NA NA NA NA NA NA

availability should be
dependable and
available to
clients on a
constant basis.
NFR0106 System The system NA NA NA NA NA NA

interface should be simple

to upgrade and
maintain over
time.
NFR0107 Design at If the website is NA NA NA NA NA NA NA

worldwide designed for a

stage worldwide
audience, it
should
accommodate
many languages
and currencies
NFR0108 Unauthorise The system NA NA NA NA NA NA NA

d access should prevent

control unauthorised
access or
interference
with sensitive
consumer
information and
 transactions.
NFR0109 User The system NA NA NA NA NA NA NA

friendly should be simple

interface to use and
navigate for
customers, with
a user-friendly
interface and
clear
instructions.
NFR0110 System face As a farmer login NA NA NA NA NA NA

design into the system, I

should see a) a
personalized
banner b)
recommended
products c)
recently viewed
products d) new
products on the
site.
NFR0111 Shipping The product NA NA NA NA NA NA

and delivery package shipping

receipt and delivery
receipt should
be given to the
farmers as hard
copy on paper
either on 2”x 4”
white paper.

Question 37 – 10 Test Case Documents

Test Case ID OAPS001 Test Case Name Farmer Search for Products
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS001 Tester ID
Test Plan ID OAPSTP001 Tester Name
Test Schedule ID OAPSTS001 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
Farmers should be able to search for available products in fertilizers, seeds, pesticides

Set1 Set 2 Set3 Set 4 Set 5

1.A farmer accesses the search function in
the system
Input Data 2.The farmer enters a keyword for the
product they are looking for, such as
"tomato seeds"
1.The system displays a list of available
products matching the keyword "tomato
seeds", including their names, brands,
prices, and quantities available.
2.The system allows the farmer to filter the
Expected results by criteria such as price range, brand,
Behaviour quantity, and availability.
3.The system allows the farmer to select a
product to view more information, such as
product description and reviews.
4.The system allows the farmer to add the
desired product to their cart or Wishlist.
1.If the system functions as expected, it
should display a list of products matching
the keyword entered by the farmer, allow
filtering by various criteria, and provide
options to view more information or add
products to the cart or wishlist.
Actual 2.If the system does not have the
Behaviour functionality to search for available products
in fertilizers, seeds, and pesticides, or if it
does not display a list of products, allow
filtering, or provide options to view more
information or add products to the cart or
Wishlist, then it is not meeting the expected
behaviour.
Comments

Result
Pass
Pass/Fail
Test Case ID OAPS002 Test Case Name Manufacturers upload their
Products
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS002 Tester ID
Test Plan ID OAPSTP002 Tester Name
Test Schedule ID OAPSTS002 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
Expecting to have a login for all its users (fertilizers, seeds, pesticides manufacturers and Farmers)

Set1 Set 2 Set3 Set 4 Set 5

1.A user attempts to access the
Input Data
system without logging in.
1.The system should display a login
page or prompt the user to log in.
2.The login page should include
fields for the user to enter their
username or email and password.
Expected 3.The system should validate the
Behaviour user's credentials before allowing
access to the system.
4.The system should provide options
for the user to reset their password
if they forget it or to create a new
account if they are a new user.
1.If the system functions as
expected, it should display a login
page and prompt the user to enter
their credentials, validate them, and
provide access to the system.
2.If the system does not have a login
page, or if it does not validate the
Actual
user's credentials, then it is not
Behaviour
meeting the expected behaviour.
3.If the system allows the user to
access any part of the system
without logging in, or if it allows a
user to access another user's
account, then it is not meeting the
expected behaviour.
Comments

Result
Pass
Pass/Fail

Test Case ID OAPS003 Test Case Name Expecting Login

Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS003 Tester ID
Test Plan ID OAPSTP003 Tester Name
Test Schedule ID OAPSTS003 Date of Test

Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
Manufacturers should be able to upload and display their products in the application.

Set1 Set 2 Set3 Set 4 Set 5

1.A manufacturer attempts to upload a product to
the system.
Input Data 2.The manufacturer provides product information
such as name, description, image, price, and
quantity available.
1.The system should allow the manufacturer to
upload a product, including the product
information and image.
2.The system should display the product in the
Expected
application, including the product name,
Behaviour
description, image, price, and quantity available.
3.The system should provide options for the
manufacturer to edit or remove the product if
necessary.
1.If the system functions as expected, it should
allow the manufacturer to upload a product and
display the product in the application with the
Actual correct information and image.
Behaviour 2.If the system does not allow the manufacturer to
upload a product or if it does not display the
product in the application correctly, then it is not
meeting the expected behaviour.
Comments

Result
Pass
Pass/Fail

Test Case ID OAPS004 Test Case Name Add product to buy later list
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS004 Tester ID
Test Plan ID OAPSTP004 Tester Name
Test Schedule ID OAPSTS004 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
If a farmer wants to buy any product or add them to buy-later list.

Set1 Set 2 Set3 Set 4 Set 5

1.A farmer searches for a product they want to buy
or add to their buy-later list.
2.The farmer selects a product they want to buy or
Input Data
add to their buy-later list.
3.The farmer adds the product to their cart or buy-
later list.
1.The system should allow the farmer to add a
product to their cart or buy-later list.
2.If the farmer adds a product to their cart, the
system should display the product in the cart with
the correct information, such as product name,
quantity, price, and total cost.
3.The system should allow the farmer to modify the
Expected product quantity or remove the product from the
Behaviour cart.
4.If the farmer adds a product to their buy-later list,
the system should display the product in the list
with the correct information, such as product name,
brand, price, and availability.
5.The system should allow the farmer to remove the
product from their buy-later list if they change their
mind.
1.If the system functions as expected, it should
allow the farmer to add a product to their cart or
buy-later list and display the product with the
Actual correct information.
Behaviour 2.If the system does not allow the farmer to add a
product to their cart or buy-later list, or if it does not
display the product correctly, then it is not meeting
the expected behaviour.
Comments

Result
Pass
Pass/Fail
Test Case ID OAPS005 Test Case Name Create new account and a secure
password
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS005 Tester ID
Test Plan ID OAPSTP005 Tester Name
Test Schedule ID OAPSTS005 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
If it is a new user, then they can create a new account by submitting their email ID and creating a secure
password
Set1 Set 2 Set3 Set 4 Set 5
1.A new user visits the application for the first time.
2.The new user clicks on the "Sign Up" button.
Input Data
3.The new user provides their email ID and creates a
secure password.
1.The system should allow the new user to enter their
email ID and create a secure password.
2.The system should validate the email ID and
password to ensure they meet the required format and
security standards.
Expected 3.If the email ID and password meet the required
Behaviour standards, the system should create a new account for
the user and redirect them to the application
dashboard.
4.If the email ID and password do not meet the
required standards, the system should display an error
message indicating what requirements were not met.
1.If the system functions as expected, it should allow
the new user to create a new account and redirect
them to the application dashboard.
Actual
2.If the system does not allow the new user to create a
Behaviour
new account or if it does not validate the email ID and
password correctly, then it is not meeting the expected
behaviour.
Comments

Result
Pass
Pass/Fail
Test Case ID OAPS006 Test Case Name Browse through products
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS006 Tester ID
Test Plan ID OAPSTP006 Tester Name
Test Schedule ID OAPSTS006 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
A Farmer should be able to browse through the products catalogue once they visit the Application.

Set1 Set 2 Set3 Set 4 Set 5

1.A farmer visits the application for the first time.
Input Data
2.The farmer clicks on the "Browse Products" button.
1.The system should display the products catalogue to
the farmer.
2.The products catalogue should include all available
products in the system.
3.The products catalogue should display each
Expected product's name, description, brand, price, and
Behaviour availability.
4.The products catalogue should allow the farmer to
filter and sort products based on their preferences,
such as price, brand, or category.
5.The products catalogue should allow the farmer to
search for specific products using keywords.
1.If the system functions as expected, it should
display the products catalogue to the farmer and
allow them to browse through the available products.
2.If the system does not display the products
catalogue or if it does not include all available
Actual products, then it is not meeting the expected
Behaviour behaviour.
3.If the system does not display each product's name,
description, brand, price, and availability correctly, or
if it does not allow the farmer to filter, sort, or search
for products, then it is not meeting the expected
behaviour.
Comments

Result
Pass
Pass/Fail
Test Case ID OAPS007 Test Case Name Payment through COD
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS007 Tester ID
Test Plan ID OAPSTP007 Tester Name
Test Schedule ID OAPSTS007 Date of Test
Set1 Set 2 Set3 Set 4 Set 5
1.A customer has added items to their cart and
wishes to complete their purchase.
Input Data
2.The customer clicks on the "Proceed to Checkout"
button.
1.The system should display a list of payment options
to the customer.
2.The payment options should include cash-on-
delivery (COD) as one of the options.
3.The payment gateway should be easy-to-use and
user-friendly.
Expected
4.If the customer chooses COD as the payment
Behaviour
option, the system should display a confirmation
message and allow the customer to confirm their
purchase.
5.If the customer chooses any other payment option,
the system should redirect them to the payment
gateway for that option.
1.If the system functions as expected, it should
display a list of payment options to the customer and
Actual allow them to choose COD if they prefer.
Behaviour 2.If the system does not include COD as a payment
option or if the payment gateway is difficult to use,
then it is not meeting the expected behaviour.
Comments

Result
Pass
Pass/Fail
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
An easy-to-use payment gateway which should include cash-on-delivery (COD)
Test Case ID OAPS008 Test Case Name Payment through credit/debit
card
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS008 Tester ID
Test Plan ID OAPSTP008 Tester Name
Test Schedule ID OAPSTS008 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
An easy-to-use payment gateway which should include Credit/Debit card

Set1 Set 2 Set3 Set 4 Set 5

1.A customer has added items to their cart and wishes to
Input Data complete their purchase.
2.The customer clicks on the "Proceed to Checkout" button.
1.The system should display a list of payment options to the
customer.
2.The payment options should include Credit/Debit card as one
of the options.
3.The payment gateway should be easy-to-use and user-
friendly.
4.If the customer chooses Credit/Debit card as the payment
option, the system should redirect them to a secure payment
Expected gateway to enter their payment details.
Behaviour 5.The payment gateway should accept all major credit and
debit cards and provide an option for the customer to save
their payment information for future purchases.
6.If the payment is successful, the system should display a
confirmation message and allow the customer to confirm their
purchase.
7.If the payment fails, the system should display an error
message and allow the customer to try again or choose a
different payment option.
1.If the system functions as expected, it should display a list of
payment options to the customer and allow them to choose
Credit/Debit card if they prefer.
Actual 2.If the system redirects the customer to a secure payment
Behaviour gateway and accepts all major credit and debit cards, then it is
meeting the expected behaviour.
3.If the payment gateway is easy-to-use and user-friendly, then
it is meeting the expected behaviour.
Comments

Result
Pass
Pass/Fail
Test Case ID OAPS009 Test Case Name Payment through UPI
Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS009 Tester ID
Test Plan ID OAPSTP009 Tester Name
Test Schedule ID OAPSTS009 Date of Test

Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
An easy-to-use payment gateway which should include UPI options.

Set1 Set 2 Set3 Set 4 Set 5

1.A customer has added items to their cart and wishes to
Input Data complete their purchase.
2.The customer clicks on the "Proceed to Checkout" button.
1.The system should display a list of payment options to the
customer.
2.The payment options should include UPI (Unified Payment
Interface) options as one of the options.
3.The payment gateway should be easy-to-use and user-
friendly.
4.If the customer chooses UPI as the payment option, the
system should redirect them to a secure payment gateway to
Expected enter their UPI ID and other necessary details.
Behaviour 5.The payment gateway should accept all UPI options
supported by the bank and provide an option for the customer
to save their UPI ID for future purchases.
6.If the payment is successful, the system should display a
confirmation message and allow the customer to confirm their
purchase.
7.If the payment fails, the system should display an error
message and allow the customer to try again or choose a
different payment option.
1.If the system functions as expected, it should display a list of
payment options to the customer and allow them to choose
UPI if they prefer.
Actual 2.If the system redirects the customer to a secure payment
Behaviour gateway and accepts all UPI options supported by the bank,
then it is meeting the expected behaviour.
3.If the payment gateway is easy-to-use and user-friendly, then
it is meeting the expected behaviour.
Comments

Result
Pass
Pass/Fail

Test Case ID OAPS010 Test Case Name Order Email confirmation

Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS010 Tester ID
Test Plan ID OAPSTP010 Tester Name
Test Schedule ID OAPSTS010 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
A user gets an email confirmation regarding their order status.

Set1 Set 2 Set3 Set 4 Set 5

1.A user places an order for one or more products in the
Input Data system.
2.The system receives the order and processes it.
1.The system should send an email confirmation to the
user's registered email address.
2.The email should include the details of the order such as
the order ID, date of purchase, list of items purchased, total
amount, shipping address, and expected delivery date.
Expected 3.The email should also provide information on how the
Behaviour user can track their order and get in touch with customer
support in case of any issues.
4.The email should be sent within a reasonable amount of
time after the order is placed.
5.The email should be well-formatted and easy to read, with
clear and concise information.
1.If the system functions as expected, it should send an
email confirmation to the user's registered email address.
2.If the email includes all the required details such as order
ID, date of purchase, list of items purchased, total amount,
shipping address, and expected delivery date, it is meeting
the expected behaviour.
3.If the email also provides information on how the user can
Actual
track their order and get in touch with customer support, it
Behaviour
is meeting the expected behaviour.
4.If the email is sent within a reasonable amount of time
after the order is placed, it is meeting the expected
behaviour.
5.If the email is well-formatted and easy to read, with clear
and concise information, it is meeting the expected
behaviour.
Comments

Result
Pass
Pass/Fail

Test Case ID OAPS011 Test Case Name Delivery tracker

Project ID OAPS Project Name Online Agriculture product Store
PM ID ### PM Name
Test Strategy ID OAPSTS011 Tester ID
Test Plan ID OAPSTP011 Tester Name
Test Schedule ID OAPSTS011 Date of Test
Scenario: Online Agriculture Product Store: Farmers to purchase farming products online and Manufacturer
supplier can sell through this application and products can delivered to the farmers door step.
A delivery tracker to track the whereabouts of their order.

Set1 Set 2 Set3 Set 4 Set 5

1.A user has placed an order and received a confirmation
email that includes a delivery tracking number.
Input Data
2.The user has access to the delivery tracker feature in the
application.
1.The delivery tracker should display the current status
and location of the user's order in real-time.
2.The delivery tracker should be easy to use and navigate.
The delivery tracker should be accessible to the user from
the application at all times.
Expected 3.The delivery tracker should provide regular updates on
Behaviour the status of the user's order, including expected delivery
date and time, if available.
4.The delivery tracker should be able to provide accurate
information about the whereabouts of the user's order,
and any delays or issues that may arise during the delivery
process.
1.If the delivery tracker displays the current status and
location of the user's order in real-time, it is meeting the
expected behaviour.
2.If the delivery tracker is easy to use and navigate, it is
meeting the expected behaviour.
3.If the delivery tracker is accessible to the user from the
application at all times, it is meeting the expected
Actual behaviour.
Behaviour 4.If the delivery tracker provides regular updates on the
status of the user's order, including expected delivery date
and time, if available, it is meeting the expected
behaviour.
5.If the delivery tracker provides accurate information
about the whereabouts of the user's order, and any delays
or issues that may arise during the delivery process, it is
meeting the expected behaviour.
Comments

Result
Pass
Pass/Fail
Question 38 – DB Design

1. Consider Every Viewpoint During Planning

Don’t start building a database without input from the project sponsor and other stakeholders. Get
consensus on precise expectations, and consider how hard it will be to train users on the search
functions.

2. Choose A Database Type

This is usually as easy as deciding between SQL and NoSQL (though there are more specific types
that may be appropriate for some projects).SQL databases are the standard for structured data,
when data integrity is absolutely important. Emerging technology like machine learning or the
Internet of Things (IoT) find the speed, scalability, and fluid requirements of NoSQL databases a
better fit. Web analytics, social networks and some other types of databases also work much better
within the NoSQL framework.

3. Normalize Your Data

In reality, most companies today function in a hybrid world of SQL and NoSQL databases that work
together in complex arrangements. With such a complicated structure, it’s critical to normalize data
to achieve minimum redundancy.

Eliminate multi-valued attributes and repeated attributes, then start in on the subkeys.

4. Make Structures Transparent

The database belongs to its future users, not its creator, so design with them in mind. Stay away
from shortcuts, abbreviations, or plurals. Use consistent naming conventions. Don’t reinvent the
wheel or make things difficult for those who may need to modify the database at some point, which
will certainly happen.

5. Define Constraints to Maintain Data Integrity

Look into the full range of options to enforce business rules, such as foreign key, check, not null, and
the like. The application will prevent some bad data from getting in, but not all of it.

6. Document Everything

No matter how annoying it may seem, documentation is as essential as primary keys. Take care to
document the design, entity-relationship schemas, and triggers for future users.
7. Plan for Increasing Backup Time in the Build

Before delving too deeply into design, think about what happens during a natural or man-made
disaster. Plan for failover clustering, auto backups, replication and any other procedures necessary
to ensure that the database structure remains intact.

As the saying goes, “Prepare and prevent, don’t repair and repent.”

8. Keep Privacy Primary

The GDPR signals an era of increasing privacy concerns. Encrypt passwords, and don’t assign an
administrator without privacy training and well-documented qualifications. This can be a tricky rule
to follow due to office politics, but as a good security practice the database should be as closed as
possible.

9. Optimize for Speed

Create indexes for queries that will be used regularly. Use a database analyser to determine if an
index or a clustered index is necessary. Consider incorporating tools like Elasticsearch to speed up
searches.

10. Keep the Database on Its Own Server

Put the database on a different server than the web to lower CPU usage. In addition to freeing up
compute resources, it also helps to keep the database out of the reach of unauthorized users.
Database schema
ER Diagram
Question 39 – Data Flow Diagram

A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination. Data flowcharts can range from
simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively
deeper into how the data is handled. They can be used to analyse an existing system or model a new
one. Like all the best diagrams and charts, a DFD can often visually “say” things that would be hard
to explain in words, and they work for both technical and nontechnical audiences, from developer to
CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow
software and systems, they are less applicable nowadays to visualizing interactive, real-time or
database-oriented software or systems.
Question 40 – Change Request

A change request is a proposal to alter a product or system, often brought up by the client or
another team member. During a project, this can happen when a client wants to change or alter the
agreed upon deliverables.

There are a lot of obstacles to overcome when trying to deliver on a project. A change request will
often come up throughout the course of most projects so it is a good idea to have a plan for how to
handle them ahead of time.

Often, change requests are necessary and can offer many benefits. Managing this process in an
effective way can allow for greater internal communication, efficiency, and alignment with overall
business goals. Here are five tips on effectively managing change requests:

Request any supporting materials

You want the person who is making the change to be as specific as possible. Ask that person to put
their request in writing and provide any supporting materials that might be helpful.

Have that person articulate why they are requesting this change and what the anticipated benefit of
their change request is. This will help your team determine whether or not the change request is
worth the effort.

Determine whether the change request is in inside or outside the scope

It is a good idea to consider what the scope of the change request is. If your team chooses to
implement this change, what new requirements will this put on the project? You will want to
consider all aspects of the project that will be impacted by implementing this change request.

If the request is outside of the scope, a lot of problems might end up popping up – going over-
budget, for example. Or having to waste too much time on a project you’d never even agreed on.

Have your team assess the priority of the change request

Before your team implements any changes to the project you should consider any possible risks.
What is the expected benefit of the change being proposed? Is this change request the result of an
actual need to respond to a change in the marketplace or would it simply be nice to have?

You can consider the opinion of the person who proposed the change request, but at the same time,
use common sense. The client might not know what’s in their own best interests.

Have clearly defined guidelines for evaluating the urgency as there may be varying opinions amongst
team members.
Approve or reject the change request

Now that you know how important (or unimportant) the change request is and understand the
impact it will have on the project, the team can either approve or reject the request.

Different organizations will have different ways of going about the approval process. Generally, a
change request that will require minimal additional work can be approved within the team. Whereas
a change request that would require a month’s worth of additional work may require executive
approval.

Decide on a course of action going forward

If the change request is approved then the project deliverables will need to be updated. This can
include plans and schedules, business process documents, and the requirements documents.

Once these updates have been made, the project manager can communicate the new course of
action to everyone who will be impacted. Now you can delegate the necessary tasks to the people in
charge of implementing these new changes.

Question 41 – Change Request Vs an Enhancement

It is a Change request. So As a BA I will try to explain the difference and the process of it

To me,

An enhancement is an improvement to existing functionality. With respect to defects, a fault raised

around the way a function works (e.g., navigation, position of buttons, usability etc) is an
enhancement request.

Change Request (CR) – A formally submitted artifact that is used to track all stakeholder requests
(including new features, enhancement requests, defects, changed requirements, etc.) along with
related status information throughout the project lifecycle. All change history will be maintained
with the Change Request, including all state changes along with dates and reasons for the change.
This information will be available for any repeat reviews and for final closing.
Activity Description Responsibility

Submit CR Any stakeholder on the project can submit a Change Submitter

Request (CR). The Change Request is logged into the
Change Request Tracking System (e.g., Rational
ClearQuest) and is placed into the CCB Review Queue, by
setting the Change Request State to Submitted.

Review CR The function of this activity is to review Submitted Change CCB

Requests. An initial review of the contents of the Change
Request is done in the CCB Review meeting to determine
if it is a valid request. If so, then a determination is made
if the change is in or out of scope for the current
release(s), based on priority, schedule, resources, level-of-
effort, risk, severity and any other relevant criteria as
determined by the group.

Confirm If a Change Request is suspected of being CCB Delegate

Duplicate or a Duplicate or Rejected as an invalid request (e.g.,
Reject operator error, not reproducible, the way it works, etc.), a
delegate of the CCB is assigned to confirm the duplicate or
rejected Change Request and to gather more information
from the submitter, if necessary.

Update CR If more information is needed (More Info) to evaluate a Submitter

Change Request, or if a Change Request is rejected at any
point in the process (e.g., confirmed as
a Duplicate, Rejected, etc.), the submitter is notified and
may update the Change Request with new information.
The updated Change Request is then re-submitted to the
CCB Review Queue for consideration of the new data.

Assign & Once a Change Request is Opened, the Project Manager Project Manager
Schedule will then assign the work to the appropriate team
Work member – depending on the type of request (e.g.,
enhancement request, defect, documentation change,
test defect, etc.) – and make any needed updates to the
project schedule.

Make The assigned team member performs the set of activities Assigned Team
Changes defined within the appropriate section of the process Member
(e.g., requirements, analysis & design, implementation,
produce user-support materials, design test, etc.) to make
the changes requested. These activities will include all
normal review and unit test activities as described within
the normal development process. The Change Request
 will then be marked as Resolved.

Verify After the changes are Resolved by the assigned team Tester
Changes in member (analyst, developer, tester, tech writer, etc.), the
Test Build changes are placed into a test queue to be assigned to a
tester and Verified in a test build of the product.

Verify Once the resolved changes have been Verified in a test CCB Delegate (System
Changes in build of the product, the Change Request is placed into a Integrator)
Release Build release queue to be verified against a release build of the
product, produce release notes, etc. and Close the Change
Request.

Question 42 – Estimations
 OAPS Project Estimation
Project
Project Name OAPS ID
Project
Project Manager Sponsor
End
Start Date Date
Manhour
Resources Resource Estimated Cost Other Estimated
Project Deliverables Remarks
req. Name Hours (Per Cost Cost
Hour)
Initation / Planning
Task 1
Mr
TasK 2
2 Vandanam 24hrs
Task 3
Mr.Shivam
…......
Requirement Analysis
Task 1
TasK 2 Mr.
1 56hrs
Task 3 Shivam
…......
Design
Task 1 Mr
TasK 2 Vandanam
3 168hrs
Task 3 Ms. Juhi
…...... Mr Shivam
Development
Task 1 Ms. Juhi
TasK 2 Mr Teyson
5 Ms Lucie 1080hrs
Task 3 Mr Tucker
…...... Mr Bravo
Testing / QA
Task 1
Mr Jason
TasK 2
3 Ms Alekya 1440hrs
Task 3
Mr Shivam
…......
Implementation
Task 1
Mr Mike
TasK 2
3 Mr John 720hrs
Task 3
Mr Shivam
…......
Operation & Maintenance
Operation Activities
Maintenance
Activities
Estimated Total Cost

Estimated Total 11 Resources

Resources
Estimated Total Time
(Months/Days/Hours 3488 Hours (5 Months apprx)
)

Question 43 – UAT

UAT (User Acceptance Testing) is the process of evaluating a system or its component(s) with the
intention of accepting it. The acceptance process involves the following steps:

1. Plan: Define the scope, objectives, and the approach for UAT.

2. Requirements gathering: Identify the functional and non-functional requirements of the

system and ensure they are met.

3. Test preparation: Create test cases based on the requirements and allocate them to the
testers.

4. Test execution: Conduct UAT by executing the test cases and verifying that the system meets
the requirements.

5. Defect management: Document and track any defects found during UAT and ensure they are
fixed.

6. Report generation: Prepare a UAT report summarizing the testing results and make
recommendations for acceptance or rejection.

7. Approval: Obtain approval from stakeholders such as the business sponsor, project manager,
and the client.

8. Implementation: Implement the system into production once it is accepted.

9. Approval: Once all defects have been resolved and the solution meets the required
standards, the solution is approved for release.

10. Deployment: The solution is deployed to the production environment.

11. Post-Deployment Review: Conduct a review of the solution after deployment to ensure that
it is functioning as intended and to identify any areas for improvement.

The UAT process is crucial for ensuring that the system meets the expectations of the end-users and
meets the business requirements before it is deployed to the production environment.

Here's how I would suggest as Business Analyst handle this situation:

 1. Contact the client and schedule a UAT (User Acceptance Testing) session to verify if the
product meets the client's requirements and expectations.

2. Provide the client with a clear explanation of the UAT process, including the objectives,
scope, and expected outcome.

3. Prepare the UAT environment, which should be as close as possible to the production
environment, and ensure that all necessary resources are available.

4. Provide the client with detailed instructions on how to perform the tests, and ensure that
the client has access to all relevant documentation and test cases.

5. Monitor the UAT process, and provide support to the client as needed.

6. Document any issues or defects identified during UAT, and work with the development team
to resolve them as quickly as possible.

7. Once the UAT process is successfully completed, and all issues and defects have been
resolved, request the client's approval to proceed with deployment to the production
environment.

To close the project, the following steps should be taken:

1. Confirm that all project deliverables have been completed and accepted by the client.

2. Document the final results of the project, including any lessons learned, and use this
information to improve future projects.

3. Obtain formal acceptance from the client and stakeholders, indicating that the project has
been completed successfully.

4. Release any resources that have been allocated to the project, such as team members,
equipment, or software licenses.

5. Archive project documentation and other relevant materials in a secure location for future
reference.

6. Deliver final documentation: Deliver the final project documentation to the client, including
the UAT test cases, test results, and any other relevant documents.

7. Celebrate the successful completion of the project and recognize the contributions of all
team members.
Question 44 – Project Closure Document

A project closure document is a formal document that outlines the completion of a project. It
summarizes the key results and achievements of the project, provides a final assessment of the
project's performance, and outlines any lessons learned for future reference. The purpose of the
project closure document is to formally close the project, transfer ownership of the deliverables to
the client, and ensure that all stakeholders are aware of the project's status.

The following is a general outline of the content that can be included in a project closure document:

1. Executive summary: A brief overview of the project, including the project's objectives, scope,
and key results.

2. Project performance: An assessment of the project's performance against its objectives and
KPIs (Key Performance Indicators).

3. Deliverables: A list of all the deliverables produced during the project, along with a
description of their quality and functionality.

4. Acceptance: Confirmation of acceptance by the client of the deliverables and the project as a
whole.

5. Closeout: Details of how the project was closed, including any remaining actions required to
complete the project.

6. Lessons learned: A summary of lessons learned during the project, including both successes
and failures, and recommendations for future projects.

7. Final reports: Any final reports produced during the project, such as a project plan, risk
assessment, and status reports.

8. Next steps: Recommendations for future actions, including any follow-up projects or further
improvements.

The project closure document serves as a record of the project's completion and provides valuable
information for future reference and continuous improvement.