Make sure to maintain the Project Structure Plan for non-trivial tasks. In the rest of this article, best practices for the individual steps are described.
= Functional design =
Based on the requirements collected by the customer, we can create a Functional Design (FD). Such a description suggests what a solution should look and behave like. FDs are of paramount importance in a project, because they nail down the scope of a use-case or task. Functional specifications are great to negotiate specific goals with the customer, allowing us to design a technical solution and to estimate the effort. Optimally, an FD contains:
* A description of the use-case
* Mock-ups of the UI (if any)
* A diagram of the workflow (without technical details)
Often, tricky questions are encountered when making a Functional Design. This means we're doing it right, because without an FD, the same questions would appear during implementation, when it's too late. Better to resolve these questions with the customer or the project leader before we start working on the issue, allowing us to adjust our estimate in time.
= Technical design =
Based on the FD, a Technical Design (TD) can be created. Such a concept elaborates on how to provide a suggested functional solution, technically. TDs can greatly reduce the time spent on an implementation, because it allows us to avoid spending the time going down a wrong path by looking ahead, speaking metaphorically. It should address several aspects:
* Architecture
* Data model
* Algorithm
These aspects are described in greater detail in the following chapters.
= Architecture =
** using which protocol
** covering what data
=== Semantics ===
* What is the purpose of a module?
* What information is exchanged via an interface, what does it do for the use-case?
=== Restrictions ===