07 Team - Design Document
Objectives
Plan the design of your app.
Instructions
Now that you have determined what you are going to build (features/requirements), have a basic idea of how an Android project is organized, and thought about some of the major components of your project, researching the biggest unknowns, it is time to work with your team to do a more detailed design.
While you will be producing a design document to turn in, the real benefit of this activity is to think through the different components of your system and how they will interact. And at an even more detailed level, you will identify the classes you will need, along with the public methods they will provide and a knowledge of what each of those methods should do. Once you have this design in place, you will be prepared to stub out the classes/methods, write unit tests, break up the coding tasks a little, and generally get to work on the project.
This design document itself should be professional in its appearance and content. It should contain the following sections. (The first few sections can be copied directly from your earlier feature requirements document, and tuned if necessary)
Design Document
Here is what your design document should contain:
Team contact information
An overview of the problem
A bulleted list of the core features and stretch goals from your requirements document
An overview of the design / approach
Here, you'll describe your overall approach to the problem including a description of the major, high-level components you will have, and how they will interact.
UML showing the classes you will have and the relations among them
User interface plans (likely showing some rough mock-ups)
As a gauge, consider that another member was going to be added to your team next week. Would they be able to read this document to come up to speed on what the project is and how you are going about it, to the point that they could be a valuable contributor?
Design Process Suggestion
A great way to get started with your design is to come up with as many "use cases" as you can for your project. Then, walk through each of these use cases, noting what the user might see and do, but also considering how the system will carry out the necessary actions.
Once you have a description of these use cases, you should be able to come up with some user interface designs and mock-ups. But also, look at the process you described for your system to carry out these actions. See if you can identify any nouns in the process, these can become classes in your class design.
For each of these nouns / classes, make a bulleted list of the responsibilities of each one. If you find too many responsibilities for a class, consider breaking it up into multiple classes, perhaps with a parent class that "has-a" child class or two. Then, look at the verbs, or things that the class needs to do to carry out the responsibilities.
If you cannot come up with every private method of every class at this point, that's ok, but you should try to be as accurate as possible about the public interface to help in coordinating the efforts of your team members. In other words, you need to agree on the interface between classes at this point, but the details of how the implementation will be done can be determined later.