The goal of this series of articles is to provide insight, clarity and a process of accountability within the design and development process for the entrepreneur seeking to design and bring to life their own software-based product.
The first step on our product development journey is to begin the process of documenting our requirements. Let's get into it..
My time is mostly split between a couple of core activities. Over the course of a day, I wear 2 major metaphorical hats; the programmer hat and the analyst hat. When I wear my programmer hat, the end result is stringing together a series of instructions in the form of source code that tell a computer what to do. When I wear my analyst hat, the end result is stringing together a series of instructions in the form of documents that tell a programmer what to do. Not to get all inception on you or anything but, when I'm being an analyst, my job is to program programmers. The analyst role, and the process of creating a product starts with the gathering of requirements.
In short, a requirement is a statement that defines a desired behavior within a system. In our case we are referring to a software based system. In software based systems, there are two basic types of requirements, non-functional and functional. For the most part we will be dealing with the functional aspect.
There are many benefits to taking a requirements based approach to software design. Let's start by defining a few.
Creating a requirements document brings a necessary level of clarity to any project, regardless of size. It becomes the basis for most conversations and gives a central point for determining the progression of the planning effort. You can check each requirement off as it is satisfied by a mock-up or specification.
Moscow is a mnemonic device for remembering the three levels of requirement prioritization: must, should and could. Describing requirements as such makes it very easy to make decisions based on time and resources.
A visitor must be able to create an account.
A member should be required to activate their account.
A member could be able to enable 2FA.
Once all parties involved in the project have agreed on a deliverable consisting of a certain set of requirements, it should be fairly obvious to all parties if the modification of an existing requirement or the introduction of a new requirement will affect the timeline and resources. This is a planning trigger, and an opportunity to recalibrate and reset expectations accordingly.
Once a project has begun, the addition or modification of a requirement should never be taken lightly.
Without further ado, its time to grab your proverbial pen and get started. Once you start documenting your requirements, you will start to find natural logical groups for them, whether by role, module, screen etc. One thing to note about the requirements process is that it never ends. You will be forever adding, updating and deleting them and for the sake of your project, you need to make peace with this.
Here are some examples to get you started:
The system must maintain a 99.999% uptime.
The system should use a fault tolerant 3rd party system for sending transactional emails.
A visitor must be able to create an account on the system.
Feature: Password Reset
A member must be able to reset their password.
Feature: Add Payment Method
A member must be able to add a payment method.
Give it a try and remember, requirements will always change so, don't be afraid to get started and don't be afraid to refine them until you have a clear picture of what your product should do.