Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Im really not getting the idea:

  1. What is Detailed Design.
  2. Why use Detailed Design.
  3. Advantages/Disadvantage of using Detailed Design.
  4. Any alternative methods other than using Detailed Design.

Could some one please guide/explain me ?

share|improve this question
    
Please elaborate: UI design or general software architecture design? Or anything else? – user2567 Nov 17 '10 at 13:19
    
Architectural design – Mafahir Fairoze Nov 17 '10 at 13:25
up vote 18 down vote accepted

1) When most people talk about detailed design, they are referring to a process known as top-down design. In short, when you think about the problem you are trying to solve, you start at the highest level and then work yourself into the details. This approach works very well when you have an overall structure you want your application to live within. At the macro level you are considering how many machines will be needed to host your application, which existing services you will need to use, etc. As you dive deeper, you are looking at use cases (or user stories if you prefer that terminology), and error handling (use cases have both normal and error condition paths to worry about). As you go even further into the details, you are looking at your algorithm, state transitions, logical sequence, and how internal parts of the code work together.

2) The classic top-down approach to detailed design is what is taught with the "waterfall" methodology, IEEE process guides, UML vendors, universities, and CMMI among others. In many of these heavy processes they have you writing two design documents. One is the overall architectural diagram (the top level design). The other is the detailed design where you go further down the rabit hole. In many cases it is the only approach to design many people know. It is a very logical and methodical approach to breaking down a software problem.

3) The main advantage is that you have identified what the critical sections are likely going to be. If you will need to start working on how your software will be using another existing service, you have compiled your list of integration points. You would be able to start talks with the owners of those services to plan your integration along with how to handle unexpected events.

The main disadvantage is that many times people go too far down the rabit hole, and the design document takes a life of its own. While it is advantageous to have an overall vision and architecture for how an application will work, you will invariably find your initial thoughts on the core details were flat wrong. When that happens, either the design document is neglected or you have whole teams maintaining the paper and slowing progress on work.

4) I've already mentioned top-down design, so it follows there must be a "bottom-up" approach, right? As it turns out, there is. Essentially, the "bottom-up" approach is the core thought process behind Test Driven Development and Continuous Design methodologies. Essentially, the details of working code start driving the design of how larger chunks of working code cooperate and interface with each other. With TDD, you have unit tests to ensure that the details behave properly and keep validating your design. Continous design teaches us that we will never truly know the details until the software is done. Therefore, why try to fight the fact? Instead of a big up-front design stage, the design is built in increments over several iterations of design/code and testing. It is actually a very liberating concept that lets you concentrate on solving problems.

Bottom line, there is no perfect answer. For me, I find a healthy balance between top-down and bottom-up design works well. Essentially, I still take the time to think about the big picture. I even map out a plan for the user interface idioms and my best ideas for it's design. However, I don't go into great detail because I know the details will change. Basically, you need to stop the top-down process when you are getting to areas you are not sure about. Once you get to those areas, start with the bottom-up approach. This lets you try different things, verify with the customer if it makes sense to them, and continue to improve over time.

share|improve this answer
    
IMO you mix a bit two concepts: top-down or down-top design mean how you imagine your software, from the global concept or from specific low-level use cases ( e.g. I have to create a MSWord, so it shall allows the user to write and save the text. I have to create a software which allows the user to write and save the text, so I will create an MSWord). The other concept is waterfall/V life cycle versus incremental life cycle, which mean how much of your software you design before to start codding. – Adrian Maire Jan 6 at 9:11
    
Is it accurate to describe user stories and use cases as the came construct? As I use them user stories, use cases and use case scenarios are all serve different functions and contain different information despite having similar names. – Gusdor Jan 20 at 9:45
    
As always, the definitions of these terms is evolving, and sometimes the same terms can mean different things to different teams. For example, many agile shops distinguish between Epics (features) and User Stories (use cases), and other shops still use a formal Use Case scenario with user stories as the parent. Still others don't even use User Stories. – Berin Loritsch Jan 20 at 14:45
    
In Code Complete it's called BDUF. – bigstones Apr 9 at 6:32

When most people talk about detailed design, they are referring to a process known as top-down design. In short, when you think about the problem you are trying to solve, you start at the highest level and then work yourself into the details. This approach works very well when you have an overall structure you want your application to live within. At the macro level you are considering how many machines will be needed to host your application, which existing services you will need to use, etc. As you dive deeper, you are looking at use cases (or user stories if you prefer that terminology), and error handling (use cases have both normal and error condition paths to worry about). As you go even further into the details, you are looking at your algorithm, state transitions, logical sequence, and how internal parts of the code work together

share|improve this answer

A detailed design allows you to evaluate design options prior to actually implementing them. It can potentially save you a ton of needless work you would otherwise have spent on an implementation that was deeply flawed due to a high level design choice and had to be extensively rewritten.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.