Market analysis :
should describe what is expected from the product. Usually, this happens in the following way: a the product manager supervises the marketing department and describes how to address the clients needs: the Market Requirements Document (MRD) lists these aspects.
This happens in two phases: first, the macro level where we translate the MRD into a high-level concept. This is described in a Product Requirements Document (PRD) that lists the product features and main requirements.
Accordingly, the engineering team/analysts detail the PRD into sub features describing the product specifications in a functional way: how should the product behave (not the technical how). This results in a Functional Specifications Document (FSD).
Conception focuses on the “WHAT“.
Keep it simple, keep it efficient. Products are as the rest: alive and evolving. So, before translating the functional specifications into a technical implementation, consider structuring the product first. For instance, a software product requires a global architecture before start coding, otherwise, you just keep doing the same thing over and over again. This is a simple logic. Think of your architecture as general guidelines that allow you and anyone on the team to see the big picture, the map. And when you’re lost (and trust me, you’ll be), you just go back to that.
Just starts by drawing your concept and highlight your system components and actors. From that point on, you just define how each part should interact with the rest. Don’t overdo it, keep in mind that it’s a guideline. Macro first then Micro. Go from the general to the specifics. It easier to understand this way.
It’s easier to describe this through an example. For instance, if you’re building a software that manage multiple users in a networked environment to access a common database and share stuffs on it through a custom policy managed by an administrator. Your actors will be: client user, server administrator. Your system components are a client, server, and a database.
Keep in mind that when you’re architecture is simple, it allows you to evolve your product without breaking it.
From here on, you can define specifics guidelines on your components according to your constraints: choose languages, define interfaces, wireframe GUIs, etc.
Development focuses on the “HOW“.
Let me put it in one sentence: an untested system is not a working one. It’s always better to find your bug, whatever its criticality, when it’s still inside your company, rather than let it slip to your customers. As a general rule of thumb, customers are not forgiving.
To be continued in the next part.