Analysis Report Template

The 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 the agreement between you and your customer of what will be built. It is also intended 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) riefly give enough bac!ground so that a person outside your team reading this document would understand why this document exists and what it is used for. Requirements (1 page) " numbered list of the main requirements for this project with a brief definition of each requirement #often a sentence will suffice, no more than a short paragraph$. %equirements should be grouped so that similar requirements are grouped together. The point of this section is to list and identify requirements. It is not necessary to include a myriad of details that may evolve over time, as long as the main requirement has been identified. Example Data and Test Cases ( !" paragraphs) Identify the data that the customer will be providing, or you will be building to test and verify the system throughout the project lifecycle. If it is not currently available, identify the process and schedule by which it will be made available #and highlight it as a ris! in your project status report that needs to be managed$. &lease note that you and your customer cannot have possibly come to a common understanding of the requirements, unless you have agreed upon the test cases and sample data that will be used to verify requirements have been met. It is essential 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 will be used to start wor! on test cases. 'ou do not have to provide test cases in this document, but you should use the scenarios and example data to illustrate your analysis of the requirements throughout this document. #se Case $odel or %unctional %eatures o& 'ystem ( !" paragraphs per &eature or use case) (efine )*"T functionality the system will provide. Ideally this would be organi+ed around the major use cases the system would support. This can also be organi+ed around the major functions or features of the system. In either case, your system should have somewhere in the range of ,-./ of these use cases or major features. Include an updated use case diagram. For each use case or feature0 Identify the requirements that are addressed by it, the actors it is relevant to, and any preconditions or restrictions. (efine clearly the 1normal1 flow of interactions with the system. Identify the variations on this normal flow that are possible, and in particular what 1exceptions1 must be handled.

Illustrate the normal flow #and variations$ with an example using the sample data from one or more of your critical scenarios. #If the illustration will be shown in your user interface moc!ups, simply reference which screen shot should be loo!ed at$ (on!%unctional %eatures (1 paragraph per &eature) 2ome requirements are non-functional. 3.g. the system must be scalable and support a 4567 usage. 8r the system must be usable by novice users. For each of these, describe your strategy for addressing them0 a$ from a design point of view #how do you plan to design and build the system to address the requirement$ and b$ from a testing point of view #how do you plan to verify that the requirement is met$. )igh *e+el Architecture ( !" ,ages) (raw a pac!age diagram #or possibly an updated deployment diagram$ that shows the !ey components of your system #e.g. web server, database, user interface$ and what third party technologies you will use or be dependent on #e.g. II2, 9y2ql, &*& etc.$. For each component there should be a brief statement of what its role is in supporting the requirements of the system. Illustrate your architecture by drawing two or three high level interaction diagrams that show how the components interact for your critical scenarios and example data. #If you are using a :9; tool li!e %ational %ose you will need to create a facade class to represent each of your components$. #ser -nter&ace $ockup ( !" pages) 2creen shots or actual <:I or *T9; pages that illustrate the loo! and feel of the user interface for your critical scenarios. 9a!e sure you use your example data. Data.ase 'chemas and %ile %ormats (1 page) If your data will be stored persistently either in a database or a file, define the relevant database schemas or file formats. Illustrate by showing how your example data will be stored. Algorithms ( !" paragraphs per algorithm) If your system will be dependent on any significant algorithms #pattern recognition, image processing, game strategy, matching problem etc.$ then identify them here. riefly outline the problem that needs to be solved, the alternatives considered, and the algorithm selected. Illustrate the algorithm with an example using the example data.