Lab 2 - Requirements Specification, Modeling, Planning

During this homework you will produce a part of the SRS - Software Requirements Specification, the initial design of the Domain Model and create the project plan. In this lab you will be working with the existing project from bitbucket. You will figure out what needs to be updated so that all the requirements are fulfilled.

You will need to download the project. If you wish, take a peek at lab 3 to see how to setup git. Otherwise, you can as well just download the project as an archive (zip) since you will not yet be making any changes to the project for this lab.

To be able to run the application and to see the project structure correctly, your preferred IDE has to have the Gradle integration enabled.

• If you are using Eclipse oxygen, install the "Buildship: Eclipse Plug-ins for Gradle" via the Eclipse update manager (Help > Install new software... > Work with http://download.eclipse.org/releases/oxygen)
• If you are using IntelliJ IDEA, install the Gradle plugin via the IDE settings (File > Settings > Plugins > Enable Gradle). In case you have downloaded the Community Edition, the plugin should be already installed.

You can then import the project by choosing import as a Gradle project. This should create 3 projects: pos, SaleSystemCLI and SaleSystemGUI. SaleSystemCLI is the commandline interface, SaleSystemGUI the graphical interface and pos the core project that is used by both interface projects.

To run the project, open up the view Gradle Tasks. Then double click under the interface project you would like to run the task “run”. You will learn what gradle is and why we are using it in the next lab. For this lab being able to run the project should be enough. If you run into any problems ask your supervisor.

NB: If you decide to use IntelliJ IDEA, you may face a problem while you are running the CLI version of the POS System. In this case, remember that you can always run the POS System from the Command Line using the command gradlew :SaleSystemCLI:run.

Requirements Specification

During the first homework your team gathered functional requirements. Now, you need to choose 5 of them and create 5 use cases that cover the 5 chosen requirements. You must choose the most important business requirements. Each use case must have at least the following parts covered:

• Title
• Precondition
• Primary Actor
• Main Success Scenario
• Extensions - possible alternatives of the main success scenario

Note that we are asking for textual use case descriptions.

Produced use cases should be delivered by Bitbucket wiki. All use cases must have the same type of template.

Modeling

This is the first step towards understanding of how to build your POS application. Till this point we were focused on what functionality an application should support. As we will produce our POS application with an OOP language, we will practice modeling with domain model (model classes). Since part of the application is already written you will be able to use the code to generate a class model for the existing code. This means you only need to update it.

To create a class model of the existing code, you can use a modeling tool.

• If you are using Eclipse, you might install the Amateras Modeler plugin (Help > Install new software… > Work with https://takezoe.github.io/amateras-update-site/). To create a class model of the existing code you can create a new class diagram and then drag-and-drop all the classes in the project into the class diagram.
• If you are using IntelliJ IDEA Ultimate, you might use the included UML support. See this documentation.
• If you are using IntelliJ IDEA Community Edition, you should install another tool for creating UML diagrams since only the Ultimate version provides UML support. In this case, you might use StarUML with the Java plugin (Tools > Extension Manager > Search for “Java” > Install). Once you have installed them, you will be able to generate your model from Java source code (Tools > Java > Reverse Code…)

Since there are 3 projects, you should create 3 class diagrams. Your task now is to analyse how these diagrams have to be updated so that all the functional requirements could be met.

How to Model?

• List class candidates
• Add them to the class diagram
• Add links
• Add attributes
• Add methods/operations

Note: In a Domain Model methods/operations are not needed; however, since you generate part of the model from existing code, for that part you should show the (most important) methods.

How to Find Classes?

• Previous experience
• Go through all requirements and finding there nouns (bill, payment, customer, ...)
• Categorize classes based on the domain
  • Physical objects (cash register, ...)
  • Specifications (product, ...)
  • Locations (store, ...)
  • Transactions (order, ...)
  • Roles (cashier, ...)

How to Find Links?

• Previous experience
• Categorizing
  • A is B's physical part (CashDrawer – CashRegister, ...)
  • A is B's logical part (BillRow – Bill, ...)
  • A is physically inside B (CashRegister – Store, ...)
  • A belongs to B during some transaction or report (OrderedProduct - Order, ...)
  • A is B's member (StoreManager - Store, ...)
  • A uses/manages B (Cashier – POSTerminal, ...)

Model Submission

The domain model shall be delivered as a class diagram (image file: jpg, png or gif). You can embed the image in your project wiki. The domain model must contain classes, links between classes (associations), class attributes (with attribute type specified - like String, Int, Date,..) and methods.

Planning

Adding an issue tracker to your project:

1. Go to Settings
2. Go to Issue Tracker Settings
3. Choose “Private issue tracker”
4. Go to Milestones
5. Add releases as milestones (Lab3, Lab4 and Lab5)

At this point, your team has produced and analyzed a lot of requirements and can proceed to the next step - initial project plan. Since part of the application is already developed you should now run the application to see which parts of the functional requirements are not yet implemented. Tasks needed to implement the missing requirements should be listed in the project plan. In addition, you should include in the plan those tasks needed to test the software such as writing unit test cases. You should regard this project plan as the actual plan that you are going to fulfill in the next labs.

Your initial project plan must be composed of three main aspects, dividing your work into the following three releases:

1. Functionality needed for the first stage: creating the team tab (Lab 3).
2. Functionality needed for the application to perform as required with the exception that data does not have to persist closing and reopening the application - i.e. no database support yet needed (Lab 4).
3. Functionality needed for database integration (Lab 5).

Listed parts of your work/development must be added as tasks to the Bitbucket issue tracker. Tasks are small and simple pieces of work needed to achieve the aims described in the requirement. Each of the requirements will need a bunch of the smaller tasks needed to satisfy it. In other words, you should divide the work behind each of the requirements into smaller meaningful and independent tasks. Remember that the functionality has also to be tested; thus, the work behind the requirements also includes testing tasks. Each task must have at least the following parts:

• Description (what must be done) in the title
• Effort Estimation (in hours) added to the description
• Assignee
• Kind = “Task”
• Priority
• Release as milestone

You need to divide your tasks between your team members. You need to cover all unimplemented requirements for your application and assign priorities based on at least the following priority classes (if you wish you can add more classes):

• Major - Really essential
• Minor - Nice to have

You should keep track of each person's allocated time, as this should be reasonable for each homework.

When adding the tasks you should also add the task number to the functional requirement in the Bitbucket wiki as “#<task number>”. This lets Bitbucket link all tasks to functional requirements and you can easily keep track of which functional requirements have been implemented.

You should cover all the missing requirements with at least 50 tasks!

Summary

Your team must submit the results of the following tasks:

• Use case descriptions (specifications) for at least 5 important requirements (2p)
• Class diagram (use the suggested modeling tools to generate the class model and update it) (4p)
• Tasks in the Bitbucket issue tracker with added links to functional requirements. At least 50 tasks are expected, including both development and testing tasks (4p)

Detailed instructions for the three listed tasks are provided in the sections above.

Results must be delivered with the Bitbucket wiki and Bitbucket issue tracker. You also need to add a link to the second homework solutions to the project readme page. This is considered as a homework submission.

NOTE: In the assessment/consultation lab you must be able to show partial solutions of all tasks.