8/2/2019 Analysis Report Template

1/2

Analysis Report TemplateThe point of this document is to capture your understanding of the requirements,and how you plan to address them. This document is used to capture theagreement between you and your customer of what will be built. It is alsointended to be a useful reference for your project team.

Not all of the following sections will be relevant for every project. For example,not every project will have a user interface, or a database.

Background (1 paragraph)Briefly give enough background so that a person outside your team reading thisdocument would understand why this document exists and what it is used for.

Requirements (1 page)A numbered list of the main requirements for this project with a brief definition ofeach requirement (often a sentence will suffice no more than a short paragraph).Requirements should be grouped so that similar requirements are groupedtogether. The point of this section is to list and identify requirements. It is notnecessary to include a myriad of details that may evolve over time, as long as themain requirement has been identified.

Example Data and Test Cases (2-3 paragraphs)Identify the data that the customer will be providing, or you will be building totest and verify the system throughout the project lifecycle. If it is not currentlyavailable, identify the process and schedule by which it will be made available(and highlight it as a risk in your project status report that needs to be managed).

Please note that you and your customer cannot have possibly come to a commonunderstanding of the requirements, unless you have agreed upon the test casesand sample data that will be used to verify requirements have been met. It isessential that you start building up these test cases and sample data early.Identify two or three critical scenarios and define example data for them that willbe used to start work on test cases. You do not have to provide test cases in thisdocument, but you should use the scenarios and example data to illustrate youranalysis of the requirements throughout this document.

Use Case Model or Functional Features of System (2-3 paragraphs per featureor use case)

Define WHAT functionality the system will provide. Ideally this would be organizedaround the major use cases the system would support. This can also be organizedaround the major functions or features of the system. In either case, your systemshould have somewhere in the range of 3-10 of these use cases or major features.Include an updated use case diagram.

For each use case or feature:

Identify the requirements that are addressed by it, the actors it is relevantto, and any preconditions or restrictions.

Define clearly the "normal" flow of interactions with the system. Identify the

variations on this normal flow that are possible and in particular what"exceptions" must be handled.

8/2/2019 Analysis Report Template

2/2

Illustrate the normal flow (and variations) with an example using the sampledata from one or more of your critical scenarios. (If the illustration will beshown in your user interface mockups, simply reference which screen shotshould be looked at)

Non-Functional Features (1 paragraph per feature)Some requirements are non-functional. E.g. the system must be scalable andsupport a 24*7 usage. Or the system must be usable by novice users. For each ofthese, describe your strategy for addressing them:

1. From a design point of view (how do you plan to design and build the systemto address the requirement) and

2. From a testing point of view (how do you plan to verify that therequirement is met).

High Level Architecture (2-3 Pages)Draw a package diagram (or possibly an updated deployment diagram) that showsthe key components of your system (e.g. web server, database, user interface) andwhat third party technologies you will use or be dependent on (e.g. IIS, MySql, PHPetc.). For each component there should be a brief statement of what its role is insupporting the requirements of the system. Illustrate your architecture by drawingtwo or three high level interaction diagrams that show how the componentsinteract for your critical scenarios and example data. (If you are using a UML toollike Rational Rose you will need to create a facade class to represent each of yourcomponents).

User Interface Mockup (2-3 pages)

Screen shots or actual GUI or HTML pages that illustrate the look and feel of theuser interface for your critical scenarios. Make sure you use your example data.

Database Schemas and File Formats (1 page)If your data will be stored persistently either in a database or a file, define therelevant database schemas or file formats. Illustrate by showing how your exampledata will be stored.

Algorithms (2-3 paragraphs per algorithm)If your system will be dependent on any significant algorithms (patternrecognition, image processing, game strategy, matching problem etc.) then

identify them here. Briefly outline the problem that needs to be solved, thealternatives considered, and the algorithm selected. Illustrate the algorithm withan example using the example data.