Medição de Trilhas de Auditorias
É muito comum em sistemas corporativos que haja o requisito de se rastrear as operações efetuadas pelo usuário. Normalmente isto é feito por meio da gravação de trilhas de auditoria que ficam disponíveis depois para consultas.
A origem deste requisito costuma ser da área de segurança da informação da organização responsável por especificar quais ações serão rastreadas, quais dados serão armazenados, por quanto tempo, como serão consultados, etc.
A diferenciação do requisito funcional de um requisito não funcional
Pessoas com uma formação superficial em Engenharia de Requisitos podem pensar em uma explicação simplória de que os requisitos funcionais sejam os que descrevem “o quê” o software deve fazer enquanto os requisitos não funcionais descrevem “o como” esses primeiros são implementados.
Outros podem ter uma visão distorcida do assunto julgando que requisito funcional “é o que o usuário pediu”. Definitivamente esse não é o caso já que o usuário pode pedir uma série de requisitos não funcionais.
A chave para diferenciar o que seja um requisito funcional de um requisito não funcional é:
- O primeiro aborda o que há de específico no comportamento que se espera do software quando ainda uma necessidade ou, no caso de um software pronto, já uma característica possuída. Digo comportamento em termos da interação desse software com um usuário no desempenho de uma de suas tarefas ou serviços até que seu objetivo (do usuário) seja atingido.
- Os requisitos não funcionais abordam restrições aos requisitos funcionais, tipicamente refletindo: (a) um comportamento comum ao software como um todo ou compartilhado vários requisitos funcionais; (b) uma qualidade associada ao software. Eles não são especificados para cada tarefa ou serviço do usuário (ainda que possam sê-lo já que há qualidades de um software produto específicas de um único requisito funcional).
Enquanto você lê este texto…
Quantas vezes você parou para respirar? E quantas vezes você parou para fazer com que seu coração batesse? Por fim, quantas vezes você piscou seus olhos? (Lembre-se que é muito importante piscar os olhos principalmente quando lendo a partir de uma tela retroiluminada como a que deve estar lendo agora).
Ao descrever a tarefa de ler um artigo, você não se preocupará em descrever esse tipo de coisa. Isso não é um comportamento consciente de sua parte, é um comportamento autônomo que não necessita ser descrito (pelo menos em termos da consciência).
O mesmo acontece com os requisitos não funcionais… e você deve estar percebendo que decisões de arquitetura realizadas ainda em momentos preliminares de um projeto afetam essa relação. Um desenho que não canso de utilizar é aquele utilizado nos treinamentos da IBM:
Funcional x Não Funcional
O CPM e os requisitos não funcionais
Um exemplo bem claro dessa relação e como o CPM se posiciona a respeito é o “Ajuda no Nível de Campo – Primeira Ocorrência” em que há a contagem de uma CE para a função de apresentar HELP.
A referência para atributos de qualidade de produto é a ISO/IEC 25.010 e ela estabelece usabilidade como uma categoria desses atributos e capacidade de ser aprendido como uma subcategoria.
Atributos de qualidade do produto não representam restrições classificadas como requisitos não funcionais? O método da APF não se diz aplicável apenas medir os requisitos funcionais em observação a ISO/IEC 14143?
O propósito influência a fronteira e determina o escopo
O CPM também diz que o propósito da medição influencia o posicionamento da fronteira e determina o escopo da medição. Se quem provê as funcionalidades de HELP não é o software em análise, mas uma outra aplicação – por exemplo, o Windows Help Utility – não é compatível com o propósito da medição posicionar essas funcionalidades como parte do software sendo medido; a menos que o software em análise seja o Windows Help Utility!
A trilha de auditoria e o CPM
A ISO/IEC 25010 também estabelece como qualidades do software produto alguns atributos como:
Capacidade de Colocar a Responsabilidade em uma Entidade
Capacidade de ser analisado
Proteção contra erros do usuários
Se pararmos para pensar, percebemos que a trilha de auditoria está intimamente associada a todas essas qualidades e não especificamente associada a uma tarefa ou serviço do usuário; ainda assim e de maneira bem similar ao caso do HELP, há um exemplo em que se orienta a contagem dos campos referentes a uma imagem com a configuração anterior a uma atualização como um TD no CPM.
Isso quer dizer que sempre devemos contar assim? Claro que não!
Antes devemos avaliar se esse comportamento não é fornecido por outra aplicação (tipicamente uma aplicação de infraestrutura como um framework com funcionalidades gerais compartilhadas)
Vamos avaliar alguns cenários:
Cenário I: Gravação da trilha de auditoria
Normalmente a gravação da trilha de auditoria ocorre para todas (ou quase todas) as transações da aplicação. Não sendo, portanto, um requisito específico e particular das tarefas associadas a essas transações, mas sim requisitos gerais da aplicação.
Um sintoma disto, é que isto não estará presente nos casos de uso que especificam os requisitos funcionais, mas em uma parte complementar da especificação de requisitos.
Logo não há transação adicional a ser considerada pela gravação da trilha de auditoria; assim como também não haverá nas transações em que se gravam registros de trilha de auditoria a contagem de um arquivo referenciado para esses dados.
Caso haja um requisito específico e particular de gravar para determinado grupo lógico de dados informações de configurações passadas antes e após uma atualização, isso deve ser considerado na contagem quando é parte do software em análise.
Isso se dá pela contagem de um novo tipo de registro nesse arquivo (afinal normalmente existe mais de um campo funcionalmente dependente dessa configuração anterior como a data em que o evento aconteceu, quem foi o responsável pela substituição da configuração anterior por uma nova ou mesmo pela exclusão de um registro).
A geração desse registro está associada ao seu fato gerador e com isso não deve ser contada uma função especificamente para esse fim, mas sim considerar a geração desse registro como um passo do processo responsável pelo fato gerador.
Cenário II: Consulta à trilha de auditoria
Caso seja responsabilidade do software em análise disponibilizar consultas e relatórios aos dados de auditoria, estas transações deverão ser consideradas também funções desta aplicação, pois representam requisitos específicos da mesma.
Caso as consultas aos dados de auditoria sejam efetuadas por outra aplicação, nada relativo a estas consultas deve ser considerado na contagem da primeira aplicação. Haver uma função cujo negócio seja consultar os dados de auditoria (chamemos essa função de “Trilha de Auditoria Geral – Consultar”) não implica na contagem de um ou vários arquivos lógicos internos referentes à manutenção desses dados nem tão pouco na contagem de arquivos referenciados nas funções de atualização.
Para a aplicação que possui a função “Trilha de Auditoria Geral – Consultar”, o arquivo “Trilha de Auditoria Geral” deve ser contado como um AIE; ele deve ser contado como um arquivo referenciado na avaliação da complexidade da função “Trilha de Auditoria Geral – Consultar”.
O arquivo “Trilha de Auditoria Geral” não deve ser contado como um arquivo referenciado na avaliação da complexidade das funções que atualizam os dados auditados (Cenário 1). A mesma lógica se aplica na eventualidade de haver outra aplicação que compreenda a função “Trilha de Auditoria Geral – Consultar” como um requisito funcional.
Para que exista um AIE, obrigatoriamente ele deverá ser um ALI em alguma outra aplicação. O arquivo “Trilha de Auditoria Geral” é um ALI para um aplicativo de infraestrutura que mantém esses dados e possui funções como “Trilha de Auditoria Geral – Incluir”. Esta situação é similar ao exemplo de Telas de Help presentes no manual do IFPUG. O diagrama abaixo ilustra o exposto neste texto:
Cenário III: Dados da trilha de auditoria
Na situação em que alguns grupos lógicos de dados da aplicação exigem a manutenção do histórico de configurações anteriores; e houver necessidade de integrar esses dados em consultas que façam uma referência cruzada desses dados históricos independentemente do grupo lógico de dados em particular e da atual configuração desses dados; e os dados históricos são mantidos mesmo quando os dados atuais não foram mais relevantes para o negócio, cabe a contagem de um grupo lógico de dados especificamente para a sua manutenção. Especificamente para as transações que mantém dados nesse arquivo, um novo AR será contabilizado ao avaliar a complexidade dessas funções.
