J. Correia Lopes


User Tools

Site Tools


Artefacts A1-A11

Master in Informatics and Computing Engineering
Database and Web Applications Laboratory
Instance: 2018/2019

I. Requirements Specification and User Interfaces (ER)

This component groups the artefacts related to the Requirements Specification of the system to be developed during the project. These artefacts are usually included in the Requirements Document of a system [IEEE98] developed in the initial phase of analyses, by a team that includes all project stakeholders.

A1: Project presentation

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

A1 MediaLibrary example | A1 template

A2: Actors and User Stories

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

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 modelled; 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. The user stories have a priority (high or essential, medium or conditional, and low or optional) indicating the need to be included in the design implementation stages and project. 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 in an Annex to A2.

This annex contains business rules, technical requirements and other restrictions on the project:

  • A business rule defines or constrains one aspect of the business, with the intention of asserting business structure or influencing business behaviour;
  • Technical requirements are concerned with the technical aspects that the system must meet, such as performance-related issues, reliability issues and availability issues;
  • A restriction on the design limits the degree of freedom in the search for a solution [Ambler04 ].

A2: MediaLibrary example | A2 template

A3: User Interfaces Prototype

This User Interface Prototype has the following objectives:

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

Since an User Interface Prototype (or horizontal prototype) allows for a much faster implementation than the final product, it allows to easily test and validate the design at an early stage of the development, enabling empirical testing, such as usability testing and in situ observations of the design being used by real users. It also permits to quickly iterate on the design of the interface, implementing the results from the initial tests.

This artefact should include three elements:

  1. Overview of the interface elements and features common to all pages;
  2. Overview of the information system from the viewpoint of the users (sitemap); and
  3. Identification and description of the main interactions with the system (at least two), organized as sequences of screens (storyboards).

The user interfaces must be implemented using HTML, CSS, JS. The overview of the interface elements must include a presentation of the behavior of the interfaces in small screen devices such as smartphones. This artefact includes screenshots of the interfaces, alongside with a link to a web page for each interface implemented.

A3: MediaLibrary example | A3 template

II. Database Specification (EBD)

This component groups the artefacts to be made by the development team in order to support the storage requirements and retrieval of the information identified in the requirements specification.

A4: Conceptual Data Model

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.

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 not included in the class diagram are described by words or using OCL (Object Constraint Language) included as UML notes.

A4 MediaLibrary example | A4 template

A5: Relational Schema, validation and schema refinement

This artefact contains the Relational Schema obtained by mapping 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)

UK means UNIQUE and NN means NOT NULL.

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

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.

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 | A5 template

A6: Indexes, triggers, user functions and population

This artefact contains the physical schema of the database, the identification and characterization of the indexes, the support of data integrity rules with triggers and the definition of the database user-defined functions. This artefact also includes the complete database creation script, including all SQL necessary to define all integrity constraints, indexes and triggers.

Physical Schema

The physical schema of the database contains a study of the predicted system load (database load), including an estimate of tuples at each relation and the Physical Schema of the database. The database load includes the most important queries (SELECT) and their frequency, important changes (UPDATE, DELETE) and their frequency, and the required performance for these queries and updates.

Should it be necessary to improve the performance of the queries, indexes of convenient type (B-tree, Hash, GiST and GIN) are introduced. As last resource, controlled redundancy may be introduced (de-normalisation). It is also needed to decide the clustering of an index.

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 can not be achieved in a simpler way, the triggers are identified and described by presenting the event, the condition, and the activation code.

User-defined Functions

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 populated with data

The database script must also include the SQL 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.

A6 MediaLibrary example | A6 template

III. Architecture Specification and Prototype (EAP)

This component groups artefacts related to the architecture specification of the information system to be developed and the (vertical) prototype implemented to validate the architecture.

A7: High-level architecture. Privileges. Web resources specification

This artefact presents an overview of the web resources to implement, organized into modules. Also included in this artefact are the permissions used in the modules to establish the conditions of access to resources.

For each module identified in the artefact, a catalogue of web resources that are part of the module, including possible APIs, must be presented. For each resource, the expected URL, HTTP methods and parameters supported as well as possible responses should be included. For resources with a user interface, a reference (link) is included to the corresponding graphical interface defined in A3 artefact. For resources that need SQL, a reference is included to the corresponding SQL statement in A9 artefact.

A7 MediaLibrary example | A7 template

A8: Vertical prototype

The Vertical Prototype includes the implementation of two or more user stories (the simplest) and aims to validate the architecture presented, also serving to gain familiarity with the technologies used in the project. It should be based on the LBAW Framework and include work on all layers of the architecture of the solution to implement: user interface, business logic and data access.

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

The code of the prototype is kept in the GitLab repository in an independent branch (named proto).

The prototype is available, inside the FEUP VPN, at http://lbaw18GG.lbaw-prod.fe.up.pt.

A8 MediaLibrary example | A8 template

A9: Main accesses to the database and transactions

This artefact presents the main accesses to the database, including the transactions.

For each transaction, the isolation level must be explicitly stated and read-only transactions must be identified to improve global performance. For each identified access, the SQL code and the reference of web resources (A7) must be presented. A given database access can be used in more than one resource.

A9 MediaLibrary example | A9 template


[Ambler04] Scott Ambler, The Object Primer, Cambridge University Press, 3rd Edition, 2004, ISBN: 978-0-521-54018-6
[IEEE98] IEEE Computer Society, IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998, 1998, DOI: 10.1109/IEEESTD.1998.88286
[Dennis10] Steve Dennis, How to write meaningful User Stories, subcite.com Articles & Tutorials, 2010


teach/lbaw/artefacts.txt · Last modified: 31/01/2019 15:17 by Correia Lopes