MDX Sorgulama

Este sub-processo tem a finalidade de gerar os documentos necessários para descrever os requisitos do sistema de software a ser desenvolvido. Para isso, o elaborador de requisitos gera um conjunto de documentos de entrada. A Figura 40 apresenta o diagrama do sub-processo obter os requisitos do sistema de software.

Figura 40 – Sub-processo obter os requisitos do sistema de software (1).

O diagrama prevê a elaboração dos documentos de requisitos pelo elaborador de requisitos, utilizando quaisquer técnicas de elicitação de requisitos. O elaborador de requisitos pode ser o cliente ou o responsável pela elaboração dos requisitos do sistema de software.

Os principais documentos de entrada são constituídos pelo modelo de casos de uso (composto pelo diagrama e especificação dos casos de uso), especificação de requisitos não funcionais com suas respectivas prioridades, complementados pelo glossário e documentos existentes, como: workload do sistema, o workload organizacional, fluxo de informações, especificações de requisitos funcionais, prioridades organizacionais, entre outros. A descrição dos artefatos de entrada se encontra no Apêndice B.

O engenheiro de requisitos deve executar a atividade verificar documentação de entrada (1.1) a fim de analisar se os documentos recebidos apresentam o conteúdo adequado, através dos padrões estabelecidos no Apêndice B. Em função dos resultados da verificação, os documentos podem ser aceitos ou rejeitados. Em caso de rejeição, o engenheiro de requisitos solicita a adequação ao elaborador de requisitos, para que os documentos possam ser reapresentados conforme padrões estabelecidos.

4.4 Sub-Processo 2: Relacionar Interesses Funcionais e Não- Funcionais

Este sub-processo tem como objetivo identificar interesses funcionais e não-funcionais e associá-los no diagrama de casos de uso do sistema de software. Neste sub-processo o método proposto por Supakkul e Chung (2004) descrito na seção 2.3.2 é detalhado para que seja incorporado ao PARNAFOA. Este método define um conjunto de regras para associar elementos do diagrama de casos de uso e softgoals, e analisar os impactos dos softgoals através dos elementos do diagrama de casos de uso.

Relacionar Interesses Funcionais e Não Funcionais (2) Integrar Interesses Funcionais e Não Funcionais (2.2) Identificar Interesses Funcionais e Não Funcionais (2.1) Documentos existentes (#1) Modelo de casos de uso (#2) Especificação de requisitos não funcionais (#3)

Glossário (#4) (#5) Lista de interesses (#6) Tabela de RNF (#7) Diagrama Integrado (#8) SIGs iniciais (#9) Modelo de caso de uso (#2)

Figura 41 – Sub-processo relacionar interesses funcionais e não-funcionais (2).

Os interesses não-funcionais são separados na atividade para identificar interesses funcionais e não-funcionais (2.1). Um conjunto de RNFs, tais como desempenho, segurança e confiabilidade é considerado um interesse não- funcional.

O catálogo de tipos de RNFs do NFR Framework (CHUNG et al., 2000) é utilizado para classificar interesses não-funcionais. Porém, como este catálogo é restrito aos tipos de requisitos de acurácia, segurança e desempenho, são utilizadas a norma ISO/IEC 9126 (ISO/IEC 9126, 2001), com as características e sub-características de qualidade, e a lista de RNFs proposta por Chung et al. (2000) para extender a lista de tipos de RNFs disponíveis. O uso de uma lista mais abrangente de tipos de requisitos não-funcionais, que facilite a classificação dos interesses não-funcionais, é uma das contribuições deste trabalho.

Os interesses não-funcionais identificados para o sistema de software são representados como softgoals. Desta forma, um softgoal representa um interesse não-funcional, que por sua vez, pode ser composto de um ou mais RNFs.

Os interesses funcionais, por sua vez, são obtidos através do modelo de casos de uso. Cada um dos casos de uso representa um interesse funcional do sistema de software a ser desenvolvido.

A saída da atividade para identificar interesses funcionais e não-funcionais (2.1) são os softgoals, a lista de interesses funcionais e não-funcionais, e a

tabela de requisitos não-funcionais (RNF) com os interesses não-funcionais associados a cada um dos RNFs.

Durante a atividade para identificar interesses funcionais e não-funcionais, os softgoals possuem somente a definição de tipo de RNF. A lista de interesses possui a relação de interesses do sistema de software e a classificação de acordo com sua natureza, que pode ser funcional ou não-funcional. A tabela de RNF possui os RNFs relacionados aos interesses não-funcionais e a definição da origem da classificação do interesse, que pode ser proveniente do catálogo de tipo de RNFs, da lista de Chung et al. (2000) ou das características e sub- características de qualidade da norma ISO/IEC 9126 (ISO/IEC 9126, 2001).

A atividade para integrar interesses funcionais e não-funcionais (2.2) considera os dados provenientes da atividade 2.1 e utiliza o método de Supakkul e Chung (2004). No PARNAFOA, as heurísticas para a associação de um softgoal a um elemento do diagrama de casos de uso do método original foram detalhadas. Para o detalhamento, foi considerada a classificação de requisitos não-funcionais proposta por Kotonya e Sommerville (1998), apresentada na seção 2.1 deste trabalho. O detalhamento das heurísticas para associação de um softgoal a um elemento do diagrama de casos de uso é uma das contribuições deste trabalho.

A classificação de Kotonya e Sommerville (1998) foi escolhida pois faz a diferenciação entre RNFs externos, de produto e de processo. Esta distinção é necessária para que os RNFs externos sejam associados aos elementos externos do sistema de software (atores), e para que os requisitos de produto e processo possam ser associados aos demais elementos como: casos de uso, relação atores e casos de uso e limite do sistema.

As heurísticas definidas para associar um softgoal a um elemento do diagrama de casos de uso são listadas a seguir:

• O ponto de associação entre um softgoal e um ator deve ocorrer quando existirem requisitos não-funcionais externos ou restrições operacionais aplicáveis ao ator;

• O ponto de associação entre um softgoal e um caso de uso deve ocorrer quando existirem requisitos de produto aplicáveis ao caso de uso;

• O ponto de associação entre um softgoal e o relacionamento ator-caso de uso deve ocorrer quando existirem requisitos de acesso ao sistema

de software, comunicação, interface entre o ator e o sistema de software, ou troca de informação entre o sistema de software e os atores;

• O ponto de associação entre um softgoal e o limite do sistema de software deve ocorrer quando existirem requisitos externos, de processo, ou de produto considerados para o sistema de software como um todo;

Os SIGs iniciais referentes ao sistema de software são gerados no momento em que os interesses funcionais (casos de uso) e não-funcionais (softgoals) são associados entre si no diagrama integrado de casos de uso. O diagrama integrado terá a representação conforme descrito na seção 2.3.2.

A estrutura de um SIG inicial do diagrama integrado é compatível com a nomenclatura tipo [tópico], onde tipo representa um tipo de requisito não- funcional e o tópico representa o contexto ou qualificação para o tipo (CHUNG et al., 2000). A saída deste sub-processo deve ser o diagrama integrado que contém os SIGs iniciais associados aos elementos do diagrama de casos de uso.

Os documentos existentes e o glossário, fornecidos como entrada, são utilizados para consulta, conforme necessidade.