Brian Smith's guidelines for design theses (originally posted at the MIT Media Lab.) © Brian Smith, reposted here by permission.

there can be only six…

One of the things people distress over when writing a thesis is the number of chapters. Before writing my own thesis, I was given a piece of advice by a very bright man named Bruce Buchanan. Professor Buchanan is known for his pioneering work in medical artificial intelligence. But he also knows how to direct theses. So here is what he told me. I consider it gospel.

For a PhD thesis, you can basically expect to spend a month on each chapter. You won't have that luxury for the typical M.S. thesis. But also remember that you aren't writing a PhD dissertation. Nonetheless, you should realize that it takes time to make the writing come together.
You'll want to start from the beginning, from the introduction. And you could do that. But, in all likelihood, you'll only end up rewriting the intro once the entire body is complete. In other words, you'll know more about what you're doing once you get all the way through it. So plan on rewriting your intro. It's just going to happen.
Here's one that suggested by Linda Peterson, the real academic head of MIT's Media Lab. Write your acknowledgments to your advisor and readers first. Cause when it's all said and done, you may not be feeling altogether political.

Finally, the most important thing that Professor Buchanan suggested was that all theses can be reduced to six chapters ... no more, no less. I've generally found this to be true, so I give you the six chapters.

Chapter	Contents
1) Introduction	what's the problem you're trying to solve? why is it important to solve (read: why should I care)?
2) Extended Example	give an example of your system and how it works. i stress the word example. use the chapter to give a hypothetical (better yet, a real) scenario of use. Most theses that I've supervised are application oriented, so this is easy. For those doing purely experimental work, you'll probably end up with five chapters, this one going away.
3) Theory/Rationale	why are you doing what you're doing? who are the giants whose shoulders you stand on? this is the opportunity to get into detailed surveys of previous work. but, this is not meant to be a literature review. lit reviews are typically boring accounts of things people think they have to list with no apparent rationale. this chapter should connect prior work to your own; it should justify the implementation you'll describe in the next chapter.
4) Design/Implementation	how was it built? how does the final implementation relate to the theory you set forth in chapter four?
5) Evaluation	research must have questions, and questions must be evaluated. else, you end up saying something like, "my system behaves exactly as it behaves." How well does your work achieve the claims you set forth in the introduction and theory sections? how do you know that it "works"? and if it doesn't work…even better, failure is important. but you have to explain successes and failures equally.
6) Conclusion	and now, you're done. you can put in future work, but i haven't a clue why you would; it's likely that you'll never pursue such work. you'd be better off just summarizing your main argument, how the design of the technology supports the argument, and how the evaluation supports your hypotheses.

For another take on the six chapter model, see Stephen Intille's recap of Brian's six chapters. His other tips may also be useful.