The requirement IDs are defined in the below format:

`<system><front><functional_type><requirement_type><id>`

In which:
* system: ES: Entry System (actual access control system), IS: Identity System (fingerprint identity registration system)
* front: M: Mechanics, H: Hardware, S: Software
* functional_type: F: Functional, NF: Non-functional
* requirement_type: R: Requirement
* id: [dd]: 1-indexed two-digit incrementing number that identifies a requirement in the most specific sub-type

Example:
`ESMFR01`: #1 mechanics functional requirement of the entry system

Whereas the anti-requirements are simply AR<id>.

There are also some Optional , i.e. requirements that will be done only if there’s enough time, Drop-out X, i.e. requirements that will not be done if the Xth member drop-out happens and Removed due to time constraints, i.e. requirements that were dropped based on the project evaluation after the schedule was set and time limits were established, requirements. Taking this into account and considering succintness, a few requirements also include an “(if so)” highlight to account for the impact of requirements that can be optional/disabled in some development scenarios in a part of the implementation flow while their abscence doesn’t necessarily make the requirement classifiable as e.g. Optional or Drop-out uniquely (e.g. “The entry system central module, turnstile and mock turnstile (if so) material must be either MDF, wood or plastic.”).

As an overview:

• If a first member drops out, the offline event personnel managed entry with delayed authentication (if an internet outage happens) and the multiple ticket types, marked as Drop-out 1, will be considered Optional.
• If a second member drops out, some management web app features and the utility to transfer tokens in the ticketing web app directly, marked as Drop-out 2, will be considered Optional.
• The battery system and mock turnstile were Removed due to time constraints.

Base de dados sem título