This is a living document and will change over the course of the quarter as you discover new things and implement your project. These are probably living documents on your wiki. We'll take a look at these documents on 10/15 and 10/22 to evaluate where you are at.
You should review (preview?) the wrapup milestone (this preliminary version anyway) as a checklist of things to do and consider.
The System Architecture document provides a detailed definition of the system’s software components. It identifies the major modules and their functionality, and the interfaces between modules, required to implement the system. It should address the design of the system from the customer's viewpoint, as well as that of the developer or administrator. (This may require separate perspectives and/or diagrams.)
Describe, in detail, what data your system stores, and how. If it uses a database, give the high level database schema. If not, describe how you are storing the data and its organization.
You should describe the major components of your system. You should show the major interactions between said components. You should expose the interfaces that allow the components to work together. (This maybe redundant with your database schema.) Pictures and text work well here.
Exposing all the major classes is a good way to do this. Class descriptions of all attributes and methods (do not list get/set/is methods) inheritance/interface relationships, and associational relationships (named and directed, with multiplicity adornments).
It may be helpful to include a UML class (object) view and UML sequencing diagram outlining important use cases from your requirements specification. UML tools that you may want to use are found here, though some of the links are out of date. When I say UML, I mean "real" UML. If you don't use real UML, then your pictures sort of resemble UML diagrams, but they are perhaps ad hoc.
Your design should use the design principles discussed in this class and prior ones. Here are some general design tips, which essentially come down to “put functionality in a logical place”.
keep related data and behavior in the same place; emphasize cohesion, limit coupling, and minimize each class's public interface
We've pushed these descriptions into the requirements document that you are writing. Rightfully or wrongfully. So, include user interface and user experience diagrams there.
The tools and runtime description describes all of the tools and the runtime stack that you will be using in this project and a description of why you chose them. Tools that you will consider (but are not limited to) are: programming language(s), compilers, debuggers, editors, version control system, wiki, bug tracking system, test system, deployment system, etc. The runtime system includes the OS you will deploy on, storage technology (e.g. database), application server, front end server, hosting partners, etc. In addition to the enumeration of the tools and runtimes you'll be using, an explanation of why you chose them and what the alternatives were.
You should describe where you are going to deploy (department machines, WebFaction, AWS, etc.) and why you made this choice (and why you rejected alternatives).
You should have a description of the "physical" topology -- how all the pieces fit together. A picture works well here.
The process description describes in detail how you are going to create and release software. While there are three releases that you must do, you have a fair amount of latitude on how you do this. However, we suggest that you use evolutionary delivery with milestones defined at each release deadline -- hybrid of the the feature-based and train process. Each release cycle is two weeks. By 10/22 you should propose what you want to deliver at each release.
Further, the process of how you are going to operate in each cycle should be defined. When are you going close on requirements? When will the feature design be done? When will implementation be completed? When will testing be completed? (How are you going to test?) When are you going to deploy to the live site (if you are doing a web app)? How are you going to deploy?
By 10/22, we may or may not have discussed how to test or how to deploy. So, there's some room for chaos at this time for lack of information. However, as the quarter moves on and we discuss this, you should evolve these processes.
If you aren't using evolutionary delivery with hybrid feature/train process (e.g. you decide to do continuous releases of features), describe how you will do this. (Probably want to consult with your TA.)
We discussed the possibility of pipelining your releases because 2 week cycles from requirements (refinement) to deployment might be too short. This is your call.
By 10/22 you should have a good idea of the features that you want to deploy. You should have made some estimates on how long it is going to take to deploy each feature. Additionally, there are probably some "infrastructure" that you need to implement. By 10/22, you should make a proposal as to what features you want to deliver by which release dates. This can change as time goes on, but this "strawman" proposal is your first stab at what and when you can deliver the features of your project. Because this is a joint exercise between those specifying requirements and those specifying architecture, design, implementation, deployment, etc., this can be documented in either the requirements document or this document. Put it in your requirements document.
The description of your organization is essentially an "org" chart that shows everyone on the team, what their "titles" are and what they are responsible for doing.
At the 10/15 milestone, the high level decisions should be made and many of the detailed decisions too. Your data schema, class hierarchy are starting to take form. The UI and UX are starting to take form (you are documenting this in the requirements document). You should have at least experimented with the tools -- the programming language, the debuggers, git, github, the runtime, etc. You may have "implemented" and "deployed" some of it. Perhaps you've prototyped some of the system. You should describe all of these decisions and the rationale behind them.
You are pretty sure of the tools and runtime pieces that you will use, though you may add or swap out pieces later. You have experimented with the software that you will be using. You have a good understanding of the version control system, bug tracking system, wiki, etc. but, with the exception of the wiki, you may have not brought up these systems. You have a good idea of where you are going to deploy and you have experimented with this. Your wiki should be up and running.
The basic organization and roles should be determined at this point. You should document them with a a chart or table showing the people on the team, their roles, the "reporting" structure, and titles.
We'll take a look at this document to see where you are at. You've probably refined the architecture, tools, and process. Update the document to reflect this.
At the 10/22 milestone, you've definitely had experience with the tools and runtime. You may have implemented/prototyped a bunch of code. Your have a pretty good idea about your data model. UI and UX for much of the application is coming together. You have a webserver/app server/datastore "sort of" running in a development environment and on your "live" site. But you may decide to throw away everything you've prototyped/implemented at this point. However, the architecture, design, tools, runtime, and process should start to settle down. However, all team members may not yet be able to bring up a development environment and the process kinks may not yet be worked out.
On 10/24, you'll give a 7 minute presentation in class to discuss where you are at with respect to requirements, everything in this assignment your proposed schedule, and what you've been hacking together thus far.