As ferramentas CASE são amplamente utilizadas para fornecer suporte automatizado para atividades de processos de software. Um fator importante para o sucesso do projeto é a correta identificação e documentação dos requisitos de software, e outro fator é que para obter controle sobre o gerenciamento de mudanças no sistema, a avaliação de impacto entre os requisitos e as regras de negócio deve ser considerado. Propõe-se também que a ferramenta possibilite o rastreamento de requisitos que abranja alguns aspectos relacionados ao documento IEEE-830-1998 e ao RUP (Rational Unified Process), especificamente a disciplina de requisitos, que são modelos de práticas recomendadas para implementação de software. especificação.
Portanto, sugere-se também que a ferramenta gere documentos de especificação de requisitos de software com base nesses modelos.
INTRODUÇÃO
OBJETIVOS
- Objetivo geral
- Objetivos específicos
O objetivo geral deste projeto é desenvolver uma ferramenta CASE para auxiliar na Especificação de Requisitos de Software (ERS). Gerar o documento de especificação de requisitos baseado no modelo IEEE-830-1998 e nos modelos propostos pelo RUP na disciplina de requisitos;
METODOLOGIA
Levantamento de requisitos: Identificação da necessidade e da solução do problema apresentado através de requisitos funcionais, requisitos não funcionais e regras de negócio; Análise: Detalhamento através de diagrama de casos de uso, utilizando prototipagem de interface para facilitar tanto a validação quanto a investigação de novos requisitos. Segundo, o diagrama de classes de domínio foi criado com o propósito de cumprir os detalhes sugeridos no diagrama de casos de uso; Isso é.
Implementação: Interpretação de requisitos funcionais, não funcionais e regras de negócio para desenvolver a ferramenta de forma que todos os objetivos sejam atendidos.
ESTRUTURA DO TRABALHO
Paralelamente, foi realizado um levantamento de ferramentas CASE para categorizar também a ferramenta a ser desenvolvida, e foi apresentado um levantamento de algumas ferramentas similares. Por fim, há o capítulo com o desenvolvimento deste projeto, que abrange a análise dos requisitos da ferramenta proposta, ou seja, a análise dos requisitos funcionais e não funcionais e das regras de negócio, bem como cenários de utilização e diagramas de classes de a ferramenta. . Este capítulo também contém detalhes sobre a implementação da ferramenta e são apresentadas todas as suas funcionalidades; Também são mostradas telas da ferramenta para melhor compreensão.
Foi realizado um estudo de caso para exemplificar e também validar o uso da ferramenta, portanto o Apêndice C contém um exemplo de documento de especificação de requisitos gerado pela ferramenta.
FUNDAMENTAÇÃO TEÓRICA
ENGENHARIA DE REQUISITOS
- Processos da Engenharia de Requisitos
- Requisitos
- Gerenciamento de requisitos
Análise e negociação de requisitos: Com os requisitos corretamente eliciados, já é possível começar a criar uma base para a sua análise. Geralmente utiliza linguagem natural para definir requisitos funcionais e não funcionais de forma mais simplificada, o que também é compreensível para os usuários do sistema. Os requisitos do sistema são caracterizados por serem requisitos do usuário definidos com mais detalhes.
Quando os requisitos funcionais são expressos em termos de requisitos do usuário, eles são bastante genéricos, porém, os requisitos funcionais do sistema definem as funções do sistema com mais detalhes (SOMMERVILLE, 2003).
FERRAMENTAS CASE
- Taxonomia
- Benefícios e desvantagens das ferramentas CASE
Ferramentas de análise e design: permitem que engenheiros de software criem um modelo do sistema a ser construído e avaliem sua qualidade. Ferramentas de prototipagem e simulação podem possibilitar prever o comportamento de um sistema antes de ele ser construído. Ferramentas de prototipagem: Ferramentas que suportam o paradigma de prototipagem da engenharia de software podem ser incluídas nesta categoria;
Ferramentas de gerenciamento de projetos: podem ter impacto na melhoria da qualidade do gerenciamento de projetos de desenvolvimento de software.
MODELOS DE DOCUMENTOS DE ESPECIFICAÇÃO DE
- IEEE 830-1998
- Rational Unified Process - RUP
- Análise comparativa entre os modelos
Este documento descreve as características que um bom documento de Especificação de Requisitos de Software deve ter. Um documento ERS é escrito especificamente para um produto de software, programa ou conjunto de programas em um ambiente específico. Isso significa que o documento ERS pode ser menos modificado durante o processo de desenvolvimento de software.
A estrutura da seção de requisitos específicos de um documento ERS pode ser organizada por modalidade, classes de usuários, objetos, características, estímulos, hierarquia funcional ou múltiplas organizações. Uma visão geral básica da estrutura de um documento ERS com seus elementos essenciais é mostrada na Figura 5 e detalhada abaixo. Definições, siglas e abreviaturas: todos os termos necessários à interpretação do documento ERS serão definidos nesta subsecção.
A segunda seção do documento ERS deve descrever genericamente os aspectos que afetam o produto e seus requisitos, portanto não estabelece requisitos específicos. Esses fatores podem não ser restrições do projeto, mas são todos os tipos de mudanças que podem afetar os requisitos de um documento ERS. Esses dois artefatos capturam todos os requisitos de software que devem ser descritos para descrever um bom documento ERS.
O RUP fornece dois modelos de estrutura para um documento ERS, um que contém modelagem de dados de caso de uso e outro que não contém. Em ambos os casos é dada orientação para consultar o documento IEEE-830-1998 sobre como organizar um documento ERS.
FERRAMENTAS SIMILARES
- RequisitePro
- RaQuest
- Requisitemanager
- Análise comparativa entre as ferramentas
Quanto ao modelo que inclui modelagem de casos de uso, esta seção não contém tantos detalhes predefinidos, pois os requisitos serão capturados por meio de artefatos de casos de uso e especificações adicionais. Conclui-se que o documento IEEE-830-1998 é mais conciso que os documentos propostos pelo RUP, mas que muitas das informações essenciais para um documento ERS são comuns entre os dois. O modelo IEEE, segundo IEEE (1998), não fornece modelos prontos, mas fornece um esboço simples para a estrutura de um documento ERS, e também oferece outros modelos organizados de diferentes maneiras, conforme mostrado na Seção 2.3. 1.2.
A proposta deste projeto é utilizar o modelo especificado pelo RUP sem os casos de uso, baseado no padrão IEEE e no detalhamento dos itens-chave dos artefatos da disciplina de requisitos do próprio RUP. Foi desenvolvido por uma afiliada da empresa Sparx Systems no Japão para dar suporte a outro produto desenvolvido pela mesma empresa, Enterprise Architect (EA). Tela para visualização dos termos do glossário cadastrados na ferramenta RaQuest. Fonte: adaptado de Sparx Systems (2005).
O Requisitemanager é uma ferramenta desenvolvida em 2004 como tese do acadêmico Luciano Marquardt da Universidade Regional de Blumenau (FURB) (MARQUARDT, 2004). A definição da política de requisitos, o controle e a rastreabilidade estão incluídos nesta ferramenta, além dos relatórios. A Figura 11 mostra como o usuário pode cadastrar dados para a próxima geração do documento Especificação de Requisitos do Programa na ferramenta Requisitemanager.
Tela de cadastro de partes do documento ERS na ferramenta requisitemanager Fonte: Adaptado de Marquardt (2004). Considerando que o documento de especificação de requisitos de software é de fundamental importância no gerenciamento de requisitos, uma comparação com alguns elementos relevantes das ferramentas apresentadas é apresentada na Tabela 3.
PROJETO
- REQUISITOS
- Requisitos funcionais
- Requisitos não funcionais
- Regras de negócio
- CASOS DE USO
- Casos de uso
- DIAGRAMA DE CLASSES
- XML SCHEMA
- IMPLEMENTAÇÃO
- APRESENTAÇÃO DA FERRAMENTA
RF08 – O sistema deverá gerar o documento ERS, para cada versão, com base no que foi registrado; RNF04 – O sistema deve ser implementado de acordo com o modelo de documento IEEE ERS organizado por classe de usuário (IEEE 830-1998) e com o modelo sem casos de uso apresentado pelo RUP;. UC01 - Criar Projeto: O objetivo deste caso de uso é permitir ao usuário criar um projeto para utilizar as funcionalidades da ferramenta.
UC02 – Open Project: o caso de uso Open Project tem como objetivo permitir ao usuário abrir um projeto previamente salvo para poder usufruir de outras funcionalidades da ferramenta. UC03 – Salvar Projeto: Permitir que o usuário salve o projeto em que está trabalhando em um documento XML é o objetivo deste caso de uso. UC04 – Solicitação de registro: novos requisitos funcionais e não funcionais e regras de negócio podem ser registrados através da implementação deste caso de uso.
UC06 - Criar Matriz de Rastreabilidade: Este caso de uso visa capacitar o usuário a criar uma matriz de rastreabilidade entre requisitos funcionais e não funcionais e regras de negócio. UC07 - Criar Documento ERS: O objetivo deste caso de uso é permitir ao usuário criar um documento .RTF, documentação do que foi cadastrado na versão atual ou em versões anteriores da ferramenta. UC08 - Cadastrar dados para seções ERS: O objetivo deste caso de uso é possibilitar o cadastro de dados relativos a seções de texto de um documento ERS para que o usuário crie documentação futura.
UC09 - Salvar versão do documento ERS: O objetivo deste caso de uso é permitir que o usuário salve uma versão do documento Especificação de Requisitos do Programa. É possível criar um documento especificando os requisitos de software para um projeto aberto, para isso o usuário deverá acessar o “Arquivo | Crie um documento ERS”.
CONCLUSÃO
Além disso, pode haver uma função onde as alterações feitas diretamente no documento ERS podem ser refletidas no arquivo do projeto. Ainda considerando o documento ERS como parte do processo de desenvolvimento de software, pode-se desenvolver funcionalidades para armazenar a descrição dos processos que compõem os requisitos, tornando o documento final mais completo. RF07: O sistema deve permitir a criação de uma matriz de rastreabilidade entre requisitos funcionais e não funcionais e regras de negócio;
Permite o registro de dados relativos a partes do documento ERS para geração de documentação futura pelo usuário. RF09: o sistema deve permitir o registo de dados em formato de texto para as secções do documento ERS. Esta ferramenta deverá permitir o registro de requisitos funcionais e não funcionais e regras de negócio, bem como novos atributos para os mesmos.
Deverá também permitir salvar a versão do documento de especificação de requisitos de software e deverá gerar o documento em formato .RTF. Não há como refletir as alterações feitas diretamente no documento ERS gerado em RTF no arquivo do projeto. RN4 - As informações contidas nos modelos de documento ERS IEEE-830-1998 (requisitos organizados por classe de usuário) e RUP (modelo de documento ERS sem casos de uso) devem ser estabelecidas no projeto.
RF7 - O sistema deve permitir a criação de uma matriz de rastreabilidade entre requisitos funcionais e não funcionais e regras de negócio. RF8 - O sistema deverá gerar o documento ERS, para cada versão, de acordo com o que está cadastrado. RNF4 - O sistema deve ser implementado de acordo com o modelo de documento IEEE ERS organizado por classe de usuário (IEEE 830-1998) e o modelo use case-free apresentado pelo RUP.
RF8 - O sistema deverá gerar o documento ERS, para cada versão, de acordo com o que está cadastrado.
