Due: Wednesday April 15, by 9:30am
Congratulations! Your team has been funded to produce a software product. The customer hiring you to complete the project is a conglomeration, CSRocks Inc., which includes the executives (Ernst, Beall, and Shawcroft) and upper-level managers (another team of the class), 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. And parts of it are an update to your proposal.
Submit a document, 4-5 pages in length not counting the UI diagrams or use cases, that answers the questions in the "Product Description" and "Process" sections below.
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 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 install and run it. You can expect that the user will have installed any necessary libraries and tools (such as a Java Virtual Machine, or a Ruby framework runtime, or a simulator for a mobile device), but after that, the user should be able to download and run your system easily.
The product ultimately be made open source. As a step towards this, the software should be buildable from source by others, and well documented to enable new developers to make enhancements. If your project is a web-based server, you will ultimately need to provide instructions for someone else setting up a server. Documentation will include design documents, test cases, and bug reports.
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.
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 is it solving?
What alternatives exist, and what are their strengths and weaknesses? How will your system be different, from the user's point of view?
What are its major features? Include at least 4 major features you will provide, along with at least 2 other minor features or aspects you hope to complete.
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 developer documents such as design rationale and alternatives, and also 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. 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 Stocks, you should draw the initial UI that is presented when the user wishes to purchase a stock, along with any other major windows, messages, etc. that appear as the user navigates through this use case. The diagrams can be drawn by hand or computer. If a window leads to a dialog box, drop-down box, etc., include it as a sub-diagram. Your diagrams do not need to be pretty to get full credit, but they should be clear and legible. The main point is to illustrate your thoughts about what informtation should be shown and how the user will use the software.
Submit at least three use cases. These do not count against the page limit. The format is up to you, but these aspects must be clear: actors, preconditions, minimal/success guarantees, the list of steps to the success scenario, extensions/alternatives/failures, and failure-handling remedies as appropriate (or a statement that you do not have one and what you will do to generate one). It is impossible to think of every possible use case or failure mode ahead of time, and not useful to drown the reader in boring details. Make a brief, informal argument that your set of use cases covers the important scenarios (perhaps by referring back to the product description).
Software Toolset: What programming languages, data sources, version controli, bug tracking, and other tools will you use?
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, but If a disagreement arises, how will it be resolved? Be specific.
Schedule / Timeline: Provide a rough schedule for each member or sub-group within your team. For example, how long 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? Which features are “beta” features? Provide reasonable guesses as much as possible, but you will not be graded on the accuracy of these predictions.
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.
Change log: 4/11 - Clarified bug tracking requirement and need for install instructions for web-based server projects.