Ġğne ile yapılan süspansiyonlar:

O artefato central do NFR Framework é o SIG que permite representar e registrar decisões de projeto. Chung et al. (2000) definem um conjunto de dez passos para elaboração deste grafo:

1. Aquisição do conhecimento do domínio;

2. Aquisição e catalogação do conhecimento sobre os RNFs; 3. Identificação dos RNFs do sistema de software;

4. Decomposição dos softgoals dos SIGs iniciais; 5. Definição de prioridades dos softgoals;

6. Identificação de possíveis operacionalizações;

7. Definição das interdependências implícitas entre softgoals; 8. Registro de decisões de projeto;

9. Seleção de alternativas de projeto; 10. Avaliação do impacto das decisões.

Os passos listados não precisam ser realizados necessariamente na seqüência apresentada; a seqüência a ser adotada depende das características de um sistema de software a ser desenvolvido.

Durante a aquisição do conhecimento do domínio, o desenvolvedor deve formalizar o seu conhecimento relativo ao domínio do sistema de software a ser desenvolvido e identificar as prioridades que podem influenciar o desenvolvimento. A documentação do domínio deve fazer parte da especificação dos requisitos de software. As prioridades podem originar-se de considerações sobre diversos fatores, tais como as prioridades organizacionais (exemplo: um banco pode considerar que a segurança de informação é muito importante) e a carga de trabalho organizacional (exemplo: um sistema de cartão de crédito pode ter um grande número de vendas para autorizar em um dia). Além disso, pode-se priorizar os requisitos durante o desenvolvimento.

Durante a aquisição e a catalogação do conhecimento sobre os RNFs, o desenvolvedor deve tomar conhecimento dos catálogos do NFR Framework relacionados aos requisitos não-funcionais, métodos, relacionamentos e correlações, para poder desenvolver o sistema de software de forma aderente ao NFR Framework. Estes catálogos determinam a terminologia e a classificação dos conceitos a serem utilizados e podem ser estendidos conforme a necessidade.

Durante a identificação dos RNFs do sistema de software são definidos os SIGs iniciais que representam os principais RNFs do sistema de software. São representados os tipos de requisitos (desempenho, segurança, etc), e tópicos relacionados. A Figura 13 apresenta um exemplo de SIGs iniciais para contas bancárias.

Figura 13 – SIGs iniciais de desempenho e segurança adaptados de Chung et al. (2000).

Durante a decomposição dos softgoals dos SIGs iniciais, o desenvolvedor pode optar pela decomposição de tipo e/ou tópico. No exemplo da Figura 14, foi escolhida a decomposição de tipo de RNFs.

Figura 14 – Decomposição de tipo dos softgoals de desempenho e segurança adaptado de Chung et al. (2000).

Durante a definição de prioridades dos softgoals, o desenvolvedor estabelece os pontos relevantes do SIG, introduzindo softgoals que indicam a importância do ponto de vista de prioridade. Estes dados podem ser úteis para

análises de trafeoff entre softgoals. A Figura 15 mostra um exemplo de prioridade definido para a acurácia das contas bancárias.

Figura 15 – Definição de prioridade para a acurácia de contas adaptada de Chung et al. (2000).

Durante a identificação de possíveis softgoals de operacionalização, os RNFs devem estar suficientemente refinados, para que os desenvolvedores definam as estratégias de projeto a serem utilizadas. O exemplo da Figura 16 apresenta os softgoals de operacionalização identificados para os RNFs de desempenho e segurança.

Figura 16 – Exemplos de operacionalizações dos softgoals de desempenho e segurança adaptados de Chung et al. (2000).

Neste exemplo, as nuvens com bordas mais grossas são softgoals de operacionalização, que representam possíveis alternativas de projeto identificadas para os RNFs de desempenho e segurança.

Durante a identificação de interdependências implícitas entre softgoals, os desenvolvedores devem consultar os catálogos de correlações do NFR

Framework ou avaliar as possíveis interdependências, positivas e negativas,

entre os softgoals, com base na experiência a respeito dos RNFs. A Figura 17 apresenta exemplos das interdependências implícitas identificadas para os

softgoals de desempenho e segurança.

Figura 17 – Definição de interdependências implícitas adaptada de Chung et al. (2000).

No exemplo da Figura 17 foram identificadas correlações negativas entre o uso de formato descomprimido e o softgoal de espaço, entre a validação de acesso contra regras de elegibilidade e o softgoal de tempo de resposta, a requisição de identificação adicional e o softgoal de usabilidade. Uma correlação positiva foi detectada entre a validação de acesso contra regras de elegibilidade e o softgoal de acurácia.

Durante o registro de decisões de projeto, decisões, fatos, opiniões e resultados de análises de tradeoffs devem ser registrados através de softgoals de afirmação. Um exemplo é apresentado visualizado na Figura 18.

Figura 18 – Registro de softgoals de afirmação adaptado de Chung et al. (2000).

Os softgoals de afirmação, neste exemplo, estão associados à validação de acesso contra regras de elegibilidade, em que o desenvolvedor afirma que uma validação de acesso otimizada não irá interferir no tempo de resposta. O

softgoal de afirmação relacionado a acurácia enfatiza que este requisito é vital

para o sistema de software.

Durante a seleção de alternativas de projeto, o desenvolvedor toma decisões relativas às alternativas de projeto que foram identificadas nos passos anteriores, considerando informações do domínio, prioridades, decisões de projeto, interdependências entre softgoals e o conhecimento registrado em catálogos. A Figura 19 ilustra os softgoals de operacionalização selecionados (√) e rejeitados (X).

Figura 19 – Seleção entre alternativas adaptada de Chung et al. (2000).

É importante observar que nem todos os softgoals de operacionalização precisam obrigatoriamente de avaliação. Um exemplo desta situação é o

softgoal de uso de senha, que foi deixado em branco.

Durante a avaliação das decisões é analisado o impacto das decisões tomadas nos softgoals ascendentes, utilizando-se os procedimentos de avaliação. A propagação das contribuições negativas ou positivas, o julgamento e a experiência dos desenvolvedores também devem ser considerados. A Figura 20 apresenta um exemplo de SIG avaliado.

Após conclusão dos dez passos devem ser definidos os relacionamentos de meta de operacionalização, o texto das metas, e o relacionamento entre os requisitos funcionais e as decisões tomadas. A Figura 21 exemplifica estes relacionamentos.

Figura 21 – Relacionamento com o requisito funcional adaptado de Chung et al. (2000).

A caixa de nota representa a meta a ser atingida. A meta deve ser conectada a todas as operacionalizações relacionadas a ela através dos relacionamentos de meta de operacionalização. O requisito funcional Manter

Contas é relacionado à meta através do relacionamento de decisão de projeto.