Documentation:

• User Guide:
  Start drafting a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v2.0. Which means, you can include commands that you may not implement in the project.

  • We recommend that you follow the reference project's User Guide in terms of structure and format.
  • As this is a beginning draft, don't waste time in formatting, copy editing, etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
  • However, do try to come up with concrete command syntax for feature that you would implement (at least for those that you will implement by v1.4).
  • Include a mock-up of how your interface may look (e.g., either GUI or CLI landing screen). (GUI mock-up can be hand-drawn or created using a tool such as PowerPoint or Balsamiq).

• Developer Guide:
  Update the developer guide (target user profile, user stories, use cases, and non-functional requirements) based on the feedback from your tutors.

Admin pages:

• Create the About Us page:
  Use this page from the reference project as a reference for the format. We need this page for module admin purposes. Please follow the format closely or else our scripts will not be able to give credit for your work.
  • You may copy the page and replace info of SE-EDU developers with info of your team, including a suitable photo as described here.
  • Including the name/photo of the supervisor/lecturer is optional.
  • The photo of a team member should be docs/images/githbub_username_in_lower_case.png e.g. docs/images/johndoe.png. If you photo is in jpg format, name the file as .png anyway.
  • Indicate the different roles played and responsibilities held by each team member. You can reassign these roles and responsibilities (as explained in Admin Project Scope) later in the project, if necessary.

• README page: Update it to match your project.

  • Add a UI mock-up of your intended final product.
    Note that the image of the UI should be docs/images/Ui.png so that it can be downloaded by our scripts. Limit the file to contain one screenshot/mock-up only and ensure the new image is roughly 1280px X 1024px in size. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.

  • The original README file (which doubles as the landing page of your project website) is written to read like a setup instructions page. You should restructure this page to look like the home page of a real product (not a school project) targeting real users.  e.g. remove the section on feedback and reference to duke issue tracker

Project Phase 2

• Step 0 : Identify the target user profile and the problem you are solving for the target users

  Decide on the project direction (e.g., enhance or morph?)
  Document these details in the introduction section of your developer guide.

• Step 1 : Brainstorm user stories

  

  This is a good time to analyze requirements with a view to conceptualizing the next version of the product (i.e. v2.0).

  Get together with your team members and brainstorm for user stories  for the v2.0 of the product. Note that in the module project you will deliver only up to v1.4 but here you should consider up to v2.0 (i.e. beyond the module).

  • It is ok to have more user stories than you can deliver in the project. Aim to create at least 30 user stories. Include all 'obvious' ones you can think of but also look for 'non obvious' ones that you think are likely to be missed by other teams.

  • Refer [Textbook Specifying Requirements → UserStories → Usage → (section) Tips] for tips on how to use user stories in this task.

  • You can write each user story in a piece of paper (e.g. yellow sticky note, index card, or just pieces of paper about the size of a playing card). Alternatively you can use an online tool (some examples given in [Textbook Specifying Requirements → UserStories → Usage → (panel) Tool Examples ]).
    

  • Note that you should not 'evaluate' the value of user stories while doing the above.  Reason: an important aspect of brainstorming is not judging the ideas generated.

 

Requirements → Specifying Requirements → User Stories →

Introduction

User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. _{[Mike Cohn]}

A common format for writing user stories is:

User story format: As a {user type/role} I can {function} so that {benefit}

Examples (from a Learning Management System):

1. As a student, I can download files uploaded by lecturers, so that I can get my own copy of the files
2. As a lecturer, I can create discussion forums, so that students can discuss things online
3. As a tutor, I can print attendance sheets, so that I can take attendance during the class

We can write user stories on index cards or sticky notes, and arrange on walls or tables, to facilitate planning and discussion. Alternatively, we can use a software (e.g., GitHub Project Boards, Trello, Google Docs, ...) to manage user stories digitally.

^{[credit: https://www.flickr.com/photos/jakuza/2682466984/]}

^{[credit: https://www.flickr.com/photos/jakuza/with/2726048607/]}

^{[credit: https://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png]}

• a. They are based on stories users tell about similar systems
• b. They are written from the user/customer perspective
• c. They are always written in some physical medium such as index cards or sticky notes

• a. Reason: Despite the name, user stories are not related to 'stories' about the software.
• b.
• c. Reason: It is possible to use software to record user stories. When the team members are not co-located this may be the only option.

Critique the following user story taken from a software project to build an e-commerce website.

As a developer, I want to use Python to implement the software, so that we can resue existing Python modules.

Refer to the definition of a user story.

User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. _{[Mike Cohn]}

This user story is not written from the perspective of the user/customer.

Bill wants you to build a Human Resource Management (HRM) system. He mentions that the system will help employees to view their own leave balance. What are the user stories you can extract from that statement?

Remember to follow the correct format when writing user stories.

User story format: As a {user type/role} I can {function} so that {benefit}

As an employee, I can view my leave balance, so that I can know how many leave days I have left.

Note: the {benefit} part may vary as it is not specifically mentioned in the question.

• Step 2: Prioritize the user stories

  

  Suggested workflow:

  • Take one user story at a time and get team member opinions about it.

  • Based on the team consensus, put the story (i.e. the piece of paper) onto one of these three piles:

    • Must-Have : The product will be practically useless to the target user without this feature.
    • Nice-To-Have : The target user can benefit from this user story significantly but you are not certain if you'll have time to implement it.
    • Not-Useful : No significant benefit to the target user, or does not fit into the product vision.

  • If using physical paper to record user stories: After all stories have been put in the above three piles, you can make a record of which stories are in the three piles.

  • Step 3: Document requirements of the product

    Based on your user story categorization in the step above, given module requirements/constraints for the project, and the current state of the product, select which user stories you are likely to include in v2.0.

    Document the following items using a convenient format (e.g., a GoogleDoc).

    • Target user profile, value proposition, and user stories: Update the target user profile and value proposition to match the project direction you have selected. Record the list of the user stories, including priorities in the correct format (It is suggested to use a tabular format similar to the examples shown in the lecture). This can include user stories considered but will not be included in the final product.
    • Use cases: Give use cases (textual form) for a few representative user stories that need multiple steps to complete. e.g. Adding a tag to a person (assume the user needs to find the person first)
    • Non-functional requirements:
      Note: Many of the project constraints are NFRs. You can add more. e.g. performance requirements, usability requirements, scalability requirements, etc.
    • Glossary: Define terms that are worth defining.
    • [Optional] Product survey: Explore a few similar/related products and describe your findings i.e. Pros, cons, (from the target user's point of view).