Project Name
Analysis and Design Document

Read about the Minimal IT analysis and design template for instructions on how to use and review this template.

This template is offered for free, without restriction, on an "as is" basis. Minimal IT does not guarantee that this template will be suitable for your particular circumstances, and will not accept any liability for its use.

1. Summary

Write this section last.

Summarise the main points from the document. Make sure you include the business and IT opportunities, not just the design and plan.

2. About the document

State the main content and purpose of the document, and any relevant information about its authorship, versioning and relationship to other documents. Imagine you are providing a summary for a librarian, who is not the slightest bit interested in the business and technical content of the document but wants to be able to classify and file it correctly.

3. Business opportunity

The purpose of this section is to draw out the reasons for the proposed activity and explain what business change will occur. This must be fully understood before considering the IT response.

3.1 Background

Provide a brief description of the business area under study. This is only here to set the scene for later sections, not to show off how much analysis you have done.

3.2 Opportunity

Carefully describe the opportunities that exist for improvement. Where possible, provide quantifiable benefits, even if these are only order-of-magnitude.

3.3 Required business changes

Describe what changes to business activity and operation would be required to grasp the opportunity. Limit this to the most important primary changes that are directly required to exploit the opportunity. Do not document changes that are required to support the changes -- these go in the next section.

For example, if you are considering a video rental business, the main changes might be acquiring stock and distribution channels. You may want to publish film reviews, but this is only a supporting change. The distinction is subjective, but gives the opportunity to prioritise the main points to your readers.

In this section, or the next section if appropriate, make sure you document any significant changes to responsibilities.

3.4 Supporting changes

Describe the main changes that are likely to be required to support the changes required to grasp the opportunity.

4. IT opportunity

The purpose of this section is to document whether an IT response is appropriate, and if so what it should contain.

4.1 IT value

Describe how IT could add value to the required and supporting business change. IT can only add value by remembering, transforming or communicating information faster, more accurately or cheaper than people. IT may do these things better than people, or may be able to do things that are not feasible with people.

Limit this section to a few areas where IT could add most value. This is critically important. Any IT solution needs to focus on the areas of greatest value.

4.2 IT capability

Restate the value in the previous section in terms of specific IT requirements aligned with existing or proposed organisational responsibilities. Only include the requirements directly related to the main areas IT value.

Make sure that each piece of IT capability fits in with organisational responsibilities, i.e. state on who's behalf it is remembering, transforming or communicating. This is critically important. If you do not know this, stop the project.

4.3 Supporting IT requirements

List important business requirements which will be required if there is to be an IT system, but which are not of themselves reasons to have an IT system. For example, ease of use may be a particularly important requirement, but is not of itself a reason to have an IT system.

Do not get carried away in this section. Give a high-level list of the main requirements. Do not just list everything you can think of. Do not include expected system characteristics, like security and resilience, unless they are specifically related to the business opportunity.

5. IT architecture

The purpose of this section is to provide a context to support the systems design. It is not intended as a complete design of all the technology, or a regurgitation of standards and best practices.

5.1 System partitioning

Describe the separate systems involved in the solution. Make sure these reflect the alignment of organisational responsibilities described in section 4.2.

5.2 IT architecture requirements

List the most important things that have to be achieved by the IT solution, over and above the requirements listed in the previous sections. This might include such things as viability, fit to corporate standards, or ease of outsourcing. Explain why each is required.

5.3 High-level components

Provide a high-level description of the main components of the IT solution. For example, this might include a web application server, relational database, and browser. Briefly mention any important standards and why they need to be applied.

5.4 Major technology choices

Where relevant, state what technology, design approaches and products will be used to support the solution.

6. IT design

The structure and content of this section will depend on the proposed design approach. The headings below are given as a guide.

This section is only intended to illustrate how the IT requirements can be met, and as a basis for planning. It is not intended as a complete design from which the system can be built.

Make sure this section reflects the capabilities and requirements in sections 4.2 and 4.3, and respects the architecture in section 5.

6.1 Data

Document the information to be stored within the IT systems.

6.2 Processes

Document the activities, rules and calculations that will take place within the system.

6.3 User interfaces

Document the main user interfaces to the system.

6.4 System interfaces

Document the flow of information between this system and other systems.

7. Plan

The structure and content of this section will depend on organisational standards and requirements. The headings below are given as a guide.

This section is intended as a summary for review. It is not the complete project management working documents.

7.1 Approach and deliverables

Describe the approach to be taken to more detailed design, build and implementation activities. Describe what actual deliverables will be produced at each stage.

7.2 People

List the people and groups that will work on the project. If individuals are not known, describe the skills required.

7.3 Schedule

Provide a schedule which shows what work will be done when. If actual dates are not known, still show tasks and their duration.

7.4 Costs

Provide a breakdown of the costs of the proposed solution. State whether these are fixed or an estimate. If an estimate, describe how accurate they are and what is likely to make them change.

Acknowledgements

You are free to remove this section if you wish, but you might like to leave it in so that your readers know where the template has come from.

This document was prepared using a template from Minimal IT. For more information, read about the Minimal IT analysis and design template.