Project Iteration 1: Requirements

In this iteration you are to give the requirements your project should meet, and an outline of the planned architecture. Refer to the lecture notes and the HFOOA&D book for more details on the requirements capture process.
Components of your group's submission must include the following. Structure your document to have section headers being the names in bold below (you can of course include more sections).
  1. Include your names, group number, and project title.
  2. Begin with a Vision Statement summarizing your project
  3. Write a Feature List, to help flesh out the vision statement. Features you will leave for later iterations mark as extended features. If the domain the project is working over is something not common knowledge, include a Domain Analysis along with your features -- Domain analysis was covered in lecture.
  4. Include UI Sketches (aka storyboards/mocks) of key UI elements to help express your vision. If it is a phone app you are encouraged to use one of the many nice storyboarding tools for this. Focus on the non-trivial aspects of the app, not the obvious features such as login or change password.
  5. Key use-cases You don't need to write a long list of use-cases; instead we want use-cases only for complex multi-step processes which are not obvious from the UI sketches. For example, "login" in most applications is a self-explanatory process so you do not need to make a use-case for it. Also if your storyboards/mocks clearly show the stepwise sequence there is no need to repeat that information in a use-case. If you don't have any key use-cases it is a sign your project is too data-centric: it has no interesting algorithms in it.
  6. Give a proposal for the Architecture: Describe the major packages, components, and your proposed deployment methodology. Include a listing of Frameworks, libraries, tools, etc you plan to use in this section.
  7. While no code is required for this submission, you should be downloading and installing various frameworks you have not used before, reading the documentation on how to use those frameworks, installing, running, and playing with provided demo examples, etc. You are also encouraged to develop one-off prototypes if you need to check feasibility of a design idea.
  8. If your project is a variation on an existing application, mention somewhere the application and describe how you plan to make your project different.
Make sure you have been thorough in your requirements. Some common incompletenesses include:
  • Your overview is incredibly vague and lacks concrete features or requirements that show you put some real time into thinking about your design.
  • Features apparent from the vision statement and UI sketches are missing from the feature list, or key features are not appearing in any UI sketch.
  • An important sequence of actions is not made clear in either UI sketches or a use-case.

Assembly / Submission

  1. Every group will be given a GitHub repository specifically created for your project. You will need to use the GitHub wiki feature for that repository to develop and present your requirements. The Course git page gives more information on git and GitHub.
  2. Make a separate wiki page called Requirements so we will know where to look. You will be following it with a page for iterations 2 called Design; for iterations 3-6 the wiki will not be used.
  3. The wiki is in fact in a separate git repository such as 2018-group-3.wiki, so clone etc all the usual git operations to synchronize on wiki edits
  4. The GitHub wiki text is formatted with markdown, a largely self-explanatory format. See e.g. Adam's Markdown Cheatsheet for a few tips.
  5. You will need to make a well-organized and readable wiki.
  6. For UI sketches, you can scan them in if drawn by hand, or you can use a tool. All that matters is that they are easy to read. Some good UI prototyping tools are listed on the course tools page.