Documentation:
1) The "Concept Document" should be different from the SRS. A concept document answers the questions a) "What capabilities will the system provide to the user?" and b) "Why have we chosen this particular set of capabilities for this system?" It is an informal description of the system you plan to build. This corresponds (more or less) to the first couple of sections in the example project 1 documentation.
2) The SRS is supposed to be a more formal, black box specification of the required system behavior. It is a technical specification that characterizes the expected outputs of the system for any possible inputs. (This will not actually be possible given the time you have available). The SRS should answer the question: "Exactly what is the required, observable behavior of the system and any constraints on its implementation?"
3) In practice, these may be combined in the same document. That is what we will end up doing for Project 1. I.e., the first section or two of the SRS will answer the questions in part 1) above and the later sections will address part 2).
Project 1 Deliverables:
The purpose of turning in the initial project documentation is to allow me to comment on what you are doing and for you to make mid-course corrections if needed. I will not grade these. Rather, you will revise them and turn them in with your code at the end of Project 1.
Thus, what I need to understand from you documentation includes (at a minimum):
a) Exactly what capabilities you plan to provide
b) Your technical approach to developing the system
c) Your planned schedule and resource allocation
a) This means that you need to write and deliver the sections of the SRS corresponding to the "concept document" so I know what you plan to build. If possible, you should also have started on the sections giving a more detailed specification of the required system behavior though this will not be complete.
b) You need to develop and document an initial software architecture for your system that is consistent with the requirements. This should give the basic breakdown into components.
c) You should have a pretty well developed project plan including a detailed schedule, milestones, and work breakdown. The plan should also address any perceived risk issues. The project plan in the "Mapster" example is a good model.
Due Dates:
Let's go with turning in your preliminary documentation on Monday, April 11th though I will take it earlier if you have it.