Spectodesign » History » Revision 3
Revision 2 (Shuvam Misra, 05/12/2018 06:11 PM) → Revision 3/18 (Shuvam Misra, 05/12/2018 06:12 PM)
# From spec to design of a business application
{{>toc}}
This page will describe
* what processes we can follow to arrive at detailed software design from layman specs, and
* what documents we need to create along the way
We will first start by taking a look at the spec and design documents conventionally used in the industry for a few decades, then look at the terminology used by the much more recent agile development chaps, and then arrive at the documentation we need for our use in Merce. After that, we will describe the process we can follow to arrive at the detailed design document.
The objective of this entire process is to arrive at documentation which can be handed over to a bunch of good programmers who can then do the coding and testing without discussing spec with the client.
## Documentation in the traditional approach
The traditional approach, called the "waterfall" approach, believed in documenting everything in great detail, getting the client to sign off on each document, and then starting software development. In that approach, the steps were as follows:
* The **BA** (Business Analyst) studies the business operations of the client, suggests some changes to the process for suitable computerisation, and then captures all this in something called a **BRD** (Business Requirements Document). The BRD is also known as BRS (Business Requirements Specifications), FRS (Functional Requirements Specification), etc. They roughly mean the same thing.
* The tech team then sits with the **BRD** and creates the **SDD** (Software Design Document). This contains technical design and architecture which is useful for the programmers who will develop the software.
* Modern applications are expected to have very good UX and UI, since no user wants to go through a training programme or read a user manual to use it. Therefore, a third activity is the UX and UI design, which is done by studying the BRD. This UI design is used by developers to design the screens.
This is three-part process for software design and specification in the conventional approach. The dev team finally gets
* the SSD
* the UI spec and screens
to do their coding.