Students should consider Heilmeier's Catechism when developing their proposal. They should also evaluate what type of business model will make their project sustainable.

Vision Statement
The product vision contains the information to enable the customer to verify that you understand the product's context and scope. It is informal and should include motivation and ultimate intent.

The key parts of the vision statement that you should include are the following:

• Motivation / Opportunity: Why are you building this product; that is, what is the problem being solved? Why not buy something off-the-shelf or use an existing open-source product? What is it that will set your product apart from others in the marketplace? Besides a text description, this section typically contains the following two tables:

Problem Statement

Product Position Statement

• Users: Who will be the users of your application? What do they want to do with your application? What computer experience or other expectations do they have?

• Feature List: What features must the product provide?

• Constraints: What factors constrain the solution to the problem? For example, product must use open-source libraries, must use .Net, must use mysql, etc. Are there cost and pricing constraints, installation and licensing limitations, dependencies on hardware etc.

Use Cases
Use Cases are used to specify how external actors (human or other systems) will interact with your system. You can derive use case from the Feature List of the Vision Statement. For each iteration, the use cases for that iteration will be detailed.

The key parts of a use case are the following:

• Identification: A short text description of the use case and a number that allows you to uniquely identify the use case. If use cases are decomposed, then you should use a dot number scheme to relate similar use cases together. For instance, if Use Case 3 is decomposed, it would into 3.1, 3.2 etc.

• Primary Actor: This identifies the primary external actor that would interact with the system using this use case.

• Stakeholders and Interests: This lists all the stakeholders that are impacted by this use case and what their interest in the use case is. This information helps you put the use case into perspective, so that when you design the system, it will meet the goals and concerns of the organization.

• Preconditions: What has to be true before this use case can occur? Usually this references another use case that must have been accomplished before this use case can be performed.

• Postconditions: What is true after this use case is completed? How has the state of the system (as seen by the user) changed?

• Main Success Scenario: This is the interaction between the user and the system enumerated as a series of actions ordered by time. This scenario assumes that everything operates normally. The language should always be in terms of the user and not in terms of the implementation.

• Extensions and Alternative Flows: Here is where we account for things going wrong during the scenario. These are usually keyed to the steps in the Main Success Sceanario that they relate to.

• Open Issues: As you are writing the use cases, you may run into a situation where you are unsure how to handle something, or how something should be done. This section is a record of questions so that they can be clarified when you review the use cases with your customer.

Thanks to Georgia Tech's Computing for Good course for the Vison Statement and Use Cases template.