Software Project Documents
Explained and categorized
Abstract
Business Analyst aspirants and professional alike require clarity on various Project Documents
which are produced during various phases of a software project. Though Project Documentation
is an important activity for a Business Analyst, not all project documents are prepared by
Business Analysts.
Vijay Shekhar Shukla
director@qbi.in, https://wa.me/9810055734
PRE- PROJECT OR PROJECT AWARD PHASE DOCUMENTS 4
Business Case Document 4
Feasibility Study Document 5
Business Requirement Document 5
Project Charter 5
Request for Proposal Document 6
Proposal Document or Response to RFP / RFQ Document 6
Contract Document 6
PROJECT START 7
Scope of Work Document 7
Functional Specification Document 7
Software Requirements Specification Document 8
High Level Design Document 8
Risk Management Plan 8
Product Backlog 8
Test Plan and Test Case Documents 9
Wireframes 9
Process Models 9
PROJECT MIDDLE 9
Low Level Design 9
Change Requests 10
Acceptance Criteria 10
Sprint Backlog 10
Release Notes 10
PROJECT END 10
User Acceptance Testing Report 10
Training Manual 11
User Manual 11
Implementation Manual 11
PROJECT CLOSURE 11
Lessons Learned Document 11
Client Appreciation Letters 12
Project Closure Report 12
Prepared By Vijay Shekhar Shukla
Reviewed By
Finalized By
Version No
Dated
Prominent Documents for Software
Projects
Pre-Project or Project Start Project Middle Project End Project Closure
Project Award
Phase
Business Case Detailed Scope of Low Level Design User Acceptance Lessons Learned
Document Work Testing Reports Document
Feasibility Study Risk Management Change Requests Training Manuals Client
Plan Appreciation
Letters
Business Functional Acceptance User Manuals Maintenance
Requirement Requirement Criteria and Support
Document Document Plan
Project Charter Software Release Notes Implementation Project Closure
Requirement Manuals Report
Specification
Document
Vision / Mission High Level Design Sprint Backlog
Document
Request for Product Backlog Product Backlog
Proposal / Request
for Quote
Proposal Test Plans & Test Test Plans & Test
Document or Cases Cases
Response to RFP /
RFQ Document
Contract Process Models,
Document Wireframes
Project Plan
Pre- Project or Project Award Phase Documents
Business Case Document
A Business Case Document is a concise report that outlines the rationale behind a proposed business
initiative. It typically includes an analysis of costs, benefits, risks, and potential returns on investment,
providing decision-makers with the information needed to evaluate the feasibility and strategic
alignment of the proposed project or endeavor.
Generally Prepared By: Executives in the corporate planning department at the client organization.
Next Steps: The project sponsor will provide a ‘Go’, ‘No Go’, for this Business Case
Feasibility Study Document
A Feasibility Study Document for a software development project assesses the viability of the project by
evaluating technical, economic, and operational factors. It includes an analysis of resource requirements,
potential risks, and the project's alignment with organizational goals. For example, a feasibility study for
developing a mobile banking app would assess technical feasibility, market demand, and potential
financial returns.
Generally Prepared By: External Consultants hired by the client organization.
Next Steps: The executives at the client organization may give a go ahead for the project based on the
report submitted by the external consultant. The budget for the project is also approved at this stage.
Business Requirement Document
A Business Requirement Document (BRD) for a software development project outlines the business goals
and objectives to be accomplished by business stakeholders after the solution has been deployed. We
derive functional specifications of the software from the Business Requirements document. For example,
for a training organization the business requirement can be 24 By 7 learning for geographically disbursed
learners who are large in numbers.
Generally Prepared By: Senior executives at the client organization
Next Steps: A Business Requirement Document is referred all through the project. If a Business
Requirement Document has not been prepared by the client, it is during the project start phase that the
Business Analyst should take up this activity. In any case the client should approve the Business
Requirements and there should be a common understanding that these business goals or business
objectives will be addressed once the project is completed. Business Requirements are looked into while
we identify and finalize functional and system requirements of the project.
Project Charter
A Project Charter for a software development project is a formal document that authorizes the project,
defining its scope, objectives, roles, and responsibilities. It outlines project stakeholders, constraints, and
success criteria. For example, a Project Charter for developing customer relationship management (CRM)
software might include project goals, key features, team members, and expected timelines.
Generally Prepared By: Senior executive at the client organization.
Next Steps: If a RFP or Request for Proposal Document has to be prepared An available project charter is
a very handy resource for the IT team. It should align its deliverables with the project charter.
Request for Proposal Document
A Request for Proposal (RFP) in a software development project is a formal document inviting vendors to
submit proposals for providing services or solutions. It outlines project requirements, objectives, and
evaluation criteria. For instance, an RFP for developing a custom e-commerce platform among other
requirements might specify the need for responsive design, secure payment processing, and integration
with third-party APIs.
Generally prepared by: Expert consultants who have expertise in software features / subject matter and
request for proposal document development.
Next Steps: Interested IT vendors will submit response to RFP document which will be evaluated by the
client organization.
Proposal Document or Response to RFP / RFQ Document
A Proposal Document in a software development project is a formal response to a Request for Proposal
(RFP), presenting a vendor's detailed plan, approach, and cost estimates for delivering a solution. It
outlines the vendor's understanding of project requirements, technical expertise, and a comprehensive
strategy for successful project completion. For example, a software development company might submit
a proposal for building a custom e-commerce platform, detailing development methodologies, timelines,
and associated costs.
Generally prepared by: Business Development team of IT vendor.
Next Steps: Response to the RFP document or bid will be evaluated by the client and the contract will be
awarded to the most suitable vendor.
Contract Document
A Contract Document between an IT Vendor and Client in a software development project outlines the
terms, conditions, and obligations governing the project. It specifies project scope, deliverables,
timelines, payment terms, and any legal considerations. For example, a software development contract
might define the development milestones, acceptance criteria, and intellectual property ownership for a
mobile application project.
Generally prepared by: Multiple people on client and IT vendor side. Legal, commercial, technical, and
delivery people are involved.
Next Steps: Next logical step will be project start or project initiation as per the specifics mentioned in
the contract.
Project Plan
The project plan outlines the detailed steps, timelines, resource allocation, and budget for the project's
execution. It provides a roadmap for the project manager and serves as a reference for tracking progress
and adjusting as needed. A high level project plan may be included in the project proposal or in response
to RFP as well.
Generally Prepared By: Project Manager
Next Steps: As the project moves from Project Start to Project Middle to Project End Phases the
development tries to adhere to the agreed upon phase wise deliverables and the deliverables mentioned
in the project plan.
Project Start
Scope of Work Document
A Scope of Work (SOW) Document between an IT Vendor and Client in a software development project
outlines the specific tasks, deliverables, and timelines agreed upon for the project. It details the project's
objectives, features, and functionalities to be developed. For example, in a mobile app development
project, the SOW might specify the creation of user authentication, payment processing, and push
notification features, along with associated deadlines.
Generally prepared by: Business Analyst or Project Manager
Next Steps: As the project will progress the IT team will endeavor to deliver as per Scope of Work
Document within agreed upon timelines. The Scope of Work Document or the SOW document will be
referred by multiple stakeholders to monitor and track project progress.
Functional Requirement Document
Functional Requirement Document is also known as Functional Specification Document. Functional
Requirements are goals which end users will be able to achieve through the application or system being
developed. A Functional Specification Document (FSD) defines the detailed requirements of the system.
It outlines the specific functionalities, user interactions, and system behavior. For instance, in an e-
commerce website development project, the FSD may detail features like product catalog management,
shopping cart functionality, and secure checkout processes with specific technical requirements and
workflow descriptions.
Generally Prepared By: Business Analyst
Next Steps: BRD, FRD and SRS together will be the inputs for the development team to develop the
software application.
Software Requirements Specification Document
A Software Requirements Specification (SRS) document in a software development project details the
system and and non-functional requirements of the software system. It includes features, user
interactions, performance criteria, and constraints. For example, in a customer relationship management
(CRM) software project, the SRS might specify requirements for contact management, lead tracking, and
reporting functionalities, along with data security and scalability considerations.
Generally Prepared By: Business Analyst
High Level Design Document
A High-Level Design (HLD) document in a software project outlines the overall structure and components
of the system without delving into detailed technical specifications. It focuses on architecture, modules,
and their interactions. For example, in an e-commerce website development project, the HLD might
illustrate the system's architecture, outlining components like user interface, database, and payment
processing modules, along with how they interact at a high level.
Generally prepare by: Software Designer / Software Architect
Risk Management Plan
A Risk Management Plan for a project outlines how potential risks will be identified, assessed, and
managed throughout the project lifecycle. It helps in proactively addressing challenges and minimizing
the impact of unexpected events. Typical areas addressed in a Risk Management Plan include
Risk Identification
Risk Assessment
Risk Mitigation
Risk Management
An example of a technical risk can be integration of 3rd party systems in our software.
Generally prepared by: Project Manager / Business Analyst
Next Steps: The technical team and all the stakeholders should be aware of potential risks and how they
have been mitigated or how they are to be managed,
Product Backlog
The Product Backlog is a UpToDate and prioritized list or catalogue of user stories, enhancements, and
bug fixes in a software project. It represents the dynamic requirements of the project and is a key
element in Scrum framework. For example, a Product Backlog for an e-commerce website may include
user stories like "Implement product filtering by category" or "Optimize search functionality."
Generally prepared by: Product Owner (Business Analyst)
Next Steps: Product Backlog is very important document for projects following the Scrum framework. It
is an emergent document. Sprint Backlog is the subset of Product backlog.
Test Plan and Test Case Documents
A Test Plan outlines the approach, scope, resources, and schedule for software testing. Test Documents
detail test cases, scenarios, and procedures. For instance, a Test Plan may specify testing phases, while a
Test Document could contain specific cases like "Verify user login functionality" with steps and expected
results.
Generally prepared by: Test Managers, Software Testing Team
Wireframes
Wireframes in a software project are skeletal outlines illustrating the layout and structure of a user
interface. For example, in a mobile app development project, wireframes may depict the arrangement of
buttons, menus, and content on a screen, providing a visual guide for designers and developers before
the actual design phase begins.
Generally prepared by: Business Analysts
Next Steps: Wireframes are utilized for Requirements Development. UI/UX team utilizes the wireframes
to come up with elaborate application user interfaces.
Business Process Models
Business Process Models outputs may include simple flowcharts or a bit more detailed process models
utilizing the BPMN 2.0 notation set.
Generally prepared by: Business Analysts
Note: Product Backlog , Test Management Plan & Test cases have been explained under the heading
Project Start so we have not explained them in this section.
Project Middle
Low Level Design
Low-Level Design (LLD) in a software project is a detailed description of system components and their
interactions. It elaborates on the High-Level Design, providing specifics on modules, data structures,
algorithms, and interfaces. For example, in an e-commerce system, the LLD may detail the design of the
checkout module, including data flow, error handling, and payment processing logic.
Generally prepared by: Project Managers , Module Leaders
Change Requests
Change requests in a software project are formal proposals to modify project scope, schedule, or
resources. An example could be a request to add new features not initially included, such as
incorporating real-time chat functionality in a messaging app that was not part of the original
specifications.
Generally prepared by: Client and/or Business Analysts
Acceptance Criteria
Acceptance criteria in a software project are specific conditions that must be met for a user story or
feature to be considered complete. For instance, for an e-commerce website's checkout functionality,
acceptance criteria may include requirements such as successful payment processing, order
confirmation, and proper updating of the user's shopping cart.
Generally prepared by: Business Analyst
Sprint Backlog
The Sprint Backlog is a subset of the Product Backlog selected for a specific sprint in agile development.
It contains tasks necessary for implementing user stories. For example, a Sprint Backlog may include
items like "Implement payment processing module" and "Conduct user acceptance testing" for a two-
week development sprint in an e-commerce project.
Generally prepared by: Development team members
Release Notes
Release Notes in a software project summarize changes, new features, and bug fixes in a software
release. For example, in a version update of a mobile app, Release Notes might outline enhancements
like "Improved user interface," bug fixes such as "Resolved login issue," and any new functionalities like
"Added dark mode support."
Generally prepared by: Development Team Members
Project End
User Acceptance Testing Report
A User Acceptance Testing (UAT) Report in a software project summarizes the results of testing
conducted by end-users to ensure the system meets business requirements. For example, a UAT report
might include details on test scenarios, observed issues, and a final assessment of whether the software
is ready for deployment, with specific examples of tested functionalities like order processing and
account management.
Generally prepared by: Software testing team members
Training Manual
Training Manuals in a software project provide instructions for users to understand and operate the
software effectively. For instance, in an enterprise software project, the Training Manual might include
modules on user authentication, data input, and reporting features, with step-by-step guides and
relevant screenshots to facilitate user training.
Generally prepared by: Technical Writers
User Manual
A User Manual in a software project provides instructions on how to use the software. For example, an
e-commerce platform's User Manual might include step-by-step guides on account creation, product
browsing, and checkout processes, accompanied by screenshots and troubleshooting tips.
Generally prepared by: Technical Writers
Implementation Manual
An Implementation Manual in a software project provides guidance on deploying and configuring the
software. For instance, in a web application project, the Implementation Manual might include steps to
install the application on a server, configure databases, and set up necessary dependencies, along with
any troubleshooting tips.
Generally prepared by: Implementation Team Member or Business Analyst
Project Closure
Lessons Learned Document
A Lessons Learned Document in a software project summarizes insights gained throughout the project
for future improvement. For example, after completing a web development project, the document might
highlight lessons like "Early client engagement is crucial for clear requirements" and "Regular code
reviews reduce post-implementation issues," aiding in more effective planning and execution in
subsequent projects.
Generally prepared by: Project Manager
Client Appreciation Letters
Client Appreciation Letters in a software project express gratitude and acknowledgment to clients for
their collaboration. For instance, a letter might thank the client for their partnership, highlight project
achievements, and express the team's commitment to continued success. It could also mention specific
positive contributions from the client, fostering a positive client-vendor relationship.
Generally Prepared By: Sr Executives at Client or IT Vendor organization
Project Closure Report
A Project Closure Report in a software project summarizes the project's outcomes, achievements, and
any remaining activities. For example, it might include details on completed deliverables, challenges
faced, and lessons learned. The report ensures a smooth transition to maintenance or future projects
and serves as a formal closure document for stakeholders.
Generally prepared by: Project Manager
