In past semesters, many students have developed their intelligent systems using a standard project development lifecycle. In such cases, requirements gathering precedes analysis, which precedes design, which precedes implementation, which precedes testing, which precedes fielding the system. Those project teams often produced as their midterm deliverable a Project Analysis and Design Document. The remainder of this page outlines a typical analysis and design.
Recently, students have opted for more exploratory approaches, or a lightweight development methodology such as extreme programming, which produce prototypes and designs and other artifacts as their results along the way. For this style of project, a traditional analysis and design is probably not the best way to document the first half semester's results. If you want to do something like this, talk with me about what your team should produce at midterm.
This document should contain:
The document should be organized with the following sections in the following order:
A one-page summary of the problem, proposal, and design.
What is the project? What are the goals of the project? What methods have been used as part of the project?
A narrative description of the problem and the people who solve it. This description can be augmented with organization charts that demonstrate the structure of the system, context and data-flow diagrams that document how the task is currently performed. Some issues that you will probably want to address in your analysis include:
A description of the system being proposed. This description should then specify the goal(s) and structure of the proposed system. It should also present any alternatives considered, including system scope and system implementation. Finally, it should justify the alternatives selected, discussing the relative advantages and disadvantages of the proposal.
A recursive analysis of the tasks underlying the system, the possible methods for achieving each task, and the sub-tasks established by each method. Your analysis will not be complete at this stage and should focus specifically on the methods and sub-tasks indicated by the domain knowledge collected to date and by the system proposal.
An initial model of the high-level components in your system architecture and how they interact. You should begin to assign domain knowledge to each component based on your knowledge acquisition and system analysis to date.
A summary is a closing abstract. Conclusions imply judgment or expert opinion. You should provide both.
Document outside sources that you have read in support of your analysis and design, including your textbook if relevant.
Use if appropriate. An appendix can be used to present existing forms, documents, etc., that provide details relevant to your report but not appropriate for inclusion in the report body. These may also include questionnaires used, transcripts of interviews, and the like.
The report must be delivered in a black cardboard binder with fasteners, as demonstrated in class. All pages must be numbered, except for the title page and table of contents. The title page should contain the title of the document, the names of the team members, the course name and number, the instructor's name, the date the document is submitted, and the department and school name. The table of contents should list all sections and indicate the pages on which they begin. Sub-sections may be listed if appropriate.
The sections of the document must be in the order listed above. Each section should be marked to indicate the person(s) responsible for writing it.
The references in the bibliography should be listed in alphabetical order and should be numbered consecutively. Citations in the report should use the number to indicate the reference.