Product Discovery
Step one in building your software project is to understand what its requirements are. This process is called Product Discovery.
Functional Requirement
A (functional) requirement is a single thing that the software has to do.
For example, here is a functional requirement for MyBooks App: The app allows adding new book entries and it keeps a record of them (i.e., stores them in a Database).
In addition to functional requirements, you should consider non-functional requirements.
Non-Functional Requirement
Non-functional requirements define how a system is supposed to be whereas functional requirements define what a system is supposed to do.
For example, here is a non-functional requirement for MyBooks App: The system should be highly available. If the service is down, even briefly, a user may not be able to see the list of all saved books.
Here is another one: The app's user interface must be user friendly and easy to use.
If you are pursuing the "entrepreneur track," product discovery will be a harder task. Software projects involving several people start with very different impressions on how the end product will need to be. Your primary goal during product discovery is to expand on and unify those visions into one cohesive vision. This happens through extensive discussing, questioning, sketching, ......... among all parties involved: management, developers, customers, etc.
Stakeholders
Developers, investors, customers, managers, and really any person with a specific interest in and knowledge of the software product to be specified.
During product discovery, you must speak with all the stakeholders and involve them in defining the software requirements.
Software Requirements Specification
Product discovery leads to the creation of a Software Requirements Specification (SRS). This document defines the intended functionality of the software and any potential constraints on its operation.
Software companies often use a template document for software specifications. In this course, we will provide you with a template to guide your work.
It is important to remember that a software specification is an abstraction of what the system will ultimately become. As you start implementing the system and delve into the lower-level details, you may encounter issues with the initial specification. This is normal—there will always be challenges that you couldn't have predicted in advance!