mecanismos de integração e extensão da ferramenta de...

Ferramentas de Gerenciamento de Requisitos

Engenharia de Requisitos e Ferramentas Case

Universidade Federal de PernambucoDepartamento de Informática

Gilberto A. de A. Cysneiros FilhoMárcia Seabra Cabral

Recife, 5 de Dezembro de 1999.

1. IntroduçãoQuando os requisitos de um sistema são pobremente entendidos, possivelmente o produto final

não será livre de falhas e a versão do sistema entregue ao cliente na maioria das vezes não corresponde ao produto encomendado inicialmente. É comum que ao longo do desenvolvimento do software ocorra mudanças nos requisitos do sistema, mas o que ocorre é que estas mudanças raramente são documentadas, ou seja, o documento de requisitos não é atualizado. O problema ocorre quando o impacto que ocorre nos requisitos do sistema devido as mudanças que foram realizadas não são tratados adequadamente. Tais mudanças nos requisitos do sistema podem atrasar o prazo de entrega do sistema bem como alocar recursos adicionais ao mesmo. Devido a este e outros fatores não mencionados neste documento, várias empresas estão aperfeiçoando os métodos para adquirir, analisar e gerenciar os seus requisitos.

As equipes de projetos documentam seus requisitos em uma especificação de requisitos de software estruturada escrita em linguagem natural. Porém, há algumas limitações com relação a este tópico [Wiegers99]:

Dificuldade de rastreamento de requisitos;

Dificuldade de comunicar mudanças aos membros da equipe;

Dificuldade de armazenar informação complementar sobre cada requisito;

Dificuldade de definir ligações entre requisitos funcional e use cases correspondentes, projetos, testes e tarefas de projeto.

Com base nos problemas citados anteriormente, notamos que é crucial um gerenciamento de requisitos mais eficaz. Para auxiliar esta tarefa podemos utilizar ferramentas de gerenciamento de requisitos com o objetivo de produzir produtos eficazes, mas que também satisfaçam a necessidade do consumidor. Estas ferramentas fornecem funções para manipular e ver o conteúdo do banco de dados, importar e exportar requisitos, definir ligações entre requisitos e conectar requisitos para outras ferramentas de desenvolvimento de software.

Neste documento descreveremos as características básicas esperadas de uma ferramenta de gerenciamento de requisitos e damos visão geral de cinco ferramentas comerciais: o Caliber-RM da Technology Builders(TBI), o QSSrequireit e o DOORS da Quality System & Software(QSS), RequisitePro da Rational e o RTM Workshop da Integrated Chipware.

2. Ferramentas Comercias de Gerenciamento de RequisitosAs ferramentas de gerenciamento de requisitos deixam você definir diferentes tipos de

requisitos, como requisitos de negócio, use cases, requisitos funcionais, requisitos de hardware, requisitos não funcionais e testes. Elas permitem você diferenciar objetos individuais que você quer tratar como requisitos de outras informações úteis contidas no Documento de Requisitos(SRS). Todas as ferramentas possuem a capacidade para definir atributos para cada tipo de requisito o que é um grande vantagem sobre a abordagem típica de SRS baseada em documentos.

A maioria das ferramentas de gerenciamento de requisitos se integram com o Word, tipicamente adicionando um menu específico da ferramenta na barra de menu do Word. Outras se integram também com o Adobe FrameMaker, como o RTM Workshop. As ferramentas mais poderosas tem suporte a uma rica variedade de formatos para exportação e importação de arquivos. Algumas dessas ferramentas permitem que você selecione um texto específico de um documento para ser tratado como um requisito discreto, como também permitem você adicionar novos requisitos diretamente para banco de dados.

FERRAMENTAS DE GERENCIAMENTO DE REQUISITOS 2

Quando você marca um texto do documento como um requisito, as ferramentas normalmente destacam os requisitos(como um fundo de cor diferente ou uma cor de fonte diferente) e inserem bookmarks e textos ocultos. As ferramentas também permitem que você use um parser sobre documentos de várias maneiras para extrair requisitos individuais. Os mecanismos de parser serão imperfeitos a menos que você use estilos de textos e palavras reservada de uma forma padronizada na escrita do documento.

As ferramentas suportam o nomeação de requisitos de um forma numérica e hierárquica, além de manterem um identificador interno único para cada requisito. Esses identificadores normalmente consistem de um pequeno prefixo que indica o tipo do requisito seguido por um identificador único. Algumas ferramentas fornecem um visão dos requisitos com interface similar a o Windows Explorer o que deixa você manipular uma árvore de requisitos hierárquica.

Outras capacidades das ferramentas incluem a habilidade de gerar documentos de requisitos, tanto num formato especificado pelo usuário ou como um relatório tabular. Por exemplo o Caliber-RM possui Document Factory que possibilita você definir um modelo(template) no Word para formatar a saída das informações dos requisitos de acordo com suas necessidades.

Todas as ferramentas possuem características de rastreamento que permitem a definição da ligação entre requisitos e outros elementos do sistema. Quando um requisito é modificado depois que você tem estabelecido ligações, algumas dessas ferramentas automaticamente seguem as ligações e marcam qualquer outros requisitos ou componentes que podem ser afetados pelas mudanças como suspeitos(suspect). Isso ajuda a analisar o impacto das mudanças de requisitos propostas.

Outras características incluem a habilidade de definir grupos de usuários e permissões para usuários selecionados ou grupos para leitura, escrita, criação e remoção de projetos, requisitos, atributos e os valores dos atributos. Alguns dos produtos permitem que você insira objetos não textuais como planilhas de texto e gráficos no repositório de requisitos,

As ferramentas mostram uma tendência de aumentar a integração com outras ferramentas usadas no desenvolvimento de sistemas, como teste, modelagem de projeto, gerenciamento de projeto. Uma das características importantes quando você seleciona um ferramenta de gerenciamento de requisitos é observar se ela troca dados com outras ferramentas que você usa. Alguns exemplos de interconexão desses produtos são:

Você pode ligar os requisitos no RequisitePro a use cases modelados no Rational Rose e para caso de testes no Rational Team Test.

O DOORS deixa você rastrear requisitos para elementos de projeto individual armazenados no Rational Rose.

O RequisitePro e o DOORS podem conectar requisitos individuais a tarefas de projeto no Microsoft Project.

O Caliber-RM deixa você ligar requisitos a use cases, classes ou elementos de projeto armazenados no Select Enterprise da Select Software e para entidades de teste armazenados no TestDirector da Mercury Interactive.

2.1 QSSrequireit

O QSSrequireit é uma ferramenta de gerenciamento de requisitos que trabalha em conjunto com o Microsoft Word. Toda a funcionalidade do Word é disponível no desenvolvimento e no gerenciamento de seus documentos de requisitos, junto com a funcionalidade adicional do QSSrequireit para capturar, organizar e rastrear os requisitos. Ele é projetado para usuários de PC com poucas ou nenhuma experiência sobre gerenciamento de requisitos.


2.1.1 Caracterísitcas

O QSSrequireit trabalha com a estrutura de projetos e documentos. Um projeto é basicamente um folder (diretório do Windows) que contém um conjunto de documentos QSSrequireit(arquivos do Windows) relacionados.

Para criar um projeto QSSrequireit basta você criar um diretório no Windows e salvar um documento QSSrequireit nesse diretório. Todos os documentos QSSrequireit que pertencerem ao mesmo diretório automaticamente pertencem ao mesmo projeto. E o nome do projeto é idêntico ao nome do diretório que contém os documentos QSSrequireit.

Um documento QSSrequireit pode ser criado de um documento Word novo ou através de um documento já existente. Para se criar um documento QSSrequireit você deve abrir um documento no Word e se garantir que ele está salvo no diretório correto(projeto). E então clicar no botão Start QSSrequireit da barra de ferramentas do Word e entrar as informações sobre documento QSSrequireit na caixa de dialógo Document Information conforme figura 1. Você pode digitar um título, uma descrição, um prefixo para o documento e selecionar uma lista de atributos iniciais. O título do documento é um campo obrigatório que pode ser dado o mesmo nome do arquivo e ele deverá ser único no projeto. O campo de descrição também é obrigatório e pode conter até 255 caracteres e deve conter um resumo do conteúdo do documento. O prefixo do documento, entrado na caixa de diálogo é adicionado ao identificador único atribuído pelo sistema a cada requisito. Uma vez criado, o prefixo do documento não pode ser editado.

Você pode marcar os requisitos manualmente ou automaticamente. Para marcar manualmente você tem que selecionar o texto desejado e clicar no botão Mark Requirement da barra de ferramentas do QSSrequireit. Para marcar os requisitos automaticamente você tem que escolher a opção do menu QSSrequireit =>Automated Requirement Marking. E na caixa de dialogo Automated Requirement Marking (ver fig.2) você pode especificar uma palavra e então clicar no botão Find. Se a sentença encontrada é para ser um requisito clique no botão Accept. Se você quer todas as sentenças no


Figura 0 – Tela de Informação do Documento

Figura 2 – Tela de Marcação dos Requisitos

documento que contenha a palavra procurada seja marcada como requisitos você então clica no botão Accept All.

Após você criar um requisito o QSSrequireit atribui automaticamente um número de requisitos e um identificador ao requisito criado. O número de requisitos é um inteiro que é atribuído unicamente a cada documento de requisitos. O identificador do requisito também é único e combina o prefixo(que é definido quando da criação do documento QSSrequireit) e o número do requisito( ex.: UR3).

Certas funções do QSSrequireit só operam sobre o requisito corrente. Isso inclui a remoção dos requisitos, navegação através das ligações e a expansão de um requisito para visualizar seus atributos. Para fazer um requisito corrente você tem que colocar o cursor em qualquer lugar dentro do texto do requisito que você quer marcar como corrente e clicar no botão da barra de ferramentas do QSSrequireit. O requisito corrente é mostrado com o texto na cor azul e com o fundo na cor turquesa.

QSSrequireit possui funções de navegação através dos requisitos. Ele possui as funções para pular para o próximo, para o anterior, para o primeiro, para o último e para um requisito específico(onde você tem que entrar o número do requisitos). Estas funções podem ser alcançadas através do menu do QSSrequireit=>Go to Requirement.

Outras funções do QSSrequireit são as de permitir ligação entre requisitos e a navegação entre eles possibilitando a análise de impacto, definir atributos definidos pelo usuário e os seus valores como também dos atributos predefinidos, mecanismos manual e automático para definir os atributos como suspeitos(suspect), filtros sobre os requisitos de acordo com algum critério sobre os atributos e a geração de relatórios tabular dos requisitos e de suas ligações.

Requisitos do Sistema

Sistema Operacional Windows 95, Windows 98 ou Windows NT 4.0 ou superior

Processador 486 ou melhor

Espaço de Disco 2MB mínimo

Memória 8MB para Windows 95, 16MB para Windows98 e Windows NT

Processador de Texto Microsoft Word 97 ou superior

2.4 RequisitePro

A solução de gerenciamento de requisitos da Rational é constituída basicamente de três ferramentas: o Rational RequisitePro, o Rational RequisiteEnterprise Add-on e o Rational RequisiteWeb.

O RequisitePro é a ferramenta de gerenciamento de requisitos baseada no Windows. Ele organiza os requisitos através da ligação sincronizada com Microsoft Word com um banco de dados comercial multi-usuário, fornecendo rastreamento e gerenciamento de mudanças através do ciclo de vida do projeto. O RequisitePro combina ambas as abordagens centrada a documento e centrada a banco de dados para o gerenciamento de requisitos

O RequisiteEnterprise Add-on permite a seleção do banco de dados a ser utilizado para o gerenciamento das informações dos requisitos. Você pode gerenciar os requisitos usando o banco de dados Microsoft Access, Oracle ou Microsoft SQL Server. Além disso, ele fornece API baseada em COM que pode ser usada para estender as funcionalidades do RequisitePro.


O RequisiteWeb é uma interface para Web que fornece ao usuário a capacidade de ambos ver e modificar as informações dos requisitos. O RequisiteWeb elimina a necessidade de se instalar um software cliente em cada máquina, pois ele permite que os membros do time contribuam para o projeto via um interface com a Web. O RequisiteWeb é bastante útil para ambientes multi-platoforma ou remoto.

O RequisiteWeb permite os usuários modificar os atributos dos requisitos e os relacionamentos de rastreamento, participar de grupos de discussão e criar e ver filtros através de uma interface com os browser Internet Explorer ou Netscape Navigator.

2.4.1 Características

Quando você inicia o RequisitePro, o que você primeiro ver é paleta de ferramentas(Tool Palette) conforme figura 3. A paleta de ferramentas é o principal método para acessar o RequisitePro. As outras janelas que você poderá trabalhar são o RequisitePro Views(fig. 4) e a janela do Microsoft Word.

Figura 3 - Paleta de Ferramentas

Figura 4 – RequisitePro View mostrando uma matriz de atributo


O RequisitePro liga dinamicamente os documentos do Word com o banco de dados. Assim ele mantém a informação contextual capturada no documento enquanto permite mecanismo de consulta e ordenação no banco de dados sobre os mesmos requisitos. O RequisitoPro possui permite a ligação entre requisitos e essas ligações podem ser manipuladas através de uma estrutura de matriz ou de árvore conforme figura 5 e 6 respectivamente.

Figura 5 – Matriz de Rastreamento

Figura 6 – Árvore de Rastreamento


O RequisitePro possui mecanismos de integração com o Ratioanal ClearCase, Microsoft SourceSafe e o INTERSOLV PVCS, possibilitando você criar versões de baselines de todo projeto de requisitos . Ele também se integra com o Rational Rose e com o Rational TeamTest

Outras características do RequisitePro são a marcação automática de todos os requisitos relacionados como suspeitos quando um requisito é modificado, a criação de grupos de discussão sobre requisitos, o gerenciamento de mudanças(história dos requisitos - quando, quem e porque fez as mudanças), mecanismos de segurança, requisitos hierárquicos e um mecanismo chamado de Offline Authoring que permite que você trabalhe no Word sem o RequisitePro( O RequisitePro automaticamente atualiza o projeto quando documento é trazido de volta).


Rational RequisitePro 4.0

Sistema Operacional Windows 95, Windows 98 ou Windows NT 4.0

Processador Pentium 133Mhz ou melhor

Espaço de Disco 55MB mínimo

Memória 64MB recomendado

Processador de Texto Microsoft Word 95 ou Word 97 (8.0)

Suporte a LAN Windows Networking

Rational RequisiteEnterprise 4.0 Add-on

Software Rational RequisitePro 4.0

Banco de Dados Oracle 7.3 ou Microsoft SQL Server 6.5

Cliente Se usar o banco de dados Oracle, o software cliente deve ser instalado

Ratioanal RequisiteWeb 4.0

Requisitos do Servidor

Sistema Operacional Windows NT Server 4.0 Service Pack 3

Memória 128MB

Processador Pentium 200MHz ou melhor

Processador de texto Microsoft Word 97 (8.0)

Requisitos do Cliente

Browser Internet Explorer 4.0 ou Netscape Navigator para Windows 95/98 ou para UNIX


2.3 RTM Workshop

RTM WORKSHOP é uma completa re-engenharia da ferramenta conhecida como RTM. A Marconi Systems Technology desenvolveu originalmente o RTM em 1990. Em 1997, a Integrated Chipware começou a gerenciar o produto e tem desde então atualizado o RTM.

RTM WORKSHOP é uma coleção de características de software que são agrupadas em duas caixas de ferramentas: icCONCEPT e icMANAGE.

As características das caixas de ferramentas do RTM WORKSHOP são listadas abaixo:

IcCONCEPT IcMANAGE

IcExplorer --- ferramenta de navegação visual Automação de engenhariaGeração de relatórios padrão Formulários definidos pelo usuárioDefinição de usuários, grupos, papéis Workflow engineCaptura de requisitosGerenciamento de mudançasAnálise de impactoRastreamentoDesktop publishingLinguagem de scripting SQL embutidaControle de versãoMulti-usuárioInteratividade baseada na web

O RTM Workshop trata os requisitos como objetos que pertencem a classes que correspondem a vários tipos de requisitos ou outros artefatos de projetos como elemento de projeto ou casos de teste. Cada projeto define um esquema de classe na forma de um diagrama entidade-relacionamento. Rastreamento é feito pela definição de ligações entre objetos de classes(ou dentro da mesma classe), baseado nos relacionamentos de classes definidos no esquema.

O RTM Workshop se integra com o Word e com o Adobe FrameMaker de forma semelhante ao RequisitePro. Além disso o RTM possui uma interface tipo Windows Explorer para manipular requisitos na forma de uma árvore hierárquica. Ele possui a flexibilidade de importar requisitos de diferentes tipos de documentos(como o Excel e o Project) e pode exportar requisitos em vários formatos.

No RTM você pode criar formulários rapidamente para manipular os objetos numa classe específica usando uma ferramenta de desenho.


Sistema Operacional UNIX, PC

Processador PC: Server Pentium-200 / Client Pentium-166

Espaço de Disco Server: Unix: Oracle Server (including project database) 350Mb / RTM Workshop 150Mb

PC: Oracle Server (including project database) 200Mb / Oracle

Client 10Mb / RTM Workshop 40Mb


Memória Unix: Server 64MB / Client 32MB

PC: Server 64MB / Client 32MB

2.4 DOORS

O DOORS é um produto sofisticado que pode gerenciar requisitos sobre grandes projetos. Ele trata requisitos individuais como objetos que podem ser agrupados em módulos que por sua vez pertencem a um projeto. Cada projeto possui uma lista de usuários que podem acessa-los. Ele possui uma tela que mostra os requisitos, junto com seus valores de atributos, indicadores de ligações para outros requisitos e barras coloridas que indicam qual o estado de mudança do requisito(ver fig. 7).

Ele possui quatro visões que podem representar os requisitos:

A visão gráfica que mostra a hierarquia da estrutura do módulo(fig. 8)

A visão resumida que mostra apenas os requisitos(fig. 9)

A visão filtrada que mostra apenas os atributos selecionados(fig. 10)


IdentificadoresDos Objetos

Identificadores de Links

Objeto Somente de Leitura

Figura 7 – Tela de Requisitos do DOORS

Figura 11 – Visão de Rastreamento

A visão de rastreamento que mostra claramente os relacionamentos de rastreamento(fig 11)


Figura 8 – Visão Gráfica

Figura 9 – Visão Resumida

O DOORS armazena a história das mudanças de objetos individuais, módulos, mas objetos não possuem número de versões. O DOORS inclui uma linguagem de scripting(DXL) com sintaxe tipo C pra personalização ou desenvolvimento de extensões. Ele também possui interfaces para o Microsoft Project, Rational Rose e o COOL: Teamwork da Select Software, além de você poder criar interfaces para outras ferramentas através de uma API. Ele também pode exportar e importar requisitos para vários formatos.

Outras características interessantes do DOORS são um mecanismo de proposta de mudanças(CPS – Change Proposal System) e o acesso através da Internet pelo DOORSNet.

2.5 Caliber-RM

O Caliber-RM fornce um interface bastante compacta que combina uma visão hierárquica em árvore do requisitos com detalhes dos requisitos acessíveis através painel com tabuladores do lado direito da tela(ver fig.12).


Figura 10 – Visão Filtrada

Outras características do Caliber-RM são a definição de requisitos atribuídos pelo usuários, geração de documentos(através do Document Factory), importação de requisitos do Word, gerenciamento de versão do requisitos, grupos de discussão dos requisitos, criação de um glossário dos termos usados na definição dos requisitos, reuso de requisitos, mecanismo de segurança e criação de baseline.


Server

Windows NT 4.0 ou superior (Service Pack 3 ou supeior)

Pentium 100 ou superior

128 Mb RAM

125 Mb de espaço de disco disponível

Cliente

Windows 95/98 ou Windows NT 4.0 ou superior

Pentium

64 Mb RAM

50 Mb de espaço de disco disponível

3. Seleção de Ferramentas de Gerenciamento de RequisitosExistem várias ferramentas que auxiliam o gerenciamento de requisitos, mas a escolha de qual

ferramenta utilizar depende do usuário e de sua circunstância bem como do processo de gerenciamento de requisitos [INCOSE].

3.1 Identificação de Fatores Para Seleção de Ferramentas

Segundo o [INCOSE] são os fatores que influenciam a seleção.

3.1.1 Tamanho do Projeto

O termo “projeto” refere-se a uma tarefa e ao grupo de pessoas organizadas para acompanhá-lo. A tabela 1 mostra uma descrição do tamanho do projeto [INCOSE99]

.


Figura 12 – Tela de Requisitos do Caliber-RM

1. Tiny 2. Small 3. Medium 4. Large 5. HugeDesign Professionals (no.) 3 15 75 400 2.000

Duration (months) 12 24 36 48 60Geographical Area Building City Multi-city Country World

States/modes (number) 3 30 300 2.000 10.000States/modes (type) Well Defined Deterministic Stochastic

Interface Params (no.) 9 90 900 6.000 30.000Physical Environment of

ProductIndoor In/outdoor 1

LocationOutdoor Global

Global Space, Ocean

Requirements (no. of text pages)

15 150 500 2.000 50.000

Requirements (approxinate no.)

150 1.500 5.000 20.000 500.000

Number of Specs Generated 1 3 10 200 1.000Examples Electric Kitchen

mixer; low budget art film

Housing development; TV set; grand

opera

Night viewing system; highway system

Aircraft Space vehicle; Battleship & armament

Tabela 1 – Tamanho dos Projetos

3.1.2 Disciplina do Usuário

Há várias categorias de usuários que utilizam a ferramenta de gerenciamento de requisitos:

Engenheiro de Sistemas

Análise dos Requisitos do Sistema; Projeto do Sistema; Engenheiro de Confiabilidade; Engenheiro de Manutenibilidade; Suporte Logístico Integrado;

Engenheiro de Teste;

Outros. Gerente

Especialista em Projeto/Análise

Projeto Elétrico; Projeto Mecânico; Projeto Ótico; Projeto de Software; Outros.

Garantia de Qualidade

Fabricante (Manufacturing)

Consumidor

Externo; Interno.


3.1.3 Estrutura/Tamanho Organizacional

O ambiente organizacional exerce um impacto direto sobre os requisitos de um sistema. Os fatores que influenciam este impacto podem ser resumidos em: tamanho e maturidade da organização e sua comunicação e suporte a infra-estrutura [INCOSE]. A tabela 2 descreve o tamanho/estrutura da organização.

1. Tiny 3. Medium 5. HugeProfessional Employees (number)

3-15 300-1.500 30.000-150.000

Geographical Area Building Multi-City WorldStructure Unstructured Structured RigidDatabases None Electronic Information Systems ElaborateCommunication System No Formal System Electronic Elaborate Electronic

Tabela 2 – Tamanhos da Organização.

3.1.4 Processo de Maturidade Organizacional Relatado a Ferramenta RM

Dependendo de diferentes níveis organizacional com relação a maturidade do processo, há necessidade por parte das organizações de diferentes ferramentas de gerenciamento de requisitos.

a. Ferramenta de Gerenciamento Relatada a Processo

Os processos organizacionais, segundo o INCOSE, relacionados a ferramenta de gerenciamento de requisitos são: processos de gerenciamento de requisitos em engenharia de sistema; ferramenta, distribuição de documentação de ferramenta e processo de instalação; computador e suporte de ferramenta; processo de aprendizagem de uso da ferramenta; processo de desenvolvimento de métodos de ferramenta.

Os itens chaves que devem ser cobertos no processo de gerenciamento de requisitos em engenharia de sistemas são os seguintes:

Requisitos do consumidor/market no topo do nível começará e será identificado formalmente;

Cada requisito derivado será documentado em um relatório ou modelo de documento/técnico de análise formal;

Cada requisito será atribuído para uma organização ou indivíduo específico;

Checagem será realizada com a finalidade de verificar quais requisitos têm um pai e são atribuídos apropriadamente;

Requisitos de verificação/teste serão incluídos neste processo;

Um processo de revisão será usado durante análise de requisitos.


b. Definições do Nível de Maturidade

Os níveis de maturidade são mostrados na tabela 3.

Level 1 Level 2 Level 3 Level 4-5Requirements Management

Done Planed by Project Organizational Standard Followed

Improvement Method Followed

Tool & doc distribution & Installation

Individual Must Get Project does Organization-wide Support

Computer & Tool Support

Individula Maintenance

Project Suport Support Organization & Strict Standards

Tool Use Learning Individual Study Project Classes & Study Time

Formal Training Program & Study Time

Tool Methods Individual Must Determine

Project Must Determine Organization-wide Methods available

c. Mapeamento do Modelo do Processo de Maturidade em Engenharia de Sistemas

O NCOSE (Capability Assessment Working Group) e o consórcio da indústria (Bate et al. 1994), têm definido modelos capacitação de processos de modelos de maturidade para engenharia de sistemas com o objetivo das organizações avaliarem seu processo de maturidade. Áreas de processos que compõem o modelo:

Áreas do Processo de Engenharia

Entender as necessidades e expectações do consumidor; Derivar e alocar requisitos; Analisar soluções candidatas; Desenvolver arquiteturas física; Integrar disciplinas; Integrar sistema; Integrar e verificar sistema.

Áreas do Processo do Projeto

Planejar esforço técnico; Gerenciar configurações; Monitorar e configurar esforço técnico; Gerenciar risco; Garantir qualidade.

Áreas do Processo Organizacional

Definir processo de engenharia do sistema da organização; Melhorar o processo de engenharia do sistema da organização; Gerenciar o ambiente de suporte de engenharia de sistemas; Gerenciar treinamento de sistemas de engenharia; Gerenciar evolução do produto.


Áreas chave que correspondem à gerenciamento de requisitos relatada a ferramenta: entender as necessidades e expectações do consumidor, derivar e alocar requisitos, gerenciar o ambiente de suporte de engenharia de sistemas e gerenciar treinamento de sistemas de engenharia contém as práticas base:

Entender as necessidades do consumidor e área de expectação;

Derivar e alocar área de requisitos;

Gerenciara a área de ambiente de suporte a engenharia de sistemas;

Gerenciar a área de treinamento de engenharia de sistema.

Os cinco níveis de maturidade, depois do “Nível 0 – Não Executado”, que representam “os estágios através do qual o progresso do processo é definido, implementado e melhorado” são:

1. Práticas base informalmente executada (boas práticas são executadas);

2. Práticas base planejada e trilhada (nível de projeto);

3. Práticas base bem definida (uma prática padrão é definida e executada através de uma organização);

4. Práticas base controlada quantitativamente (medição dos objetivos de qualidade são estabelecidos);

6. Práticas base melhoradas continuamente (medição contra os objetivos é usado para melhorar o processo).

3.2 Arquiteturas das Ferramentas

a. Visão das Arquiteturas

Nas arquiteturas A e B, baseadas em documentos e híbrida respectivamente, os requisitos estão na forma de documentos, que são armazenados em formato eletrônico. Nas arquiteturas C e D, baseadas em banco de dados proprietário e banco de dados comercial respectivamente, os requisitos estão armazenados em um banco de dados eletrônico ou em um banco de dados. No decorrer deste documento haverá uma descrição mais detalhada destas arquiteturas.

b. Classes

Para as classes C e D temos três classes de funções: classe 1, classe 2 e a classe 3.

Classe 1 – Com Características Básicas – a ferramenta encontra as necessidades de gerenciamento de requisitos básicas descritas anteriormente.

Classe 2 – Com Características Básicas e Estendidas – possui muitas das capacidades descritas anteriormente para certas circunstâncias. Estas ferramentas podem ser muiltiusuários e baseada em workstation, provavelmente com uma versão baseada em PC.

Classe 3 – Com Capacidade de Análise – Ferramentas nesta classe possuem a propriedade de facilitar uma ou mais metodologias de engenharia de sistemas com capacidade de análise built-in significante, fornece certas capacidades, tais como: decomposição/análise funcional, análise estruturada, linguagem


de requisito formal, caracterização de requisitos em uma formalidade elemento-relação-atributo, orçamentos técnicos, modelagem de comportamento, e representação de sistema gráfico/hierárquico.

b. Exclusões

As ferramentas de propósito geral não possuem provisão ou customização específica para gerenciamento de requisitos, porém fornecem alguma automação de preparação de tabelas de requisitos e seu destino. Estas ferramentas incluem spreadsheets (LotusTM, MSExcelTM, Quatro ProTM) ou processadores de texto (MS WordTM, WordPerfectTM, FrameMakerTM), que são usadas sem nenhuma provisão de automação.

3.2.1 Arquitetura A – Baseada em Documentos

Este tipo de arquitetura utiliza especificações com cada requisito identificado, como identificadores em chaves {}; tabelas de referência cruzada nas especificações; tabelas de referência cruzada externa em documentos ou spreadsheet. As tabelas externa são usadas para atribuir requisitos de uma especificação ou análise para seu destino e lista o nome/designação do requisito.

É um tipo de arquitetura baseada em spreadsheets e/ou processador de texto usadas com macros para automação, programas de banco de dados de objetivo geral, como o MSAccessTM.

3.2.2 Arquitetura B -Híbrida

Este tipo de arquitetura possui validação automática de requisitos, as mesmas características da arquitetura anterior. É uma arquitetura baseada na combinação de ferramentas whatever que é utilizado para geração de spec mais um software auxiliar customizado para funções automáticas. Exemplo: sistema P66 TeamworkTM.

3.2.3 Arquitetura C – Baseada em Banco de Dados Proprietário

Todo o texto do requisito, nesta arquitetura, permanece no banco de dados do computador. São ferramentas de requisitos fullfledged e dedicadas. O banco de dados utilizado é de objetivo especial, as ferramentas talvez sejam capazes de escrever ou ler um banco de dados em um formato que é usado pelas ferramentas de banco de dados padrão. Esta arquitetura possui três classes:

a. Classe 1 – Somente com Características Básicas – Exemplo: tbd.

b. Classe 2 – Com Características Básicas e Estendidas – Exemplo: DOORS (Dynamic Object Oriented Requirement System) TM Versão 2.1 e Vital LinkTM Versão 2.0.

c. Classe 3 – Com Características de Análise- Exemplo: CORETM Versão 1.2 e RDD-100Tm Versão 4.0.

3.2.4 Arquitetura D – Baseada em Banco de Dados Comercial

Nesta arquitetura, os requisitos estão no banco de dados do computador. São ferramentas fullfledged e dedicadas. O programa de banco de dados é um programa comercial separado que é fornecido e integrado com a ferramenta. Classes da arquitetura:


a. Classe 1 – Somente com Características Básicas – Nenhuma.

b. Classe 2 – Com Características Básicas e Estendidas – Exemplo: RequiremenTraceability & Management (RTM) TM Versão 2.3, esta ferramenta utiliza o banco de dados relacional do OracleTM.

c. Classe 3 – Com Características de Análise – Exemplo: SLATE TM (System Level Automation Tool for Engineers Versão 2.0, utiliza o banco de dados orientado a objetos VersantTM.

3.2.5 Mapeamento da Taxonomia da Ferramenta

O NCOSE Systems Engineering Tools Working Group, em 1994, classificou as ferramentas de engenharia de sistema da seguinte forma:

Por Uso – mapea a classificação ao processo;

Por Nível de Formalidade – informal a formal;

Por Estrutura Interna – habilidade de modificar a informação base;

Por Interoperabilidade – isolar totalmente os ambientes integrados;

Por Expandibilidade - para crescimento futuro;

Por Plataforma – ambiente de hardware e software;

Por Metodologia – a metodologia suportada;

Por Banco de Dados Interno – qual sistema de gerenciamento de banco de dados;

Por Fase no Ciclo de Vida – qual fase do ciclo de vida é aplicável.

Caracterização das características das arquiteturas e a classificação do NCOSE:

Critérios do Grupo de Trabalho de Ferramentas do NCOSE

Arquitetura

A B C D

Uso Gerenciamento de Requisito [Classe 3: Modelagem d eSistema e Simulação]Formalidade Semi-Formal ou FormalEstrutura Restrita ExtensívelExpansibilidade Não SimInteroperabilidade VáriosPlataforma Único Usuário Única (PC/Macintosh) ou Estação MultiusuárioMetodologia Usualmente uma

vezUsualmente Repetida

Banco de Dados Arquivo Flat (Documento)

Arquivo Flat e Possivelmente BD Relacional

Built-in Relacional/BD

OO

BD Objetivo Geral

Relacional/ooCiclo de Vida Projeto/Definição de Requisito


3.3 Necessidade de Utilização de Ferramentas de Requisitos

3.3.1 Características

Uma ferramenta de gerenciamento de requisitos deve conter basicamente as atividades de identificação, avaliação, iteração e interface.

a. Identificação: Identificação dos Requisitos – Os requisitos devem ser identificados de uma maneira detalhada, cada um como “gotta do” é avaliado por alguém (uma organização, um indivíduo ou uma companhia), como um requisito separado. Não é obrigatório que toda a declaração de requisito esteja na ferramenta para que o requisito possa ser identificado. Exemplos de ferramentas que não contém declaração de requisitos são ferramentas baseadas em spreadsheets e ferramentas que contam com código no documento. O requisito mínimo que a ferramenta deve possuir é fornecer um meio de identificar não ambigüidade em cada requisito.

b. Avaliação: Avaliar e Armazenar Requisito – Cada requisito deve ser avaliado claramente durante o progresso do processo flowdown. O requiisito deve também ser armazenado pelo um destino em particular, como por exemplo um item de software critico. O requisito mínimo que a ferramenta deve possuir é fornecer um meio de identificar não ambigüidade durante a avaliação de cada requisito no destino para que possa ser feita uma analise.

c. Iteração: Versão do Requisito – Como o desenvolvimento de requisitos é um processo iterativo que envolve versões seqüenciais, faz-se necessário conhecer qual a versão em particular que esta em uso. O requisito mínimo que a ferramenta deve fornecer é a identificação da versão, o revisor, data e hora etc.

d. Iteração: Identificação/Linha Base do Grupo de Revisão de Requisitos – As mudanças nos requisitos devem ser disseminadas em grupos em intervalos controlados. Aconselha-se adicionar um resumo da informação descrevendo a razão da revisão. Requisito mínimo que a ferramenta deve possuir é identificar não ambigüidade nos grupos referentes as versões dos requisitos.

e. Interface: Interface de Dados Básica – É desejável uma interface padrão em todo o software. O requisito mínimo que a ferramenta deve possuir é importar ou exportar arquivos de dados do computador em algum formato prescrito que contém declarações/identificadores dos requisitos com todos os atributos e relacionamentos manuseados normalmente pela ferramenta.

3.3.2 Desempenho

O motivo pelo qual se utiliza uma ferramenta automatizada é o aumento da eficiência do gerenciamento de requisitos e tornar as funções de gerenciamento profitable, caso contrário será impraticável. Por isto o sistema de gerenciamento de requisitos deve ser de custo eficaz para todas as funções.

3.3.3 Instalação e Manutenção

A ferramenta deve ser de localização e acesso fácil. Uma boa plataforma deve ser escolhida para um bom trabalho da equipe.


3.4 Vantagens do Uso de Ferramentas de Gerenciamento de Requisitos

Abaixo há uma lista de algumas vantagens do uso de ferramentas de gerenciamento de requisitos segundo o [INCOSE].

1. Identificação e Captura dos Requisitos

1.1 Análise/enriquecimento do Documento de Entrada – Usar a informação do documento existente (o glossário, índice, etc) aids a análise do requisito do usuário, identificação de requisitos, etc.

Análise de Mudança/Comparação do Documento de Entrada – A ferramenta deve possuir a habilidade de comparar/contrastar duas versões diferentes de um documento fonte.

1.2 Parsing Automático de Requisitos – A identificação de requisitos deve ser feita de maneira automática por meio de palavras chave, estrutura, identificadores únicos etc, com a finalidade de criar requisitos do texto.

1.3 Identificação de Requisito Iterativa/Semi-automática – A ferramenta ser capaz de identificar os requisitos por meio do mouse, ou seja o mouse deve destacar o requisito, ou prompting ao sistema: isto é um requisito?.

1.4 Identificação Manual do Requisito – Deve haver a possibilidade de criação ou identificação por meio manual.

1.5 Classificação do Requisito – Capacidade da ferramenta classificar/categorizar os reaquisitos durante a identificação.

2. Capturação da Estrutura do Elemento do Sistema – Após os requisitos terem sido capturados, eles devem ser alocados para os subeelementos do sistema.

2.1 Capturar Graficamente a Estrutura do Sistema – A ferramenta deve possuir a capacidade de capturar graficamente a implementação do sistema (arquitetura, decomposição funcional, WBS) e mostrar isto graficamente desde que os requisitos sejam ligados a eles (arquitetura, decomposição funcional, WBS).

2.2 Captura Textual da Estrutura do Sistema - A ferramenta deve possuir a capacidade de capturar textualmente a implementação do sistema (arquitetura, decomposição funcional, WBS) e mostrar isto textualmente desde que os requisitos sejam ligados a eles (arquitetura, decomposição funcional, WBS).

3. Análise de Rastreamento – o usuário deve ser capaz de visualizar de onde vêm as ligações, para onde vão e porque são aplicadas.

3.1 identificar Incosistência – O usuário deve ser capaz, por meio da ferramenta, identificar inconsistência, como por exemplo: requisitos não ligados ou elementos do sistema.

3.2 Visibilidade das Ligações Existentes da Fonte para a Implementação – O usuário deve possuir a habilidade de seguir a ligação para ver de onde ela vem e para onde irá.

3.3 Verificação do Requisito – Durante a vida do projeto, a ferramenta de gerenciamento de requisito deve ser usada para verificar quais os requisitos que já foram encontrados. A ferramenta deve ser capaz de saber quem fez o requisito, e como o requisito foi feito.

4. Gerenciamento de Configuração


4.1 Histórico das Mudanças do Requisito, quem, o que, quando, onde, porque e como – Capacidade da ferramenta, após os requisitos terem sido capturados, de manter um histórico das mudanças dos requisitos, quem mudou, quem fez, porque foi feito o requisito etc.

4.2 Controle da Versão/Linha Base – Capacidade da ferramenta de comparar e contrastar entre as várias versões de salvamento dos requisitos.

4.3 Controle de Acesso – A ferramenta deve proteger os requisitos de modificação, visualização por pessoas não autorizadas.

5. Groupware – O trabalho que feito pela equipe de engenheiros sobre a mesma informação ao mesmo tempo é crítico.

5.1 Suporte a Revisão Concorrente, Markup e Cometários – Capacidade da ferramenta de suportar uma equipe de engenheiros revisando, marking up e comentando os requisitos ou alternativas de implementação.

5.2 Avaliação/Controle de Acesso Multi-Nível – O controle de acesso ao banco de dados deve ser temperado pelo controle de acesso multi-nível, como por exemplo ter a habilidade de proteger coisas que estão sendo modificadas.

CALIBER RM 2.0 DOORS 4.0 QSSrequireit

1.0RTM 4.X

Captura Requisitos/IdentificaçãoAnálise/Enriquecimento do

Documento de EntradaCompleto Completo Completo Completo

Mudança/Comparação de Análise do Documento de

EntradaCompleto Parcial

InexistenteCompleto

Parsing Automático dos Requisitos Completo Completo Completo Completo

Identificação do Requisito Iterativa/Semi-automática Completo Completo Parcial CompletoIdentificação Manual de

Requisitos Completo Completo Completo CompletoOperação em Modo Batch

Completo Completo Inexistente CompletoAtualização em Modo Batch por


Documento/Link-fonte Completo Parcial Completo CompletoClassificação de Requisitos

Completo Completo Completo CompletoCaptura da Estrutura do

Elemento do SistemaCaptura da Estrutura do Sistema

Graficamente Parcial Completo Completo CompletoCaptura da Estrutura do Sistema

Textual Completo Completo Completo CompletoFlowdown dos Requisitos


Derivação de RequisitosCompleto Completo Completo Completo

Alocação do Desempenho dos Requisitos aos Elementos do Sistema

Completo Completo Completo Parcial

Ligação Bidirecional dos Requisitos aos Elementos do Sistema

Completo Completo Completo Completo

Razão, Contabilidade, Teste/Validação Captura de Alocação

Completo Completo Completo Completo

Análise de Rastreamento

Identificar Inconsistência CompletoCompleto Completo Completo

Visibilidade das Ligações Existentes da Fonte Para a Implementação

Completo CompletoCompleto Completo

Verificação de Requisito CompletoCompleto Completo Completo

Verificação do Desempenho do Requisito dos Elementos do Sistema

ParcialCompleto Inexistente Completo

Gerenciamento de Configuração

Histórico das Mudanças dos Requisitos Completo

Completo Inexistente Completo

Controle da Versão/Linha BaseCompleto

Completo Completo Completo

Controle de Acesso CompletoCompleto Completo Completo

Documentos e Outros Meios de Saída

Especificação Padrão de SaídaCompleto


Checagem de Qualidade e Consistência Completo


Apresentação de Saída CompletoCompleto Completo Completo

Características de Saída Customizadas Completo


WYSIWYG previewing CompletoCompleto Completo Completo

Relatório de Status CompletoCompleto Completo Completo

Relatório de Progresso/Status do Requisito Completo Completo

Completo Completo

Outras Consultas e Pesquisas ad hoc Completo



Grpoupware

Suporte de Revisão Concorrente, comentário e markup

CompletoCompleto Completo Completo

Controle de Avaliação/Acesso Multi-Nível Completo


Interface a Outras Ferramentas

Comunicação Inter-Ferramentas

Interfaces a Outras Ferramentas Inexistente

Troca de Informação Entre diferentes Instalação da Mesma Ferramenta

CompletoCompleto Inexistente Completo

Checagem de Consistência/Comparação Entre Conjunto de Dados da Mesma Ferramenta

ParcialCompleto Inexistente Parcial

Ambiente do Sistema

Único Usuário/Múltiplo Usuários Concorrentes

Completo

Várias Plataformas/SO

BD Comercial x ÚnicoInexistente

Interface do Usuário

Fazer alguma coisa enquanto está procurando por outra. Completo


Atualização Simultânea de Visão Aberta Completo

Completo Inexistente Parcial

Controle/Entrada de Dados Gráficos Iterativos

CompletoCompleto Parcial Completo

Execução via Scripts ou macrosCompleto Completo

Completo Completo

Interface com Browser Web

CompletoCompleto Inexistente Completo


5. ConclusãoO uso de ferramentas de gerenciamento de requisitos auxilia a equipe de desenvolvimento de

projeto de software. Permitindo a equipe gerenciar as mudanças dos requisitos com práticas sofisticadas.

A escolha de qual ferramenta utilizar irá depender da organização e do grau de maturidade da mesma. Por exemplo, se a empresa não tem um processo de gerenciamento de requisito bem definido ela pode iniciar com o QSSrequireit para ajudar o processo. Porque é uma ferramenta simples de trabalhar quando ainda não se tem um processo automatizado de desenvolvimento. Permitindo ao engenheiro de requisitos desenvolver o seu documento por meio de um editor de texto com adição de algumas funcionalidades.

Caso a organização queira continuar com o gerenciamento de requisitos baseado em documentos textuais e automatizar o processo através de um grupo de trabalho, ela pode utilizar o RequisitePro, que sincroniza as informações do requisito contidas no documento com as informações do banco de dados.

Em outro caso, podem se utilizar ferramentas centradas a banco de dados onde deve haver um treinamento com as pessoas envolvidas na elaboração do documento de requisitos, para que elas possam utilizar adequadamente a ferramenta.

6. Bibliografia[Wiegers99] Wiegers, K.; http://www.sdmagazine.com/supplement/ppm/features/s99/pp...

Jones, D. e York, D. “Factors Influencing Requirement Management Toolset Selection”, iProceedings of the Fifth Annual Symposium of the National Council on Systems Engineering, Volume II, July, 1995

Waters, J. “Software Requirement Management”, OBJECT Magazine, 1999.

Acaba R. “Lessons Learned In The Selection Company Standard Requirements Management Tool”, 1998.

Sommerville, I. e Kotonya, G. “Requirements Engineering”, Johon Wiley & Sons, 1997

[QSSrequireit] http://www.qssrequireit.com

[DOORS] http://www.qssinc.com

[RequisitePro] http://www.rational/requisite

[RTM Workshop] www.chipware.com

[Caliber-RM] www.tbi.com


http://www.tbi.com/

http://www.chipware.com/

http://www.rational/requisite

http://www.qssinc.com/

http://www.qssrequireit.com/

mecanismos de integração e extensão da ferramenta de...

Documents