Restrições do Sistema

Os requisitos não funcionais são restrições sobre os serviços ou funcionalidades oferecidos pelo sistema e aplicam-se normalmente ao sistema todo. Esta página identifica essas restrições, que servirão de base para os requisitos não funcionais.

Cada restrição indica:

• Tipo de Restrição: se é uma restrição do sistema (como o sistema deve ser ou comportar-se) ou do processo de desenvolvimento (como, quando e com que recursos o sistema é construído);
• Justificação: a razão pela qual a restrição existe;
• Tipo de requisito não funcional: segundo a classificação de Sommerville (ver tabela no fim da página).

Os valores marcados com (a validar com o cliente) são pressupostos que têm de ser confirmados com o NEEI.

ID	Restrição	Justificação	Tipo de Restrição	Tipo de requisito não funcional
R1	O sistema deve estar concluído e em funcionamento antes da abertura das inscrições da LAN Party de 2026.	Prazo definido pelo NEEI: "LAN Party para o ano de 2026".	Processo	Organizacional – Desenvolvimento
R2	O sistema deve suportar cerca de 5000 inscrições no evento.	Pedido do cliente: "São previstas cerca de 5000 inscrições".	Sistema	Produto – Eficiência
R3	O desenvolvimento do sistema deve respeitar o orçamento aprovado pelo NEEI.	Custo definido pelo NEEI: "obter um orçamento".	Processo	Organizacional – Desenvolvimento
R4	O sistema deve distinguir participantes internos (membros da Universidade) de participantes externos; apenas os externos pagam a inscrição.	Decisão do NEEI: só as "pessoas externas à Universidade" pagam.	Sistema	Organizacional – Operacional
R5	A inscrição num torneio só deve ser possível para quem tem a inscrição no evento confirmada (e paga, no caso dos externos).	Regra própria de um evento com torneios.	Sistema	Requisito de domínio
R6	O tratamento de dados pessoais deve cumprir o RGPD.	Imposto por lei: o sistema guarda dados pessoais dos participantes (nome, email, contactos).	Sistema	Externo – Legislativo
R7	Os pagamentos devem gerar o respetivo comprovativo / fatura, de acordo com a legislação fiscal portuguesa.	Imposto por lei: existem pagamentos por parte dos participantes externos.	Sistema	Externo – Legislativo
R8	O sistema não deve guardar dados de cartões de pagamento; os pagamentos devem ser processados por uma plataforma de pagamentos externa e certificada.	Imposto pelas normas de segurança dos pagamentos com cartão.	Sistema	Externo – Regulamentar
R9	O sistema deve ser acessível através de um navegador de internet (browser), em computador e em telemóvel, sem instalação de software.	Decisão do NEEI: os participantes usam os seus próprios dispositivos.	Sistema	Organizacional – Ambiental
R10	O sistema deve integrar-se com métodos de pagamento usados em Portugal (ex.: MB Way, Multibanco, cartão).	O sistema tem de comunicar com sistemas de pagamento externos.	Sistema	Externo – Interoperabilidade
R11	Os resultados dos torneios devem ser atualizados em tempo real, sem o utilizador ter de recarregar a página (atraso máximo de poucos segundos (a validar com o cliente)).	Pedido do cliente: "consulta dos resultados (...) em tempo real".	Sistema	Produto – Eficiência
R12	Os resultados devem continuar disponíveis para consulta após o fim de cada torneio e do evento.	Pedido do cliente: "e após cada torneio".	Sistema	Produto – Fiabilidade
R13	A identificação dos membros da Universidade deve ser feita através do seu email institucional.	Decisão do NEEI sobre a forma de provar que alguém é membro da Universidade (necessário para R4).	Sistema	Organizacional – Operacional
R14	O sistema deve suportar picos de acessos simultâneos, sobretudo na abertura das inscrições e durante os torneios.	Cerca de 5000 participantes e resultados em tempo real.	Sistema	Produto – Eficiência
R15	O sistema deve estar disponível durante todo o período de inscrições e durante os dias do evento.	Uma falha durante o evento impede a gestão dos torneios e a consulta dos resultados.	Sistema	Produto – Fiabilidade
R16	Os dados (inscrições, pagamentos e resultados) não podem ser perdidos; devem existir cópias de segurança.	Os pagamentos e os resultados são informação oficial do evento.	Sistema	Produto – Fiabilidade
R17	O sistema deve poder ser usado pelos membros do NEEI sem formação técnica específica.	O evento é organizado por estudantes voluntários.	Sistema	Produto – Usabilidade
R18	Cada utilizador só deve ter acesso às funcionalidades do seu perfil (ex.: apenas os gestores de torneio registam resultados).	Ver Lista de Utilizadores e Lista de Funcionalidades.	Sistema	Produto – Segurança
R19	As comunicações com o sistema devem ser cifradas e as passwords devem ser guardadas de forma segura.	O sistema trata dados pessoais e pagamentos.	Sistema	Produto – Segurança
R20	A interface deve estar em português; pode estar também em inglês, para participantes estrangeiros (a validar com o cliente).	Público do evento.	Sistema	Produto – Usabilidade

Tipos de requisitos não funcionais (Sommerville)

Tipo	Pergunta para decidir	Subtipos usados nesta página
Produto	Descreve como o sistema se deve comportar?	Usabilidade (fácil de usar), Eficiência (rápido e capaz de aguentar muitos utilizadores e dados), Fiabilidade (não falha e não perde dados), Segurança (protege o acesso e os dados)
Organizacional	Resulta de uma decisão ou regra do próprio cliente (NEEI)?	Ambiental (onde e em que equipamentos o sistema funciona), Operacional (como o sistema é usado), Desenvolvimento (como, quando e com que custo o sistema é construído)
Externo	É imposto por alguém de fora do NEEI (leis, normas, outros sistemas)?	Legislativo (leis), Regulamentar (normas de entidades externas), Interoperabilidade (comunicação com outros sistemas)
Domínio	É uma regra própria do tipo de negócio (neste caso, um evento com torneios)?	—

Bibliografia: Ian Sommerville, Software Engineering, 10.ª edição, Addison-Wesley, 2016, Capítulo 4.

Voltar à página principal