Observe o diagrama abaixo modelado em UML 2.5.1.

Semanticamente, o diagrama indica que:

A ORG_A é uma organização que anualmente conduz um processo seletivo interno para cargos de gerência. Concorrem aos cargos aqueles funcionários que cumprem um rol de requisitos definido em norma interna. A ORG_A já possui um software para gestão de funcionários e deseja estendê-lo com uma inovação para apoiar os processos seletivos.

O representante do cliente explicou que os funcionários que cumprem os requisitos para um cargo devem ser automaticamente selecionados pelo sistema, e seus nomes devem ser exibidos em tela em ordem crescente de data de admissão, um dado relevante para os usuários e para o processo de seleção. Deve ser disponibilizada a opção para que os usuários do sistema possam alterar a ordenação dos nomes dos funcionários, arrastando e soltando na posição desejada. O sistema deve salvar a nova ordenação após a solicitação do usuário. A alteração da ordenação pode ser refeita a qualquer tempo, mas o sistema deve armazenar o histórico das listas anteriores. As listas de funcionários podem ser impressas em tela. Opcionalmente, as listas podem ser exportadas para os formatos PDF, JSON e XML para interoperabilidade com outros sistemas da ORG_A.

Considerando a solicitação do cliente à luz da engenharia de requisitos, para a inovação solicitada identificam-se:

Ministerio_WEB é uma aplicação Web desenvolvida em multicamadas que utiliza o padrão arquitetural REST, cujo backend tem por base uma Application Programming Interface (API) e cujo frontend foi desenvolvido em React.JS. Foi padronizado que todas as funcionalidades para pesquisa de dados devem entregar os resultados aos usuários por meio de componente estruturado em tabela. É relevante para os usuários que cada apresentação de tabela respeite o limite de 15 registros por tela. O backend, por sua vez, fornece serviços de entrega de conjuntos de dados que resultam de pesquisas com a opção de parametrização da quantidade de registros a serem disponibilizados ao utilizador do endpoint.

Considerando que Ministerio_WEB precisa ser medido funcional e não funcionalmente, optou-se pelo uso do SNAP (Software Non-Functional Assessment Process) para dimensionamento não funcional.

Pela perspectiva da medição não funcional utilizando o SNAP, as funcionalidades para pesquisa de dados utilizadas no Ministerio_WEB estão aderentes, respectivamente, à categoria:

Durante um processo de contagem de pontos de função de uma aplicação, as telas do sistema foram utilizadas como subsídios. As Figuras 1 e 2 apresentam as telas para cadastro de clientes.

Com base na Análise de Pontos de Função, o cadastro apresentado nas Figuras 1 e 2 deve ser contado como:

Observe a transação SQL a seguir.

BEGIN;
INSERT INTO Parte (ParteID, NomeParte)
    VALUES (1, 'Mariana Souza');
SAVEPOINT insercao;
INSERT INTO Parte (ParteID, NomeParte)
    VALUES (2, 'Joca Silva');
SAVEPOINT insercao;
INSERT INTO Parte (ParteID, NomeParte)
    VALUES (3, 'Luiz Almeida');
ROLLBACK TO SAVEPOINT insercao;
RELEASE SAVEPOINT insercao;
ROLLBACK TO SAVEPOINT insercao;
SELECT * FROM Parte;
COMMIT;

No PostgreSQL, após a execução da transação SQL, o(s) registro(s) da tabela Parte é(são):