Example 3 - Undrained Analysis with Fixed Widths

A proposta aqui apresentada considera que o documento de requisitos, artefato inicial deste trabalho, está completo, ou seja, abrange todas as funcionalidades desejadas pelos clientes e por todos os stakeholdersenvolvidos no projeto.

Com base na literatura e no estudo de caso, foi proposta a adaptação de um template para o documento de especificação de requisitos (SRS) que deve ser utilizado contendo as informações sugeridas neste trabalho. Com base neste template, deu-se continuidade à pesquisa, onde foi proposto um modelo de rastreabilidade e um processo para sua aplicação. É importante considerar que o modelo de rastreabilidade trará mais benefícios quando os documentos da SRS e do MCU estiverem de acordo com os padrões estabelecidos neste trabalho. Entretanto, com um mínimo de organização nestes documentos já é possível sua aplicação.

O utro ponto a ser considerado é que na segunda etapa desta pesquisa, foram desenvolvidos, em conjunto com o grupo de pesquisas em engenharia de requisitos do CD Pe (Centro de D esenvolvimento D ell/PUCRS), os modelos conceituais da SRS, do MCU e um modelo de integração. Estes modelos serviram como ponto inicial para o restante do desenvolvimento deste trabalho e à medida que a pesquisa foi evoluindo, eles foram sendo adaptados conforme as

necessidades identificadas na literatura e no estudo de caso.

Estes ajustes foram discutidos e avaliados com pesquisadores e colegas do PPGCC durante o seminário de andamento e durante todo o ciclo de pesquisas envolvendo esta pesquisa de mestrado.

A seguir serão apresentadas algumas considerações sobre os modelos inicialmente desenvolvidos neste trabalho, apresentados em [CER06a], [RO C06a] e no Apêndice I. Estes modelos foram desenvolvidos como ponto de partida para alcançar as versões finais, que serão apresentados na seção 6. A partir destes modelos foi desenvolvido, também, um modelo para a avaliação da qualidade da tradução dos requisitos para os casos de uso, que pode ser conferido no artigo apresentado em [RO C06b].

4.1.1 Modelo conceitual inicial da SRS

A partir dos campos e características apresentadas na documentação da SRS da IEEE [IEE84] [IEE98] foi construído seu modelo conceitual. A decisão da utilização deste modelo de especificação de requisitos se deu devido a sua ampla utilização no mercado e, também, devido a sua grande aceitação no meio acadêmico.

O s elementos e seus relacionamentos, indicados nas práticas recomendadas para especificação de requisitos definidas pela IEEE [IEE84] [IEE98], foram representados em um diagrama de classes [UML05].

Schimidt [SCH00] coloca que [IEE98] fornece diretrizes detalhadas das informações que devem estar contidas em cada uma das seções da SRS, porém afirma que, ainda assim, existem dúvidas sobre quais informações detalhar em determinadas seções.

Um ponto comum de confusão, de acordo com Schimidt [SCH00], é a diferença entre a seção “Propósito” e a seção “Escopo”, subseções da “Introdução”

.

O utra possível confusão geralmente ocorre em relação às informações presentes nas seções 2 e 3, já que ambas devem incluir informações sobre as interfaces, funcionalidades e restrições do software. Entretanto a seção 2 (D escrição Geral) não especifica os requisitos, apenas dá uma base destes que serão detalhados na seção 3 da SRS (Requisitos Específicos).

Assim, o modelo conceitual da SRS foi inicialmente desenvolvido contendo todos os elementos indicados pela documentação da IEEE [IEE84] [IEE98]. O s elementos que fizeram parte do modelo inicial podem ser vistos na estrutura apresentada na Figura 17.

identificadas. O modelo final pode ser conferido na seção 6.1.

Figura 17 – Estrutura da SRS da IEEE [IEE98].

4.1.2 Modelo conceitual inicial do modelo de casos de uso

D a mesma forma que no modelo anterior, este foi desenvolvido em conjunto pelo grupo de Engenharia de Requisitos do Centro de D esenvolvimento e Pesquisas D ELL/PUCRS (CD Pe). Este modelo teve como base o template de casos de uso de Cockburn [CO C01], onde para cada campo

foi definida uma classe, responsável por armazenar as devidas informações dos casos de uso. As pesquisas realizadas em [RUP06], [SO M06] e [CO C01], contribuíram para a definição da utilização deste template e, também, para a identificação das informações que deveriam estar presentes em cada classe do modelo.

Um ponto importante é que a seção Cenário de sucesso principal, é onde será contada a história sobre o que o sistema entrega como resultado. Antes de tentar identificar todas as exceções ou condições de falha, deve ser mostrado como o sistema funciona em caso de sucesso. Este tipo de cenário pode gerar exceções, o que ocasiona a criação de um Fluxo alternativo para seu tratamento. Tanto o Cenário de sucesso principalquanto o Fluxo alternativosão compostos de passos que explicam sua execução.

O nível indicado na especificação é considerado como sendo sempre “O bjetivo de Usuário”, conforme explicado anteriormente na seção 2.5.

O template utilizado para compor o modelo é apresentado na Figura 18.

O utros detalhes sobre a adaptação do modelo, bem como a apresentação do modelo final, serão vistos na seção 6.2.

4.1.3 Modelo conceitual de integração

O modelo de integração é resultado de uma análise realizada sob os modelos conceituais da SRS e do MCU. Através de estudos e pesquisas realizadas em artigos, relatórios e documentos [RUP06] [IEE84] [IEE98] [SCH00], foram identificadas as relações entre os elementos de ambos os modelos para que fosse possível definir de onde poderiam ser retiradas, na SRS, as informações para as descrições dos casos de uso.

Cada elemento foi analisado individualmente e suas características foram sendo comparadas uma a uma para que fosse possível identificar as relações de umas com as outras. Após amplas pesquisas e estudos sob exemplos e materiais teóricos encontrados na literatura, foram definidas as relações mostradas na Figura 19.

Figura 19 – Integração entre as classes dos modelos.

O desenvolvimento do modelo de integração se deu para que ficasse facilitada a construção do modelo de rastreabilidade. A partir dos relacionamentos identificados neste modelo, foi possível verificar sua viabilidade de aplicação devido ao estudo de caso realizado e devido a sua aplicação em exemplos reais.

A explicação da origem e dos relacionamentos identificados para este modelo, podem ser vistos em [CER06a], encontrado também no Apêndice 1.