Guidelines for the 1st iteration

Grading for the first iteration will be based on the criteria described below. You can see that the first iteration is being graded only with regard to paperwork, but this should not discourage you from already digging into the technical details. You have a lot to implement during the course, so it is strongly recommended that you start early.

The most important is to build something that is useful for the customer/end users. If you are not going to deliver a useful and bug-free application, no amount of paperwork is going to save you.

PRODUCT VISION

The Product vision describes the purpose of a Product, what it aims to achieve for customers and users. Having a clear and inspiring Product vision helps in motivating and inspiring people, like the Project Team, the customers, and the users. To be able to create the Product Vision, you need to try to answer the following questions:

• What is the product to be developed? What type of system it will be (e.g. a Web API, a Web frontend, a mobile app, a desktop app?) and what will the system allow its users to achieve? Additionally, what makes this product different from competing products? Knowing the type of the system to be developed will help the development team understand the target customer and some of their goals as well as technical issues.
• Why should customers buy this product? What problem it will solve or what opportunity is it meant to exploit? The team needs to clarify the problem that the project is intended to solve by focusing on key points such as Problem description, Impact of the problem, and Expectations of the successful solution.
• Who are the target customers and users?

It’s important to identify the Users but also the other Stakeholders of the system, as the latter may also positively or negatively be affected by the project outcome. So every stakeholder should be identified together with their influence and role in the project.

The "Product Vision" should be written as a separate entry in the Wiki. It should separately include the answers to the abovementioned questions, and it should also be summarized in the form defined by Moore's template, provided here: FOR (target customer) WHO (statement of the need or opportunity) The (PRODUCT NAME) is a (product category) THAT (key benefit, compelling reason to buy) UNLIKE (primary competitive alternative) OUR PRODUCT (statement of primary differentiation)

FUNCTIONAL REQUIREMENTS - HIGH LEVEL - USER STORIES

Break the functionality of the product into a set of functional requirements, at higher level (from the customer perspective), by using User Stories. Reading the set of high-level functional requirements is expected to give a clear understanding of what the system will allow its users to do. This set of requirements is structured in a logical manner. For example, if you list 20 functional requirements, it is expected that they are organized into a few groups in a logical manner. Also, it is expected that there is some logic behind the order in which the functional requirements are listed. Use the Wiki section (of Gitlab, for example) to define them.

Prioritize the requirements as must-have, should-have, could-have, or won't-have.

"Functional requirements - High level" should be written as a separate entry in the Wiki.

USE CASES

For every subset of requirements (user stories) that you decide to move to an iteration or sprint backlog for development, you need to make these requirements more specific and detailed by using use cases. Usually, a use case corresponds to one or more user stories. During Iteration 1, at least two of the core high-level functional requirements should be detailed as use case specifications. With core functional requirements, we don’t mean ones such as Login or Logout, but something that directly contributes to the primary workflow. It could be for example “Create Prescription”. On the other hand, it shouldn’t be too broad such as “Manage Prescription”.

"Use Cases" should be written as a separate entry in the Wiki.

NON-FUNCTIONAL REQUIREMENTS

Provide a list of the most important non-functional requirements. Your list should include at least seven measurable non-functional requirements. Note the requirements down in the Wiki, preferably in the form of user stories. Reading the requirements is expected to give a clear understanding of how you are going to measure whether the system satisfies a given requirement.

Non-functional requirements also include the initial architectural choices, listing what technologies you are going to use in order to complete the project.

Prioritize the requirements as must-have, should-have, could-have, or won't-have.

PROJECT PLAN

First version of the project plan should be present in the Wiki/Issue tracker. It should contain the following at minimum:

• Project roles. Define each team member role and their assigned responsibilities.
• Communication means. Your Project Plan should include the means of communication among the team members but also between the team and the customer, as well as the time and place of communication.
• Work process. The following need to be defined regarding your work process:
  • How and using what materials the customer is going to understand what you are going to build
  • How do you determine that the customer is accepting your solution proposal
  • How you are internally going to build the accepted solution (who assigns the tasks, who is going to implement it, will the tests be written, will code be reviewed, who is going to verify, who is doing the validation, etc.)
  • When do you consider something ready to be delivered to the customer for review
  • How do you gather feedback from the customer and/or end users.
  • What is the definition of DONE on a task
• Scope. List of all the main tasks/items you currently foresee need to be delivered in order to complete the project. Tasks/items are planned into iterations, given priorities, and they contain initial estimation about the amount of work involved. Once you finish an iteration, the actual times spent should be mentioned. Tasks/items for iterations 1 and 2 should be presented in detail, including sub-tasks, priorities and times. Tasks/items for iterations 3 and 4 are expected to be presented in less detail. Later iterations might not be clear enough to have their tasks broken down according to your current knowledge of requirements, so you can keep these tasks written simple or refine them a little bit if possible.
  • The tasks of the second iteration are defined at the proper level of granularity (90% of tasks take less than 16 hours, no task is larger than 40 hours).

COLLABORATION INFRASTRUCTURE - VCS

VCS should be in use. The repository should be created with the basic project structure in it - meaning you have thought through how you structure your code, libraries, documentation, etc. you are about to keep in the VCS.

There should be a trace of at least five commit/push operations from several project members in the repository. There should be a trace of links between the tasks in issue tracker and code in VCS. The mentor must be able to access the VCS in read-only mode.

COLLABORATION INFRASTRUCTURE - WIKI

Wiki (well, most likely a wiki, but alternatives are also possible) should be in use. The requirements should be entered in the Wiki. At least two of the functional requirements should be detailed in the selected format (use case specification). Links between detailed requirements and tasks in issue tracker should be present. The minutes of at least the first meeting with the customer should be in the Wiki. The mentor must be able to access the "wiki" in read-only mode. The wiki should be logically structured. It should be easy for the mentor to find the deliverables of iteration 1. There should be a description of the project in the front page.

Collaboration Infrastructure - Issue Tracker. Issue tracker should be in use. Tasks should be opened/assigned/closed during the first iteration. Tasks for the 2nd iteration should be entered and assigned to team members, given priorities, have assignees, detailed descriptions, and they contain initial estimation about the amount of work involved. Tasks in issue tracker should be linked to the corresponding user stories and use cases, where applicable. The mentor must be able to access the issue tracker in read-only mode.

Other deliverables in this iteration may include a Use Case diagram, including at least the two use cases for which their detailed description will be specified, as well as a sequence diagram and an activity diagram for each of the aforementioned use cases. Additionally, a class diagram and database design may be parts of this iteration. However, apart from the Use Case diagram, the rest of the diagrams and database design may be planned for the next iteration or may be refined during that if started in the first iteration.

And after you have done all of the above, please make it easy for your mentor to find everything from your Wiki.