Analysis Template

The point of this milestone is to capture your understanding of the requirements; how you plan to address them; and 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.

Requirements Page

1.      Identify and manage the most essential requirements. 

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 essential requirements have been identified and it is clear how they are being managed.

It is sufficient to have a numbered list of the essential requirements for this project on your wiki page with a brief precise “testable” definition of each requirement (often a sentence will suffice, no more than a short paragraph. The list should include both functional and non-functional requirements.

If you prefer, or if your client insists, you could decide to use instead third party tool to manage requirements; use a requirement label to track as issues: or use a product backlog to manage user stories/features.

2.      Test Data and Critical Scenarios

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 label it as a “Risk” in your list of issues).

Please 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 work on test cases.  You do not have to provide test cases in this milestone, but you should use the scenarios and example data to illustrate your analysis of the requirements.

Critical Scenario Specifications

Define and specify these as issues, or as documents in source control, or on your requirements page.

For each critical scenario:

Identify the requirements that are addressed by it, the actors it is relevant to, 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.

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 mockups, simply reference which screen shot should be looked at)

Non-Functional Requirements

Define and specify these as issues, or as documents in source control, or on your requirements page.

For each Non-Functional Requirement, describe your strategy for addressing them:

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).

Supporting Documentation Page

Indicate where useful documentation is found (wiki, source code, google drive etc.) including (if relevant):

DB Schemas and File Formats

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 (2-3 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. Briefly 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.

Architecture Page

Update as appropriate. Illustrate with interaction diagrams how your architecture supports critical scenarios.

Actor and Use Cases, Development Environment, System Demo Pages

Update as appropriate

Risks, Project Plan

Update as appropriate (issues, boards, pages …)