Agile methodologies suggest to elaborate documentation only as needed, without having any required artifacts for each stage as traditional methodologies usually do. The reason why heavy documentation is not recommended is because requirements are expected to change constantly during the development process, forcing to update every diagram and text each time a change is applied, with the consequent loss of time that could have been otherwise used to develop the product.
For this reason, only some simplified diagrams were drawn during the specification and design stages, the necessary to understand the system and share ideas with the SPHERE.IO team. Therefore most of the artifacts presented in both this section and section Design 4, were made after the product was already built, intended to assist the reader in understanding better the system.
The specification section here presented describes the necessary system to fulfill the functional requirements previously gathered. Here are first described the set of use cases that are initially planned for the project, which corresponds to the final Product Backlog (see list in Appendix B Product Backlog). The conceptual model of this system is then presented and, for each use case, is explained the expected behavior of the system with the user.
USE CASE MODEL
There are three actors that interact with the system: the customer, the payment platform and the SPHERE.IO e-commerce platform . The customer can either be an anonymous customer or an identified customer previously existing in the SPHERE.IO platform. Since the required functionalities of the present project were mainly designed to test the SPHERE.IO platform, it is no surprise that the platform is present in every single use case of the system whatsoever, so for the sake of readability it will be omitted from the use case diagrams henceforth.
As mentioned earlier, the system has three functionalities where all use cases fall into: display products, purchase products and manage customer account . The customer is present in all use cases of the system, while the payment platform is only involved in the functionality for purchasing products.
The use cases for displaying products are shown below in Figure 3.3. The customer can either list a set of products or display a particular product. Further additional functionalities can be applied to the product listing, individually or combined together, in order to alter the list itself (i.e. filtering) or the way the products are listed (i.e. sorting and pagination).
Shows the use cases related to purchasing products. They can be clearly divided into two different topics: on the one hand all those use cases for managing the shopping cart (i.e. adding, updating and removing items), on the other hand those related to placing and listing orders. When placing an order the customer may be requested to pay online, in which case the payment platform will provide the necessary means. Anonymous as much as registered customers can place orders, but only customers that have been identified are able to list their own orders, otherwise they are requested to identify themselves.
Finally, for the use cases related to account management , a registered customer can manage his address book (i.e. add, update or remove postal addresses) or update his account (i.e. change his personal data or password). He can as well decide to log out from the system and become an anonymous customer. As an anonymous customer, he can sign up a new account or log in with an existing one. In case he cannot remember his credentials, he will be given the option to recover his password.