Analisando os requerimentos do sistema, definimos um conjunto de papéis( 6.1.2) satisfazendo a quantidade de níveis5 de acesso desejada.
Começamos com um número pequeno de papéis e, à medida que o sistema evoluiu, os papéis também se multiplicaram. Apenas para exemplificar: o papel Alterador de solicitação foi adicinado quando percebemos que existia um ação(alterar pedido da solicitação) no sistema que requeria um nível de acesso diferenciado. Imagine, por exemplo que exista uma solicitação com o seguinte pedido: Listagem de alunos da FEA que possuem média maior que sete. Se não houvesse um controle para execução desta ação, o seguinte cenario poderia ocorrer: o texto pedido é alterado e o NAEG acaba desenvolvendo um trabalho inútil. Além disso, o estado em que a solicitação se encontra também influencia na permissão de alteração do pedido. Por exemplo: o solicitante não pode alterar seu pedido se a solicitação estiver sendo desenvolvida, por razões óbvias.
A escolha das ações do sistema foi feita a partir da análise dos requerimentos e, assim como ocorreu com os papéis, aumentou durante evolução do sistema. Por exemplo: quando o sistema foi concebido, não existia a ação Reabrir projeto. Entretanto, a partir do momento em que o sistema entrou em operação, notamos que, muitas vezes, os usuários precisavam reabrir um projeto concluído para alteração de diversos itens. Com isso, decidimos adicionar esta açao.
Observando os diversos casos( 6.1.3) de uso do sistema, é possível ter uma boa noção da complexidade envolvida na definição dos papéis e ações do sistema. Toda esta complexidade de refletiu no momento da codificação e, principalmente nos teste pois, era preciso testar cada caso de uso.