An important part of solving large engineering problems is to break the work down. We have long used the terms analysis and design in the context of creating software systems. Despite this lengthy history there seemed to me to be a lack of clarity as to the aims and practices of the two phases. In particular I was concerned that some approaches – popular ones at that – were actually doing high-level design and calling it analysis.
I proposed that we take the word analysis at face value and find something to analyze. You can’t start thinking about software classes, no matter how high a level, and say that you are analyzing. (I used the term classes because the book assumed that the eventual target implementation technology was object-oriented.)
I also wanted to address the seemingly simple but important question of what do you actually do when carrying out analysis and design. Many books just gave aims and objectives. I wanted to offer a practical, doable set of steps to carry out.
(The old site, written with Dreamweaver, has been updated to this version based on WordPress. I’ve ported the pages I consider still relevant, but if you encounter broken links or missing sections, or were using one of the old resources, do feel free to let me know by emailing:
)
* Historically the publisher wanted some exercise solutions available only to teachers. Hence the two links above.