You are to write a report that gives the abstract (conceptual) architecture of the the system that you are studying.
Your report should be web-readable, with links as appropriate to web-accessible related information. In particular, links to web pages describing the system of interest are important.
The abstract architecture includes information about what the system does (its functionality) and how this is broken into interacting parts. What are the parts? How do they interact? How does the system evolve? What is the control and data flow among parts? What concurrency if any is present? What are the implications for division of responsibilities among participating developers?
The concentration is on the conceptual organization of the system rather than on the details of its implementation. You should assume that your readers have the basic knowledge of a typical computer science graduate.
The following are suggestions for your report.
Title: About 3 to 6 words making clear what your report is about.
Authors: Author, address, date, etc.
Abstract: About 2/3 of a page overviewing the key points in your report.
Introduction and Overview: About 1 to 3 pages summarizing the purpose of report, its organization, and its salient conclusions. A person should be able to read just the abstract or just the introduction and have a good idea what is in the rest of your report.
Architecture: Give the overall structure the system, with descriptions of each major component and of the interactions among them. These components are to be primarily subsystems and modules, files, and data bases. In your descriptions, concentrate on goals, requirements, evolvability, testability, etc., rather than on lower level concepts such as variables and control flow. However, you should clarify global control flow, such as units of concurrency and method of passing control from one component to another.
Your description of this architecture should be easy to understand, ideally with simple interfaces, and modest interactions among subsystems and modules.
Clarify what style of architecture, if any (in the sense of Garlan and Shaw) that characterizes (various parts of) the system.
You are not to concentrate on minor components, such as procedures, which are smaller than modules. However, you may wish to discuss important abstractions, ADTs, data structures or algorithms that are critical to the successful implementation of the architecture.
You should use diagrams that clearly illustrate the structure of your system. You may choose to use DFDs (Data Flow Diagrams), ERDs (Entity-Relation Diagrams), structure charts (at the level of modules not procedures), or software landscapes. Except possibly at a very high level, STDs (State Transition Diagrams) are not the right kind of diagram. Do not give diagrams that are too low level, eg, do not give diagrams of details within objects (as in OOA), nor within modules.
Data Dictionary: Include a glossary that briefly defines all the key terms used in the architecture, giving when appropriate, the "type" of the item being explained.
Naming Conventions: List any naming conventions used in the architecture. Explain any abbreviations that you use.
Evolvability: Discuss how the architecture is designed to support future changes.
References: List any documents that your reader may wish to or need to read in conjunction with your report. Include URL links to references when appropriate.
DOCUMENT STYLE AND LENGTH
Do not make your report longer than necessary. In general, shorter reports that contain appropriate information are preferred. Your report must not be longer than 10 pages, including all diagrams and appendices.
LIMITED TIME
Like much work in software development, you are being asked to do more that you have time to do. Part of your job is to choose what you will actually do for these assignments.