Lab 1 - Requirements Gathering

General Info

1. Homework must be completed in teams of three students. Teams are formed during this lab session. Each team must write a team name and names+emails of team members on the blackboard and in the email to the lab assistant. Use your team name as the subject in the email to the lab assistant.
2. For homework submission, check the exact deadline date/time on your lab specific page (you find the link at the end of the Labs overview page). Homework should be submitted using the Bitbucket repository. Your team should fork the course project on Bitbucket and your project name should start with "Lab[number]-[team-name]". Last commits of the homework X to the repository should be done before the Homework X deadline (we check logs)!
   • Here are different GUI clients, git can be easily used through eclipse as well.

Bitbucket Project

First, you should set up a Bitbucket project. Your Bitbucket project will contain all homework submissions for this course. Some of which are submitted as wiki entries (for example this homework) and others are submitted as code. We chose Bitbucket over Github as Bitbucket lets you create private repositories with a regular account. (Note that for a normal account up to 5 collaborating users are allowed. You can add your UT e-mail address to your account to increase the number of allowed users if needed.)

We have created a project containing the code you need during the next labs. You should fork this project. Forking basically means making a copy of the project for yourself. The difference between simply copying the code of a project and forking a project is that a fork will remain connected to the original project. This makes it easier for the lab assistants to follow your progress. Don't worry about the code that came with the fork, you don’t have to look at it before lab 3.

To fork the project:

1. Create a Bitbucket account if you don't have one yet and log in.
2. Go to course project.
3. Click on the "+" button on the left panel, and then on "Fork this repository".
4. Choose a name for your project that starts with "Lab[number]-[team-name]".
5. Check the option "This is a private repository"
6. Click "Fork repository"
7. Now you have a new repository. Under "Settings" --> "User and group access", add the account se2017bitbucket@gmail.com to give TAs access to your repository. You can also add the other team members.
8. Under "Settings" --> "Wiki", check the option "Private wiki" and then save the setting
9. Under "Settings" --> "Issue tracker", check the option "Private issue tracker" and then save the setting

For this homework, you have to edit the project wiki. When your homework is done you should add a link to the corresponding wiki page to the readme page that is displayed in the project overview. The readme page is the text you can see on the project overview page. Creating a readme page creates a file named README.md. The readme should contain your team members names and links to submitted homework. This way your lab assistant can see that your homework is ready. The corresponding wiki page of a homework should not be altered after the homework submission (we will check logs!).

Homework 1

Intro

Congratulations, you are employed as an analyst by "Joostes Marss AS" company. During the first day at work, you are informed that "Joostes Marss" got a new client who needs a new POS system. Your new boss is patting your shoulder and says that you are responsible for the project and become the lead analyst of the project.

Customer

Your customer is a BSC, a big supermarket chain. This company is mostly dealing with the management of supermarkets. Currently, the company has 22 stores in Estonia, Latvia, Lithuania and Poland. Your customer has ambitions to expand to 100 stores, and enter the markets of Finland, Sweden and Norway. Today, your customer is using a different POS software in their stores, which makes it expensive to maintain business processes across the company. The administration decided to replace their current POS software by a new software solution developed specifically for their needs.

Initial Requirements

The customer has already done some analysis on what the software should do. This means that some of your work has been already done by the customer. They know pretty well how the new software should look like. The initial document supplied by the customer contains images of the different views with some clarifying comments.

Your Task

After you finished reading the contract you realize to your surprise that although the images define pretty well how the software should look like, there is no list of requirements for the software to be developed, nor a defined workload or fixed deadlines. Thus, as a newly appointed analyst your task is to estimate/find out about these issues and to make an offer. In other words, clarifying the list of requirements and making an offer is your first homework. For this homework you need to:

1. Find out user roles
2. Find out the requirements regarding software functionality (functional requirements) and write them up as user stories
3. Find out the requirements regarding software usability and performance (non-functional requirements)

To clarify the requirements you have to analyse the initial document given by the customer and prepare questions for anything that is unclear. You have the possibility to interview the customer for 5 minutes (here your lab assistant plays the role of the customer). The interview should be recorded and any requirements not based on the initial document have to be based on the interview.

Before doing the interview make sure that you have pinpointed what is unclear about the requirements! If you run into unclarities after the interview is done and you realised you forgot to clarify something you may ask the lab assistant, but this means you can miss out on points for the interview.

User stories are requirements of the form:

  As a <<user role>>, I want to <<specific requirement>>, so that <<benefit>>.

Submission of the results

For evaluation you need to submit the following:

1. Interview during assessment lab. NOTE: The main learning experience here is about being prepared, asking good questions and simulating the interview situation. All requirements have to be based on either the initial document or the interview. NOTE: You must present 20 functional requirements as user stories already in the consultation/assessment lab to get full marks. (3p)
2. Functional requirements: Your team should find at least 20 functional requirements as user stories for the software to be created. The user stories must be in line with the interview protocols described above. (4p)
3. Non-functional requirements: Your team should find at least 5 user stories related to usability and 5 user stories related to performance. In addition, at least one user story should state the request for both types of interfaces (CLI and GUI). (3p)

Note: Use the INVEST criteria to check the quality of your user stories (cf. lecture slides).

Tip: Look through the lecture slides again. They will contain useful information on these subjects that are often more precise than the provided links.

Your results should be published to your team project wiki on Bitbucket. When all results are published to the project wiki, you should link the corresponding homework wiki page in the project readme (which will then be displayed in project overview).