Before you Write it Down
Remember to keep in mind your audience when composing the document.
Who is your audience?
yourself: writing is likely the most effective method for clarifying and focusing your thoughts
your team: this document is the place to forge a common vision for where the project aims
your project partner: your partner should help formulate the document and can also throw it back if it doesn't capture his or her vision
your technological heirs: Many projects will persist as other teams take the baton and develop your ideas further. Make sure that your ideas are clear.
Your paper begins here. Please note, we are focused on content, not word counts here. Also, we'll be evaluating this assignment using the same rubric from Milestone 1. Finally, this paper is written as a group, and everyone in the group will receive the same group grade.
Section 1: Background
The background describes the current conditions, existing systems, problems and pertinent history of where the project is today. It should provide enough context such that the vision statement can be clear, concise and well understood.
If needed, please include any special definitions, concepts, or terms in this section. Be sure to name the project partners, their stakeholders, or anyone else outside of Capstone who is on the team in this section. There is no word count for this section, and you should write in paragraphs using subheadings for the sake of clarity.
Section 2: Vision
In this section, you will answer the question: What is life like when the problem is solved? The vision statement consists of prioritized goals for the project and the project partner. In this section, summarize your project outcomes, not technical solutions which are described later in the scope section. Write one paragraph or more summarizing a high-level of your project outcomes.
2.1. In addition to the vision, please write two central hypotheses:
Growth hypothesis: What are the reasons that make users adopt your product or service? The growth hypothesis is a way to test how new users will discover your product or service.
Value hypothesis: What makes your product or service beneficial? The value hypothesis is a way to test whether your product or service really delivers value to customers who use it.
2.2 Also, please list some high-level requirements, as articulated by your project partner. These would include:
Functional requirements - Description of what your system or project can do, the function of your system, project or software. It defines the basic system behavior and Explains what the system should or shouldn’t do.
Non-functional requirements - While functional requirements are about what the system does or must not do, non-functional is a description that specifies how the system should do it or how well the system should function.
Section 3: Prioritized Project Constraints
All projects are constrained by the three components: time, resources and scope. At this point in the project you will not have a detailed understanding of these components. However, consider and write what little you do know about the following potential constraints:
TIME: unlimited < --to-- > severely limited time
Consider and describe where the project is with regard to time and resources, and consider what is a reasonable scope. First, write a few sentences or more about the Capstone timeline, your weekly time allowance to work, and the extent to which you'll be limited. You may also consult with the project partner about their perceptions of time and related constraints.
RESOURCES: Bill Gates' budget < --to--- > no budget
Next, describe what resources you know are available to you and what you predict you might need. In this section, you might want to estimate the types of resources that might need to be purchased and provide a justification. Again, you'll want to consult with your project partner about resources available to you, whether human or financial. You won't have all the information yet, but you may have some ideas to write here.
SCOPE: every conceivable feature <--versus--> minimal deliverable
In this section, you'll want to talk about some constraints in scope. Again, you will likely look at time and resources and make some boundaries around what you think you may or may not be able to deliver. It's important to continually talk with the project partner about why they want a feature or certain functionality. It helps you manage expectations, as discussed in Mark Clement's lecture.
Section 4: Scope
In this section, you will be describing the scope of your project. The scope is what is to be achieved. Please describe your scope as Process Flows (see below, 4.1) and the User Stories (see below, 4.2).
4.1 Process Flows: In this section, you will be mapping process flows. To do this, think through the problem. Then, zoom out and describe the major components of the project. Finally, distill that abstract solution or those components into a visual representation, like a cross-functional work flow of UML activity diagram. Here are some different abstractions, each with its own flavor. (Thank you Wikipedia. We'll provide more links from IEEE or another source very soon...).
https://en.wikipedia.org/wiki/Business_process_modeling (Links to an external site.)
(Links to an external site.)
https://en.wikipedia.org/wiki/Use_case_diagram (Links to an external site.)
(Links to an external site.)
https://en.wikipedia.org/wiki/Activity_diagram (Links to an external site.)
(Links to an external site.)
https://en.wikipedia.org/wiki/Unified_Modeling_Language (Links to an external site.)
(Links to an external site.)
4.2 User Stories:
In this section, you will write some initial user stories to get started. Recall that the Agile philosophy and Scrum practices state that it is best to form of user stories when starting your sprints. User stories are approachable from a development point of view.
When you write your own user stories, please use the following form and number them.
“As a …. (user, customer, machinist, principal)"
"I need … (to automate a task, a way to calculate, a picture of something)"
"so that… ( I can work quicker, I can learn, I can direct workers…)"
When writing these user stories, also consider the potential stakeholders in the project. The list of stakeholders should include, at a minimum, the groups of end users of the final product, the sponsor of the project (the client or project partner) and the development team(s) of the project. We encourage you to write at least one user story for each of the stakeholders.
Please note: The collection of User Stories becomes the Product Backlog from which you will organize your subsequent sprints.
Section 5: Iteration Plan and Estimate
In this section, describe and estimate your iteration plan for the next few months. This plan will change as you learn more information about the product you're working on and as you populate your project backlog. In other words, in this section you will attempt to describe each Sprint as best you can and the reasonable fraction of the project backlog that will be delivered in each based on what you currently know. Realize that you will be updating your iteration plan as you learn more information and run into problems.