Lab 1 - Requirements Gathering
- Homework must be completed in teams of four 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.
- 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 GitHub repository (send an email with a link to your repository, again use your team name as the email subject). As repositories are open, try to keep your team repository link in secret from other teams. Last commits of the homework X to repository should be done the Homework X deadline (we check logs)!
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.
Your customer is the “Beerhouse International” company. This company is mostly dealing with the management of beer restaurants. Currently, the company has 32 restaurants in Estonia, Latvia, Lithuania and Finland. Your customer has ambitions to expand to 100 restaurants, and enter the markets of Sweden and Norway. The company's concept is to mostly sell local beer brands with a small addition of international brands from their supply network (Guinness, Corona, …). Today, your customer is using a different POS software in their restaurants, 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.
Additionally, after reading the order description you got the following quite random requirements:
- Waiter shall be able to enter and track orders.
- Waiter shall be able to perform billing and accept payments.
- Head waiter (vahetuse vanem) shall be able to record cash registers initial and end states.
- Restaurant manager shall be able to calculate bonuses for waiters based on the monthly income of the restaurant.
- Restaurant manager shall be able to order goods from a warehouse.
- It shall be possible to send advertisements to the regular patrons (guests who regularly come to the restaurant).
- Company administration shall be able to get different reports for each particular restaurant and arbitrary groups of restaurants.
It is obvious that you need to them and !
After you finished reading the contract you realize to your surprise that there is neither a clear description of the functionality of the software to be developed, nor a defined workload or fixed deadlines. Thus, as a newly appointed analyst is to estimate/find out about these issues and to make an . In other words, Requirements elicitation or requirements gathering is your first homework. For this homework you need to find at least:
- Who are the user roles (e.g., waiters, head waiter, restaurant manager, ...)?
- What different user group activities must your software support?
- What are the requirements regarding software usability and performance (non-functional requirements)?
Links and Hints
During requirements gathering you can use three different sources of information:
- Familiarization with existing (similar) software solutions. Today, you can find hundreds of different POS solutions in the market. However, your customer is quite confident that there is no out-of-the-box solutions that satisfies his requirements. He insists that he needs a custom-made system that fulfills his special needs. Lets give him this opportunity. But as a freshly appointed analyst the field of POS systems is quite new for you, and you first need to make yourself familiar with the existing solutions. Three of them were suggested by your colleagues (LikePOS - http://erply.com, OpenBravo - http://www.openbravo.com/, Floreant POS - http://floreantpos.com/). And Google will find the rest.
- Observing POS users. If you look around, you will see lots of POS users - starting from Selver cashiers to Möku barmans. Just watch their work and pay attention to the operations they perform with the POS system.
- Interview users. For example, you can arrange a meeting with one of the 'user roles' and ask clarification questions. However, the interviewed users are quite allergic to questions like "what should I do?", so before asking the questions its worthwhile to make some research and prepare examples. You should simulate the interview with one of the team members playing 'user role' who will give you exact answers. The resulting interview protocol with questions and answers will be a great source of requirements information.
Example on how to work with the list of Initial Requirements
Let's take, for example, the first of the initial requirements: "Waiter shall be able to enter and track orders". This is a rather ambiguous/vague requirement. During the interview with the 'customer', you might ask the following questions to clarify the initial requirement and transform it into a more precise requirement:
- Must clients pay for the order immediately after its entered to the system or can the bill be left open?
- Must an open bill have a limit? If so, will it depend on the client? Can the limit be increased if client is using an accepted credit card?
- Can the bill be divided into several bills later?
- Should waiters be able to hand the bill over to the other waiter?
- Should we support credit cards at all? Which credit cards?
- Are there any differences in the mentioned operations between different countries?
Submission of the results
For evaluation you need to submit the following:
- Interview protocols. Simulate interviews with at least four different user roles (e.g., waiter, restaurant manager, ...) Each interview protocol must include at least 20 question-answer pairs. NOTE: The main learning experience here is about asking good questions and simulating the interview situation. It's not so important what exactly the content of the answers of the simulated user role is in terms of the kind of features he wants to have. However, it is important that you manage to make the user role formulate precise statements (i.e., not ambiguous, not contradictory, not incomplete). And by the way, this is just a preparatory exercise - you will get modified requirements from an expert in one of the future labs.
- List of user roles. Note that different user roles perform different functions with the system (for example: waiter needs the function 'client card must give 10% discount before the bill is printed'). The total number of roles to define is up to you.
- Functional requirements the software must support. Requirements must be in harmony with interview protocols described above. Your team should find at least 50 functional requirements for the software to be created.
- SMART requirements to usability and performance. (Hint - the requirement “System must work fast” is not an acceptable performance requirement). Your team should find at least 5 requirements to usability and 5 requirements to performance.
Your results should be published to your team project wiki on the https://github.com/. When all results are published to the project wiki, you need to send an email with corresponding wiki links (plus link to the project repository) to your lab assistant.