The goal of this milestone is to establish a solid definition of your project on which to base a design and implementation.
Due: Tuesday April 10, by 11:00PM
Congratulations! Your team has been funded to produce a software product. Your customer is a conglomerate, either KNOW++ (executives are Notkin, Curran, Beyer, and Trebacz) or The Idea Works (Notkin, Muşlu, and Osobov), who will meet with you periodically to discuss and evaluate your progress. The most important next step is to pick a short and manageable name for your team!
Now, you need to define the project, based on the proposal, as a foundation for your later design and implementation. Your first deliverable is a set of requirements documents (sometimes called “Software Requirements Specification” or SRS). These describe the goals of your project and how users will interact with it (the high-level UI design). You will also document your plans for completing the project. This is a living document that you will update at periodic points in the development cycle.
You will submit five documents: (1) a product description; (2) UI diagrams; (3) use cases; (4) a process description; and (5) customer meeting reports. The product and process descriptions together should be roughly five pages total. There is no page limit on the UI diagrams and use cases, but don't overwhelm the executives. The meeting reports should be well under a page.
Only one person from your group—the program manager (PM)—will submit your deliverables (for this and for every milestone and weekly report); more details later.
While the customer likes the high level features outlined in your proposal, they are happy to leave the next level of refinement to you. They do, however, have the following requests:
Beyond these requests, you are largely free to take the next turn of the product development spiral and firm up your product requirements. This requirements document will essentially be a contract with CSRocks for what you plan to deliver. Consequently, you should talk to your customer as you plan in order to make sure your product meets their needs. Customers occassionally change their minds about some aspect of a project in midstream, so there may be a late-breaking requirement added sometime in the project lifecycle.
Product Description
You can think of this as an enhanced and refined version of your product proposal. What is your product? Who is the target audience you expect to use the product? What problem does it solve?
What alternatives exist, and what are their strengths and weaknesses? How will your system be different, from the user's point of view? Be specific
What are its major features? Include at least four major features you will provide, along with at least two “stretch” features you hope to implement but that could slip to version 2.0 if necessary.
What are its non-functional requirements?
What external documentation will you provide that will enable users to understand and use your product? This could take the form of help files, a written manual, integrated help text throughout the UI, etc. (You will separately produce other documentation such as: administrator documents about how to install/customize your system, developer documents such as design rationale and alternatives, and code comments about both your interfaces and implementations. We are not asking about those here.)
UI diagrams
What will the UI look like? Submit diagrams (at least two, possibly more) containing rough sketches of your product's user interface, when executing your use cases. A “diagram” is a depiction of a complete major screen, web page, window, etc. of your system. You should show at least all screens that a user would see when executing your use cases. From looking at these UI diagrams, the customer should be able to clearly see how your product will be able to successfully complete each use case you are submitting. Your group will not be “locked in” to using the exact UI represented by these diagrams on your actual final project. The purpose of a prototype is to try out a set of user interface ideas, see how they work, and revise/modify the UI as needed.
These diagrams should depict the major UI used to complete the use cases you submit. For example, if one of your use cases is to Purchase Tulip Bulbs, you should draw the initial UI that is presented when the user wishes to purchase a tulip bulb, along with any other major windows, messages, etc. that appear as the user navigates through this use case. If a window leads to a dialog box, drop-down box, etc., include it as a sub-diagram.
The diagrams can be drawn by hand or computer. If you draw them by hand, scan them to PDF. Your diagrams do not need to be beautiful to get full credit, but they should be clear and legible. They should reflect forethought about what information needs to be shown and how the user will use the software. Part of your grade comes from choosing appropriate UI elements to effectively accomplish the desired task.
To help the customer understand how to “use” your prototype, make it clear which items and sheets go together, for example, by putting numbers or names on the back of papers. For sub-diagrams such as pop-up windows, drop-down boxes, etc., it is helpful to put a corresponding number/name in the place that sub-diagram appears. If there is anything non-obvious about how your UI is used, you may include brief written instructions about how the user is expected to walk through the UI.
Use cases
Submit at least three use cases for scenarios you think are the most important to your product. Make a brief, informal argument that your set of use cases covers the important scenarios (perhaps by referring back to the product description). Remember that it is not useful to drown the reader in boring details.
The format of the use cases is up to you, but these aspects must be clear: actors, preconditions, triggers (what starts the use case), minimal/success guarantees (end condition), the list of steps to the success scenario, failure end conditions, and extensions/variations of the scenario.
Also discuss failure-handling remedies as appropriate (or a state that you do not have one and what you specific steps you will take to generate them). It is impossible to think of every possible use case or failure mode ahead of time. But you should list a reasonable set of extensions and remedies if reasonable ones exist.
Process
Software Toolset: What programming languages, data sources, version control, bug tracking, and other tools will you use? What, if any, software components will you attempt to use “off the shelf” versus implementing them from scratch? Explain why you chose these tools and languages, as well as why they are suitable for use on this project.
Group Dynamics: For the most part, your group organization is up to you. However, we require that you choose a single person to serve as your Project Manager (PM). Who will be your project manager? What will be the other members' roles? Will everyone share in the development, or will you have designated designers, testers, etc.? Why have you chosen these roles? Will the roles differ for different parts of the project? (This may require you to think a little bit about how your system will be implemented.) If a disagreement arises, how will it be resolved? Be specific. Also justify your decisions by briefly explaining why you have chosen this structure. Consider how resilient the structure is if somebody gets sick, or drops the course, for example.
Schedule / Timeline: Provide a rough schedule for each member or sub-group within your team. For example, how long do you believe your developers will spend working on each major feature listed in your product description? Who will work on the design, and how much time do you expect it will take? For each feature, when will it be complete (e.g., for the beta release)? Provide reasonable guesses as much as possible. You will not be graded on the accuracy of these predictions. You will, however, be graded on their reasonableness, completeness, and justifications.
Risk Summary: What are the major risks (at least three of them) regarding completing your project? What are you most worried about, and why are these the most serious risks? Describe specific experiments that you will perform to gather information that will reduce the risk. Also describe what you will do if you are unable to overcome the problems — for example, if you cannot get an external component to work, or if you fall behind schedule. This might include feature cuts, but not every one of them may be a feature cut: others might include adjusting your group dynamics, time schedule, testing, etc.
As a special case of risk reduction, describe at what point(s) in your process feedback from an external user evaluation will be most useful, and how you will get that feedback.
Customer meeting report
You are required to have discussions with your customers. Don't forget to schedule these meetings well in advance! You may find it helpful to give your customers a draft of your product requirements before you meet with them. Every team member is required to attend at least one of the two customer meetings for this assignment but not every team member needs to be at every meeting. The reports are generally short, with a paragraph describing issues that were raised by your customers during the meeting and one on your high-level plans for addressing these issues.
Your Team TA
One of the TAs will be specifically assigned to your team as a combination of customer and mentor. As a customer, they will provide some feedback in between customer meetings; but be careful, especially if KNOW++ is your customer, since the TAs aren't up to speed on KNOW. Notkin and Beyer will be available to play the in between role of customer as well for KNOW++ projects. You should plan on weekly or biweekly meetings with your assigned TA (plus others as needed); they can, for example, meet with you on Tuesdays during the scheduled "group meeting" time; let them know where you meet.
As a mentor, the TA can help you to resolve conflicts or give suggestions about designs, teamwork, and tools. The instructor can, as well.
It is a bad idea to try to hide information from your customer or the staff. If things are going poorly or you are having trouble, be upfront. You may get good suggestions, and the customer won't feel blindsided if you are unable to resolve the problems on your own. It is a doubly bad idea to try to hide problems from the staff. Instead, use the staff as a resource to help solve your problems.
Group Website
You are required to maintain a development website for your group, which must include at least:
You are free to build and host this website in any way you like, and to include other information. Our recommended software tools might be useful. Note that this developer-focused website is separate from any user-focused website that you will build as part of your product.
You must provide the URL to your website in your requirements document, and make sure we link it from the projects page.
Intellectual property
Your group will collectively own its own work. There are consequences of using third-party software, such as libraries or other components. Read the license. Be especially careful if you are working on a KNOW++ project. If you think you may want to commercialize your project, our advice is to consult early with a legal source. Two resources on campus are the CSE commercialization committee (contact Ed Lazowska), and the UW Center for Commercialization (C4C) The number of groups interested in commercialization is dramatically higher than the number of groups who end up with a commercializable idea and implementation. So, have realistic expectations, and our recommendation is to focus in 403 on what you learn, not what you might earn.
Part of your grade will come from the plausibility, thoughtfulness, and level of detail of your work. For example, if you are listing features, take care not to forget important aspects that would reasonably required of a project such as yours. When listing software tools, list a plausible set of tools for all aspects of the project and defend your choices. When listing group dynamics and a schedule, choose a group strategy that makes sense for your team and for the time given.
In use cases, sloppy or incomplete work often leads to deductions. We want to see that you have given due thought by choosing substantial use cases that are important to the core functionality of your product. You should also list a reasonable set of steps in the various scenarios that can occur in these use cases. Take care not to omit important steps or details. Make sure that the state of the system at the end of any path through the use case matches the guarantees that the use case claimed would occur.
Your documents must be clear and professional-looking: your customers should be able to read them and extract information from them. This means they should be clearly written in a professional writing style in complete sentences as appropriate, with proper spelling and grammar, clear wording, and formatted with a enough organization to present your ideas clearly to the reader.