This artefact introduces the context and motivation of the project, and briefly describes the web information system to be developed. It includes the goals of the project and lists the main features that should be supported, together with the identified access groups. ¶

A1 MediaLibrary example | ER template | A1 checklist ¶

This artefact contains the specification of the actors and their user stories, serving as agile documentation of the project requirements. ¶

Based on both the common and the theme-specific functional requirements, each group is expected to identify and describe the actors and the user stories for their project. The full implementation of the features identified as required corresponds to a grade of 18 (in 20). The additional 2 points are for features proposed by each group, considering the quality and innovation of these features. ¶

An Actor models a type of role played by an entity that interacts with the system being specified. This may include persons (not just the end-user) and other entities external to the system. Actors are always external to the system being modeled; they are never part of the system [Ambler04]. ¶

A User Story is a high-level definition of a requirement containing only the necessary information so that the developers can produce a reasonable estimate of the effort required to implement it [Ambler04]. A user story, a brief description of a potential interaction with the system by one of its users, focuses only on interaction requirements and not on the technical aspects of the design of the system. Each user story has a priority: high or essential, medium or conditional, and low or optional. A team of expert analysts also includes an estimate of the effort required for its implementation. ¶

Each user story must follow the template [Dennis10]: ¶

“As a [user], I want [function], so that [value]” ¶

The supplementary requirements are also presented as a section, and includes business rules, technical requirements and other restrictions on the project [Ambler04]: ¶

• A business rule defines or constrains one aspect of the business, with the intention of asserting business structure or influencing business behaviour. Business rules often supplement usage or user interface requirements; ¶
• Technical requirements are concerned with the technical aspects that the system must meet, such as performance-related issues, reliability issues and availability issues. Highlight and justify the three most critical technical requirements for your project; ¶
• A restriction on the design limits the degree of freedom in the search for a solution. ¶

A2 MediaLibrary example | ER template | A2 checklist ¶

The Information Architecture artefact presents a brief overview of the information architecture of the system to be developed. It has the following goals: ¶

• Help to identify and describe the user requirements, and raise new ones; ¶
• Preview and empirically test the user interface of the product to be developed; ¶
• Enable quick and multiple iterations on the design of the user interface. ¶

This artefact enables a brief exploration of the information architecture of the system to be developed, in particular the identification of the content, how it is organized and made available, and how it is presented. ¶

This artefact includes two elements: ¶

• Overview of the information architecture from the viewpoint of the users (sitemap); ¶
• Description and prioritization of the functionally and content of, at least two, main individual screens (wireframes). Include the homepage and the core product page (e.g. view question, view action, view timeline, etc). ¶

A3 MediaLibrary example | ER template | A3 checklist ¶

The Conceptual Domain Model contains the identification and description of the entities of the domain and the relationships between them. ¶

At this stage of the project we are mainly interested in the database specification, thus the Conceptual Domain Model is simplified to include only concepts (entities and relationships) of the domain that are stored in the database. In this artefact the data requirements of the system are detailed. As highlighted in the project rules, the project dimension should lead to the identification of approximately 10 organizational entities.  ¶

The Conceptual Data Model is obtained by using a UML class diagram containing the classes, associations, multiplicity and roles. For each class, the attributes, associations and constraints are included in the class diagram. Business rules or other restrictions not included in the class diagram are described by words or using OCL (Object Constraint Language) included as UML notes. ¶

A4 MediaLibrary example | EBD template | A4 checklist ¶

This artefact contains the Relational Schema obtained from the Conceptual Data Model. ¶

The Relational Schema includes the relation schemas, attributes, domains, primary keys, foreign keys and other integrity rules: UNIQUE, DEFAULT, NOT NULL, CHECK. ¶

Relation schemas are specified in the compact notation: ¶

Table1(id, attribute NN)
Table2(id, attribute → Table1 NN)
Table3(id1, id2 → Table2, attribute UK NN)
Table4((id1, id2) → Table3, id3, attribute)  ¶

Primary keys are underlined. UK means UNIQUE and NN means NOT NULL. ¶

The specification of additional domains can also be made in a compact form, using the notation: ¶

Today DATE DEFAULT CURRENT_DATE
Priority ENUM ('High', 'Medium', 'Low')  ¶

To show the domains of the attributes and the CHECK constraints of attributes and tuples, in addition to this representation, the relational schema is also presented in SQL as an annex. ¶

To validate the Relational Schema obtained from the Conceptual Model, all functional dependencies are identified and the normalization of all relation schemas is accomplished. Should it be necessary, in case the scheme is not in the Boyce–Codd Normal Form (BCNF), the relational schema is refined using normalization. ¶

A5 MediaLibrary example | EBD template | A5 checklist ¶

This artefact contains the physical schema of the database, the identification and characterization of the indexes, the support of data integrity rules with triggers, the definition of the database user-defined functions, and the identification and characterization of the database transactions. ¶

This artefact also includes the complete database creation script, including all SQL code necessary to define all integrity constraints, indexes, triggers and transactions. ¶

The physical schema of the database contains a study of the predicted system load (database load), including an estimate on the number and growth of tuples in each relation. ¶

Performance indexes are applied to improve the performance of select queries. At most, three performance indexes can be proposed, identifying the ones that have the biggest impact on the performance of the application. For each proposed index, it is necessary to indicate and justify the type chosen (B-tree, Hash, GiST, GIN), and also if clustering is needed. As a last resource, controlled redundancy may be introduced (de-normalisation). ¶

The system being developed must provide full-text search features supported by PostgreSQL. Thus, it is necessary to specify the fields where full-text search will be available and the associated setup, namely all necessary configurations, indexes definitions and other relevant details. ¶

To enforce integrity rules that cannot be achieved in a simpler way, the necessary triggers are identified and described by presenting the event, the condition, and the activation code. ¶

User-defined functions, and trigger procedures, that add control structures to the SQL language, or perform complex computations, are identified and described to be trusted by the database server. ¶

Every kind of function (SQL functions, Stored procedures, Trigger procedures) can take base types, composite types, or combinations of these as arguments (parameters). In addition, every kind of function can return a base type or a composite type. Functions can also be defined to return sets of base or composite values. ¶

Database transactions are needed to ensure the integrity of the data in the presence of concurrent accesses. ¶

For each transaction, with a proper justification, the isolation level must be explicitly stated and read-only transactions must be identified to improve global performance. For each identified transaction, the SQL code is presented. ¶

The database script must also include the SQL code to populate a database with test data with an amount of tuples suitable for testing and with plausible values for the fields from the database. ¶

Instructions on setting up and using PostgreSQL are provided at Persist data with PostgreSQL. ¶

A6 MediaLibrary example | EBD template | A6 checklist ¶

This artefact presents an overview of the web resources to implement, organized into modules. It also includes the permissions used in the modules to establish the conditions of access to resources. Web resources are specified using the OpenAPI standard. For each resource, the expected URL, HTTP methods and parameters supported, as well as possible responses are documented. ¶

A7 MediaLibrary example | EAP template | A7 checklist ¶

The Vertical Prototype includes the implementation of the features marked as necessary (with an asterisk) in the common and theme requirements documents. This artefact aims to validate the architecture presented, also serving to gain familiarity with the technologies used in the project. It must be based on the LBAW Framework (see the template-lavavel repository) and include work on all layers of the architecture of the solution to implement: user interface, business logic and data access. ¶

The US implemented must be specific of the group's project. Adapting the provided authentication system is required but not considered part of those US. The US must include at least a form, an action, an AJAX request, search, and updates to the database. ¶

The instructions on installing and deploying the framework are provided at Developing the project with Docker, Laravel & PostgreSQL. ¶

When the image is uploaded FEUP's GitLab, the prototype will be available, inside the FEUP VPN, at http://lbaw21gg.lbaw.fe.up.pt (it may not be immediate). ¶

A8 MediaLibrary example | EAP template | A8 checklist ¶

This artefact is the result of the implementation of the information system designed in the earlier stages, using PHP and the Laravel Framework for producing dynamic web pages, and PostgreSQL as a database management system. ¶

The product includes instructions for installation and use, and access credentials. The product version considered for evaluation is the one available on the group's GitLab Container Registry by the component's delivery deadline. That container will be made available at http://lbaw21gg.lbaw.fe.up.pt and will be used, from that URL, for the demonstration (A10). No update to the image at the production machine will be done after the submission deadline. ¶

The product should also describe the type of assistance supported by the web application (context-sensitive help, notifications, help pages, etc.), describe and briefly justify the revisions introduced to the initially defined requirements and architecture, and identify the development status (in %) of each of the requirements (user stories) initially set in A2. ¶

The product is evaluated by observing the operation of the developed web application and the delivered code. The following items will be assessed: ¶

• Product usability — accessibility, usability of interfaces and online assistance (e.g. help online). ¶
• The features implemented — minimum set of features considered essential. ¶
• The architecture and the use of technology — modularity of the solution, the quality of the source code, proper use of languages ​​and technologies. ¶
• The robustness of the product — absence of failures during operation, error handling (the access to the database and business logic in PHP), form validation in HTML and JS. ¶

PA template | A9 checklist ¶

This artefact includes the promotion, a presentation, the demonstration of the product, and a discussion of the developed features. The promotion should include a short video of 2 minutes, showcasing the main features of the product. ¶

For the presentation, the group must follow a presentation script (not to be delivered), and demonstrate the product accessing the official URL at the production machine: https://lbaw21gg.lbaw.fe.up.pt. The web application will be available until the grades are published. ¶

PA template | A10 checklist | Rules and Scheduling of Presentations ¶