Due: Monday, Apr 13, 2015, 11:00pm
The goal of this assignment is to establish a solid definition of your project from which to base a design and implementation.
Congratulations! Your team has been funded to produce a software product. The customer hiring you to complete the project is a conglomerate, CSRocks Inc., which includes the CSE 403 staff, who will meet with you periodically to discuss and evaluate your progress.
Now, you need to define the project, as a basis 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.
Note that this document will be a living document. You will be asked to provide updates to it at periodic points in the development cycle. Furthermore, parts of it are an update to your proposal.
You will submit 4 brief documents.
The product and process descriptions together should be 4-6 pages total. There is no page limit on the UI diagrams and use cases, but don't overwhelm the TAs. The meeting reports should be well under a page.
Only one person from your group should submit your deliverables. Choose a short project name for your group. Submit a single ZIP file named TeamName_PhaseName.zip — for example, PacMan_SRS.zip. Each document inside the ZIP archive should use a similar name that reflects its contents, such as PacMan_use-cases.zip. You may receive a deduction if you turn in clumsily named or poorly organized files. Make sure that your project's name and all group members' names and CSE NetIds appear clearly atop each document. Don't forget to add your project website URL to the wiki.
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:
The product should be as usable as possible, even for people who are not expert computer users (with the exception of projects that are designed specifically for experts, such as software development tools).
The product must be robust against errors that can reasonably be expected to occur, such as invalid user input, lost network connections, etc.
The product must be installable by a user, or if the product is a web-based service, the server must have a public URL that others can use to access it. If the product is a stand-alone application, you will be expected to provide a reasonable means for others to easily download, install, and run it. Your instructions should assume that your target user is using a UW CSE Linux VM.
The software (all parts, including clients and servers) should be buildable from source by others. If your project is a web-based server, you will need to provide instructions for someone else setting up a new server. Naturally, your system should be well-documented to enable new developers to make enhancements.
The scope of the project must match the resources assigned.
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.
There may be a late-breaking requirement added sometime in the project lifecycle.
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 4 major features you will provide, along with at least 2 “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.)
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. By “diagram” we mean 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.
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 (in which case the total file size must be less than 500KB per page). 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 grader/customer understand how to “use” your prototype, it would be helpful if you labeled which items and sheets go together, for example, with numbers or names. 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.
(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 user interface ideas, see how they work, and revise/modify the UI as needed. By being concrete now, you will make discoveries early and at relatively low cost.)
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 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.
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.
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 (give a milestone, such as by 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 you may no use “feature cut” as all of your mitigation strategies: 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.
You will be required to have regular (weekly or semi-weekly) meetings with the course staff, but you may schedule additional meetings if you like. A staff member will contact your team to set up a weekly 20-min minute during their office hours.
The course staff serves as both customer and mentor. When you have a meeting with your TA, you are allowed to ask the TA to serve any of these roles, or even to switch roles during the meeting. As customer, the TA can help you to determine what a reasonable set of requirements are, and whether your documents and prototypes are compelling. As mentor, the TA can help you to resolve conflicts or give suggestions about designs, teamwork, and tools. Don't forget or underuse either of these roles.
It is a bad idea to try to hide information from your customer (or, for that matter, your TA). 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 your TA. Instead, use the TA as a resource to help solve your problems.
You are required to maintain a development website for your group, which must include (at a minimum)
After your zero-feature release, you must also include
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 may build as part of your product.
You must provide the URL to your website in your requirements document, and link to it from the class wiki.
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.
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.
Be aware that 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.
If you have specific software/hardware needs, talk to the course staff as soon as possible, and they will try to accommodate you.