Your requirements establish a solid definition of what your project is all about. It is the basis for what your team will build.
On both 10/8 and 10/22, your assignment is to turn in this requirements document. The difference between what is turned in on these dates is details, clarity, improvements, and completeness. High level product specification This is largely a refinement of your project proposal. What's the big vision of your product? Who are the customers? What problem are you trying to solve? What alternatives/competitors currently exist? How is your product different? What is the "scale" of your product? How many customers/users are there? What are the major features you want to deliver? You should have most of this figured out by the 10/8 date. Users and use cases Who are the users of your product? How will they use it? What are the major scenarios? A scenario shows a sequence of steps that user takes to accomplish task. Text and/or pictures work well to describe users/use cases/scenarios. By 10/8, you should describe the users/actors in your system and describe the important use cases, at least at a high level. Detailed descriptions of users and use cases should follow in the 10/22 delivery. We'll discuss formats in class that make use cases useful. Feature specification What are the features that you will implement? By 10/8, you should understand the big picture of what the product should do. You have some details but it may be incomplete. But 10/22, you have drilled down into specific details of what you will be implementing. You should have a good idea of the "cost" to implement the features and have refined the feature list so that it is likely implementable by the end of quarter. Or, you should have some confidence that if things don't go well, what features you will drop and still have a successful project. It's possible that you have some high level requirements that you may have thought of and want to implement but don't have time. Further, you may or may not have done a detailed drill down. That's okay. It's good to have a "wish list" of things you want to do in the future, even though you haven't gotten to the details. Go ahead and list these too. I've found a detailed text description of all the features to be useful when accompanied by a summary table. The summary table lists out:
After 10/22, you may continue to add or drop features as you approach the first, second, and third releases. UI Diagrams/User Experience/User Design What will the UI look like? Submit diagrams containing rough sketches of your product's user interface and user experience. A "schematic" depicts the basic application flow. Pictures should should depict what the users will see "on their screen." Pictures should show the major UI components to be used on screen -- e.g. text boxes, buttons, scroll bars, sliders, etc. The schematic and pictures are a "prototype" to represent the users, use cases, and functionality. They should reflect forethought about what information needs to be shown and how the user will use the software. The diagrams can be drawn by hand or computer. It's likely the process to get to a schematic and pictures involves pencil, paper, a white board, and "sticky" notes. You may have used tools such as Powerpoint or Balsamiq. If you done things "by hand", photograph or scan them to PDF. Your diagrams do not need to be beautiful but they should be clear and legible. You need to decide on your "design assets" -- fonts, styles, colors, iconography, graphics. Beyond the "low fidelity" mockup of your project, you may choose to do a high fidelity mock up. This basically shows the prototype dressed up with all the design assets. If you do a high fidelity mock up, include it. However, you might decide to by pass the high fidelity mock and go straight to implementation from the low fidelity mockup. That's okay too. By 10/8, you should have some basis idea of the user experience/user interface will be. You've sketched out the basic user flow with paper/pencil and sticky notes. Perhaps you have some paper design mock ups. You may or may not have decided on the "design assets" -- the colors, fonts, iconography, styles, etc. that you will use. That might not come in until 10/22. By this time, your requirements describes all users, the (major) use cases, and all the major flows (if not all flows) expressed by the feature specification. You have a solid understanding of the application flow at this point. Product deliverables What exactly are you delivering as a product? If you are doing a consumer facing web application, this is pretty easy. A website. However, you should describe which browsers, operating systems, and mobile platforms you will support. If you are doing a software product, there are other issues. What's the install procedure? Is there documentation? Are you doing a source code release? How to turn in this in: You should give waynekyamamoto and meganca, tlehmann, and anton-github-username access to your wiki. You'll submit via Dropbox 1 or more URLS to access your requirements document(s). I've assumed that you'll be hosting your wiki on github. But if not, figure out how to give us access. Guidelines for 10/08 Milestone (These are hints about the minimum of what you should produce, use the aforementioned descriptions for more details)
Guidelines for 10/22 Milestone (These are hints about the minimum of what you should produce, use the aforementioned descriptions for more details) -- We're still evolving the guidelines; stay tuned
|
Classwork > Project Milestones >