Área de engenharia de software por julio cezar chrystopher
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA CASE PARA ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE OBSERVANDO IEEE-830-1998 E RUP
Área de Engenharia de Software
por
Julio Cezar Chrystopher Quirino
Fabiane Barreto Vavassori Benitti, Drª Eng. Orientadora
Itajaí (SC), dezembro de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA CASE PARA ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE OBSERVANDO IEEE-830-1998 E RUP
Área de Engenharia de Software
por
Julio Cezar Chrystopher Quirino Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Fabiane Barreto Vavassori Benitti, Drª Eng.
Itajaí (SC), dezembro de 2005
TERMO DE APROVAÇÃO
FERRAMENTA CASE PARA ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE OBSERVANDO IEEE-830-1998 E RUP
Julio Cezar Chrystopher Quirino
Este Relatório foi julgado adequado para obtenção dos créditos da disciplina de Estágio
Supervisionado do curso de Ciência da Computação.
_____________________________________
Profª. Fabiane Barreto Vavassori Benitti, Dra.
Orientadora
_____________________________________
Profª. Anita Maria da Rocha Fernandes, Dra.
Coordenadora da disciplina de Trabalho de Conclusão de Curso
_____________________________________
Prof. Cesar Albenes Zeferino, Dr.
Coordenador da disciplina de Trabalho de Conclusão de Curso
BANCA EXAMINADORA
_____________________________________
Prof. André Raabe, Msc.
_____________________________________
Profª. Adriana Gomes Alves, Msc.
Itajaí, dezembro de 2005.
iv
AGRADECIMENTOS
Sobretudo, a Deus, por ser meu Pai e por permitir que este sonho tenha se tornado realidade.
A minha tutora, tia e mãe, Ivonete e a minha família, pela compreensão em relação aos momentos
de ausência, e também por sempre me apoiarem e confiarem na minha capacidade. À minha
orientadora, Profª. Drª Fabiane Barreto Vavassori Benitti, por sua extrema paciência em discussões
e revisões sobre este trabalho e por todos os ensinamentos nessa etapa da minha vida. Aos meus
amigos Ana Paula, Everton Flávio, Júlia Marques, Mariana e a todos que, de alguma forma,
contribuíram positivamente para essa conquista, o meu muitíssimo obrigado.
v
SUMÁRIO
LISTA DE ABREVIATURAS................................................................vii LISTA DE FIGURAS ............................................................................viii LISTA DE TABELAS..............................................................................ix
RESUMO ...................................................................................................x
ABSTRACT ..............................................................................................xi 1. INTRODUÇÃO.....................................................................................1 1.1. OBJETIVOS ........................................................................................................ 4 1.1.1. Objetivo geral .................................................................................................... 4 1.1.2. Objetivos específicos ......................................................................................... 4 1.2. METODOLOGIA................................................................................................ 4 1.3. ESTRUTURA DO TRABALHO ....................................................................... 5
2. FUNDAMENTAÇÃO TEÓRICA .......................................................7 2.1. ENGENHARIA DE REQUISITOS ................................................................... 7 2.1.1. Processos da Engenharia de Requisitos .......................................................... 8 2.1.2. Requisitos ......................................................................................................... 10 2.1.3. Gerenciamento de requisitos.......................................................................... 15 2.2. FERRAMENTAS CASE................................................................................... 19 2.2.1. Taxonomia ....................................................................................................... 19 2.2.2. Benefícios e desvantagens das ferramentas CASE ...................................... 22 2.3. MODELOS DE DOCUMENTOS DE ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE ............................................................................. 23 2.3.1. IEEE 830-1998................................................................................................. 24 2.3.2. Rational Unified Process - RUP..................................................................... 31 2.3.3. Análise comparativa entre os modelos.......................................................... 39 2.4. FERRAMENTAS SIMILARES....................................................................... 40 2.4.1. RequisitePro .................................................................................................... 40 2.4.2. RaQuest............................................................................................................ 41 2.4.3. Requisitemanager............................................................................................ 42 2.4.4. Análise comparativa entre as ferramentas................................................... 44
3. PROJETO............................................................................................45 3.1. REQUISITOS .................................................................................................... 45 3.1.1. Requisitos funcionais ...................................................................................... 45 3.1.2. Requisitos não funcionais ............................................................................... 46 3.1.3. Regras de negócio............................................................................................ 46 3.2. CASOS DE USO ................................................................................................ 48 3.2.1. Casos de uso..................................................................................................... 49 3.3. DIAGRAMA DE CLASSES............................................................................. 51
vi
3.4. XML SCHEMA ................................................................................................. 52 3.5. IMPLEMENTAÇÃO ........................................................................................ 56 3.6. APRESENTAÇÃO DA FERRAMENTA ....................................................... 57
4. CONCLUSÃO.....................................................................................65
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................67
APÊNDICE A – REQUISITOS FUNCIONAIS ...................................70
APÊNDICE B – XML SCHEMA PARA A FERRAMENTA PROPOSTA .............................................................................................81
APÊNDICE C – DOCUMENTO GERADO PELA FERRAMENTA 87
LISTA DE ABREVIATURAS
CASE Computer Aided Software Engineering CSV Comma Separated Value DTD Document Type Definition EA Enterprise Architect ERS Especificação de Requisitos de Software FURB Fundação Universidade Regional de Blumenau HTML HyperText Markup Language IBM International Business Machines IEEE Institute of Electrical and Electronic Engineers IETF Internet Engineering Task Force PHP Hypertext Preprocessor RFC Request For Comments RTF Rich Text Format RUP Rational Unified Process TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language XSD XML Schema Definition
LISTA DE FIGURAS
Figura 1. Processos da Engenharia de Requisitos ................................................................................8 Figura 2. Estágios no processo do gerenciamento de mudanças........................................................17 Figura 3. Exemplo de uma tabela de rastreabilidade .........................................................................18 Figura 4. Exemplo de uma Lista de Relacionamentos .......................................................................19 Figura 5. Esboço da estrutura de um documento de ERS ..................................................................28 Figura 6. Disciplinas, fases e iterações do RUP.................................................................................32 Figura 7. Papéis e artefatos utilizados na disciplina de requisitos .....................................................36 Figura 8. Fluxo de atividades da disciplina de requisitos ..................................................................38 Figura 9. Tela de rastreabilidade da ferramenta Rational RequisitePro.............................................41 Figura 10. Tela para visualização dos termos de glossário cadastrados na ferramenta RaQuest ......42 Figura 11. Tela para cadastro das seções do documento de ERS na ferramenta requisitemanager...43 Figura 12. Casos de uso para o presente projeto ................................................................................49 Figura 13. Diagrama de Classes.........................................................................................................52 Figura 14. Estrutura do elemento projeto...........................................................................................54 Figura 15. Estrutura detalhada de um elemento requisito funcional..................................................55 Figura 16. Estrutura detalhada de um elemento requisito não funcional ...........................................55 Figura 17. Estrutura detalhada de um elemento regra de negócio .....................................................55 Figura 18. Exemplo de funções de acesso a um atributo de um documento XML............................56 Figura 19. Tela de cadastro de novo projeto ......................................................................................58 Figura 20. Tela de cadastro das seções textuais do documento a ser gerado. ....................................59 Figura 21. Tela de cadastro do atributo “status” para requisitos não funcionais ...............................60 Figura 22. Tela de cadastro de um requisito não funcional – Dados básicos ....................................61 Figura 23. Tela de cadastro de um requisito não funcional - Atributos .............................................61 Figura 24. Matriz de rastreabilidade ..................................................................................................62 Figura 25. Matriz de rastreabilidade com relacionamento suspeito...................................................62 Figura 26. Tela para preenchimento dos detalhes para salvar versão ................................................63 Figura 27. Tela para escolha da versão que será gerado o documento ..............................................63 Figura 28. XML Schema apresentado para a ferramenta proposta. ...................................................86
LISTA DE TABELAS
Tabela 1. Fatores que levam a mudança de requisitos .......................................................................16 Tabela 2. Aspecto geral da comparação entre as ferramentas apresentadas ......................................44 Tabela 3. Características específicas do documento de ERS .............................................................44
RESUMO
QUIRINO, Julio Cezar Chrystopher. Ferrramenta CASE Para Especificação de Requisitos de Software Observando IEEE-830-1998 e RUP. Itajaí, 2005. 102 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005. A Engenharia de Software se preocupa com a produção do software desde os estágios iniciais até sua implantação e manutenção, se dedicando tanto aos processos técnicos de desenvolvimento, como gerenciamento de projetos, e o desenvolvimento de ferramentas, métodos e teorias que favoreçam a produção do mesmo. Atualmente, no desenvolvimento de um projeto de software, grande parte dos problemas ocorre pela definição dos requisitos de forma incorreta, ou até mesmo por não haver essa definição. O esforço realizado para identificar o impacto no sistema caso seja necessário alterar alguma regra de negócio ou algum requisito já definido é outro fator relevante que causa transtornos na fase de desenvolvimento. Sendo assim, considera-se importante a etapa de especificação de requisitos, na qual serão definidas as restrições e funcionalidades do sistema, fazendo uma vinculação entre a solicitação inicial do cliente e a implementação propriamente dita. Dentro desse contexto, a idéia de ferramenta CASE (Computer-Aided Software Engineering) pode ser amplamente difundida. As ferramentas CASE são largamente utilizadas para proporcionar apoio automatizado às atividades de processo de software. Um fator de relevância para o sucesso do projeto é a identificação e documentação dos requisitos de software de forma correta, outro fator é que, para se obter o controle sobre o gerenciamento de alterações em um sistema, a avaliação de impacto entre os requisitos e as regras de negócio devem ser ponderadas. Nesse contexto, o principal objetivo deste trabalho é propor uma ferramenta de auxílio a essa etapa da Engenharia de Software, a especificação de requisitos, já que a mesma é essencial no processo de desenvolvimento. Propõe-se também que a ferramenta permita o rastreamento de requisitos, englobando alguns aspectos relacionados ao documento IEEE-830-1998 e ao RUP (Rational Unified Process), mais especificamente a disciplina de requisitos, os quais são modelos de práticas recomendadas para realizar a especificação de software. Com isso, é proposto também que a ferramenta gere documentos de especificação de requisitos de software baseados nesses modelos. Palavras-chave: Engenharia de Requisitos. Especificação de Requisitos de Software. Ferramenta CASE.
ABSTRACT
The Software Engineering worries about the production of software since the initial periods of training until its implantation and maintenance, it is dedicating as the technician processes of development as management of projects, and the development of tools, methods and theories that are in favor to the production. Currently, in the development of a software project, great part of the problems occurs by the definition of the requirements of incorrect form, or even though because there is not this definition. The effort carried out to identify the impact in the case system is necessary to modify some rule of business or some requirement already defined is another important factor that causes disruptions in the development phase. Being thus, the specification requirement is an important stage, in which the restrictions and functionalities of the system will be defined, making a link between the initial request of the customer and the implementation properly said. About this context, the CASE (Computer-Aided Software Engineering) tool idea can be spread out widely. The CASE tools are used to provide automatized support to the activities of software process. A factor of relevance for the success of the project is the identification and documentation of the software requirements in correct form, another factor is that, to get the control about the management of alterations in a system, the evaluation of impact between the requirements and the rules of business must be considered. In this context, the main objective of this work is to propose a tool of aid to this stage of the software engineering, the specification of requirements, because the same one is essential in the development process. It is also proposed that the tool allows to the tracking of requirements, emboding some aspects related to document IEEE-830-1998 and RUP (Rational Unified Process), more specifically the requirements discipline, which are models of practical recommended to carry out the software specification. With this, it is also proposed that the tool generates documents of specification of requirements of software based on these models. Keywords: Requirement Engineering. Specification of Requirements of Software. CASE Tool.
1. INTRODUÇÃO
A Engenharia de Software, de acordo com Sommerville (2003), se preocupa com a produção
do software desde os estágios iniciais até sua implantação e manutenção, se dedicando tanto aos
processos técnicos de desenvolvimento como gerenciamento de projetos e o desenvolvimento de
ferramentas, métodos e teorias que favoreçam a produção de um software.
Ao desenvolver um software, existe um conjunto de atividades e resultados associados que
geram um processo de software. Embora existam vários processos de software diferentes, existem
atividades comuns entre eles, tais como: Especificação de Requisitos de Software onde se define as
restrições e funcionalidades, projeto e implementação do que foi especificado, validação para
garantir que o software faz o que o cliente deseja e a evolução do software para atender as futuras
necessidades (SOMMERVILLE, 2003).
Carpena e Kirner (1998) afirmam que uma etapa essencial do processo de desenvolvimento
de software é a especificação de requisitos. A atividade de especificação de requisitos tem como
objetivo levantar os requisitos de um sistema como um todo. Kotonya e Sommerville (1997)
afirmam que os requisitos são definidos durante os estágios iniciais do desenvolvimento como
especificação do que deve ser implementado. São informações que regram a maneira do software
agir, o domínio da informação e restrições ou especificação das propriedades de um atributo.
Peters e Pedrycz (2001) concluem que um requisito de software fornece uma base para o
desenvolvimento de um software. E quanto mais essa base é criada de forma adequada, melhor será
a qualidade do software produzido.
Uma boa documentação de um projeto de software fornece uma base sólida para o
desenvolvimento, aumenta o nível de confiabilidade e geração de testes. É através da documentação
que se sabe o que deve ser projetado. Essa documentação provê o necessário para construir e avaliar
os resultados de um processo de software (PETERS e PEDRYCZ, 2001).
Ainda segundo Peters e Pedrycz (2001), após a conclusão de um relatório de necessidades
do processo de pré-desenvolvimento, os processos da engenharia de requisitos devem ser iniciados.
A engenharia de requisitos, segundo Lopes, Majdenbaum e Audy (2003), se preocupa com a análise
e documentação dos requisitos, fornecendo meios para facilitar diversas atividades relacionadas.
2
Atualmente existem modelos de práticas recomendadas para realizar a especificação dos
requisitos de um software. Segundo Kotonya e Sommerville (1997), diversas organizações
propuseram modelos diferentes. Os documentos abordados neste trabalho, são propostas no IEEE-
830-1998 do Institute of Electrical and Electronics Engineers (IEEE) e no Rational Unified Process
(RUP).
Identificar e documentar os requisitos de software corretamente é um grande fator para que
um projeto obtenha sucesso. O padrão descrito no documento IEEE-830-1998 define características
de qualidade para um documento de Especificação de Requisitos de Software (ERS), bem como
recomendações de como atingi-las.
Referente ao gerenciamento de alterações do software, algo que deve ser destacado é a
avaliação do impacto de mudança no sistema. Para realizar esse tipo de avaliação é necessário
levantar informações sobre as dependências dos requisitos, bem como a forma de implementação
dos mesmos para que o documento de especificação de requisitos se torne mais completo. Essas
informações são chamadas de informações de rastreabilidade (KOTONYA E SOMMERVILLE,
1997).
Um documento de especificação de requisitos de software pode ser tratado como rastreável
quando a origem de cada requisito é clara e o futuro desenvolvimento ou a melhoria da
documentação é facilitada pela mesma (IEEE, 1998). Resumindo, a rastreabilidade auxilia na
verificação e validação dos clientes.
Já o RUP foi criado para contemplar o ciclo de desenvolvimento de um software completo
através das melhores práticas; é composto por um conjunto de atividades bem definidas. Ele possui
duas dimensões principais, uma que representa a parte estática onde estão os principais processos de
software e outra que focaliza a parte dinâmica do processo (SCHLICKMANN JÚNIOR, 2002).
A dimensão da parte estática é composta por nove disciplinas: Modelagem de Negócios,
Requisitos, Análise e Projeto, Implementação, Teste, Distribuição, Gerência de Mudança e
Configuração, Gerência de Projeto e Ambiente (RATIONAL, 2001 apud KAMINSKI e FISCHER,
2003).
O escopo deste trabalho estará restrito a disciplina de requisitos do RUP. Essa disciplina será
abordada de forma que as melhores características sejam absorvidas, assim como será feito também
com o modelo do IEEE.
3
Dentro desse contexto, a idéia de ferramenta CASE (Computer-Aided Software
Engineering) pode ser amplamente difundida. Esse tipo de ferramenta é, segundo Sommerville
(2003), um conjunto de programas utilizados para apoiar as atividades de processo de software.
Uma ferramenta CASE é largamente utilizada para proporcionar apoio automatizado às atividades
de processo de software.
Essas ferramentas podem ser subdivididas em Lower-CASE e Upper-CASE. Os
depuradores, geradores de casos de teste, geradores de código que apóiam a implementação e os
testes são classificadas em Lower-CASE, já as que dão suporte às fases iniciais do desenvolvimento
do sistema, como projeto e análise, são as Upper-CASE (SOMMERVILLE, 2003).
Grande parte dos problemas no desenvolvimento de um projeto de software ocorre pela
definição incorreta dos requisitos, ou até mesmo a inexistência da mesma. Outro fator que causa
transtornos na fase de desenvolvimento é o esforço realizado para identificar quais pontos serão
afetados no sistema caso seja necessário alterar alguma regra de negócio ou algum requisito já
definido.
Atualmente existem algumas ferramentas que trabalham com a engenharia de requisitos.
Pode-se citar a ferramenta comercial RequisitePro que é específica para o gerenciamento de
requisitos e é de propriedade da IBM. Existe também a ferramenta Enterprise Architect da Sparx
Systems que é mais direcionada a utilização da UML (Unified Modeling Language), e também
trabalha com o gerenciamento de requisitos, porém, com menos funcionalidades. Uma ferramenta
web para gerência de requisitos e foco acadêmico também foi encontrada; ela possui as
funcionalidades típicas de uma ferramenta desse gênero, porém, com mais simplicidade
(MARQUARDT, 2004).
A concepção de uma ferramenta para auxílio no desenvolvimento de software, focada
principalmente na especificação de requisitos, justifica este projeto de pesquisa em nível de
Trabalho de Conclusão de Curso para o Curso de Ciência da Computação, pois, conceitos e teorias
pertinentes a essa área de conhecimento serão estudados e utilizados.
Sendo assim, este projeto propõe o desenvolvimento de uma ferramenta CASE que auxilie
nas etapas de análise de requisitos, gerenciamento das associações entre requisitos e regras de
negócio e gere uma documentação baseada em padrões de práticas recomendadas, tal como a
Especificação de Requisitos - IEEE 830-1998 e os documentos propostos pelo RUP,
4
especificamente os contidos na disciplina de requisitos, a qual tem por objetivo manter o
entendimento entre as necessidades do cliente e dos usuários com os requisitos e funcionalidades do
sistema.
1.1. OBJETIVOS
1.1.1. Objetivo geral
O objetivo geral deste projeto é desenvolver uma ferramenta CASE para auxiliar na
Especificação de Requisitos de Software (ERS).
1.1.2. Objetivos específicos • Pesquisar e analisar soluções similares;
• Determinar os requisitos e o escopo da ferramenta;
• Pesquisar os conceitos e tecnologias necessárias à implementação;
• Implementar o sistema;
• Permitir a especificação de requisitos funcionais, não funcionais e regras de negócio
bem como seus atributos;
• Permitir o gerenciamento de requisitos através da rastreabilidade de requisitos;
• Gerar documento de especificação de requisitos baseado no modelo IEEE-830-1998 e
nos modelos propostos pelo RUP na disciplina de requisitos;
• Testar as funcionalidades e implementação do sistema; e
• Documentar o desenvolvimento e os resultados do sistema.
1.2. METODOLOGIA
A metodologia seguida para o desenvolvimento do presente projeto baseou-se nos seguintes
aspectos:
• Levantamento bibliográfico: Estudo dos conceitos de Engenharia de Software, mais
especificamente, Engenharia de Requisitos. Além de estudos referentes a modelos de
práticas recomendadas para realização da Especificação dos Requisitos de Software, tais
5
como IEEE-830-1998 e o RUP, estudos sobre rastreabilidade de requisitos também
foram realizados. Paralelamente um levantamento foi feito sobre ferramentas CASE para
também poder categorizar a ferramenta a ser desenvolvida e um estudo sobre algumas
ferramentas similares foi apresentado;
• Levantamento de requisitos: Identificação da necessidade e solução do problema
apresentada através dos requisitos funcionais, requisitos não-funcionais e regras de
negócio;
• Análise: Detalhamento através de um diagrama de casos de uso, tendo-se utilizado a
prototipação da interface para facilitar tanto a validação quanto o levantamento de novos
requisitos. Em um segundo momento, o diagrama de classes de domínio foi elaborado,
visando atender ao detalhamento proposto no diagrama de casos de uso; e
• Implementação: Interpretação dos requisitos funcionais, não-funcionais e regras de
negócio objetivando o desenvolvimento da ferramenta de maneira que, todos os
objetivos fossem satisfeitos.
1.3. ESTRUTURA DO TRABALHO
Na primeira parte deste trabalho é apresentada uma introdução sobre o projeto, são citados
os objetivos a serem alcançados com o projeto; a metodologia e a estrutura do projeto em si também
são organizadas nessa seção.
O levantamento teórico é apresentado no Capítulo 2, compreendendo a Engenharia de
Requisitos e seus processos, bem como o gerenciamento dos mesmos concentrando-se em sua
importância em um processo de software e em que ela contribui para auxiliar a especificação de
requisitos. Um estudo sobre ferramentas CASE englobando sua taxonomia, vantagens e
desvantagens é apresentado nesse mesmo capítulo.
Tendo-se o documento IEEE-830-1998 e o RUP como referências, esses modelos de
documentos de Especificação de Requisitos de Software foram estudados a fim de absorver as
melhores características introduzidas nos mesmos e desenvolver este projeto englobando-as.
Ferramentas similares também foram pesquisadas com o objetivo de fornecer subsídios para o
projeto a ser desenvolvido.
6
Por fim, tem-se o capítulo com o desenvolvimento deste projeto, contemplando a análise de
requisitos da ferramenta proposta, ou seja, análise dos requisitos funcionais, não funcionais e regras
de negócio, bem como os diagramas de casos de uso e de classes do negócio. Esse capítulo
compreende também detalhes sobre a implementação da ferramenta, e também todas as suas
funcionalidades são apresentadas; para uma maior compreensão, também são mostradas telas da
ferramenta. Um estudo de caso foi realizado para exemplificar e também validar o uso da
ferramenta, dessa forma, o Apêndice C contém um exemplo de documento de especificação de
requisitos gerado pela ferramenta.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
2. FUNDAMENTAÇÃO TEÓRICA
A busca de automatização do processo de definição de requisitos é um dos objetivos
principais da engenharia de requisitos, a qual é abordada na Seção 2.1. Visando aprofundar o
conhecimento sobre ferramentas CASE, a Seção 2.2 apresenta as vantagens, desvantagens, bem
como as funcionalidades das mesmas. A seção seguinte, 2.3, trata de estudar e analisar modelos de
documentos de especificação de requisitos, tal como o modelo proposto pelo IEEE e o modelo
proposto na disciplina de requisitos do RUP. Ferramentas similares também são pesquisadas e
apresentadas na Seção 2.4.
2.1. ENGENHARIA DE REQUISITOS
Peters e Pedrycz (2001) afirmam que um requisito de software é uma descrição dos
principais recursos de um software, seu fluxo de informações, bem como suas características, ou
seja, um requisito de software fornece os insumos para o desenvolvimento de um produto de
software.
O conjunto das técnicas de levantamento, documentação e análise formam uma das
disciplinas da Engenharia de Software, a Engenharia de Requisitos. Algumas técnicas de análise
dos requisitos ajudam a reproduzir especificações mais precisas (PAULA FILHO, 2001).
A Engenharia de Requisitos é uma subárea da Engenharia de Software que está focada em
descobrir, analisar, documentar e verificar as ações de um software e tem como um dos objetivos
prover subsídios para que os requisitos de um software sejam levantados corretamente, ou seja,
fornecer métodos, técnicas e ferramentas que forneçam suporte adequado às tarefas de
levantamento, modelagem e análise dos requisitos do sistema (PETERS e PEDRYCZ, 2001).
Ainda segundo Peters e Pedrycz (2001), a Engenharia de Requisitos também estuda o
processo que estabelece as funções que o cliente deseja e as restrições sob as quais o software
deverá funcionar e futuramente ser implantado.
De acordo com Hofmann e Lehner (2001), a grande maioria dos projetos de software falha
por ter uma definição deficiente de requisitos. Um processo sólido de Engenharia de Requisitos
pode assegurar que o software estará especificado corretamente e conseqüentemente garantir que a
8
chance de haver erros diminua. Isso tem feito muitos autores considerarem a Engenharia de
Requisitos uma das disciplinas mais importantes da Engenharia de Software.
As atividades de Engenharia de Software relacionadas em documento formal compõem um
documento de requisitos. Dependendo da organização esse mesmo documento pode receber outros
nomes, tais como “Especificação Funcional”, “Definição de Requisitos”, “Especificação de
Requisitos de Software”. O IEEE definiu seu próprio padrão para o documento de requisitos. O
documento gerado pela ferramenta que foi desenvolvida e está sendo abordada neste trabalho, está
embasado tanto nesse padrão como também no que aborda a disciplina de requisitos do RUP,
conforme detalhado na Seção 2.3.2.2.
2.1.1. Processos da Engenharia de Requisitos
De acordo com Kotonya e Sommerville (1997) o processo de engenharia de requisitos pode
ser definido em quatro etapas distintas, conforme ilustra a Figura 1 a seguir, e é detalhado na
seqüência.
Figura 1. Processos da Engenharia de Requisitos
Fonte: Adaptado de Kotonya e Sommerville (1997)
9
1. Elicitação de Requisitos: Esta etapa, comumente chamada de levantamento de
requisitos, compreende qual será o domínio da aplicação, os serviços, bem como as
restrições operacionais. Os objetivos gerais já devem estar definidos neste estágio. A
equipe que irá trabalhar no projeto deve então adquirir conhecimento sobre o que
devem desenvolver, e este conhecimento deve ser organizado para identificar os
pontos relevantes para os requisitos do sistema. Os stakeholders1 participam dessa
etapa. Muitas vezes a elicitação de requisitos não é realizada de forma correta porque
os limites de escopo do software não são bem definidos; muitos detalhes
desnecessários explicitados pelos clientes e/ou usuários podem atrapalhar ao invés de
esclarecer os objetivos do sistema. Além de que os requisitos uma vez levantados
podem sofrer alterações num contexto geral (KOTONYA E SOMMERVILLE,
1997);
2. Análise e Negociação de Requisitos: Com os requisitos elicitados de forma correta já
é possível começar a criar uma base para a análise dos mesmos. Essa, por sua vez,
tem por finalidade organizar os requisitos, agrupando-os através de seus
relacionamentos, identificando a interligação entre eles e verificando a consistência,
ambigüidade e omissão dos mesmos, sempre focando na solicitação do cliente;
3. Especificação de Requisitos: Existem várias formas de definir especificação de
requisitos, tais como gráficos, documentos textuais e protótipos. De acordo com
Kotonya e Sommerville (1997), o resultado dessa fase é o produto final produzido
pelos engenheiros de requisitos. Esse é o alicerce para o desenvolvimento do sistema
em si, descrevendo funções e performances requeridas tanto para a equipe de
software, quanto para equipe de banco de dados ou de hardware, por exemplo; e
4. Validação de Requisitos: Essa etapa consiste em examinar a especificação para
garantir que os requisitos foram estruturados de uma forma que não seja ambígua,
onde os erros foram identificados e corrigidos fazendo com que o projeto esteja
dentro dos padrões que foram definidos.
1 Gerentes, usuários finais, pessoas que dominam o problema e estão envolvidas no projeto
10
2.1.2. Requisitos
De forma geral, Paula Filho (2001) afirma que requisitos são características que definem os
critérios de aceitação de um produto. A engenharia tem por objetivo colocar nos produtos essas
características, ou seja, os requisitos.
Segundo Conallen (2003), uma especificação de requisitos é um conjunto de componentes,
tais como documentos, registros de banco de dados, modelos que descrevem um sistema de
software a ser criado sem ambigüidade.
Sommerville (2003) conclui que muitos problemas no processo de engenharia de requisitos
ocorrem porque existem variados níveis de descrição para os requisitos e esses não se distinguem de
forma evidente. Os termos “requisitos de usuário” e “requisitos de sistema” têm por objetivo
evidenciar esses níveis e facilitar a comunicação entre os diversos tipos de pessoas relacionadas
com o projeto.
Basicamente, os requisitos de sistema são classificados em funcionais, não funcionais e de
domínio. Os requisitos funcionais refletem as funcionalidades ou serviços que o sistema deve
fornecer. Os requisitos não funcionais são as restrições existentes sobre as ações do software. Os
requisitos de domínio são necessidades que a própria aplicação gera e que incidem sobre ela, eles
podem ser funcionais ou não funcionais (PETERS e PEDRYCZ, 2001).
Sommerville (2003) afirma que requisitos de usuário são declarações sobre o que o software
irá realizar e também suas restrições. Utiliza comumente a linguagem natural para poder definir os
requisitos funcionais e não funcionais de uma forma mais simplificada, sendo compreensível
também aos usuários do sistema.
Já Paula Filho (2001), classifica os requisitos em explícitos, normativos e implícitos. Os
explícitos seriam os que estão descritos em um documento de especificação. Os normativos seriam
as regras, conjunto de padrões e regulamentos, com os quais o software deverá estar de acordo. As
expectativas dos clientes e usuários, geralmente não documentadas, seriam os requisitos implícitos.
Requisitos de usuário devem ser descritos de uma forma na qual possa ser compreensível
aos próprios usuários, sem haver muito detalhamento técnico. O comportamento do sistema deve
11
ser especificado utilizando artifícios simples, tais como relatórios em linguagem natural,
formulários e diagramas (SOMMERVILLE, 2003).
Sommerville (2003) também afirma que, por ser definido de uma forma mais simples, a
especificação desses requisitos pode apresentar alguns problemas, tais como a falta de clareza, a
confusão e a fusão de requisitos; podendo assim, permitir que um documento de requisitos seja
escrito com algum tipo de ambigüidade.
Os requisitos de sistema são caracterizados por serem os requisitos do usuário definidos de
uma forma mais detalhada. Os requisitos de sistema devem formar uma especificação completa e
detalhada de todo o sistema (SOMMERVILLE, 2003).
De forma geral, a declaração dos requisitos de sistema não leva em consideração a forma de
implementação, considerando apenas o que o software deverá fazer.
A especificação dos requisitos de sistema também utiliza a linguagem natural, trazendo
assim, muitas vezes, problemas na especificação dos mesmos, conforme citado na Seção 2.1.2.1.
Requisito de domínio é derivado do domínio da aplicação, portanto, não é obtido através das
necessidades específicas dos usuários do software. Podem ser requisitos funcionais ou também
podem restringir os requisitos funcionais existentes (SOMMERVILLE, 2003).
Os requisitos de domínio são importantes porque eles servem como base para os outros
requisitos, ou seja, caso algum requisito de domínio não for atendido, é provável que o software não
opere da maneira adequada.
2.1.2.1. Requisitos funcionais
As funcionalidades do software são descritas pelos requisitos funcionais. São descrições das
atividades que o software deverá executar. O tipo de sistema que está sendo concebido e também os
stakeholders são fatores que definem quais serão os requisitos funcionais.
Quando os requisitos funcionais são expressos em forma dos requisitos de usuário, eles são
bastante genéricos, porém, os requisitos funcionais de sistema definem as funções do sistema de
uma forma mais detalhada (SOMMERVILLE, 2003).
12
A RFC (Request For Comments - Solicitação de Comentários) 2119 do IETF (Internet
Engineering Task Force), segundo Bradner (1997), oferece orientação sobre as frases e palavras-
chave a serem usadas nas declarações de requisitos. Esses termos, geralmente em maiúsculas, são:
"DEVE", "NÃO DEVE", "OBRIGATÓRIO", "DEVERÁ", "NÃO DEVERÁ", "DEVERIA", "NÃO
DEVERIA", "RECOMENDADO", "PODE" e "OPCIONAL".
Normalmente quem define as entradas e saídas do sistema são os requisitos funcionais,
descrevendo as ações que o sistema deve executar, identificando os procedimentos que o sistema
pode fazer, normalmente em resposta à entrada de dados externa. Um exemplo de requisito
funcional é “O sistema DEVE permitir o cadastro de usuários.” (CONALLEN, 2003).
2.1.2.2. Requisitos não funcionais
Kotonya e Sommerville (1997) definem requisitos não funcionais como qualidade total ou
atributos do sistema resultante. Os requisitos não funcionais servem de base para que as
necessidades dos usuários sejam desenvolvidas de uma melhor forma.
Ainda segundo Kotonya e Sommerville (1997), existem três tipos principais de requisitos
não funcionais: requisitos de produto, requisitos de processo e requisitos externos. Os de produto
especificam as características desejadas, as quais o sistema deverá possuir; os de processo são
restrições inseridas no desenvolvimento; e os externos são aqueles que derivam do ambiente em que
o sistema está sendo desenvolvido.
Para tornar mais fácil o processo de compreensão e controle dos requisitos não funcionais,
Conallen (2003) classifica esses requisitos em algumas categorias. Dependendo do tipo de requisito
e por existirem várias categorias, é possível que um requisito se encaixe em mais de uma
classificação.
1. Usabilidade: os requisitos de usabilidade estão intimamente ligados à interface entre
o sistema e o usuário. Tratam normalmente da aparência dos padrões de interface
com o usuário. Definem, por exemplo, a quantidade de telas que um usuário deverá
interagir até executar uma função solicitada. Um exemplo de requisito dessa
categoria é: “A interface do sistema não deve usar quadros HTML”;
2. Desempenho: Estão geralmente relacionados com a questão de tempo. Especifica por
exemplo, tempos máximos de processamento de determinada ação do sistema. Um
13
exemplo: “O sistema não deverá demorar mais de 5 segundos para ser carregado
durante o seu uso normal”;
3. Confiabilidade: Essa categoria de requisito refere-se à disponibilidade do sistema.
Seria interessante se fosse possível afirmar que o sistema estaria totalmente funcional
em tempo integral e sem interrupções. Porém, garantir isto se torna relativamente
caro. A confiabilidade se preocupa também com questões de recuperação e
armazenagem de dados. Para exemplificar, um requisito de confiabilidade pode ser:
“O sistema deve permitir o acesso ao backup semanal em menos de 1 hora”;
4. Segurança: comumente especificam níveis de acesso ao sistema. Caso exista
interação com outros sistemas, os requisitos de segurança definirão também os níveis
de acesso dessas interações. Um exemplo dessa categoria é: “O sistema deve gravar
quem está realizando o acesso a ele”;
5. Hardware: esses requisitos descrevem o hardware que é exigido para a
implementação do sistema em suas camadas, tais como, cliente, apresentação,
entidade e dados, como, por exemplo, “O servidor onde o sistema estará instalado
deve ter no mínimo 1 Gigabyte de memória”; e
6. Implantação: são restrições impostas para definir como o sistema deverá ser
instalado e acessado pela equipe de atualização, como por exemplo, “O sistema deve
ser atualizado mensalmente via Internet”. Itens relacionados à escalabilidade de
instalação do sistema estão inclusos nessa categoria.
Ainda segundo Conallen (2003), os requisitos devem usar esta categorização apenas para
estarem dispostos de forma organizada, não devendo ser escrito com base em alguma categoria
específica. Os membros da equipe também deverão fazer uma revisão completa de todos os
requisitos, não se importando caso a categorização tenha sido feita baseada em sua área específica
ou não.
2.1.2.3. Regras de negócio
Kotonya e Sommerville (1997) afirmam que os sistemas geralmente contribuem de alguma
forma para o desenvolvimento de um negócio ou de uma organização. Sendo assim, a devida
14
compreensão das regras que regem o negócio é muito importante para entender a interação entre os
sistemas e como esse pode contribuir para o sucesso da organização.
As regras de negócio podem ser consideradas como declarações que definem ou restringem
algum aspecto do negócio. Sua intenção principal é estabelecer a estrutura, controlando ou até
mesmo influenciando o comportamento do negócio (META, 1999 apud KLINGER e KROTH,
2001).
A organização denominada Business Rules Group foi criada com o objetivo de padronizar
termos relacionados às regras de negócio. De acordo com esse grupo, uma regra de negócio pode
ser analisada mediante dois aspectos: sistemas de informação e o negócio propriamente dito
(KLINGER e KROTH, 2001).
Na perspectiva de sistemas de informação, uma regra de negócio define ou restringe algum
aspecto do sistema. Já na perspectiva do negócio, a regra é uma diretiva, na qual objetiva
influenciar ou guiar o comportamento do negócio (DATE, 2000 apud WEIDEN et al., 2002).
O papel principal de uma regra de negócio é descrever restrições na estrutura e nos
processos do negócio se preocupando no que deve ser realizado e não como realizar (WEIDEN et
al., 2002).
Conforme Alenquer (2002), atualmente existem conflitos entre a gerência de um negócio e
os sistemas de informação que dão suporte ao mesmo. Isso porque os negócios tem uma dinâmica
bem maior que antigamente, ou seja, as regras de negócio têm sido alteradas em períodos de tempo
mais curtos.
Algumas soluções computacionais não conseguem acompanhar o ritmo da evolução do
negócio. Esses problemas ocorrem muitas vezes devido às regras de negócio não estarem separadas
dos aspectos de implementação e pela falta de documentação dos sistemas. Portanto, é de grande
importância que as regras de negócio e o processo de especificação de requisitos estejam alinhados
continuamente (HALLE, 2002 apud ALENQUER, 2002).
Deixar evidente as regras de negócio que estão por trás dos processos de análise é uma
atribuição do analista de negócios. Esse profissional deve se guiar especificamente pelas
necessidades do negócio e não por conjunturas tecnológicas, já que essa função cabe ao analista de
sistemas. Tendo a visão focada nas questões do negócio, não se preocupando com termos de
15
implementação, esse analista poderá tomar as melhores decisões nas quais poderão reduzir
problemas futuros (ALENQUER, 2002).
2.1.3. Gerenciamento de requisitos
Segundo Kotonya e Sommerville (1997), gerenciamento de requisitos é o processo que
consiste em uma abordagem sistemática a fim de identificar, organizar e documentar os requisitos
de um sistema, estabelecendo e mantendo um acordo formal entre o cliente e a equipe de projeto
sobre os requisitos que eventualmente mudam ao longo do ciclo de vida do projeto.
Ainda segundo Kotonya e Sommerville (1997), muitos requisitos novos surgem e as
alterações nos requisitos já existentes ocorrem geralmente em todas as fases do desenvolvimento de
um projeto. Caso não haja uma boa documentação e um controle dos requisitos, alterações que tem
um nível de prioridade menor podem ser implementadas antes daquelas que tem um nível de
prioridade maior. Além de que alterações ainda não aprovadas financeiramente podem ser
implementadas.
Gerenciar as mudanças dos requisitos já acordados, gerenciar os relacionamentos entre os
requisitos e as dependências entre o documento de requisitos e os outros documentos produzidos
são as principais preocupações referente ao gerenciamento de requisitos.
2.1.3.1. Gerenciamento de mudanças
O gerenciamento de mudanças é muito importante em todo o processo de desenvolvimento
de um sistema. Quando o projeto sofre algum tipo de mudança é necessário realizar a avaliação
desse impacto no restante do sistema.
No caso da mudança ser proposta na fase de levantamento de requisitos, o impacto nos
outros requisitos deve ser identificado, caso isto ocorra na fase de implementação, deve ser
considerado também o impacto no sistema como um todo. A forma com que os stakeholders serão,
ou não, afetados, deve ser analisada caso a mudança seja proposta após o sistema estar em operação
(SANTOS, VARGAS e ABREU, 2004).
Pressman (1995) afirma que o gerenciamento de mudanças é uma atividade abrangente.
Uma mudança pode ocorrer a qualquer tempo, sendo necessário para isso, identificar e controlar a
16
mudança, garantir que ela esteja sendo implementada adequadamente e que seja relatada às outras
pessoas que possam ter esse interesse.
Conforme Kotonya e Sommerville (1997), uma combinação de fatores pode fazer com que
haja mudanças nos requisitos, conforme mostra a Tabela 1.
Tabela 1. Fatores que levam a mudança de requisitos
Fator de mudança Descrição Erros, conflitos e inconsistência dos requisitos
Enquanto os requisitos estão sendo analisados e implementados, erros e inconsistências devem ser corrigidos. A descoberta desses problemas pode ocorrer durante a análise ou validação dos requisitos ou até mesmo no desenvolvimento.
Conhecimento do cliente/usuário final do sistema
Enquanto os requisitos são desenvolvidos, clientes e usuários finais obtém um maior entendimento do que realmente eles querem do sistema.
Problemas técnicos, de cronograma ou de custos
Problemas podem ser encontrados na implementação de um requisito. O processo de desenvolvimento de um requisito pode ser demasiadamente caro ou até mesmo o tempo de desenvolvimento pode ser demasiadamente longo.
Mudanças nas prioridades dos clientes
As prioridades do cliente podem mudar durante o desenvolvimento do sistema em conseqüência de uma mudança no ambiente de negócio, tais como concorrentes novos ou mudanças na equipe.
Mudanças de ambiente O ambiente em que o sistema está sendo instalado pode ser alterado, então os requisitos devem ser alterados para manter a compatibilidade.
Mudanças na organização A organização que pretende utilizar o sistema pode mudar a estrutura e os processos resultando em novos requisitos de sistema.
Fonte: Adaptado de Kotonya e Sommerville (1997).
Para executar o gerenciamento de mudanças é necessário identificar um problema de
requisito, o qual pode ser uma nova necessidade do cliente, um problema operacional ou de análise.
Após essa etapa, é realizada a análise das mudanças propostas para verificar como, quantos e quais
requisitos serão afetados. Por fim a mudança é implementada. Um conjunto de emendas é incluído
no documento de requisitos ou então uma nova versão é produzida. Um resumo desse fluxo é
mostrado na Figura 2.
17
Figura 2. Estágios no processo do gerenciamento de mudanças
Fonte: (SOMMERVILLE, 2003).
2.1.3.2. Rastreabilidade
Um documento de Especificação de Requisitos de Software é rastreável caso seja escrito de
forma a facilitar a consulta de requisitos individuais, ou seja, se os caminhos ascendentes e
descendentes entre um requisito e seu devido recurso de projeto podem ser identificados (DAVIS,
1993 apud PETERS e PEDRYCZ, 2001).
A rastreabilidade é um atributo de uma boa ERS e está descrita no modelo de documento de
requisitos do IEEE. Sommerville (2003) identifica alguns relacionamentos que poderão ser
rastreáveis, tais como, as relações entre um requisito e os outros, relacionamentos entre um
requisito e o projeto do sistema, e as dependências entre regras de negócio e os requisitos
levantados.
Três tipos de informações sobre os requisitos facilitam a rastreabilidade: informações que
associam os requisitos aos stakeholders que os propuseram, informações de interdependência entre
requisitos e informações as quais vinculam os requisitos com o projeto num todo
(SOMMERVILLE, 2003).
Davis (1993 apud KOTONYA E SOMMERVILLE, 1997) classifica as informações de
rastreabilidade em quatro tipos, conforme são descritos a seguir.
1. Rastreabilidade “de – para trás”: relacionamento de requisitos com as suas fontes,
sendo documentos ou stakeholders;
2. Rastreabilidade “de – para frente”: relacionamento dos requisitos para os
componentes de implementação e de projeto;
3. Rastreabilidade “volta – para trás”: relacionamento dos componentes de
implementação e de projeto de volta aos requisitos; e
Requisitos revisados
Problema identificado Análise do problema
e especificação da mudança
Análise de mudança e custo
Implementação da mudança
18
4. Rastreabilidade “volta – para frente”: relacionamento de outros documentos com os
requisitos relevantes.
Apesar de Gotel e Finkelstein (1995 apud KOTONYA E SOMMERVILLE, 1997)
apresentarem a importância de seguir os requisitos de volta para suas fontes, na prática as
informações de rastreabilidade que são mais utilizadas durante esse gerenciamento é a
rastreabilidade de requisitos para requisitos e rastreabilidade de requisitos para componentes de
projeto e implementação.
2.1.3.2.1. Tabelas de rastreabilidade
As tabelas de rastreabilidade, também chamadas por alguns autores de matriz de
rastreabilidade, têm por objetivo mostrar os relacionamentos entre requisitos ou também os
relacionamentos entre requisitos e componentes do projeto. Elas mostram as dependências dos
requisitos onde esses devem ser nomeados com identificadores nas linhas e colunas da tabela. Um
exemplo dessa tabela pode ser visto através da Figura 3 (KOTONYA E SOMMERVILLE, 1997).
Depende de R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6 * * *
Figura 3. Exemplo de uma tabela de rastreabilidade
Fonte: Adaptado de Kotonya e Sommerville (1997).
Ainda segundo Kotonya e Sommerville (1997), as tabelas de rastreabilidade servem para
ajudar a realizar o gerenciamento dos requisitos. Há casos em que um requisito é dependente de um
conjunto de requisitos, para isso pode ser criada uma tabela de rastreabilidade adicional separada.
Marquioni (2004 apud SANTOS, VARGAS e ABREU, 2004) não aconselha que a tabela de
rastreabilidade tenha mais do que 250 itens para que seu gerenciamento não se torne complicado.
19
Listas simples de relacionamentos podem ser implementadas para facilitar, porém, com as listas não
é possível avaliar a dependência inversa. Uma lista de relacionamentos é mostrada na Figura 4.
Requisito Depende de R1 R3, R4 R2 R5, R6 R3 R4, R5 R4 R2 R5 R6 R6 R1, R2, R3
Figura 4. Exemplo de uma Lista de Relacionamentos
Fonte: Adaptado de Kotonya e Sommerville (1997).
2.2. FERRAMENTAS CASE
Carvalho (2001) afirma que CASE, é um termo que é designado às ferramentas de auxílio
automatizado apoiando a Engenharia de Software. As ferramentas CASE surgiram da necessidade
de guardar informações da lógica e dos dados do sistema.
Ferramenta CASE, segundo Sommerville (2003), é o nome dado ao software que tem
objetivo de apoiar as atividades de processo de software, tais como a engenharia de requisitos, as
fases de projeto e de desenvolvimento. Essas ferramentas realizam a automação de algumas
atividades provendo apoio ao processo de software, ou seja, ajudam a reduzir significativamente o
custo de produção e o tempo de desenvolvimento dos sistemas, além de possibilitar um aumento na
qualidade e produtividade dos mesmos.
Atualmente grande parte das ferramentas CASE já abrangem o apoio às tarefas de
modelagem e desenvolvimento de sistemas, podendo gerar documentação e até mesmo código fonte
(McCLURE, 1989 apud CARVALHO, 2001).
2.2.1. Taxonomia
As ferramentas CASE podem ser classificadas por sua função, por seus papéis como
instrumentos para os desenvolvedores, pelo seu uso em várias etapas do processo de Engenharia de
Software, pela arquitetura de ambiente (hardware e software) que as suporta, pela origem ou pelo
20
seu custo. Nessa seção é apresentada a classificação proposta por QED (1989 apud PRESSMAN,
1995), que utiliza a função como critério:
• Ferramentas de planejamento de sistemas comerciais: Segundo Martin (1989 apud
PRESSMAN, 1995) a informação comercial é modelada conforme ela flui dentro de
uma organização. Essas ferramentas têm como objetivo principal ajudar a melhorar a
compreensão de como a informação é transmitida entre essas várias unidades
organizacionais de uma empresa;
• Ferramentas de apoio: essa categoria abrange ferramentas de aplicação e de sistemas que
complementam o processo de engenharia de software, sendo aplicável em todas as suas
etapas. São ferramentas de apoio as ferramentas de documentação, as quais podem
melhorar a produtividade da equipe de desenvolvimento gerando documentos com mais
rapidez; ferramentas de rede e de software básico que são acomodadas pelo ambiente
CASE, já que esse é uma tecnologia de estação de trabalho; ferramentas de garantia de
qualidade que geralmente são ferramentas de métrica que fazem auditoria no código
fonte para saber se o padrão está sendo cumprido; ferramentas de gerenciamento de
banco de dados e gerenciamento de configuração onde podem auxiliar nas tarefas de
identificação, controle de versão, controle de mudanças, auditoria e relatório de status.
As ferramentas CASE nesse domínio são alicerces para a criação de uma biblioteca de
software que poderá estimular a reutilização mais ampla de componentes de software;
• Ferramentas de análise e projeto: permitem que engenheiros de software criem um
modelo de sistema que será construído, bem como possibilitam a avaliação de qualidade
do mesmo. A maioria dessas ferramentas adota a técnicas de análise e projeto de
sistemas, tanto para modelos estruturados quanto orientados a objetos. As ferramentas de
prototipação e de simulação podem fazer com que o comportamento de um sistema seja
previsto antes de ser construído. Já as de projeto e desenvolvimento de interfaces são
tratadas como conjunto de ferramentas de componentes de programa com o objetivo de
possibilitar a rápida criação na tela de sofisticadas interfaces com o usuário. Existem
também as ferramentas núcleos de análise e projeto que utilizam uma arquitetura que
possibilita que a ferramenta seja customizada para qualquer método de análise e projeto;
• Ferramentas de programação: abrange compiladores, editores e depuradores que apóiam
linguagem de programação convencionais. As ferramentas de codificação de quarta
21
geração que também se situam nessa categoria, são ferramentas que fazem com que as
aplicações possam ter um nível de abstração mais elevado, convertendo descrição de
sistema em um programa operacional, ajudando a verificar se a especificação do sistema
está correta. As ferramentas de programação orientadas a objeto também se enquadram
nessa categoria;
• Ferramentas de integração e teste: as três subcategorias mais amplamente utilizadas são
as ferramentas de análise estática que documentam e catalogam os testes comparando as
saídas dos mesmos com o resultado esperado; as ferramentas de análise dinâmica que
fazem o controle checando quantas vezes o programa passou por determinado trecho de
código e testando valores de variáveis; e as ferramentas de gerenciamento de teste que
são usadas para controlar e coordenar os testes realizados durante cada etapa da
atividade de testes;
• Ferramentas de prototipação: ferramentas que suportem o paradigma de prototipação da
Engenharia de Software podem ser incluídas nessa categoria;
• Ferramentas de manutenção: absorvem grande parte do esforço relacionado ao software.
Estão contidas nessa categoria as ferramentas de engenharia reversa, as quais captam o
código fonte e geram modelos gráficos de análise e projeto e as ferramentas de
reengenharia que avaliam o software atual necessitando de um engenheiro de software
para modificar o que for necessário e assim gerar um novo sistema;
• Ferramentas de estrutura: exibem componentes funcionais que suportam dados, interface
e integração de ferramentas. A maioria dessas ferramentas oferece alguma capacidade de
gerenciamento de configuração, dando possibilidade ao usuário da ferramenta controlar
as mudanças em todos os itens de configuração criados por todas as ferramentas CASE
integradas com a ferramenta de estrutura; e
• Ferramentas de gerenciamento de projetos: podem influenciar a melhoria de qualidade
do gerenciamento de projetos para esforços de desenvolvimento de software. Através
delas o gerente de projetos pode gerar estimativas de esforço, custo e duração de um
projeto de software, ou seja, acompanhar projetos do início ao fim. Ferramentas de
planejamento de projetos podem auxiliar o gerente de projetos a estimar o tamanho do
projeto e também descreva sua complexidade e maturidade do processo, por exemplo.
Existem também as ferramentas de métricas e gerenciamento que fazem com que o
22
gerente possa controlar e coordenar o processo de Engenharia de Software melhorando a
qualidade do software produzido. As ferramentas de rastreamento de requisitos estão
incluídas nessa categoria, já que oferecem formas de poder rastrear os requisitos desde o
requerimento original da proposta do cliente até o trabalho de desenvolvimento.
A ferramenta deste trabalho é categorizada principalmente como uma ferramenta de
gerenciamento de projetos, já que ela irá auxiliar as etapas de análise de requisitos, facilitando o
rastreamento dos mesmos eqüalizando as necessidades do cliente e dos usuários com as
funcionalidades do sistema a ser desenvolvido. A ferramenta também é categorizada como uma
ferramenta de apoio, pois irá gerar documentação baseada em práticas recomendadas melhorando
assim a produtividade.
2.2.2. Benefícios e desvantagens das ferramentas CASE
Em muitos casos, as vantagens de se utilizar ferramentas CASE são mais qualitativas do que
quantitativas. O tempo gasto com o desenvolvimento utilizando essas ferramentas será sempre
menor, porém o benefício maior é a garantia de que o desenvolvimento está sendo realizado como
foi planejado de acordo com as necessidades do usuário.
A maioria das atividades de rotina no processo de software já suporta a tecnologia das
ferramentas CASE. Muitas melhorias na qualidade e na produtividade de software foram devidas ao
uso dessas ferramentas (SOMMERVILLE, 2003).
Fischer (1990) cita as especificações completas dos requisitos como sendo uma vantagem
das ferramentas CASE. Muitos projetos já fracassaram por não ter uma boa especificação de
requisitos, fazendo com que seja implementado algo que não foi o que o cliente solicitou. Para
reduzir a probabilidade de se obter fracasso, uma especificação completa deve ser construída.
Ainda segundo Fischer (1990), uma outra vantagem das ferramentas CASE é que com elas é
possível produzir especificações minuciosas do projeto, que são muito importantes no momento de
realizar algum tipo de manutenção no sistema. As especificações constantes na versão atual do
projeto podem estar sempre atualizadas devido a uma sincronia com o processo de implementação e
a situação atual das especificações do mesmo.
Os sistemas desenvolvidos utilizando a estrutura que as ferramentas CASE impõem na
aplicação e documentação, podem ter uma manutenção mais fácil do que os sistemas desenvolvidos
23
sem essa estrutura. A redução do tempo de desenvolvimento também é um fator de qualidade das
ferramentas CASE, pois a perda de tempo com códigos desnecessários é eliminada ou reduzida
substancialmente (SOMMERVILLE, 2003).
2.3. MODELOS DE DOCUMENTOS DE ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE
No auge da tarefa de análise, é produzida a Especificação de Requisitos de Software (ERS)
que, segundo Paula Filho (2001), é o resultado do fluxo de requisitos. Esse fluxo tem como objetivo
primário reunir as atividades que visam obter descrições claras e precisas dos requisitos de um
produto de software. Pressman (1995) afirma que o documento de ERS trata de estabelecer uma
descrição completa da informação sobre a função e o desempenho atribuídos ao software, bem
como fornecer uma indicação dos requisitos e restrições de projeto.
Peters e Pedrycz (2001) dizem que um documento de ERS descreve um produto de software,
programa ou conjunto de programas específico, executando uma série de funções em seu ambiente.
Kotonya e Sommerville (1997) apresentam algumas características que esse documento deve ter:
1. Lista de funções e serviços que o sistema deve fornecer;
2. Restrições sob as quais o sistema deve operar;
3. Propriedades gerais do sistema;
4. Definições de outros sistemas onde haverá integração com o sistema desenvolvido;
5. Informações sobre o domínio de aplicação; e
6. Restrições no processo utilizado para desenvolver o sistema.
Baseado nessas definições, existem algumas abordagens para escrever um documento de
Especificação de Requisitos de Software. O IEEE, o Departamento de Defesa Americano e o Birô
Nacional de Padrões são entidades que propõem exemplos de possíveis propostas para o formato
dessas especificações.
Segundo Schlickmann Júnior (2002), a falta de metodologia para desenvolvimento de
software acarreta vários problemas para uma organização. A busca pela rapidez no
desenvolvimento contrasta com a qualidade do produto final. Uma metodologia de desenvolvimento
de software bastante aplicada não só na indústria de software, é o RUP (Rational Unified Process).
24
Essa metodologia foi criada para contemplar o ciclo de desenvolvimento de um software completo
através das melhores práticas sendo composto por um conjunto de atividades bem definidas.
Este trabalho objetiva unir as melhores práticas recomendadas para desenvolvimento do
software através do RUP, focalizando na disciplina de requisitos juntamente com a abordagem do
padrão IEEE 830-1998, ambos detalhados nas seções seguintes.
2.3.1. IEEE 830-1998
Segundo IEEE (1998), o documento IEEE-830-1998 contém a descrição da especificação de
requisitos de software. Ele é uma prática recomendada para escrever as especificações do software.
Esse documento descreve características que um bom documento de Especificação de Requisitos de
Software deve ter. Essas práticas recomendadas descrevem a criação e o conteúdo de um produto
final, ou seja, a criação da ERS, que deve ser um documento sem ambigüidade e completo. Esse
documento deve ajudar:
• Os consumidores a descrever o que eles realmente querem obter;
• Os fornecedores a fim de que fique bem entendido o que o cliente quer; e
• A realização dos objetivos individuais: desenvolver um esboço do padrão da ERS para
suas próprias organizações; definir o formato e o conteúdo de suas especificações de
software e desenvolver listas de verificação para controle de qualidade ou até mesmo um
manual sobre ERS.
Essas práticas recomendadas podem ser utilizadas para a criação do próprio documento de
especificação de software como também pode servir de alicerce para a criação de um modelo mais
específico. De forma geral, esse documento não identifica nenhum método, ferramenta, ou
nomenclatura para a preparação da ERS.
2.3.1.1. Informações relevantes para construção de um bom documento de ERS
IEEE (1998) afirma que algumas informações devem ser consideradas ao escrever um
documento de ERS. As seções seguintes descrevem, de uma forma resumida, as informações
pertinentes ao documento de ERS baseado no padrão IEEE-830-1998.
25
2.3.1.1.1. Natureza da ERS
Um documento de ERS é escrito especificamente para um produto de software, programa ou
conjunto de programas em um ambiente específico. Alguns itens dessa seção que devem ser
considerados para a ERS são: funcionalidade, interfaces externas, performance, atributos e
requisitos de projeto impostos na implementação.
2.3.1.1.2. Ambiente da ERS
O documento de ERS de um software pode conter todas as funções essenciais para o projeto
ou ser uma parte de um grande sistema. Nesse último caso, o documento deve fazer a descrição das
interfaces de relacionamento com os outros módulos do sistema. Deve estar claro para a pessoa
responsável por escrever o documento de ERS que:
• A ERS deve definir corretamente todos os requisitos de software. Esses requisitos
podem surgir devido a características especiais do projeto;
• Nenhum detalhe de projeto e implementação deve estar incluso na ERS. Esses devem ser
descritos na etapa de projeto; e
• A ERS não pode impor novos requisitos ao software. Isto deve ser especificado por
outros documentos, tal como o plano de garantia de qualidade.
2.3.1.1.3. Características da ERS
Algumas características são necessárias para um bom documento de ERS, tais como:
• Correta: uma ERS é correta somente quando cada requisito indicado pode ser
contemplado pelo software;
• Sem ambigüidade: todos os requisitos levantados devem possuir somente uma
interpretação. Para isso, os requisitos devem ser descritos através de termos únicos e
simples;
• Completa: para ser completa, uma ERS precisa conter todos os requisitos significantes
relacionados à funcionalidade, desempenho, restrições de projeto, entre outros. Todos os
requisitos externos impostos por uma especificação de sistema devem ser conhecidos e
tratados. Deve conter também a definição das respostas do software para entradas
válidas e inválidas, além de rótulos e referências para todas as tabelas, diagramas e
26
figuras na ERS, bem como definição de todos os termos e unidades de medidas
utilizadas;
• Consistente: caso uma ERS não esteja de acordo com algum documento de alto nível,
como uma especificação de sistema, então ela não estará correta;
• Classificada por importância ou estabilidade: uma ERS é classificada dessa forma se
cada requisito descrito contiver algo que identifique a importância ou a estabilidade
desse requisito em particular. Nem todos os requisitos são importantes da mesma forma,
alguns podem ser essenciais e outros podem ser somente desejáveis;
• Verificável: para a ERS ser verificável, é imprescindível que todos os requisitos sejam
verificáveis. Os requisitos, por sua vez, somente poderão ser verificáveis se uma pessoa
ou uma máquina puder checar que o produto de software atende aos requisitos
levantados;
• Modificável: uma ERS é modificável se, e somente se, sua estrutura forneça meios para
que os requisitos possam ser facilmente alterados mantendo sua consistência e a
estrutura, caso seja necessário; e
• Rastreável: uma ERS é considerada rastreável se a origem dos requisitos contidos nela
pode ser identificada de maneira clara, facilitando que cada requisito possa ser
referenciado em algum desenvolvimento futuro ou em alguma documentação.
2.3.1.1.4. Preparação conjunta da ERS
O processo de desenvolvimento de software deve começar com um acordo entre o
fornecedor e o cliente, o qual deve conter tudo o que o software deve fazer. Esse acordo deve ser
preparado conjuntamente entre as duas partes. Isso é importante, pois geralmente nem o cliente nem
o fornecedor estão qualificados para escrever um bom documento de ERS sozinhos.
27
2.3.1.1.5. Evolução
Enquanto o desenvolvimento do projeto progride, a ERS pode ter que evoluir da mesma
forma. Isso porque existem alguns itens que podem ser impossíveis de definir na fase de
levantamento de requisitos. Duas considerações são importantes nesse processo:
• Os requisitos devem ser descritos completamente conforme o que é conhecido naquele
momento, até porque as revisões, devido à evolução, serão inevitáveis; e
• Um processo de mudança formal deve ser iniciado para identificar, controlar, rastrear, e
reportar as mudanças de projeto. Mudanças aprovadas devem ser incorporadas ao
documento de ERS.
2.3.1.1.6. Prototipação
A prototipação é utilizada freqüentemente em módulos de um projeto. Quando o cliente
interage com algo concreto, ele tem mais facilidade para dizer o que realmente irá querer de
resultado final do produto de software. Aspectos do comportamento do sistema são mostrados
antecipadamente, podendo assim fazer com que novos requisitos possam ser identificados. Dessa
maneira, o documento de ERS pode ser menos modificado no processo de desenvolvimento do
software. A prototipação é considerada uma forma de levantar requisitos.
2.3.1.1.7. Adequando o projeto à ERS
Um requisito especifica uma função visível externamente ou um atributo de sistema. Um
projeto descreve um componente de um sistema e/ou suas relações com outros componentes. Quem
está escrevendo a ERS deve claramente distinguir a identificação de requisitos requeridos e realizar
um projeto específico. Cada requisito pode limitar as alternativas de projeto, no entanto, isso não
significa que cada requisito é um projeto.
2.3.1.1.8. Adequando os requisitos de projeto à ERS
A ERS deve estar focada no produto de software e não ao processo de como produzir esse
produto de software. Os requisitos de projeto que representam um entendimento entre o cliente e o
fornecedor sobre aspectos pertinentes à produção do software não devem estar incluídas na ERS.
Requisitos de projeto são especificados através de outros documentos, como por exemplo, em um
plano de desenvolvimento de software ou em um plano de garantia de qualidade.
28
2.3.1.2. Seções de um documento de ERS
Para ter um bom entendimento, o documento de ERS, de acordo com IEEE (1998), é
dividido em seções, essas discutem cada parte essencial da especificação. A estrutura da seção de
requisitos específicos de um documento de ERS pode ser organizada por modalidade, classes de
usuário, objetos, características, estímulos, hierarquia funcional ou múltiplas organizações. Um
esboço básico da estrutura de um documento de ERS com seus itens essenciais é mostrado na
Figura 5 e detalhado a seguir.
Índice
1. Introdução
1.1. Propósito
1.2. Escopo
1.3. Definições, acrônimos e abreviaturas
1.4. Referências
1.5. Visão geral
2. Descrição geral
2.1. Perspectiva do produto
2.2. Funções do produto
2.3. Características do usuário
2.4. Restrições
2.5. Dependências e suposições
3. Requisitos específicos
Apêndices
Figura 5. Esboço da estrutura de um documento de ERS
Fonte: Adaptado de IEEE (1998).
A introdução deve fornecer uma visão geral do documento de ERS. Para isso, essa parte do
documento contém as seguintes seções subordinadas a ela:
• Propósito: deve delinear a finalidade do documento, bem como o que é pretendido com
o mesmo;
• Escopo: essa subseção visa especificar o que o produto a ser produzido deverá ou não
fazer. Deve também conter uma breve descrição incluindo os benefícios e objetivos a
serem alcançados. O escopo necessita ser também consistente com as especificações de
alto nível, tais como as especificações de requisito de sistema;
• Definições, acrônimos e abreviaturas: todos os termos necessários para a interpretação
do documento de ERS devem ser definidos nessa subseção. Essas informações podem
29
ser obtidas através de referências de um ou mais apêndices na própria ERS ou
referências de outros documentos;
• Referências: os documentos referenciados em qualquer parte da ERS devem ser listados
nessa subseção. Cada referência de documento deve conter título, data e o nome da
organização; e
• Visão geral: descreve todo o conteúdo restante da ERS e explica como o documento está
organizado.
A segunda seção do documento de ERS deve descrever de forma geral os aspectos que
afetam o produto e seus requisitos, por isso, não apresenta os requisitos específicos. Entretanto
fornece a base para o entendimento dos mesmos, os quais estarão descritos detalhadamente na seção
três do documento de ERS. A seguir são apresentadas as cinco subseções da descrição geral do
documento de ERS.
• Perspectiva do produto: essa subseção tem como objetivo obter uma perspectiva do
produto a ser desenvolvido com outros produtos relacionados disponíveis. Caso o
produto seja totalmente independente de outros, deve ser indicado nessa subseção. Se a
ERS for de um software que faz parte de um grande sistema, então os requisitos desse
sistema para que este software funcione devem ser apresentados aqui, bem como as
interfaces que farão o relacionamento desse software com o sistema. De forma geral,
essa subseção deve descrever como o software irá operar dentro de várias circunstâncias,
como por exemplo, interface de rede, interface com o usuário, restrições de memória
entre outras;
• Funções do produto: essa subseção deve conter uma lista das funções mais importantes
que o software irá executar. Às vezes essa listagem pode ser feita diretamente das
especificações de alto nível, se assim existirem, onde funções particulares são alocadas
ao produto de software. As funções devem estar organizadas de forma a proporcionar
entendimento tanto ao cliente quanto para qualquer outro que leia o documento pela
primeira vez, para isso as informações podem ser apresentadas em forma de texto ou
através de gráficos;
• Características do usuário: as características gerais dos usuários devem estar inclusas
nessa subseção, tais como, nível educacional, experiência e perícia técnica;
30
• Restrições: essa subseção deve fornecer uma descrição geral de qualquer item que irá
limitar as opções de desenvolvimento, incluindo, por exemplo, as funções de controle,
questões de segurança, relacionamento com outras aplicações e limitações de
hardware; e
• Dependências e suposições: uma listagem de cada aspecto que afeta os requisitos
indicados na ERS deve ser criada nessa subseção. Esses fatores podem não ser restrições
do projeto, mas são todos os tipos de mudança que podem afetar os requisitos em um
documento de ERS.
A seção três do documento de ERS, de acordo com IEEE (1998), deve conter a descrição de
todos os requisitos de software em um nível de detalhe suficiente para que o sistema seja
implementado e possa ser testado para garantir que o mesmo satisfaça todos os requisitos
levantados. Por se tratar da parte mais importante em uma ERS, os seguintes princípios são válidos:
• Requisitos específicos devem ser levantados seguindo as características descritas na
Seção 2.3.1.1.3;
• Requisitos específicos devem ser descritos fazendo referência a documentos
anteriormente relacionados;
• Todos os requisitos devem possuir identificação única; e
• Atenção especial deve ser dada à organização dos requisitos para aumentar a legibilidade
do documento.
Conforme já citado anteriormente, IEEE (1998) sugere algumas formas de organizar os
requisitos específicos em um documento de ERS, tais como: (i) modalidade de sistema, como por
exemplo, para treinamento, normal ou de emergência; (ii) classes de usuário, funções agrupadas por
conjuntos de usuários; (iii) objetos, um conjunto de atributos é associado a cada objeto, ou seja, a
cada entidade no mundo real; (iv) características, que é um resultado esperado de acordo com um
conjunto de entradas; (v) estímulos, as funções são descritas através de estímulos; (vi) resposta,
descreve todas as funções que suportam a geração de resposta; (vii) hierarquia funcional, a
funcionalidade total pode ser organizada dentro da hierarquia funcional; (viii) múltiplas
organizações, é utilizada quando existe uma possibilidade de unir mais do que um tipo de forma de
organização do documento de ERS.
31
Os itens que compreendem os requisitos são: relacionamento externo, funções, requisitos de
desempenho, requisitos lógicos de banco de dados, restrições de projeto, atributos de sistema e a
organização dos requisitos específicos.
Por fim, a ERS é composta também por comentários finais e informações para tornar a
compreensão da mesma mais fácil, tais como tabela de conteúdos, índice e apêndices.
2.3.2. Rational Unified Process - RUP
Sommerville (2003) afirma que um processo de software é um conjunto de atividades e
resultados associados que produzem um produto de software. O RUP (Rational Unified Process),
segundo Rational (2002), é um considerado um processo de Engenharia de Software. A atribuição
de tarefas e as responsabilidades dentro de uma organização podem ser dirigidas por esse processo.
O objetivo principal do RUP é garantir que o software seja produzido com qualidade e que as
necessidades dos usuários sejam supridas dentro do orçamento previsto.
2.3.2.1. Visão geral do RUP
Conforme mostrado na Figura 6, o RUP possui duas dimensões, pelas quais é demonstrada a
estrutura do mesmo. O eixo horizontal representa a dimensão dinâmica, mostrando o tempo e os
aspectos do ciclo de vida do processo. O eixo vertical representa as disciplinas, que agrupam as
atividades logicamente e que são tratadas como dimensão estática.
A dimensão dinâmica do RUP, segundo Kruchten (2000 apud SCHLICKMANN JÚNIOR,
2002), é composta por quatro fases conforme mostra a Figura 6. Para fazer a divisão entre essas
fases, existem marcos, esses por sua vez, são pontos definidos no tempo para operar como funções
de entrada baseadas em critérios claros e que definem se é possível passar para próxima fase,
abortar ou mudar o curso da fase atual.
32
Figura 6. Disciplinas, fases e iterações do RUP
Fonte: Adaptado de Rational (2002)
Kruchten (2000 apud SCHLICKMANN JÚNIOR, 2002) descreve as quatro fases de
maneira simplificada, conforme são apresentadas a seguir:
• Concepção: visa determinar o escopo do projeto, planejar e preparar os casos de
negócio, sintetizar uma arquitetura provável de ser utilizada e preparar o ambiente do
projeto. O marco dessa etapa é avaliar a viabilidade do projeto;
• Elaboração: nessa fase, o projeto e a implementação do software estão voltados à
arquitetura, fazendo com que alguns riscos técnicos sejam suavizados;
• Construção: fase na qual é desenvolvido e detalhado o protótipo inicial do produto
operacional. O foco dessa fase é dirigido ao projeto e implementação; e
• Transição: visa garantir que o nível de qualidade do software seja suficiente para
cumprir os objetivos propostos no início do projeto, fixando problemas, treinando
usuários, ajustando características e adicionando novas funcionalidades. Essa fase
também contempla a produção e entrega do software final.
Segundo Pires et al. (2004), uma disciplina é uma coleção de atividades relacionadas que se
interligam por meio de sua área de interesse dentro do processo. A seqüência de atividades
agrupadas com a produção de um resultado final é descrita através das disciplinas do RUP. Para
33
cada conjunto de atividades existe um diagrama de detalhamento do fluxo de trabalho. Esses, por
sua vez, dão uma visão geral do contexto, mostrando as atividades, papéis envolvidos e os artefatos
de entrada e saída.
Segundo Rational (2002), um papel é uma definição abstrata para um conjunto de atividades
executadas e seus artefatos acoplados. Geralmente os papéis são realizados por uma pessoa ou um
conjunto de pessoas trabalhando em equipe. Um membro de uma equipe pode exercer a função de
vários papéis ao mesmo tempo.
As atividades estão diretamente relacionadas com os artefatos. Os artefatos são responsáveis
por fornecer as entradas e as saídas para as atividades, é através deles que a informação é passada
entre as atividades (RATIONAL, 2002).
Rational (2002) também afirma que uma iteração abrange as atividades do desenvolvimento
que levam a uma versão de produto estável juntamente com todos os outros elementos necessários.
As iterações estão em consonância com todas as disciplinas do RUP. A duração de cada iteração
depende do tamanho e da natureza do projeto. É provável que múltiplas configurações sejam
construídas em cada iteração, conforme especificado no plano de integração para cada uma dessas.
A primeira disciplina apresentada é a disciplina de Modelagem de Negócios. O propósito
principal dessa disciplina, segundo Rational (2002), é mostrar a estrutura e as características
dinâmicas da organização nas quais o sistema irá funcionar, bem como fornecer uma visão geral do
objetivo da organização identificando problemas e implementando melhorias. Essa disciplina visa
também fornecer entendimento do objetivo geral da organização aos stakeholders modificando os
requisitos de sistema para que esteja adequado aos objetivos da mesma. Informações importantes
para a disciplina de requisitos são geradas a partir da disciplina de modelagem de negócios. Para
complementar a Modelagem de Negócios, é gerado o glossário e a especificação de negócio
complementar.
A disciplina de requisitos, resumidamente, tem por objetivo manter entendimento entre o
que o cliente deseja e o que o software deve executar (RATIONAL, 2002). Por ter maior relevância
neste trabalho, a disciplina de requisitos é abordada detalhadamente na Seção 2.3.2.2.
Transformar os requisitos em um sistema propriamente dito, segundo Rational (2002), é um
dos propósitos da disciplina de análise e projeto. Criar uma arquitetura robusta adaptando o projeto
com o ambiente de execução do mesmo analisando o desempenho também pode ser considerado um
34
dos propósitos dessa disciplina. As entradas para essa disciplina são fornecidas pela disciplina de
requisitos, conforme explanado na Seção 2.3.2.2.
Os propósitos da disciplina de implementação são: (i) definir a organização do código, em
termos de sistemas organizados em camadas; (ii) implementar componentes de classes e objetos;
(iii) testar os componentes desenvolvidos como módulos e (iv) integrar os resultados produzidos
por desenvolvedores individuais ou equipes em um sistema executável. Essa disciplina delimita
como as classes individuais serão testadas.
A disciplina de testes atua como um provedor de serviços às outras disciplinas. Para isso,
através dela são procuradas e documentadas as falhas na qualidade do software, a validação do
software também é realizada, bem como a validação dos requisitos para saber se foram
implementados de forma correta ou não.
A descrição das atividades associadas para assegurar que o software esteja disponível para
os usuários finais é o papel da disciplina de implantação. Essa disciplina descreve três modos de
implantação do produto: instalação personalizada, produto de forma “compacta” e acesso ao
software através da Internet. Embora o auge das atividades da disciplina de implantação esteja
focado na fase de transição, algumas atividades podem ocorrer em fases anteriores para fazer o
planejamento e a preparação para a implantação.
A disciplina de ambiente está focada nas atividades necessárias para configurar os processos
para um projeto. Nessa disciplina são descritas as atividades requeridas para desenvolver a base de
um projeto. O propósito principal dessa atividade é fornecer uma organização do software com o
ambiente onde ele está sendo desenvolvido.
O gerenciamento de projeto de software, segundo Rational (2002), é a arte de poder fazer o
balanceamento de objetivos competitivos, controlando riscos, e superando restrições para entregar
um produto de software que atenda as necessidades dos clientes e dos usuários. A disciplina de
gerenciamento de projetos é apresentada de forma a fornecer subsídios para fazer o controle do
projeto, aumentando assim a probabilidade de que o produto seja entregue com sucesso. Em suma,
essa disciplina fornece a estrutura para o controle, planejamento e o monitoramento de projetos.
O gerenciamento de configuração é essencial para controlar os inúmeros artefatos que são
produzidos quando muitas pessoas estão envolvidas em um projeto. Para isso, a disciplina de
gerenciamento de configuração e mudança ajuda a evitar confusões e garante que não haja conflitos
35
com os artefatos resultantes. Essa disciplina envolve a identificação, as mudanças de restrições, a
definição e o gerenciamento dos itens de configuração.
2.3.2.2. Disciplina de Requisitos
Segundo Rational (2002), os propósitos dessa disciplina são os seguintes:
• Estabelecer e manter concordância com os clientes e os stakeholders sobre o que o
sistema deverá fazer;
• Fornecer aos desenvolvedores do sistema um maior entendimento sobre os requisitos;
• Traçar o escopo do sistema;
• Fornecer base para o planejamento do conteúdo técnico das iterações;
• Fornecer base para a estimativa de custo e tempo do desenvolvimento do sistema; e
• Definir uma interface de usuário para o sistema, ponderando as necessidades e metas dos
usuários.
É de primordial importância que se compreenda de forma clara a definição e o escopo do
problema que será solucionado com o sistema a ser desenvolvido. Para isso, os stakeholders devem
ser identificados, as solicitações dos mesmos levantadas, reunidas e analisadas.
Segundo Rational (2002), alguns artefatos estão envolvidos com a disciplina de requisitos.
Dois modelos são apresentados pelo RUP nessa disciplina, um tratando os casos de uso e outro não.
As descrições do que o software deverá realizar, conforme mostra a Figura 7, são constituídas pelos
seguintes artefatos: documento de visão, modelo de casos de uso e seu detalhamento, atributos de
requisitos, solicitações dos stakeholders, glossário, o plano de gerenciamento de requisitos, a
especificação suplementar, pacote, encenação, o protótipo da interface do usuário e por fim, a
Especificação de Requisitos de Software. As fontes de informação para a geração desses requisitos,
são os clientes, usuários potenciais e os requisitos de sistema.
36
Figura 7. Papéis e artefatos utilizados na disciplina de requisitos
Fonte: Adaptado de Rational (2002).
Um documento de visão é um artefato no qual é descrito a visão que os stakeholders têm das
necessidades e características mais importantes do produto a ser desenvolvido que também serve de
alicerce para a descrição dos requisitos técnicos mais detalhados.
O modelo de casos de uso, que é um modelo das funções pretendidas do sistema e seu
ambiente, serve como um contrato entre os clientes, usuários e os desenvolvedores. Basicamente, o
modelo de casos de uso consiste em casos de uso e atores. Com esse modelo, é possível que os
usuários e clientes validem que o sistema realmente atende as necessidades dos mesmos e também
fornecer uma visão das funcionalidades para que os desenvolvedores construam o que está sendo
esperado por seus stakeholders.
As especificações suplementares têm como objetivo capturar os requisitos de sistema que
não foram capturados nos casos de uso. Sendo assim, esse artefato é um complemento bastante
importante para o artefato modelo de casos de uso. Esses dois artefatos, capturam todos os
requisitos do software que precisam ser descritos para descrever um bom documento de ERS.
O artefato solicitações dos stakeholders também interage com a disciplina de requisitos
reunindo as fontes existentes para se obter uma lista das necessidades dos clientes e usuários
potenciais juntamente com informações de como essas solicitações foram consideradas para o
projeto.
37
O artefato que especifica as informações e controla os mecanismos que serão usados para
medir, relatar e controlar mudanças nos requisitos do produto é o artefato plano de gerenciamento
de requisitos, o qual também está envolvido com a disciplina de requisitos.
De forma complementar aos artefatos já mencionados, os artefatos a seguir também estão
relacionados com a disciplina de requisitos:
• Glossário: define uma terminologia comum que é utilizada de forma consistente na
organização ou no projeto do software;
• Encenação de caso de uso: descrição lógica e conceitual de como um caso de uso é
fornecido pela interface do usuário; e
• Protótipo da interface do usuário: podem se manifestar através de esboços ou figuras
entre outros.
Para completar o entendimento da disciplina de requisitos, as atividades e os artefatos estão
organizados em etapas do fluxo de trabalho da disciplina. Cada etapa desse fluxo reflete ações que
precisam ser implementadas para poder executar o gerenciamento de requisitos de forma eficiente.
O fluxo de trabalho para a disciplina de requisitos é mostrado na Figura 8.
38
Figura 8. Fluxo de atividades da disciplina de requisitos
Fonte: Adaptado de Rational (2002).
O relacionamento da disciplina de requisitos com as outras disciplinas se dá conforme
apresentado a seguir:
• A disciplina Modelagem de Negócios fornece as regras de negócios, um modelo de
casos de uso de negócios e um modelo de objeto de negócio;
• A disciplina Análise e Projeto obtêm suas informações primárias dos requisitos. Falhas
no modelo de casos de uso podem ser descobertas nessa disciplina;
• A disciplina de Teste valida o sistema com base principalmente no modelo de casos de
uso;
• A disciplina Gerenciamento de Configuração e mudança fornece o mecanismo para
controle de mudanças dos requisitos;
39
• A disciplina de Gerenciamento de Projeto planeja o projeto e cada iteração (descritas em
um Plano de Iteração); e
• A disciplina Ambiente desenvolve e mantém os artefatos de suporte usados no
gerenciamento de requisitos e na modelagem de caso de uso.
2.3.3. Análise comparativa entre os modelos
Pode-se perceber que os padrões de práticas recomendadas apresentadas no documento
IEEE-830-1998 são dispostos de forma resumida, já na documentação do RUP eles são
apresentados de forma bem mais detalhada.
O RUP fornece dois modelos de estrutura para um documento de ERS, um contendo a
modelagem de dados de casos de uso e outro não. Nos dois casos é dada a orientação para se
consultar o documento IEEE-830-1998 sobre a forma de organizar um documento de ERS.
A primeira seção do documento de ERS, a introdução, é comum tanto para o IEEE quanto
para o RUP, contendo as seções: (i) propósito, (ii) escopo, (iii) definições, acrônimos e abreviaturas,
(iv) referências e (v) visão geral; essas estão descritas na Seção 2.3.1.2 deste projeto.
A seção que faz a descrição geral do produto também está contida nos dois padrões, porém,
no RUP, quando se utiliza o modelo de ERS com casos de uso, existe um item adicional. Item esse
que contém uma visão geral do modelo de casos de uso ou do subconjunto desse modelo aplicável a
esse subsistema ou recurso, e é identificada como relatório sintético de modelo de casos de uso.
A seção três do documento é apresentada de três formas: no documento IEEE-830-1998, no
modelo do RUP com casos de uso e sem casos de uso. Nesse primeiro, são dadas apenas algumas
diretrizes, informando que essa seção deve conter a descrição de todos os requisitos em nível de
detalhe suficiente para ser implementado e testado atendendo a todos os requisitos, conforme já
explanado na Seção 2.3.1.2.
O modelo de ERS do RUP que não contém a modelagem de casos de uso tem o mesmo
objetivo, porém já traça alguns subitens que podem ser considerados, tais como a descrição das
interfaces que serão utilizadas, a divisão dos requisitos em categorias (algumas dessas categorias
podem ser observadas na Seção 2.1.2.2), quais padrões são aplicáveis, entre outros.
40
Já o modelo que contém a modelagem de casos de uso, essa seção não contém tantos
detalhes pré-definidos, até porque os requisitos serão capturados através dos artefatos de casos de
uso e especificações suplementares.
Conclui-se que o documento IEEE-830-1998 é mais sucinto que os documentos propostos
pelo RUP, porém, grande parte essencial para um documento de ERS é comum entre os dois.
Segundo Rational (2002), o RUP fornece modelos prontos para serem utilizados com o Microsoft
Word, Adobe FrameMaker, HyperText Markup Language (HTML), e Microsoft Project. O modelo
do IEEE, segundo IEEE (1998), não fornece modelos prontos para serem utilizados, porém é
munido de um esboço simples para a estrutura de um documento de ERS, e também provê outros
modelos organizados de diversas formas conforme mostra a Seção 2.3.1.2.
A proposta deste projeto é utilizar o modelo especificado pelo RUP sem os casos de uso,
tendo como base o padrão do IEEE e os detalhamentos dos itens mais importantes dos artefatos da
disciplina de requisitos do próprio RUP.
2.4. FERRAMENTAS SIMILARES
Atualmente existem várias ferramentas no mercado que ajudam a fazer o gerenciamento de
requisitos, porém, geralmente elas têm um custo elevado. Trabalhos de conclusão de curso também
têm proposto ferramentas similares. Nas subseções seguintes são mostrados três exemplos de
ferramentas que trabalham com gerenciamento de requisitos e uma análise comparativa entre elas.
2.4.1. RequisitePro
A ferramenta RequisitePro, pertencente a Rational e que hoje é propriedade da IBM, é
utilizada para documentar e gerenciar requisitos durante todo o ciclo de vida de um projeto. Essa
ferramenta implementa conceitos e técnicas de gerenciamento de requisitos estando integrada com
outros produtos da própria Rational. O RequisitePro fornece modelos prontos para elaboração do
documento de ERS de acordo com os artefatos do RUP e também disponibiliza meios para realizar
as configurações dos requisitos, permitindo que sejam criados novos modelos.
A Figura 9 mostra um exemplo de matriz de rastreabilidade na ferramenta RequisitePro.
41
Figura 9. Tela de rastreabilidade da ferramenta Rational RequisitePro
Fonte: Adaptado de Rational (2002).
Um diferencial dessa ferramenta é que ela gera documentos de forma integrada com o
Microsoft Word. O custo da ferramenta é um aspecto negativo, já que o valor de uma única licença
ultrapassa os US$ 2.120,00, de acordo com IBM (2005).
2.4.2. RaQuest
RaQuest também é uma ferramenta de gerenciamento de requisitos. Ela foi desenvolvida por
uma filial da empresa Sparx Systems no Japão para servir de apoio a outro produto concebido pela
mesma empresa, o Enterprise Architect (EA). Dessa forma, o RaQuest fornece meios para o
rastreamento de requisitos, gerenciamento dos mesmos de forma hierárquica, gerando documentos
para todo o projeto ou parte do projeto nos formatos HTML, CSV (Comma Separated Value), Word
e Excel. Vale ressaltar que, segundo Sparx Sytems (2005), essa ferramenta está em constante
atualização (a cada duas semanas) enquanto seus objetivos são implementados.
42
A Figura 10 mostra uma tela da ferramenta RaQuest da Sparx Systems.
Figura 10. Tela para visualização dos termos de glossário cadastrados na ferramenta RaQuest
Fonte: Adaptado de Sparx Systems (2005).
Uma restrição para que essa ferramenta possa funcionar corretamente é que o usuário deve
ter obrigatoriamente instalado outro programa da empresa Sparx Systems, o Enterprise Architect
(EA) 4.1.737 ou superior já que o RaQuest foi desenvolvido de maneira integrada. Para adquirir o
RaQuest, segundo Sparx Sytems (2005), é necessário desembolsar cerca de US$ 150,00, e para o
EA em torno de US$ 125,00 a US$ 315,00 dependendo da versão.
2.4.3. Requisitemanager
O Requisitemanager é uma ferramenta que foi desenvolvida como trabalho de conclusão de
curso pelo acadêmico Luciano Marquardt da Universidade Regional de Blumenau (FURB), no ano
de 2004 (MARQUARDT, 2004). A definição de uma política de requisitos, controle e
rastreabilidade dos mesmos estão incorporados nessa ferramenta, além da geração de relatórios. O
documento de ERS gerado por essa ferramenta está de acordo com o documento IEEE-830-1993,
43
porém a estrutura das seções do documento não é passível de alteração, o modelo padrão já é
fornecido pelo sistema.
O grande diferencial dessa ferramenta é que ela utiliza a interface web. A Figura 11
demonstra como o usuário pode cadastrar os dados para a futura geração do documento de
Especificação de Requisitos de Software na ferramenta Requisitemanager.
Figura 11. Tela para cadastro das seções do documento de ERS na ferramenta requisitemanager
Fonte: Adaptado de Marquardt (2004).
44
2.4.4. Análise comparativa entre as ferramentas
A Tabela 2 a seguir mostra alguns aspectos considerados para efeito de comparação que
existem nas três ferramentas em uma visão geral.
Tabela 2. Aspecto geral da comparação entre as ferramentas apresentadas
Ferramenta Rastreabilidade Revisões / Histórico
Configuração dos Requisitos
Custo Plataforma
RequisitePRO Configurável Sim Sim US$ 2.120 Windows RaQuest Estática
(somente de requisitos para casos de uso)
Sim Sim US$ 150 + US$ 125/315
Windows
RequisiteManager Configurável Sim Permitido somente até a liberação para os usuários
Uso acadêmico – Alunos FURB
WEB (PHP)
Vale ressaltar que apenas a ferramenta RequisitePRO foi testada em suas funcionalidades
básicas, onde apresentou um alto nível de complexidade para que um usuário possa usufruir das
funções que ela se propõe a executar. Um fator que foi considerado ruim é que para cada alteração
nos requisitos, era gerado um item de histórico, deixando o documento final muito grande.
Ponderando que o documento de Especificação de Requisitos de Software é de fundamental
importância no gerenciamento de requisitos, uma comparação com alguns itens relevantes nas
ferramentas apresentadas é mostrada na Tabela 3.
Tabela 3. Características específicas do documento de ERS
Ferramenta Templates de documentos
Padrão Formato documento
RequisitePRO Sim RUP CSV Microsoft Word (Sincronizado)
RaQuest Não Próprio HTML CSV Microsoft Word Enterprise Architect
RequisiteManager Sim IEEE-830-1993 (anterior ao IEEE-830-1998)
HTML
[FIM DE SEÇÃO. Não remova esta quebra de seção]
3. PROJETO
Os tópicos referentes a modelagem deste projeto são abordados nessa seção. Alguns
diagramas da UML (Unified Modeling Language) são utilizados para caracterizar esses tópicos, a
citar o diagrama de classes e o diagrama de casos de uso.
Os requisitos identificados para este projeto também estão descritos nessa seção. Vale
ressaltar que a validação da estrutura de dados deste projeto é realizada através de um XML
(Extensible Markup Language) Schema, apresentado na Seção 3.4.
São apresentados, na Seção 3.5, alguns detalhes de como a ferramenta proposta foi
implementada seguidos da apresentação das funcionalidades, as quais são descritas na Seção 3.6.
3.1. REQUISITOS
Conforme descrito na Seção 2.1.2, é de fundamental importância que em um projeto de
software seja realizado o levantamento de requisitos para que se possa oferecer um produto final
com qualidade e que realmente atenda às necessidades. Dessa forma, as subseções seguintes
descrevem os requisitos funcionais, não funcionais e regras de negócio para este projeto.
3.1.1. Requisitos funcionais
Considerando as funcionalidades para uma ferramenta de gerenciamento de requisitos e
observando o modelo apresentado no documento IEEE-830-1998 juntamente com o que a disciplina
de requisitos do RUP se propõe, os seguintes requisitos funcionais foram identificados:
• RF01 – O sistema deve permitir a criação de um novo projeto;
• RF02 – O sistema deve permitir a abertura de um projeto existente;
• RF03 – O sistema deve permitir o salvamento do projeto em arquivo;
• RF04 – O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e
regras de negócio;
• RF05 – O sistema deve suportar a criação de novos atributos para cada requisito,
incluindo a possibilidade de definir categorias possíveis para cada atributo;
• RF06 – O sistema deve permitir ao usuário registrar versões do documento de ERS;
46
• RF07 – O sistema deve permitir a criação de matriz de rastreabilidade entre requisitos
funcionais, não funcionais e regras de negócio;
• RF08 – O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com
o que foi cadastrado;
• RF09 – O sistema deve permitir o cadastramento dos dados para as seções do documento
de ERS; e
• RF10 – O sistema deve permitir o cadastro de usuários.
3.1.2. Requisitos não funcionais
Os requisitos não funcionais identificados foram os seguintes:
• RNF01 – O documento gerado deverá ser em formato RTF;
• RNF02 – O sistema deve salvar os projetos em documentos XML estruturados por um
XML Schema;
• RNF03 – O sistema deverá ser desenvolvido utilizando a linguagem C++;
• RNF04 – O sistema deverá ser implementado em conformidade com o modelo de
documento de ERS do IEEE organizado por classe de usuários (IEEE 830-1998) e com o
modelo sem casos de uso apresentado pelo RUP;
• RNF05 – O sistema deve abrir somente arquivos com extensão “.spp”; e
• RNF06 – O sistema não deve permitir a abertura de mais de um projeto
simultaneamente.
3.1.3. Regras de negócio
As regras de negócio são tipos de requisitos que regem a forma que o sistema deve operar,
ou seja, são sentenças que definem ou restringem algum aspecto do negócio. Para este projeto,
evidenciam-se as seguintes:
• RN01 – O sistema não incorporará as alterações no projeto quando essas forem
realizadas diretamente no documento textual gerado por ele;
47
• RN02 – O sistema deve marcar o rastreamento como “suspeito” quando algum dos itens
que estão em alguma matriz de rastreabilidade for alterado;
• RN03 – O sistema não deve permitir a alteração da estrutura básica do projeto (seções);
• RN04 – As informações constantes nos modelos de documento de ERS IEEE-830-1998
(requisitos organizados por classe de usuário) e RUP (modelo de documento de ERS
sem casos de uso) deverão ser fixas no projeto. A estrutura deverá seguir o seguinte
modelo:
1. Introdução (observado no modelo do IEEE e no RUP):
Propósito;
Escopo;
Definições, Acrônimos e Abreviaturas;
Referências; e
Visão Geral;
2. Descrição Geral (observado no modelo do IEEE e no RUP):
Perspectiva do produto;
Funções do produto;
Características do usuário;
Restrições; e
Dependências e suposições.
3. Requisitos:
Requisitos funcionais organizados por classe de usuário (observado no
modelo do IEEE);
Requisitos não funcionais; e
48
Regras de negócio2;
• RN05 – Todos os requisitos não funcionais cadastrados na ferramenta devem estar
inseridos obrigatoriamente em uma dessas categorias:
o Observados no modelo do IEEE e no RUP: (i) interfaces de usuário; (ii) interfaces de
hardware; (iii) interfaces de software; (iv) interfaces de comunicação;
(v) desempenho; e (vi) restrições de projeto; e
o Observados apenas no RUP: (i) usabilidade, (ii) confiabilidade, (iii) ajuda e/ou
documentação online; e
• RN06 – Os requisitos funcionais e os não funcionais devem possuir no mínimo os dois
atributos seguintes:
o Prioridade: observado no modelo do IEEE, deve conter três categorias: essencial,
desejável e opcional; e
o Estabilidade: também observado no modelo de documento de ERS do IEEE, deve
conter as três categorias possíveis: alta, média e baixa;
• RN07 – Os requisitos funcionais devem possuir o atributo a seguir:
o Usuário: para poder gerar o documento de Especificação de Requisitos de Software
por classe de usuário, faz-se necessário o cadastro e posterior atribuição do mesmo
aos requisitos elicitados.
3.2. CASOS DE USO
Segundo Booch, Rumbaugh e Jacobson (2000),
os diagramas de casos de uso são importantes para visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistemas, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto. Os diagramas de casos de uso também são importantes para testar sistemas executáveis por meio de engenharia de produção e para compreendê-los por meio de engenharia reversa.
2 As regras de negócio constituem um artefato da disciplina de modelagem de negócios do RUP. No entanto, o conteúdo desse artefato pode ser incluído nas especificações suplementares, que, no modelo sem os casos de uso, está inserido diretamente na terceira seção (Requisitos) de um documento de ERS (RATIONAL, 2002).
49
Nos diagramas de casos de uso, é utilizado o conceito de ator. Um ator representa um
usuário do sistema no qual interage com a funcionalidade descrita nos casos de uso associados a ele.
Para o sistema apresentado neste trabalho tem-se apenas um ator, que é o usuário padrão do sistema.
As subseções seguintes discorrem sobre os casos de uso elicitados para este projeto.
3.2.1. Casos de uso
Cada caso de uso apresentado neste trabalho representa alguma funcionalidade da
ferramenta proposta. A seguir, a Figura 12 ilustra o diagrama de casos de uso contemplando seu
ator e seus dez casos de uso, o objetivo dos mesmos também são apresentados a seguir. Os detalhes
estão contemplados no Apêndice A.
Figura 12. Casos de uso para o presente projeto
50
UC01 - Cria projeto: o objetivo deste caso de uso é permitir ao usuário criar um projeto para
poder utilizar as funcionalidades da ferramenta.
UC02 – Abre projeto: o caso de uso Abre Projeto objetiva permitir ao usuário abrir um
projeto salvo previamente para poder usufruir as outras funcionalidades da ferramenta.
UC03 – Salva projeto: permitir ao usuário salvar em um documento XML o projeto no qual
ele está trabalhando é o objetivo deste caso de uso.
UC04 – Cadastra requisito: novos requisitos funcionais, não funcionais e regras de negócio
podem ser cadastradas através da implementação desse caso de uso.
UC05 – Cria atributo e/ou categoria: o objetivo desse caso de uso é viabilizar a criação de
novos atributos e a definição de novas categorias ou alteração das mesmas para cada tipo de
requisitos.
UC06 – Cria matriz de rastreabilidade: esse caso de uso objetiva permitir ao usuário criar
matrizes de rastreabilidade entre requisitos funcionais, não funcionais e regras de negócio.
UC07 – Gera documento de ERS: o objetivo desse caso de uso visa permitir ao usuário gerar
a documentação de documentos .RTF do que foi cadastrado na ferramenta da versão corrente ou de
versões anteriores.
UC08 – Cadastra dados para seções da ERS: esse caso de uso objetiva permitir o cadastro
dos dados referentes as seções textuais do documento de ERS para poder gerar a documentação
futura pelo usuário.
UC09 – Salva versão do documento de ERS: permitir ao usuário salvar uma versão do
documento de Especificação de Requisitos de Software é o objetivo desse caso de uso.
UC10 – Cadastra usuário: caso de uso com o objetivo de permitir o cadastramento de
usuários para atribuir aos requisitos funcionais.
51
3.3. DIAGRAMA DE CLASSES
Essa seção apresenta o diagrama de classes de domínio para a ferramenta CASE proposta.
Vale ressaltar que, segundo Carlson (2002), pela convenção da UML, os atributos listados em
uma classe com o estereótipo <<enumeration>> definem uma lista de valores possíveis para um
outro atributo de uma outra classe, o qual recebe como tipo um desses valores da classe com
estereótipo <<enumeration>>.
Para modelar alguns itens delimitados pelas regras de negócio RN05 e RN06 descritas na
Seção 3.1.3, utilizou-se classes com estereótipo denominado <<enumeration>>. O diagrama de
classes para este projeto é apresentado a seguir através da Figura 13.
52
Figura 13. Diagrama de Classes
3.4. XML SCHEMA
Para a compreensão de documentos XML, é necessário que se tenha entendimento sobre
alguns conceitos fundamentais. Alguns desses são citados por Tittel (2003), tais como: (i) elemento
que são marcas de abertura e fechamento coletivamente; (ii) marca ou tag, as quais identificam um
elemento (“<>” para abertura e “</>” para fechamento); (iii) atributo, pelo qual os elementos são
melhores descritos; e (iv) entidade as quais são partes de documentos que não possuem relação com
a sua estrutura.
53
Segundo Kirk (2002), o conjunto de regras que definem um documento XML é chamado de
DTD (Document Type Definition). Esse conjunto de regras ajuda a realizar a validação dos dados
quando esses são enviados à aplicação e essa por sua vez não possui internamente uma descrição
dos dados que está recebendo.
Um schema é um tipo de DTD alternativo no qual descreve a estrutura de um documento
XML sendo conhecida também por XSD (XML Schema Definition). O propósito do XML Schema,
assim como na DTD, é definir a construção de blocos de um documento XML.
Um XML Schema define:
• Elementos e atributos que podem aparecer em um documento;
• Que elementos derivam de quais elementos;
• A ordem e quantidade dos elementos derivados;
• Tipos de dados dos elementos e atributos; e
• Valores fixos e padrões para elementos e atributos.
Tittel (2003) afirma que os esquemas se sobrepõe às DTDs. Atualmente eles são
considerados sucessores das DTDs por algumas razões, tais como: (i) são extensíveis e suportam
futuras adições; (ii) são mais ricos e usuais que os DTDs; (iii) são escritos em XML; (iv) Suportam
tipos de dados; e (v) suportam namespaces, os quais são utilizados para diferenciar elementos com
nomes iguais, mas que possuem significados diferentes.
A Figura 14 apresenta alguns detalhes baseados no diagrama de classes para definir a
estrutura dos dados. A notação apresentada é proveniente do software XMLSpy. Detalhes sobre
essa notação podem ser encontrados em Kokubo (2004, p.17).
Um projeto na ferramenta proposta pode ter uma ou várias versões, a estrutura para uma
versão é a descrita na seqüência dentro da estrutura de projeto.
54
Figura 14. Estrutura do elemento projeto
O elemento “Versao.Requisitos” da estrutura do elemento “Versao”, contém todos os
atributos para cada tipo de requisito e os próprios requisitos. O detalhamento desse atributo é feito a
seguir.
55
Um requisito dentro de um projeto tem um alto nível de relevância nesse caso. Sendo assim,
é apresentada a seguir, para cada tipo de requisito, a sua estrutura detalhada. A Figura 15 mostra a
estrutura para um elemento requisito funcional.
Figura 15. Estrutura detalhada de um elemento requisito funcional
A seguir, a Figura 16 mostra a estrutura para um elemento requisito não funcional
Figura 16. Estrutura detalhada de um elemento requisito não funcional
A estrutura detalhada de um elemento regra de negócio é mostrada a seguir através da
Figura 17. O código fonte do XML Schema para este projeto é apresentado no Apêndice B.
Figura 17. Estrutura detalhada de um elemento regra de negócio
56
3.5. IMPLEMENTAÇÃO
Para a implementação da ferramenta proposta foi utilizado o Borland C++ Builder 6.0.
Conforme já apresentado anteriormente, para armazenamento das informações foi utilizado
documentos XML.
É importante notar que um recurso do Borland C++ Builder foi utilizado como facilitador no
que se diz respeito a acesso aos atributos dos documentos XML. Essa funcionalidade proporciona
ao usuário a geração automática das classes e dos métodos de acesso aos atributos dos documentos
XML, chamada de XML Data Binding. A entrada de dados dessa função é um XML Schema ou um
XML Data File, nesse caso foi utilizado o XML Schema. E a saída é um arquivo .cpp juntamente
com o seu header .h.
Uma deficiência notada nessas funções é que, mesmo constando no XML Schema que um
atributo poderia ser nulo, os métodos de acesso a este atributo, não faziam o tratamento para isso,
gerando assim um erro e impossibilitando, dessa forma, a abertura dos documentos XML. A
estrutura gerada foi estudada e alterada para corrigir esse problema encontrado.
A seguir, a Figura 18 mostra um exemplo de funções de acesso, já corrigidas, ao atributo
descrição de uma versão.
AnsiString __fastcall TXMLVersao::Get_VersaoDescricao() { if(TXMLNode::ChildNodes->Nodes[WideString("Versao.Descricao")]->GetHasChildNodes()) return TXMLNode::ChildNodes->Nodes[WideString("Versao.Descricao")]->NodeValue; return EmptyStr; }; void __fastcall TXMLVersao::Set_VersaoDescricao(AnsiString Value) { TXMLNode::ChildNodes->Nodes[WideString("Versao.Descricao")]->NodeValue = Value; };
Figura 18. Exemplo de funções de acesso a um atributo de um documento XML.
57
3.6. APRESENTAÇÃO DA FERRAMENTA
Este capítulo apresenta as funcionalidades da ferramenta proposta neste trabalho, e para
realizar uma melhor descrição das mesmas, telas do sistema são apresentadas. Para exemplificar o
uso da ferramenta implementada foi feito um estudo de caso, no qual consiste em cadastrar os dados
referentes à especificação de requisitos de software da ferramenta proposta conforme é mostrado no
decorrer desta Seção. Ao final, o documento de especificação de requisitos de software é gerado e
apresentado no Apêndice C.
Todas as funcionalidades da ferramenta somente estão disponíveis após ter um projeto
aberto. Esse pode ser um novo projeto ou é possível também abrir um projeto já existente. Para a
criação de um novo projeto é necessário acessar o menu “Arquivo | Novo projeto”, nesse menu
dados básicos sobre o projeto, tais como o nome, sua descrição e o local onde deve ser salvo o
arquivo são solicitados. Tendo em vista a geração do documento de especificação de requisitos de
software organizado por classe de usuário, é solicitada também que informe pelo menos um nome
de usuário juntamente com sua função, assim como mostra a Figura 19. A abertura de um projeto
existente é feita através do menu “Arquivo | Abrir”, solicitando assim o caminho de onde está o
arquivo a ser aberto.
58
Figura 19. Tela de cadastro de novo projeto
Para que o documento de especificação de requisitos de software gerado pela ferramenta
esteja de acordo com a regra de negócio RN04 descrita na Seção 3.1.3, faz-se necessário que alguns
dados em forma textual sejam cadastrados. O usuário deverá cadastrar/alterar esses dados nos
campos apropriados do lado direito da tela principal da ferramenta, conforme mostra a Figura 20.
59
Figura 20. Tela de cadastro das seções textuais do documento a ser gerado.
A ferramenta proporciona ao usuário que cadastre novos atributos tanto para os requisitos
funcionais, como para os não funcionais e para as regras de negócio, tornando-se dessa maneira,
uma ferramenta flexível. Para o cadastro de um novo atributo o usuário deverá acessar a função de
cadastro de atributos localizada através do menu “Projeto | Cadastrar atributos”. Para exemplificar,
a Figura 21 mostra o cadastro do atributo “status” para os requisitos não funcionais.
60
Figura 21. Tela de cadastro do atributo “status” para requisitos não funcionais
Com os atributos já cadastrados, é possível cadastrar então os requisitos do projeto, quer seja
funcionais, não funcionais ou regras de negócio. Esse cadastro está disponível através do menu
“Projeto | Cadastro de Requisitos”. Ao escolher o tipo de requisito como requisito não funcional, o
campo de categoria é habilitado, obedecendo assim a RN05. O identificador único para o requisito é
fornecido automaticamente pela ferramenta. A Figura 22 exemplifica o cadastro de um requisito
não funcional.
61
Figura 22. Tela de cadastro de um requisito não funcional – Dados básicos
Atendendo a RN06, os atributos fixos para os requisitos não funcionais aparecem para
preenchimento na Figura 23, bem como os atributos personalizados que haviam sido criados, neste
caso o atributo “status”.
Figura 23. Tela de cadastro de um requisito não funcional - Atributos
Com requisitos cadastrados, já é possível visualizar a matriz de rastreabilidade, e dessa
forma marcar as dependências entre os requisitos. O acesso a essa funcionalidade é através do menu
“Projeto | Visualizar Matriz de Rastreabilidade”. O usuário escolherá o tipo de requisito que deverá
constar na linha e o tipo de requisito que deverá constar na coluna da matriz, após isso, é mostrada a
matriz conforme a Figura 24. Quando o usuário move o cursor na matriz, é mostrada a descrição
dos dois requisitos (linha e coluna) no rodapé.
62
Figura 24. Matriz de rastreabilidade
Validando a RN02, quando um requisito pertencente a uma matriz é alterado e esse possui
algum relacionamento marcado na matriz, então ele é marcado como “suspeito”, conforme
exemplifica a Figura 25.
Figura 25. Matriz de rastreabilidade com relacionamento suspeito
63
Para manter um histórico de alterações no projeto, a funcionalidade de salvar nova versão do
documento pode ser utilizada, bastando para isso acessar o menu “Arquivo | Salvar nova versão –
Documento de ERS”. É apresentada uma tela ao usuário onde ele pode preencher os comentários
para a próxima versão a ser salva, conforme ilustra a Figura 26.
Figura 26. Tela para preenchimento dos detalhes para salvar versão
É possível gerar o documento de especificação de requisitos de software do projeto aberto,
para isso o usuário deverá acessar o menu “Arquivo | Gerar documento de ERS”. É apresentada
uma tela ao usuário, conforme a Figura 27, mostrando a versão atual e as versões anteriores, caso
existam, para a geração do documento, solicitando também o nome do autor e local para salvamento
do arquivo.
Figura 27. Tela para escolha da versão que será gerado o documento
64
O Apêndice C possui um exemplo de documento de especificação de requisitos gerado pela
ferramenta, onde estão contidos os dados que foram utilizados como estudo de caso para essa
ferramenta.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
4. CONCLUSÃO
Este trabalho objetivou o desenvolvimento uma ferramenta CASE para auxílio à
Especificação de Requisitos de Software (ERS), sendo alcançando com êxito. Foi realizado um
levantamento de requisitos e traçado o escopo da ferramenta, para isso, soluções similares foram
estudadas, bem como conceitos relacionados ao gerenciamento de requisitos. Para que as
funcionalidades propostas pudessem ser implementadas, conceitos e tecnologias foram estudados,
tais como o uso de documentos XML e seu relacionamento com o Borland C++ Builder 6.0.
O documento de ERS gerado pela ferramenta sempre será em formato RTF, ou seja, esse
documento é passível de alteração em vários editores de texto. Assim sendo, o documento de ERS
se torna fácil de ser anexado em outros documentos do sistema.
A ferramenta se destaca também por ser de fácil instalação e por permitir a
interoperabilidade entre sistemas, ou seja, um documento XML gerado nela, poderia ser utilizado
em outro software que fizesse leitura desses documentos.
Além disso, foi implementado também um controle de versões do documento de
especificação de requisitos de software, aumentando assim o nível de gerenciamento dos requisitos.
O usuário então poderá gerar o documento de ERS de qualquer uma das versões produzidas do
documento.
Para validar a ferramenta, optou-se por estar utilizando-a para realizar o cadastramento dos
dados referentes à especificação de requisitos de software deste trabalho, gerando assim, ao final,
um documento formatado com essas informações, o qual é apresentado no Apêndice C e é baseado
tanto no modelo de práticas recomendadas IEEE-830-1998 quanto na disciplina de requisitos do
RUP.
Conforme explanado na Seção 2.1.3.1, o gerenciamento de mudanças é importante em todo
o processo de desenvolvimento de um sistema. No TCC I foi realizada a prototipação da interface,
permitindo assim a validação e também o levantamento de novos requisitos, a citar o cadastramento
de usuários para os requisitos funcionais. Assim sendo, após realizar a prototipação, visando manter
o gerenciamento de mudanças, foi necessário avaliar o impacto desse novo requisito de
cadastramento de usuários em relação aos requisitos já propostos.
66
Para trabalhos futuros sugere-se a geração de documento XML compatível com padrões de
outras ferramentas, tal como o Enterprise Architect, para permitir uma melhor interoperabilidade
entre sistemas, favorecendo assim um maior relacionamento entre as diversas fases do processo de
desenvolvimento, as quais a ferramenta desenvolvida neste trabalho não aborda. Ainda analisando a
questão de integração, é sugerido também criar uma funcionalidade para realizar a pesquisa de
requisitos.
Na fase de projeto, os requisitos podem ser categorizados em grupos por serem parecidos,
dessa forma, sugere-se que seja criada também uma forma de agrupar os mesmos. Para tornar mais
completo o histórico das alterações de cada requisito, a criação de uma funcionalidade que salve as
alterações nos mesmos, gerando assim um histórico é sugerida, além da funcionalidade já
implementada de salvar as versões do documento completo.
Visando o uso da ferramenta em um ambiente corporativo, aconselha-se criar funções de
login, gravação de logs e criação de níveis de utilização de acordo com o perfil do usuário. Tendo
como base as informações principais que um bom documento de ERS no padrão IEEE-830-1998
deve conter, a idéia de hierarquia de requisitos pode ser implementada, pois conforme visto na
Seção 2.3.1.1.5, enquanto o desenvolvimento do projeto progride, a ERS pode ter que evoluir da
mesma forma, até porque as revisões nos requisitos são inevitáveis. Além disso, poder-se-ia ter uma
função onde as alterações realizadas diretamente no documento de ERS pudessem ser refletidas no
arquivo do projeto. Ainda visando o documento de ERS como parte do processo de
desenvolvimento de software, poder-se-ia desenvolver uma funcionalidade para armazenar a
descrição de processos que envolvem os requisitos, tornando o documento final mais completo.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
REFERÊNCIAS BIBLIOGRÁFICAS
ALENQUER, Pablo Lopes. Regras de negócio para análise em ambientes OLAP. 2002. Dissertação (Mestrado em Informática)-Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2002. Disponível em: <http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/ TesePablo.pdf> Acesso em: 04 abr. 2005.
BRADNER, Scott. Key words for use in RFCs to indicate requirement levels. Cambridge: IETF, 1997. Disponível em <http://www.ietf.org/rfc/rfc2119.txt?number=2119> Acesso em: 03 abr. 2005.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
CARLSON, David. Modelagem de aplicações XML com UML: aplicações práticas de e-business. São Paulo: Pearson Education, 2002.
CARPENA, Flávio Ricardo; KIRNER, Tereza Gonçalves. Especificação de requisitos de software com o método SCR. In: WORKSHOP DE ENGENHARIA DE REQUISITOS, 1., 1998, Maringá. Anais eletrônicos... Disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER98/ carpena.pdf> Acesso em: 03 dez. 2004.
CARVALHO, Júnia Gaudereto. Praxis Mentor: uma ferramenta de apoio à utilização de um processo de desenvolvimento de software. 2001. Dissertação (Mestrado em Ciência da Computação)-Universidade Federal de Minas Gerais, Belo Horizonte, 2001. Disponível em: <http://www.wppf.uaivip.com.br/pesquisa/DissertacaoJunia.pdf> Acesso em: 22 fev. 2005
CONALLEN, Jim. Desenvolvimento de aplicações web com UML. Rio de Janeiro: Campus, 2003.
FISCHER, Alan S. CASE: utilização de ferramentas para desenvolvimento de software. Rio de Janeiro: Campus, 1990.
HOFMANN, Hubert F.; LEHNER, Franz. Requirements engineering as a success factor in software projects. IEEE Software, Los Alamitas, v.18, n. 4, p. 58-66, jul./ago. 2001. Disponível em <http://www.das.ufsc.br/~romulo/discipli/cad-meto/requi.pdf > Acesso em 20 mar. 2005.
IBM. Passport advantage express. New York: IBM. Disponível em <https://www-112.ibm.com/software/howtobuy/buyingtools/paexpress /Express?P0=E1&part_number=D53NZLL,D5326LL&catalogLocale=en_US&Locale=en_US&country=USA> Acesso em 20 abr. 2005.
IEEE. Recommended practice for software requirements specifications. New York: IEEE: 1998.
KAMINSKI, Douglas; FISCHER, Renê. RUP: Rational Unified Process. 2003. Projeto de Monografia (Graduação em Ciência da Computação)-Universidade Federal de Santa Catarina, Florianópolis, 2003.
68
KIRK, C. DTDS NO XML. In: PITTS-MOULTIS, N.; KIRK, C. XML black book. São Paulo: Makron Books, 2000. 627 p.
KLINGER, Daniel André, KROTH, Eduardo. Um software assistente para especificação de regras de Negócio. In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, 1., 2001, Itajaí. Anais eletrônicos… Disponível em < http://cbcomp.univali.br/pdf/2001/eng006.pdf > Acesso em: 25 mar. 2005
KOKUBO, Eduardo. Sistema para importação de informações do currículo lattes. 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Universidade do Vale do Itajaí, Itajaí, 2004.
KOTONYA, Gerald, SOMMERVILLE, Ian. Requirements engineering: process and techniques. Chichester: John Wiley & Sons, 1997.
LOPES, Leandro T.; MAJDENBAUM, Azriel; AUDY, Jorge Luiz N. Uma proposta para processo de requisitos em ambientes de desenvolvimento distribuído de software. In: WORKSHOP EM ENGENHARIA DE REQUISITOS, 6., 2003, Piracicaba. Anais eletrônicos... Disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/ leandro_majdenbaum.pdf.> Acesso em: 04 dez. 2004.
MARQUARDT, Luciano. Ferramenta web para gerenciamento de requisitos de software. 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Universidade Regional de Blumenau, Blumenau, 2004.
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos métodos e padrões. Rio de Janeiro: LTC, 2001.
PETERS, James F.; PEDRICZ, Witold. Engenharia de software: teoria e prática. Rio de Janeiro: Campus, 2001.
PIRES, Carlo Giovano; MARINHO, Fabiana. TELLES, Gabriela; SAMPAIO, Márcia. Uma arquitetura de processos para ISO 9001:2000 e SW-CMM Nível 3. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE, 6., 2004, São Paulo. Anais eletrônicos... São Paulo: SENAC-CenPRA, 2004. Disponível em: <http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_18_Simpros2004.pdf> Acesso em 16 abr. 2005.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.
RATIONAL. RUP: release notes (version 2002.05.00). [S.l]: Rational Software Corporation, 2002.
SANTOS, Fernando dos, VARGAS, Karly Schubert, ABREU, Christian Rogério Câmara de. Rastreabilidade de requisitos através da web. In: SEMINÁRIO DE COMPUTAÇÃO,13., 2004, Blumenau. Anais eletrônicos... Blumenau: FURB, 2004. Disponível em <http://www.inf.furb.br/seminco/2004/artigos/107-vf.pdf> Acesso em 26 mar. 2005.
SCHLICKMANN JÚNIOR, Tadeu João. Customização do Rational Unified Process – RUP. 2002. 124 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)-Universidade do Sul de Santa Catarina, Palhoça, 2002.
69
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison Wesley, 2003.
SPARX SYSTEMS. Purchase Enterprise Architect. Victoria: SPARX SYSTEMS. Disponível em <http://sparxsystems.com.au/products/ea_purchase.html> Acesso em 20 abr. 2005.
TITTEL, E. Teórica e problemas do XML. Porto Alegre: Bookman, 2003. 207 p.
WEIDEN, Marcel; HERMANS, Leo; SCHREIBER, Guus; ZEE, Sven van der. Classification and representation of business rules. In: EUROPEAN BUSINESS RULES CONFERENCE, 1st, 2002, Zurich. Proceedings... Amsterdam: KNOWGRAVITY, 2002. Disponível em: <http://www.omg.org/docs/ad/02-12-18.pdf> Acesso em 14 mar. 2005.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
APÊNDICE A – REQUISITOS FUNCIONAIS
UC01 - Cria projeto
Objetivo
Permitir ao usuário criar um projeto para poder utilizar as funcionalidades da ferramenta.
Requisitos
• RF01: o sistema deve permitir a criação de um novo projeto;
Condições
• Pós-condição: um projeto será criado; e
• Pós-condição: após o projeto estar criado, a estrutura do documento (seções) deve ser
carregada a partir do modelo pré-definido.
Cenários
Cria projeto {Principal}.
1. Sistema solicita informações básicas sobre o projeto (Figura 19);
2. Usuário informa dados para a criação do projeto (Figura 19);
3. Sistema verifica os dados;
4. Sistema cria estrutura de dados básica de acordo com o modelo;
5. Sistema cria projeto; e
6. Sistema salva projeto no local onde foi definido.
Arquivo existente {Exceção}.
Caso os dados não sejam validados no passo 3 do cenário "Principal":
1. Sistema mostra mensagem "Não foi possível criar o projeto"; e
2. Retorna ao passo 1 do cenário "Cria Projeto".
Fecha projeto aberto {Alternativo}.
Caso haja um projeto aberto no momento de criar um novo:
71
1. Sistema informa o usuário com mensagem "Existe um projeto aberto no momento, para
criar um novo o atual deve ser fechado."; e
2. Retorna ao passo 1 do cenário "Cria Projeto".
UC02 – Abre projeto
Objetivo
Permitir ao usuário abrir um projeto salvo previamente para poder utilizar as
funcionalidades da ferramenta.
Requisitos
• RF02: o sistema deve permitir a abertura de um projeto existente;
Condições
• Pós-condição: um projeto estará aberto.
Cenários
Abre Projeto {Principal}.
1. Sistema verifica se existe algum projeto aberto;
2. Caso não tenha nenhum projeto aberto, sistema solicita o caminho de onde está o arquivo
de projeto a ser aberto;
3. Usuário seleciona o arquivo a ser aberto;
4. Sistema verifica arquivo;
5. Sistema abre projeto; e
6. Sistema carrega os dados do projeto.
Fechar Projeto Aberto {Alternativo}.
Caso o passo 1 do cenário "Principal" retorne que existe arquivo aberto:
1. Sistema mostra mensagem "Para abrir um novo projeto é necessário fechar o atual. Deseja
fechar SIM ou NÃO?";
2. Usuário seleciona SIM; e
3. Retorna ao passo 2 do cenário "Principal".
72
Arquivo Inválido {Exceção}.
Caso o arquivo seja inválido no passo 3 do cenário "Principal":
1. Sistema mostra a mensagem "Arquivo Inválido. Por favor, selecione novamente."; e
2. Retorna ao passo 2 do cenário "Principal";
UC03 – Salva projeto
Objetivo
Permitir ao usuário salvar em arquivo o projeto no qual ele está trabalhando.
Requisitos
• RF03: o sistema deve permitir o salvamento do projeto em arquivo;
Condições
• Pré-condição: um projeto deverá estar aberto para poder ser salvo; e
• Pós-condição: um projeto estará salvo.
Cenários
Salva projeto {Principal}.
1. Usuário solicita que o projeto seja salvo; e
2. Sistema salva projeto.
Erro ao salvar {Exceção}.
Caso ocorra algum erro no passo 2 do cenário "Principal":
1. Sistema mostra a mensagem "Ocorreu um erro. Não foi possível salvar o projeto".
UC04 – Cadastra requisito
Objetivo
Permitir ao usuário cadastrar novos requisitos funcionais, não funcionais e regras de
negócio.
73
Requisitos
• RF04: o sistema deve permitir o cadastro de requisitos funcionais, não funcionais e
regras de negócio;
Condições
• Pré-condição: sistema deverá ter um projeto aberto; e
• Pós-condição: um requisito foi cadastrado, alterado ou excluído.
Cenários
Cadastra requisito {Principal}.
1. Usuário seleciona opção para cadastro de requisito;
2. Sistema mostra tela para cadastro das informações básicas sobre o requisito (Figura 22);
3. Usuário escolhe o tipo de requisito que deseja cadastrar;
4. Sistema ativa a opção de cadastro de categoria do requisito caso ele seja um requisito não
funcional, caso contrário desativa, e fornece o identificador único para aquele tipo de
requisito;
5. Usuário preenche os dados; e
6. Sistema salva os dados.
Altera Requisito {Alternativo}.
1. Usuário seleciona o requisito na árvore do projeto;
2. Usuário escolhe opção para editar requisito;
3. Sistema mostra tela já preenchida para alterações das informações básicas do requisito
(Figura 22);
4. Usuário realiza alterações nos dados do requisito; e
5. Sistema salva os dados.
Exclui requisito {Alternativo}.
1. Usuário seleciona o requisito na árvore do projeto;
2. Usuário escolhe opção para excluir requisito;
3. Sistema mostra a mensagem "Deseja realmente excluir esse requisito e todos seus
relacionamentos? SIM ou NÃO";
74
4. Caso usuário selecione NÃO, sistema aborta operação;
5. Caso usuário selecione SIM:
6. Sistema exclui todos os relacionamentos com outros requisitos; e
7. Sistema exclui o requisito em si.
UC05 – Cria atributo e/ou categoria
Objetivo
Viabilizar a criação de novos atributos e a definição de novas categorias ou alteração das
mesmas para cada tipo de requisitos.
Requisitos
• RF05: o sistema deve suportar a criação de novos atributos para cada requisito, incluindo
a possibilidade de definir categorias possíveis para cada atributo;
Condições
• Pré-condição: sistema deverá ter um projeto aberto; e
• Pós-condição: algum atributo e/ou categoria para os requisitos foi cadastrado alterado ou
excluído.
Cenários
Cria Atributo {Principal}.
1. Usuário seleciona opção para criar atributo;
2. Sistema mostra a tela com os atributos existentes para alteração/exclusão e campo para
cadastro do novo atributo (Figura 21);
3. Usuário preenche os dados do novo atributo; e
4. Sistema salva os dados que o usuário cadastrou.
Altera Atributo {Alternativo}.
No passo 2 do cenário "Cria Atributo":
1. Usuário seleciona atributo existente em uma lista;
2. Sistema mostra campo para alteração;
75
3. Usuário realiza as alterações necessárias; e
4. Sistema salva os dados.
Exclui Atributo {Alternativo}.
No passo 2 do cenário "Altera Atributo":
1. Usuário seleciona opção para excluir atributo;
2. Sistema exibe a mensagem "Deseja realmente excluir esse atributo? SIM ou NÃO";
3. Caso usuário selecione NÃO, sistema aborta operação;
4. Caso usuário selecione SIM, sistema exclui todas as categorias relacionadas a esse
atributo; e
5. Sistema exclui atributo.
Cria Categoria {Alternativo}.
No passo 3 do cenário "Cria Atributo":
1. Usuário seleciona o cadastro de categoria;
2. Sistema mostra tela com as categorias existentes e campo para preenchimento da nova
categoria (Figura 21); e
3. Usuário preenche campo para cadastro de uma nova categoria para determinado atributo;
4. Sistema salva os dados.
Altera Categoria {Alternativo}.
No passo 2 do cenário "Cria Categoria":
1. Usuário seleciona categoria existente;
2. Sistema carrega dados para campo de alteração;
3. Usuário preenche campo para alteração da categoria para determinado atributo; e
4. Sistema salva os dados.
Exclui Categoria {Alternativo}.
No passo 2 do cenário "Altera Categoria":
1. Usuário seleciona opção para excluir categoria;
2. Sistema exibe mensagem "Deseja realmente excluir essa categoria? SIM ou NÃO";
3. Caso usuário selecione NÃO, sistema aborta operação; e
4. Caso usuário selecione SIM, sistema exclui categoria.
76
UC06 – Cria matriz de rastreabilidade
Objetivo
Permitir ao usuário criar matrizes de rastreabilidade entre requisitos funcionais, não
funcionais e regras de negócio.
Requisitos
• RF07: O sistema deve permitir a criação de matriz de rastreabilidade entre requisitos
funcionais, não funcionais e regras de negócio;
Condições
• Pré-condição: Para criar a matriz de rastreabilidade, é necessário que exista no mínimo
dois requisitos funcionais, não funcionais ou regras de negócio cadastrados;
• Pré-condição: Sistema deverá ter um projeto aberto; e
• Pós-condição: Uma matriz de rastreabilidade será criada de acordo com o que o usuário
selecionou.
Cenários
Cria rastreabilidade {Principal}.
1. Usuário seleciona funcionalidade para cadastro de rastreabilidade;
2. Sistema mostra tela para usuário selecionar qual é o tipo de rastreabilidade que ele deseja
criar/visualizar;
3. Usuário escolhe tipo de rastreabilidade;
4. Sistema verifica se há requisitos cadastrados para aquele tipo de rastreabilidade, caso
tenha, então ele carrega os dados (Figura 24); e
5. Usuário pode selecionar na matriz onde deseja criar a rastreabilidade;
A Figura 24 a exemplifica uma matriz de rastreabilidade de acordo com os dados
selecionados para a formação da matriz.
Quantidade de requisitos insuficiente {Exceção}.
Para o passo 1 do cenário "Principal" devem existir no mínimo dois requisitos cadastrados e
para o passo 1 do cenário "Alternativo" deve existir no mínimo um requisito cadastrado.
77
Caso não atenda essas restrições:
1. Sistema mostra a mensagem "Não é possível criar rastreabilidade. Número de requisitos
cadastrados insuficientes.".
UC07 – Gera documento de ERS
Objetivo
Permite ao usuário gerar documentação do que foi cadastrado em documentos .RTF da
versão corrente ou de versões anteriores.
Requisitos
• RF08: o sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o
que foi cadastrado;
Condições
• Pré-condição: sistema deverá ter um projeto aberto.
• Pós-condição: documento .RTF gerado com opção para impressão.
Cenários
Gera documento {Principal}.
1. Usuário seleciona opção para gerar documento de ERS;
2. Sistema verifica se todas as seções do documento estão cadastradas;
3. Sistema verifica se há versões anteriores cadastradas;
4. Caso existam versões anteriores, sistema apresenta uma lista das versões gravadas
mostrando a mensagem "Escolha a versão que deseja gerar o documento." (Figura 27);
5. Se existir versões anteriores, usuário seleciona a versão na qual ele deseja gerar o
documento, se não existir, sistema seleciona automaticamente a versão corrente; e
6. Sistema gera documento de ERS.
Impressão {Alternativo}.
No passo 6 do cenário "Gera documento":
1. Usuário seleciona opção para imprimir documento; e
2. Sistema envia informações para impressora.
78
UC08 – Cadastra dados para seções da ERS
Objetivo
Permite o cadastro dos dados referentes as seções do documento de ERS para poder gerar a
documentação futura pelo usuário.
Requisitos
• RF09: o sistema deve permitir o cadastramento dos dados de forma textual para as
seções do documento de ERS.
Condições
• Pré-condição: Sistema deverá ter um projeto aberto; e
• Pós-condição: O sistema conterá as seções cadastradas ou alteradas.
Cenários
Cadastra dados {Principal}.
1. Usuário seleciona na árvore do projeto o que ele quer cadastrar;
2. Sistema mostra os campos que podem ser cadastrados (Figura 20);
3. Usuário preenche os dados; e
4. Sistema salva os dados.
Altera dados {Alternativo}.
1. Usuário seleciona na árvore do projeto qual item ele deseja alterar;
2. Sistema carrega dados já cadastrados anteriormente nos campos (Figura 20);
3. Usuário altera os dados; e
4. Sistema salva os dados.
UC09 – Salva versão do documento de ERS
Objetivo
Permitir ao usuário salvar uma versão do documento de Especificação de Requisitos de
Software.
79
Requisitos
• RF06: o sistema deve permitir ao usuário registrar versões do documento de ERS.
Condições
• Pré-condição: sistema deverá ter um projeto aberto com seus dados básicos já
cadastrados; e
• Pós-condição: versão do documento de ERS salva e projeto trabalhando em versão
corrente posterior.
Cenários
Salva versão {Principal}.
1. Usuário seleciona opção para salvar versão do documento de ERS;
2. Sistema mostra tela para preenchimento de observações/descrição sobre a versão, já
mostrando o número da versão a ser salva automaticamente (Figura 26);
3. Usuário preenche o campo caso queira; e
4. Sistema salva versão do documento de ERS.
Erro ao salvar {Exceção}.
Caso no passo 4 do cenário "Salva versão" o sistema não consiga salvar corretamente:
1. Sistema mostra a mensagem "Não foi possível salvar versão do documento de ERS.".
UC10 – Cadastra usuário
Objetivo
Permitir o cadastramento de usuários para atribuir aos requisitos.
Requisitos
• RF10: O sistema deve permitir o cadastro de usuários.
Condições
• Pré-condição: sistema deverá ter um projeto aberto; e
80
• Pós-condição: usuário cadastrado no projeto, sendo possível atribuir esse usuário como
solicitante de algum requisito.
Cenários
Cadastra Usuário {Principal}.
1. Usuário seleciona opção para cadastro de novo usuário;
2. Sistema exibe campos necessários para o cadastro (Figura 19);
3. Usuário preenche campos com os dados; e
4. Sistema cadastra pessoa como novo usuário;
Erro ao salvar {Exceção}.
Caso no passo 4 do cenário "Cadastra usuário" o sistema não consiga salvar corretamente:
1. Sistema mostra a mensagem "Não foi possível cadastrar novo usuário.".
81
APÊNDICE B – XML SCHEMA PARA A FERRAMENTA PROPOSTA
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by rth77 (rus) --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Projeto"> <xs:complexType name="Projeto" mixed="false"> <xs:sequence> <xs:element name="Versao" maxOccurs="unbounded"> <xs:complexType name="Versao"> <xs:sequence> <xs:element name="Versao.Versao" type="xs:float"/> <xs:element name="Versao.Descricao" type="xs:string"/> <xs:element name="Versao.Data" type="xs:date"/> <xs:element name="Versao.Hora" type="xs:time"/> <xs:element name="Versao.Detalhe"> <xs:complexType name="Versao.Detalhe"> <xs:sequence> <xs:element name="Detalhe.Proposito" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.Escopo" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.DefAcroAbrev" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.Referencias"/> <xs:element name="Detalhe.VisaoGeral" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.PerpProduto" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.FuncProduto" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.CaracUsuario" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.Restricoes" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Detalhe.DepSuposicoes" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/>
82
</xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Versao.Projeto"> <xs:complexType name="Versao.Projeto"> <xs:sequence> <xs:element name="Projeto.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Projeto.Descricao" nillable="true"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Versao.Requisitos"> <xs:complexType name="Versao.Requisitos"> <xs:sequence> <xs:sequence> <xs:element name="Fun.Categs"> <xs:complexType name="Fun.Categs"> <xs:sequence> <xs:element name="Fun.Atributo" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Fun.Atributo"> <xs:sequence> <xs:element name="Nome"/> <xs:element name="Categoria" type="Categoria.Descricao" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="NFun.Categs"> <xs:complexType name="NFun.Categs"> <xs:sequence> <xs:element name="NFun.Atributo" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="NFun.Atributo"> <xs:sequence> <xs:element name="Nome"/> <xs:element name="Categoria" type="Categoria.Descricao" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Neg.Categs"> <xs:complexType name="Neg.Categs"> <xs:sequence> <xs:element name="Neg.Atributo" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="Nome"/> <xs:element name="Categoria" type="Categoria.Descricao" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> <xs:sequence> <xs:element name="Req.Funcional" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Req.Funcional"> <xs:sequence> <xs:element name="Funcional.Identificador" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction>
83
</xs:simpleType> </xs:element> <xs:element name="Funcional.Descricao" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> <xs:whiteSpace value="replace"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Funcional.Atributo" minOccurs="0"> <xs:complexType name="Funcional.Atributo"> <xs:sequence> <xs:element name="Funcional.Atributo.Atributo" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Atributos criados pelo usuário onde deve conter o nome e um valor ou uma categoria</xs:documentation> </xs:annotation> <xs:complexType name="Funcional.Atributo.Atributo"> <xs:sequence> <xs:element name="F.Atributo.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:choice> <xs:element name="F.Atributo.Valor" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="F.Atributo.Categoria" type="Categoria.Descricao" nillable="false"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Funcional.Usuario.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Funcional.Estabilidade" type="Estabilidade" nillable="false"/> <xs:element name="Funcional.Prioridade" type="Prioridade" nillable="false"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Req.NaoFuncional" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Req.NaoFuncional"> <xs:sequence> <xs:element name="NaoFuncional.Identificador" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NaoFuncional.Descricao" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> <xs:whiteSpace value="replace"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NaoFuncional.Atributo" minOccurs="0"> <xs:complexType name="NaoFuncional.Atributo"> <xs:sequence> <xs:element name="NaoFuncional.Atributo.Atributo" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Atributos criados pelo usuário onde deve conter o nome e um valor ou uma categoria</xs:documentation>
84
</xs:annotation> <xs:complexType name="NaoFuncional.Atributo.Atributo"> <xs:sequence> <xs:element name="NF.Atributo.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:choice> <xs:element name="NF.Atributo.Valor" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="NF.Atributo.Categoria" type="Categoria.Descricao" nillable="false"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="NaoFuncional.Estabilidade" type="Estabilidade" nillable="false"/> <xs:element name="NaoFuncional.Prioridade" type="Prioridade" nillable="false"/> <xs:element name="NaoFuncional.CategoriaRNF" type="CategoriaRNF" nillable="false"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Req.Negocio" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Req.Negocio"> <xs:sequence> <xs:element name="Negocio.Identificador" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Negocio.Descricao" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="4000"/> <xs:whiteSpace value="replace"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Negocio.Atributo" minOccurs="0"> <xs:complexType name="Negocio.Atributo"> <xs:sequence> <xs:element name="Negocio.Atributo.Atributo" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Atributos criados pelo usuário onde deve conter o nome e um valor ou uma categoria</xs:documentation> </xs:annotation> <xs:complexType name="Negocio.Atributo.Atributo"> <xs:sequence> <xs:element name="N.Atributo.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:choice> <xs:element name="N.Atributo.Valor" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="N.Atributo.Categoria" type="Categoria.Descricao" nillable="false"/> </xs:choice> </xs:sequence> </xs:complexType>
85
</xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Versao.Rastreabilidade" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Rastreabilidade"> <xs:sequence> <xs:element name="Identificador"> <xs:annotation> <xs:documentation>Contém os tipos de requisito que estão relacionados na matriz</xs:documentation> </xs:annotation> <xs:complexType name="Identificador"> <xs:sequence> <xs:element name="Coluna" type="TipoRequisito"/> <xs:element name="Linha" type="TipoRequisito"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Checado" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Usado para saber quais relacionamentos estão marcados como checado</xs:documentation> </xs:annotation> <xs:complexType name="Checado"> <xs:sequence> <xs:element name="idColuna" type="xs:string" nillable="false"> <xs:annotation> <xs:documentation>Identificador do requisito na coluna</xs:documentation> </xs:annotation> </xs:element> <xs:element name="idLinha" type="xs:string" nillable="false"> <xs:annotation> <xs:documentation>Identificador do requisito na linha</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Suspeito" type="xs:boolean" nillable="false"> <xs:annotation> <xs:documentation>Informa se o relacionamento está marcado como suspeito ou não</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Versao.Usuario" minOccurs="0" maxOccurs="unbounded"> <xs:complexType name="Versao.Usuario"> <xs:sequence> <xs:element name="Usuario.Nome" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Usuario.Funcao" nillable="false"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Usuario.Telefone" nillable="true" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="50"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Usuario.Email" nillable="true" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="100"/>
86
</xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:simpleType name="TipoRequisito"> <xs:restriction base="xs:string"> <xs:enumeration value="RF"/> <xs:enumeration value="RNF"/> <xs:enumeration value="RN"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CategoriaRNF"> <xs:restriction base="xs:string"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> <xs:enumeration value="6"/> <xs:enumeration value="7"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="Estabilidade"> <xs:restriction base="xs:string"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="Prioridade"> <xs:restriction base="xs:string"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> </xs:restriction> </xs:simpleType> <xs:complexType name="Categoria.Descricao"> <xs:simpleContent> <xs:extension base="xs:string"/> </xs:simpleContent> </xs:complexType> </xs:schema>
Figura 28. XML Schema apresentado para a ferramenta proposta.
87
APÊNDICE C – DOCUMENTO GERADO PELA FERRAMENTA
Documento de Especificação de Requisitos de Software Projeto: Ferramenta CASE Para Especificação de Requisitos de Software Observando IEEE-830-1998 e RUP Autor(a): Julio Cezar Chrystopher Quirino Versão 2.0 - Versão após a correção dos atributos dos requisitos. - Atualizado em 11/11/2005 18:43:59
Documento gerado em 11/11/2005 18:43:59 Histórico de Versões 1.0 – 11/11/2005 13:01:13 - Versão Inicial 1 Introdução 1.1 Propósito Este documento tem por objetivo apresentar os requisitos de uma ferramenta proposta como Trabalho de Conclusão de Curso do acadêmico Julio Cezar Chrystopher Quirino - 2005/2, a qual se destina a auxiliar na especificação de requisitos de software. 1.2 Escopo Esta ferramenta deverá permitir o cadastramento de requisitos funcionais, não funcionais e regras de negócio, bem como novos atributos para os mesmos. Deverá também permitir o salvamento de versão de documento de especificação de requisitos de software e deve gerar o documento em formato .RTF. Deve permitir ao usuário a visualização de matrizes de rastreabilidade entre os requisitos cadastrados e monitorar os relacionamentos marcando como "suspeito" sempre que algum requisito envolvido for alterado. 1.3 Definições, Acrônimos e Abreviaturas ERS: Especificação de Requisitos de Software IEEE: Institute of Electrical and Electronic Engineers RF: Requisito Funcional RNF: Requisito Não Funcional RN: Regra de Negócio RUP: Rational Unified Process XML: Extensible Markup Language 1.4 Referências IEEE-830-1998 RUP 2002 - Disciplina de requisitos 1.5 Visão Geral O documento está organizado conforme orienta o documento IEEE-830-1998 observando também a disciplina de requisitos do RUP. Na seção de Introdução, o propósito e escopo da ferramenta são apresentados, bem como as definições, acrônimos, abreviaturas e referências também são descritos. Na seção Descrição Geral, a perspectiva e as funções do produto são relacionadas, as características dos usuários são descritas também. É apresentado no final desta seção as restrições, dependências e suposições que a ferramenta possui. A seção Requisitos contempla todos os requisitos cadastrados, quer sejam funcionais, não-funcionais e regras de negócio. De acordo com o IEEE-830-1998, esta seção, para os requisitos funcionais, está organizada por classes de usuários. 2 Descrição Geral 2.1 Perspectiva do Produto Verificar se RTF depende ou não do word. Não necessita de rede. restrições gerais?... 2.2 Funções do Produto Permitir a especificação de requisitos funcionais, não funcionais e regras de negócio bem como seus atributos; Permitir o gerenciamento de requisitos através da rastreabilidade de requisitos; Gerar documento de especificação de requisitos baseado no modelo IEEE-830-1998 e nos modelos propostos pelo RUP na disciplina de requisitos; 2.3 Características do Usuário Para este projeto os usuários deverão possuir conhecimento técnico em Análise de Sistemas.
88
2.4 Restrições Não é compatível com padrão de outras ferramentas. Não há histórico de alterações, somente histórico de versões Não há como refletir as alterações realizadads diretamente no documento de ERS gerado em RTF no arquivo do projeto. 2.5 Dependências e Suposições Alguns casos onde os requisitos poderão ser afetados: IEEE lançar uma nova versão do documento IEEE-830-1998. RUP lançar uma versão mais atual da que foi estudada (2002) 3 Requisitos 3.1 Requisitos Funcionais Os requisitos funcionais a seguir estão organizados por classes de usuário conforme orienta o documento IEEE-830-1998. Classe de usuário: Analista • RF1 - O sistema deve permitir a criação de um novo projeto
• Prioridade: Essencial • Estabilidade: Alta
• RF2 - O sistema deve permitir a abertura de um projeto existente.
• Prioridade: Essencial • Estabilidade: Alta Rastreabilidade • RNF2 - O sistema deve salvar os projetos em documentos XML estruturados por um XML Schema; • RNF5 - O sistema deve abrir somente arquivos com extensão ".spp" • RNF6 - O sistema não deve permitir a abertura de mais de um projeto simultaneamente.
• RF3 - O sistema deve permitir o salvamento do projeto em arquivo
• Prioridade: Essencial • Estabilidade: Alta Rastreabilidade • RNF2 - O sistema deve salvar os projetos em documentos XML estruturados por um XML Schema;
• RF4 - O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e regras de negócio
• Prioridade: Essencial • Estabilidade: Alta Rastreabilidade • RN2 - O sistema deve marcar o rastreamento como “suspeito” quando algum dos itens que estão em alguma matriz de
rastreabilidade for alterado • RN4 - As informações constantes nos modelos de documento de ERS IEEE-830-1998 (requisitos organizados por classe de
usuário) e RUP (modelo de documento de ERS sem casos de uso) deverão ser fixas no projeto. A estrutura deverá seguir o seguinte modelo:1.Introdução (observado no modelo do IEEE e no RUP): 1.1.Propósito; 1.2.Escopo; 1.3.Definições, Acrônimos e Abreviaturas; 1.4.Referências; e 1.5.Visão Geral; 2.Descrição Geral (observado no modelo do IEEE e no RUP): 2.1.Perspectiva do produto; 2.2.Funções do produto; 2.3.Características do usuário; 2.4.Restrições; e 2.5.Dependências e suposições.3.Requisitos: 3.1.Requisitos funcionais organizados por classe de usuário (observado no modelo do IEEE); 3.2.Requisitos não funcionais; e 3.3.Regras de negócio.
• RN5 - Todos os requisitos não funcionais cadastrados na ferramenta devem estar inseridos obrigatoriamente em uma dessas categorias: * Observados no modelo do IEEE e no RUP: (i) interfaces de usuário; (ii) interfaces de hardware; (iii) interfaces de software; (iv) interfaces de comunicação; (v) desempenho; e (vi) restrições de projeto; e * Observados apenas no RUP: (i) usabilidade, (ii) confiabilidade, (iii) ajuda e/ou documentação online.
• RN6 - Os requisitos funcionais e os não funcionais devem possuir no mínimo os dois atributos seguintes: Prioridade (observado no modelo do IEEE, deve conter três categorias: essencial, desejável e opcional) e Estabilidade (também observado no modelo de documento de ERS do IEEE, deve conter as três categorias possíveis: alta, média e baixa)
• RF5 - O sistema deve suportar a criação de novos atributos para cada requisito, incluindo a possibilidade de definir
categorias possíveis para cada atributo • Prioridade: Desejável • Estabilidade: Média
• RF6 - O sistema deve permitir ao usuário registrar versões do documento de ERS
• Prioridade: Opcional • Estabilidade: Baixa Rastreabilidade • RNF5 - O sistema deve abrir somente arquivos com extensão ".spp"
89
• RF7 - O sistema deve permitir a criação de matriz de rastreabilidade entre requisitos funcionais, não funcionais e regras de negócio • Prioridade: Desejável • Estabilidade: Alta Rastreabilidade • RN2 - O sistema deve marcar o rastreamento como “suspeito” quando algum dos itens que estão em alguma matriz de
rastreabilidade for alterado • RF8 - O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o que foi cadastrado
• Prioridade: Essencial • Estabilidade: Baixa Rastreabilidade • RNF1 - O documento gerado deverá ser em formato RTF • RNF4 - O sistema deverá ser implementado em conformidade com o modelo de documento de ERS do IEEE organizado por
classe de usuários (IEEE 830-1998) e com o modelo sem casos de uso apresentado pelo RUP • RN1 - O sistema não incorporará as alterações no projeto quando essas forem realizadas diretamente no documento textual
gerado por ele • RN7 - Os requisitos funcionais devem possuir o atributo a seguir: Usuário (para poder gerar o documento de Especificação de
Requisitos de Software por classe de usuário, faz-se necessário o cadastro e posterior atribuição do mesmo aos requisitos elicitados).
• RF9 - O sistema deve permitir o cadastramento dos dados para as seções do documento de ERS
• Prioridade: Essencial • Estabilidade: Alta Rastreabilidade • RN3 - O sistema não deve permitir a alteração da estrutura básica do projeto (seções) • RN4 - As informações constantes nos modelos de documento de ERS IEEE-830-1998 (requisitos organizados por classe de
usuário) e RUP (modelo de documento de ERS sem casos de uso) deverão ser fixas no projeto. A estrutura deverá seguir o seguinte modelo:1.Introdução (observado no modelo do IEEE e no RUP): 1.1.Propósito; 1.2.Escopo; 1.3.Definições, Acrônimos e Abreviaturas; 1.4.Referências; e 1.5.Visão Geral; 2.Descrição Geral (observado no modelo do IEEE e no RUP): 2.1.Perspectiva do produto; 2.2.Funções do produto; 2.3.Características do usuário; 2.4.Restrições; e 2.5.Dependências e suposições.3.Requisitos: 3.1.Requisitos funcionais organizados por classe de usuário (observado no modelo do IEEE); 3.2.Requisitos não funcionais; e 3.3.Regras de negócio.
• RF10 - O sistema deve permitir o cadastro de usuários
• Prioridade: Opcional • Estabilidade: Média
3.2 Requisitos Não-Funcionais • RNF1 - O documento gerado deverá ser em formato RTF
• Categoria: Restrição de Projeto • Prioridade: Desejável • Estabilidade: Média Rastreabilidade • RF8 - O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o que foi cadastrado
• RNF2 - O sistema deve salvar os projetos em documentos XML estruturados por um XML Schema;
• Categoria: Restrição de Projeto • Prioridade: Essencial • Estabilidade: Média Rastreabilidade • RF2 - O sistema deve permitir a abertura de um projeto existente. • RF3 - O sistema deve permitir o salvamento do projeto em arquivo
• RNF3 - O sistema deverá ser desenvolvido utilizando a linguagem C++
• Categoria: Restrição de Projeto • Prioridade: Desejável • Estabilidade: Alta
• RNF4 - O sistema deverá ser implementado em conformidade com o modelo de documento de ERS do IEEE organizado por
classe de usuários (IEEE 830-1998) e com o modelo sem casos de uso apresentado pelo RUP • Categoria: Ajuda e/ou Documentacao Online • Prioridade: Essencial • Estabilidade: Alta Rastreabilidade • RF8 - O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o que foi cadastrado
90
• RNF5 - O sistema deve abrir somente arquivos com extensão ".spp" • Categoria: Restrição de Projeto • Prioridade: Opcional • Estabilidade: Alta Rastreabilidade • RF2 - O sistema deve permitir a abertura de um projeto existente. • RF6 - O sistema deve permitir ao usuário registrar versões do documento de ERS
• RNF6 - O sistema não deve permitir a abertura de mais de um projeto simultaneamente.
• Categoria: Confiabilidade • Prioridade: Opcional • Estabilidade: Baixa Rastreabilidade • RF2 - O sistema deve permitir a abertura de um projeto existente.
3.3 Regras de Negócio • RN1 - O sistema não incorporará as alterações no projeto quando essas forem realizadas diretamente no documento
textual gerado por ele Rastreabilidade • RF8 - O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o que foi cadastrado
• RN2 - O sistema deve marcar o rastreamento como “suspeito” quando algum dos itens que estão em alguma matriz de
rastreabilidade for alterado Rastreabilidade • RF4 - O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e regras de negócio • RF7 - O sistema deve permitir a criação de matriz de rastreabilidade entre requisitos funcionais, não funcionais e regras de
negócio • RN3 - O sistema não deve permitir a alteração da estrutura básica do projeto (seções)
Rastreabilidade • RF9 - O sistema deve permitir o cadastramento dos dados para as seções do documento de ERS
• RN4 - As informações constantes nos modelos de documento de ERS IEEE-830-1998 (requisitos organizados por classe de
usuário) e RUP (modelo de documento de ERS sem casos de uso) deverão ser fixas no projeto. A estrutura deverá seguir o seguinte modelo:1.Introdução (observado no modelo do IEEE e no RUP): 1.1.Propósito; 1.2.Escopo; 1.3.Definições, Acrônimos e Abreviaturas; 1.4.Referências; e 1.5.Visão Geral; 2.Descrição Geral (observado no modelo do IEEE e no RUP): 2.1.Perspectiva do produto; 2.2.Funções do produto; 2.3.Características do usuário; 2.4.Restrições; e 2.5.Dependências e suposições.3.Requisitos: 3.1.Requisitos funcionais organizados por classe de usuário (observado no modelo do IEEE); 3.2.Requisitos não funcionais; e 3.3.Regras de negócio. Rastreabilidade • RF4 - O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e regras de negócio • RF9 - O sistema deve permitir o cadastramento dos dados para as seções do documento de ERS
• RN5 - Todos os requisitos não funcionais cadastrados na ferramenta devem estar inseridos obrigatoriamente em uma
dessas categorias: * Observados no modelo do IEEE e no RUP: (i) interfaces de usuário; (ii) interfaces de hardware; (iii) interfaces de software; (iv) interfaces de comunicação; (v) desempenho; e (vi) restrições de projeto; e * Observados apenas no RUP: (i) usabilidade, (ii) confiabilidade, (iii) ajuda e/ou documentação online. Rastreabilidade • RF4 - O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e regras de negócio
• RN6 - Os requisitos funcionais e os não funcionais devem possuir no mínimo os dois atributos seguintes: Prioridade
(observado no modelo do IEEE, deve conter três categorias: essencial, desejável e opcional) e Estabilidade (também observado no modelo de documento de ERS do IEEE, deve conter as três categorias possíveis: alta, média e baixa) Rastreabilidade • RF4 - O sistema deve permitir o cadastro de requisitos funcionais, não funcionais e regras de negócio
• RN7 - Os requisitos funcionais devem possuir o atributo a seguir: Usuário (para poder gerar o documento de Especificação
de Requisitos de Software por classe de usuário, faz-se necessário o cadastro e posterior atribuição do mesmo aos requisitos elicitados). Rastreabilidade • RF8 - O sistema deve gerar o documento de ERS, para qualquer versão, de acordo com o que foi cadastrado