Apart from my day to day coding and software development studies activities. I have been having a huge love and passion for software product management lately so I decided to take a software product management specialization course on coursera courtesy of I4G and I'm currently on the third course out of six courses contained in the specialization. So in this article in will be sharing some tips on how to write a proper software product documentation.
What is Software Product Documentation (SPD): Software product documentation also know as a software requirements specification (SRS document) describes how a software system should be developed. Simply put, an SRS provides everyone involved with a road map for the software product project. It also describes the functionality the product needs to fulfil all stakeholders (business, users) needs.
A typical SPD/SRS includes:
A purpose
An overall description
Requirements
A Software Product Documentation should contain the following
- Product Vision: this encompasses what the product will eventually do to satisfy a user's need, it also contains a brief explanation of the problem the product is solving and the value it gives to the user.
Product Scope: this encompasses what can be realistically achieved within the product project. scope tells you what you will and won't do and helps manage expectations.
Business Requirement: It outlines the purpose of the product, it also felicitates the requirements of the end-users as the very first task to guide the design of the future system. Business requirements are usually captured by business analysts or product owners who analyze business activities who in turn act as subject matter expertise (SME's).
Business Rule: A business rule is a constraint of the business itself that may guide the product development. It is a rule that must be followed, no matter what else is happening. It often involves very specific criteria or conditions for compliance. like privacy policies, brand uniformity requirements, government regulations. etc
User Requirements: User requirements outline exactly what tasks the users can do with the product. They describe what the product should do for the users.
Functional Requirements: This is the behaviour of what the product should do or support. They can be expresses with inputs and outputs and a description of the behaviour itself. One way to represent functional requirements is by using an information flow diagram, information flow diagram gives you a graphical way of displaying the data flow and dependencies of all the system components.
Non-functional Requirements: This serves as a description of "how well" a product must perform. It addresses the quality factor of the product. Accuracy, safety, maintainability are an example of non-functional requirements.
Additional Requirement type:
External interface requirements: It shows how the product itself relates to something else in the system.
Physical settings requirements: It describes how the product should be design around its physical environment.
Development Constraints requirements: It outlines the implementation technology, conventions, documentation and the process which the development team will use.
In conclusion, this is the template I use at the moment while writing a software product documentation, the template is not a one size fit all. you might need to tweak it at any point to suit your need but the above tips will serve as a fundamental build block to start with.
all images used within the article are gotten from Relevant