Melhores práticas de engenharia de requisitosJulho de 2015

por Kevin Parker, vice-presidente da Worldwide Marketing, Serena Software (agora parte da Micro Focus®)

White Paper

Índice página

Os requisitos ainda são “uma coisa”? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Os requisitos são um processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Melhores práticas para o gerenciamento de requisitos . . . . . . . . . . . . . . . . . . . . 5

Atributos essenciais de uma solução de gerenciamento de requisitos . . . . . . . . 6

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

Os requisitos ainda são “uma coisa”?

Um requisito define um, e apenas um, comportamento atômico que é necessário ou

desejado pela empresa para atingir seus objetivos . O requisito deve ser testável de maneira

mensurável. Ele deve ser completo, contendo todas as informações necessárias. Não deve

contrariar nenhum outro requisito e deve ser coerente com as normas jurídicas . Deve ter

pelo menos uma parte interessada, pelo menos um patrocinador e beneficiar pelo menos um

usuário .

Um requisito define uma propriedade que é essencial para a empresa A definição é direta. A gama de metodologias adotadas para a coleta e o gerenciamento de

requisitos varia mais do que qualquer outra disciplina do Gerenciamento do Ciclo de Vida

do Aplicativo (ALM). Algumas diferenças resultam do nível de especificidade necessário

para um determinado projeto devido ao escopo do produto, à complexidade do aplicativo ou

ao tamanho e distribuição da equipe. Dentro de uma única organização, uma equipe pode

precisar de um requisito com revisão detalhada por partes interessadas, enquanto outra

equipe pode começar com uma ideia simples e iterar e criar um protótipo até que haja um

entendimento suficiente para começar a criar a solução.

O IEEE define requisitos como “...as condições ou as capacidades que um sistema (ou

componente do sistema) deve cumprir para satisfazer um contrato, um padrão, uma

especificação ou outra restrição formalmente imposta...”

Karl Wiegers1, a principal autoridade em engenharia de requisitos, simplifica a definição

para incorporar as propriedades que um produto deve ter para fornecer valor a uma parte

interessada .

Todo o trabalho no ciclo de vida do desenvolvimento de software (SDLC)2 começa com uma

ideia. Essa ideia pode ser um novo sistema a ser desenvolvido, uma solicitação para uma

melhoria de um sistema existente, ou pode ser uma necessidade de corrigir algo que não está

se comportando como deveria .

Chamamos esses novos sistemas de aprimoramentos e correções. Classificamos, priorizamos

e organizamos em lançamentos, versões e patches.

Novos — Novos sistemas ou novos recursos de um sistema existente; geralmente são os maiores projetos em uma organização, e o que os torna os mais caros. Consequentemente, é mais difícil obter financiamento para esses projetos. A estimativa, o planejamento e a execução são mais difíceis porque estamos lidando com muitas incógnitas.

Exemplo: Adicionar a capacidade de mostrar o catálogo de produtos em um dispositivo móvel.

Dentro de uma única organização, uma equipe pode precisar de um requisito com revisão detalhada por partes interessadas, enquanto outra equipe pode começar com uma ideia simples e iterar e criar um protótipo até que haja um entendimento suficiente para começar a criar a solução.

__________

1 www.karlwiegers.com e http://en.wikipedia.org/wiki/Karl_Wiegers

2 Ciclo de vida do desenvolvimento de software, veja: http://en.wikipedia.org/wiki/Software_development_process

2

White PaperMelhores práticas de engenharia de requisitos

Aprimoramentos — Melhorias no código existente; é um trabalho incremental e os custos são mais baixos, o risco é menor e o financiamento é geralmente mais fácil de obter. Podem ser projetos curtos ou longos. São mais fáceis de estimar e custear, pois são um conjunto conhecido de problema e solução.

Exemplo: Fazer o catálogo de produtos exibir os preços em euros, libras e ienes, além de em dólares americanos.

Correções — Muitas vezes pequenas mudanças no código existente que não adicionam nova funcionalidade; as correções mudam o comportamento da funcionalidade atual para atender às expectativas da empresa. A maioria corrige comportamentos errados e prejudiciais para a empresa, no entanto, às vezes, modificam o comportamento para que apenas funcione melhor ou mais rápido.

Exemplo: No registro de saída, o imposto é adicionado apenas nas vendas domésticas e não em todas as vendas em todo o mundo.

Ter a ideia e transformá-la em uma solução é do que se trata o ALM. Chegar lá é

inteiramente uma jornada. Na verdade, ter a ideia capturada não é uma tarefa pequena.

Os requisitos são um processo

Definir o problema pode levar minutos ou meses. Depende de muitos fatores. Aqui estão

apenas algumas coisas que a organização leva em consideração ao definir um problema:

Controles regulatórios e de conformidade

Segurança e integridade dos dados

Acesso e autenticação

Chegada ao mercado

Disponibilidade de soluções comerciais

Complexidade técnica

Retorno do investimento

Interrupção dos planos do projeto

Disponibilidade de recursos

Financiamento

Necessidades de desempenho

Necessidades de internacionalização

Tudo isso antes de perguntar: “O que exatamente você quer que essa tecnologia faça?”

Dez melhores práticas para obter excelentes requisitos:

1. Use protótipos e simulação em vez de definições por escrito.

2. Compartilhe ideias com o maior número possível de partes interessadas e reúna comentários.

3. Use técnicas de gamificação para obter comentários equilibrados.

4. Todos os requisitos devem ser testáveis.

5. Todos os requisitos devem ser sobre um item.

6. Mantenha a rastreabilidade desde a solicitação do requisito até a implementação.

7. Use organizadores gráficos, casos de uso, pseudocódigos ou o que oferecer ideias claras.

8. Teste todos os requisitos quanto ao seu impacto em recursos existentes e futuros.

9. Mantenha a reordenação em função das prioridades baseada em prioridades de negócios.

10. Crie versões de requisitos e documente mudanças.

3www.microfocus.com

Etapa 1 — Concepção e captura de demanda: É comum que vários sistemas de

bilhetagem estejam em uso simultaneamente para diferentes tipos de solicitações e

para diferentes sistemas. Alguns sistemas são autoajuda e outros exigem um e-mail ou

um telefonema. Com bastante frequência, o Microsoft Excel é o repositório para essas

solicitações. A maioria das organizações tem uma maneira de coletar ideias do negócio,

geralmente através de algum tipo de “bilhetes” do sistema, muitas vezes chamado de

sistema de solicitação de mudança (Change Request System, ou sistema CR). Geralmente,

são hospedados e gerenciados pelo suporte técnico (também conhecido como central de

serviços) .

Um elemento essencial deste processo é a coleção de ideias de forma consistente e rastreável.

Concepção é um conceito mais moderno e não formalizado em muitas organizações. Em

algumas empresas, é Conselho de Revisão de Controle de Mudanças (CCRB, Change Control

Review Board) ou Conselho Consultivo de Mudanças (CAB, Change Advisory Board), e

muitos outros títulos semelhantes. Com bastante frequência, o MS Excel é o sistema de

registro e isso torna a colaboração e a visibilidade muito difíceis.

Etapa 2 — Gerenciamento de mudanças: É o momento em que a triagem das ideias

ocorre de maneira que as ideias mais importantes, as ideias em que o tempo é um fator

crítico e as ideias de governança crítica recebam prioridade mais alta . As ideias passam por

uma pesquisa de viabilidade, financiamento, recursos e processo de programação antes de

receber a aprovação para desenvolvimento. Algumas solicitações urgentes e de emergência

recebem aprovação imediata quando o impacto do negócio é grave.

Às vezes, chamado de gerenciamento de demanda, é um fenômeno mais recente motivado

pela TI, que é mais responsável pelo dinheiro gasto. O objetivo do gerenciamento

de demanda é garantir que os projetos em que a TI trabalha sejam os projetos que

correspondem às prioridades da empresa. Frequentemente, os CIOs falam sobre

“alinhamento” ou “alinhamento da TI com o negócio”: quando o fazem, estão descrevendo

a necessidade de garantir que os projetos essenciais de cumprimento de missão crítica

sejam os implementados primeiros e de maneira mais rápida . O conselho de revisão pode

supervisionar esse processo e definir prioridades, metas e até orçamentos.

Etapa 3 — Descoberta de requisitos: Envolve a coleta e o registro de requisitos de

partes interessadas e outras fontes. Existem várias técnicas utilizadas, incluindo entrevistas,

análise de documentos, grupos de foco, oficinas e, mais recentemente, prototipagem,

simulação e gamificação. A prototipagem iterativa define os requisitos em menos tempo do

que leva para entrevistar e re-entrevistar o usuário de negócios.

Concepção é um conceito mais moderno e não formalizado em muitas organizações.

4

White PaperMelhores práticas de engenharia de requisitos

Em uma organização ágil, o processo seguido é praticamente o mesmo, exceto que há muitas mais iterações no tempo do que uma atividade tradicional de engenharia de requisitos ocuparia.

A pessoa principal em uma equipe ágil é o Proprietário do Produto, cuja tarefa é atuar como a ligação entre a empresa e a equipe de desenvolvimento.

O Proprietário do Produto reúne, classifica e prioriza os requisitos para a equipe de desenvolvimento. O Proprietário do Produto realiza a triagem com a empresa, ajudando a empresa a se concentrar em pedir o que é mais importante.

Equipes ágeis não desenvolvem protótipos. Eles chegam ao código de trabalho o mais rapidamente possível.

__________

3 http://en.wikipedia.org/wiki/Use_case

4 http://en.wikipedia.org/wiki/Unified_Modeling_Language

Etapa 4 — Validação de requisitos: Confirma que o conjunto de requisitos atende

às necessidades e metas da empresa. Esta etapa existe para garantir que as informações

coletadas são suficientes para criar a solução desejada e que a informação está em

conformidade com as restrições organizacionais, como padrões de conformidade e

governança .

Frequentemente, a definição dos requisitos falha porque a língua inglesa é demasiada

imprecisa para refletir as nuances da necessidade comercial. O desenvolvimento de casos

de uso3 e o uso de métodos formalizados como o UML (Unified Modelling Language)4

ajudam a definir com precisão exatamente quais seriam os comportamentos esperados para

a solução. Essas ferramentas ajudam no desenvolvimento dos casos de teste que formarão

a base de validação da implementação contra o posterior requisito no ciclo de vida de

desenvolvimento .

Etapa 5 — Gerenciamento de requisitos: Muitas vezes, essa atividade segue

procedimentos muito formais e é o processo onde os requisitos são aprimorados,

versionados, rastreados, monitorados, priorizados, designados e, em suma, gerenciados.

Essas atividades incluem:

O aperfeiçoamento contínuo dos requisitos à medida que mais dados, entradas e ideias são coletados

A classificação e priorização dos requisitos dependendo da entrada do negócio

O escopo dos requisitos individuais para o esforço

A organização dos requisitos em grupos que tornam razoáveis peças de trabalho e lançamentos a serem concluídos pelas equipes de desenvolvimento

O monitoramento de mudanças, atualizações e modificações de requisitos conforme as necessidades comerciais são aperfeiçoadas

A manutenção da rastreabilidade para garantir uma trilha de auditoria da solicitação à implementação

O monitoramento das aprovações dos requisitos a serem implementados para o financiamento dos projetos

A manutenção das relações e dependências entre e junto aos requisitos

O processo de gerenciamento de requisitos é essencial para as melhores práticas de

desenvolvimento de aplicativos. Sem o conhecimento do que é suposto desenvolver, a

probabilidade de que irá corresponder às necessidades comerciais é quase zero. Não importa

como o termo é definido, ou onde no espectro metodológico a sua organização se encontra,

as expectativas do cliente (ou do cliente potencial) devem ser compreendidas antes de iniciar

a criação. O “como” pode ser elaborado no desenvolvimento, mas o “que” deve ser entendido

antes de o financiamento ser aprovado.

5www.microfocus.com

Melhores práticas para o gerenciamento de requisitos

Esperar que os requisitos sejam de 1 a 5% por mês. — fonte Gartner

“A melhor prática para o gerenciamento de requisitos é aplicar as melhores práticas

definidas para o gerenciamento de configurações no gerenciamento de requisitos.”

— Kay Fuhrmann, Gerente de Produto, Serena Software (agora parte da Micro Focus)

1. Convenções de nomenclatura. Definição e manutenção de convenções para a identificação de lançamentos — desde o requisito aprovado definido por meio do lançamento referenciado até a correção de emergência ou patch.

2. Requisitos de linha de base. Os requisitos, como lançamentos de software, devem ser referenciados e essas linhas de base devem mapear diretamente para os lançamentos que produzem.

3. Processo de controle de mudanças bem definido e compreendido. Uma vez criada uma linha de base, as mudanças devem ser controladas, rastreadas, monitoradas, aprovadas e revisadas.

4. Revisão dos requisitos. Deve haver um processo de revisão de requisitos e ele deve ser imposto.

5. Expectativa de mudanças. Certifique-se de que as mudanças podem ser feitas facilmente, mas sob estritas regras de controle de acesso com rastreabilidade plena.

6. Gerenciamento de versões. O histórico dos requisitos deve ser mantido usando métodos que tornam mais fácil os analistas olharem para trás.

7. Rastreabilidade de requisitos. Sem a capacidade de rastrear um requisito da ideia até a sua implementação definida, não é possível entender o impacto de uma mudança proposta.

8. Manutenção de informações. Mantenha os atributos de dependências, relacionamentos, proprietários, partes interessadas, usuários, financiador, datas, custos, modelos, protótipos, diagramas, governança etc. sobre o requisito.

9. Colaboração. Forneça acesso fácil às informações sobre os requisitos e notifique automaticamente as partes interessadas de qualquer mudança de status ou mudança do requisito para incentivar a colaboração.

10. Requisitos em um único local. Mantenha os requisitos em um único local, de preferência em um banco de dados projetado para gerenciá-los.

Os projetos são gerenciados através dos Epics (uma coleção de requisitos) e das Histórias (um requisito) que compõem o Backlog do Sprint (requisitos atribuídos para desenvolvimento, mas ainda não concluídos) do trabalho a ser executado.

O progresso é rastreado através de Gráficos de burndown (requisitos concluídos) que mostram o andamento em direção ao final do Sprint atual. Um princípio importante do Agile é ser auto-organizado, e a reunião Diária em Pé mantém todos sincronizados dentro do projeto.

O Backlog do Projeto é constantemente reordenado em função das prioridades para satisfazer as necessidades comerciais em constante mudança.

6

White PaperMelhores práticas de engenharia de requisitos

Atributos essenciais de uma solução de gerenciamento de requisitos

Facilidade de uso

Implementação

A implementação da solução deve ser facilmente configurada para adotar o idioma utilizado

na organização. Não deve ser um requisito que o dicionário mude para se ajustar à solução.

O treinamento, a implementação razoável e a localização devem ser concluídos em duas a

quatro semanas .

A solução deve ser fácil de aprender

Novos usuários, independentemente da função, podem rapidamente aprender a fazer login

na solução e a navegar na interface do cliente. Nesse contexto, os revisores de requisitos não

técnicos, com uma compreensão dos requisitos corporativos, podem começar a trabalhar

com uma visão geral de uma página. Todos os demais usuários da solução, com exceção de

administradores ou gerentes de projeto treinados para apoiar a implementação, devem estar

em condições de usar o produto após duas a quatro horas de treinamento.

A solução deve ser fácil de usar

A solução escolhida para o gerenciamento e a geração de relatórios de requisitos deve

facilitar os trabalhos de todos os envolvidos, aumentando o acesso à informação. Não deve

demorar mais de uma hora para o usuário geral entender como executar funções específicas

usando a solução .

As propriedades e a exibição devem ser configuráveis

Os usuários ou administradores devem poder modificar a quantidade de informações

exibidas.

Todas as partes interessadas devem ter acesso aos documentos

Deve ser possível publicar documentos em formato corporativo para revisão e aprovação.

Não se deve exigir que os usuários usem a ferramenta para ver as informações contidas.

A filosofia e a tecnologia da ferramenta devem ser transparentes

Os usuários não devem precisar de nenhuma habilidade arquitetônica, administrativa ou

técnica para usar a ferramenta para adicionar, modificar, revisar ou aprovar requisitos e suas

propriedades .

Os 10 recursos mais solicitados de uma solução de gerenciamento de requisitos — fonte Forrester

Linha de base de requisitos para monitorar o desvio de escopo

Modelagem e simulação de requisitos

Ferramentas visuais para gerenciar requisitos em lançamentos, recursos e patches

Apoio à tomada de decisões para priorizar a seleção de requisitos

Vinculação e rastreamento de relações entre requisitos e solicitações

Captura de requisitos centrada no usuário

Reuso de requisitos de requisitos comuns e compartilhados

Workflow de requisitos que compara outros workflows de SDLC

Integração baseada na rastreabilidade com outras ferramentas de ciclo de ALM

Requisitos prontos para necessidades de conformidade comuns como ITAR

7www.microfocus.com

Os requisitos de usuário (às vezes referidos como requisitos de negócios) identificam recursos que a parte interessada quer ou precisa, enquanto os requisitos funcionais especificam o que o sistema deve fazer para fornecer o recurso declarado.

Deve haver métodos para a organização dos requisitos

Deve ser possível criar contêineres (pastas) como um meio de organizar os requisitos de

acordo com o componente, o subtipo ou criar listas para grupos ou usuários específicos.

As funções de usuário devem ser suportadas

Deve ser possível definir as funções organizacionais ou do projeto e mapear os usuários para

essas funções.

O sistema deve ser flexível Os requisitos são distinguidos por tipo ou classificação. Os tipos de requisitos comuns

incluem requisitos de usuário e funcionais. Os requisitos de usuário (às vezes referidos

como requisitos de negócios) identificam recursos que a parte interessada quer ou precisa,

enquanto os requisitos funcionais especificam o que o sistema deve fazer para fornecer

o recurso declarado. Outros tipos de requisitos comuns incluem não funcional, sistema,

técnico e casos de teste. Além desses tipos básicos, as classificações utilizadas para os

requisitos são tão diversas como o software a ser desenvolvido ou os processos empregados

pela organização para o fazer. Uma boa solução de gerenciamento de requisitos deve ser

capaz de fornecer um meio para a classificação de qualquer requisito que a organização

deseja definir, e as suas propriedades (metadados) devem também ser totalmente

configuráveis.

Os requisitos devem ser armazenados como objetos individuais

Os requisitos de todos os tipos devem ser armazenados como objetos individuais . Eles

podem estar vinculados a outros objetos do projeto, mas não pertencer a eles. Qualquer

combinação desses objetos pode ser reunida para exibição ou publicação.

Os requisitos devem poder ser organizados em hierarquias e decompostos ao

nível atômico

Deve ser possível dividir os requisitos de todos os tipos em requisitos cada vez menores até

que atinjam tamanho atômico, representando um, e apenas um, requisito específico. Dever

ser possível operar as hierarquias de requisitos decompostos individualmente, no nível

atômico, e na hierarquia e no nível hierárquico intermediário com ação em cascata até os

requisitos decompostos .

Os tipos de requisitos devem refletir os padrões corporativos

Os tipos de requisitos devem ser nomeados e descritos de acordo com as necessidades e

os processos da organização, e não conforme o fornecedor da ferramenta. Não deve haver

nenhum requisito dentro da solução para incluir qualquer tipo de requisito pronto para uso .

8

White PaperMelhores práticas de engenharia de requisitos

As propriedades devem ser configuráveis

Deve haver a capacidade de definir e atribuir propriedades a tipos de requisitos, além dos

padrões definidos pelo produto. Os tipos de dados usados na definição dessas propriedades

devem também ser flexíveis. Por exemplo, devem incluir campos de texto (curtos e longos),

listas suspensas, campos numéricos e campos de data. Deve ser possível associar gráficos ou

anexos a tipos de dados.

As propriedades precisam usar termos familiares

A linguagem usada para definir os requisitos e as suas propriedades deve refletir o léxico da

organização, e deve ser consultada consistentemente ao longo da solução. Deve ser possível

que várias equipes de projeto dentro da mesma organização definam tipos de requisitos e

usem termos que atendam às necessidades de cada um. Nenhum grupo deve ser obrigado a

carregar a bagagem dos outros .

Deve haver rastreabilidade

Deve ser possível criar uma exibição de rastreabilidade, com mecanismos para selecionar os

tipos de requisitos a serem rastreados. As informações coletadas devem ser exibidas em um

formato fácil de ler e analisar.

Requisitos de importação A maioria das equipes de projeto, antes de adotar uma solução de gerenciamento de

requisitos, mantém os requisitos em documentos do MS Excel ou MS Word. É importante

que a solução importe dados existentes e que consiga continuar importando atualizações de

requisitos .

Importar dados de arquivos do MS Word

A solução deve fornecer funcionalidade para facilitar a importação de dados de arquivos do

MS Word. Deve ser possível, por exemplo, importar os requisitos neste documento.

Importar dados de arquivos do MS Excel

Deve ser possível importar dados selecionados de arquivos do MS Excel para criar novos

requisitos, com mecanismos simples para mapear colunas para propriedades.

Exportar para arquivos do MS Excel

Deve ser possível exportar dados de requisitos selecionados para arquivos do MS Excel, com

mecanismos simples para mapear propriedades para colunas .

A linguagem usada para definir os requisitos e as suas propriedades deve refletir o léxico da organização, e deve ser consultada consistentemente ao longo da solução.

9www.microfocus.com

Atualizar objetos existentes do MS Excel

A solução deve suportar a funcionalidade de atualizar requisitos existentes com dados

de planilhas do MS Excel. Mapear identificadores de requisitos ou nomes da planilha do

MS Excel para o requisito atual e, em seguida, adicionar novas propriedades ou atualizar

propriedades existentes permitirá que todas as partes interessadas, mesmo aqueles sem

acesso à solução, desempenham uma função ativa no processo de revisão. Atualizações das

planilhas do MS Excel também garantirão os recursos de lote.

Estabelecer ou atualizar links usando planilhas

Links entre requisitos podem ser estabelecidos usando planilhas do MS Excel.

Importar dados de soluções de ALM associadas

Arquivos do MS Excel ou CSV gerados por qualquer solução ao longo do espectro do ALM

podem ser importados para vincular, modificar, adicionar ou excluir requisitos ou suas

propriedades .

Mecanismos para filtragem e classificação de requisitos

Filtros controlados pelo usuário

Os requisitos são gerenciados, exibidos e revisados em diferentes momentos do ciclo de

desenvolvimento e por pessoas diferentes com necessidades muito diferentes. Raramente é

necessário que alguém veja tudo.

Listas e relatórios filtrados por propriedade de requisito

Deve ser possível filtrar em qualquer propriedade não-binária definida dentro do requisito.

Estabelecer e atualizar conjuntos de requisitos

Deve ser possível criar conjuntos de requisitos de qualquer tipo e estabelecer linhas de base

a partir desses conjuntos .

Consultas para suportar seleção de requisitos

A ferramenta deve suportar o uso de consultas simples ou complexas para coletar requisitos

com base em tipo, propriedade, ausência ou presença em uma lista, relacionamento

(vínculo) ou uma combinação desses; por exemplo, todos os requisitos de usuário de alta

prioridade relacionados a pelo menos um caso de teste do qual a propriedade de resultado

de teste é definida como “falha”.

Os requisitos são gerenciados, exibidos e revisados em diferentes momentos do ciclo de desenvolvimento e por pessoas diferentes com necessidades muito diferentes. Raramente é necessário que alguém veja tudo.

10

White PaperMelhores práticas de engenharia de requisitos

Criação simples de documentos, listas ou arquivos csv

Deve ser possível salvar, imprimir ou criar arquivos do MS Excel ou CSV de qualquer caixa

de diálogo na interface do usuário.

A solução deve gerenciar o histórico de requisitos A solução deve ser capaz de fornecer um mecanismo para criar, excluir e alterar um

requisito, bem como qualquer e todos os metadados armazenados com o requisito.

Deve haver também a possibilidade de manter um registro de todas essas transações.

O histórico de requisitos deve ser mantido

A solução deve ser capaz de manter o histórico de mudanças para todos os requisitos e

propriedades de requisitos .

Os requisitos podem ser adiados ou abandonados

A solução deve fornecer a funcionalidade de abandonar ou adiar requisitos. Deve ser possível

filtrar facilmente esses requisitos a partir das listas gerais, mantendo a acessibilidade para

revisão ou readoção .

Os requisitos podem ser excluídos

A solução deve permitir que um requisito seja excluído permanentemente do projeto.

As linhas de base podem ser criadas e atualizadas com agilidade

Deve haver facilidades para a criação de linhas de base de lançamento que podem ser

versionadas e rastreadas quanto às mudanças. Deve ser possível comparar as linhas de base

e criar uma lista simples de requisitos alterados, bem como um relatório detalhado das

diferenças entre as linhas de base.

Vinculação e rastreabilidade de requisitos Além da necessidade de um bom sistema de requisitos ser capaz de fornecer um meio de

classificar qualquer tipo de requisito, é preciso também vincular requisitos de vários tipos.

A vinculação de requisitos fornece os mecanismos para relatórios de rastreabilidade.

Além da necessidade de um bom sistema de requisitos ser capaz de fornecer um meio de classificar qualquer tipo de requisito, é preciso também vincular requisitos de vários tipos.

11www.microfocus.com

Vinculação de requisitos

Deve haver uma funcionalidade para criar relações entre tipos de requisitos. Os vínculos

que expressam essas relações devem ser um para muitos, muitos para um ou muitos para

muitos. Por exemplo, pode haver vários casos de teste para um único requisito funcional,

mas um caso de teste pode ser aplicável para mais de um requisito funcional.

Vínculos manuais

A solução deve fornecer a capacidade de estabelecer vínculos manualmente ou através de

uma forma de importação em lotes.

Vínculos excluídos

A funcionalidade para excluir vínculo deve existir.

Objetos vinculados relatam o impacto da mudança

Os objetos vinculados devem mostrar o impacto de mudanças anteriores. Por exemplo,

dado um caso de teste vinculado a um requisito funcional que é vinculado a um requisito

de usuário, uma mudança no requisito de usuário assumirá um possível impacto e, por

conseguinte, forçará uma revisão do requisito funcional e do caso de teste. Uma mudança no

requisito funcional forçará uma revisão do caso de teste, mas não do requisito de usuário.

Matriz de rastreabilidade

Uma matriz de rastreabilidade completa usando qualquer tipo de requisito definido deve

estar disponível e deve ser relativamente fácil de usar. A rastreabilidade visualiza as

conexões entre os requisitos, permitindo que as partes interessadas vejam que os requisitos

do usuário foram detalhados por meio de requisitos funcionais associados e que os casos de

teste foram estabelecidos para cada requisito funcional. A matriz de rastreabilidade deve

reportar a execução, e para a vida útil do aplicativo, deve reportar o impacto da mudança.

Deve haver uma excelente funcionalidade de relatórios A solução deve facilitar a geração de relatórios adequados e deve ser possível gerar

documentos utilizando um formato familiar para as partes interessadas. A manutenção

de relatórios atualizados é fundamental para o processo de gerenciamento de requisitos

e a criação desses relatórios deve ser uma simples extensão de filtragem e classificação da

interface do cliente.

A manutenção de relatórios atualizados é fundamental para o processo de gerenciamento de requisitos e a criação desses relatórios deve ser uma simples extensão de filtragem e classificação da interface do cliente.

12

White PaperMelhores práticas de engenharia de requisitos

Suporte de documentos flexível

Deve ser possível selecionar listas de requisitos usando scripts ou consultas e usar facilmente

essas listas para criar ou atualizar um documento .

Documentos de controle de versão

Deve ser possível congelar o conteúdo de um documento e atribuir ao documento congelado

um nome ou uma versão. Deve também ser possível excluir esses documentos livremente.

Requisitos publicáveis em forma de documento

Deve ser possível exportar (publicar) documentos usando um formato (modelo) familiar e

que possa ser compartilhado entre os projetos .

Facilidade para comparar documentos

A solução deve fornecer a capacidade de comparar documentos versionados.

Relatórios gráficos

Deve ser possível criar relatórios gráficos ou reunir e exportar os dados necessários para

criar relatórios atuais com ferramentas existentes. Os relatórios devem incluir, mas não se

limitando a, gráficos de barras mostrando os requisitos programados por tipo, o número

de requisitos programados para um determinado lançamento e o número ainda a ser

implementado .

Os relatórios devem incluir, mas não se limitando a, gráficos de barras mostrando os requisitos programados por tipo, o número de requisitos programados para um determinado lançamento e o número ainda a ser implementado.

13www.microfocus.com

Resumo

A disciplina de gerenciamento de requisitos é difícil para algumas organizações colocarem

as mãos, e, por isso, os grupos muitas vezes sobrecarregam o processo em detrimento

do projeto . As equipes de projeto muitas vezes passarão mais tempo discutindo sobre a

estrutura adequada para o caso de uso, ou a diferença entre um requisito de usuário e

um requisito de negócio, do que sobre o conteúdo de um deles. Como esses argumentos

não fazem o projeto avançar, os membros da equipe seguirão adiante e assumirão que as

questões em aberto serão tratadas durante o desenvolvimento.

O processo de gerenciamento de requisitos é essencial para as melhores práticas de

desenvolvimento de aplicativos. Sem o conhecimento do que é suposto desenvolver,

a probabilidade de que irá corresponder às necessidades comerciais é quase zero. O

gerenciamento de requisitos pode começar com uma lista na qual as expectativas do projeto

são definidas e gerenciadas. A lista pode ser exibida como um quadro aberto, coletando e

classificando notas e mudanças. Ela pode também ser expandida para controlar detalhes

técnicos e vincular os detalhes aos casos de teste, permitindo, enfim, recursos de geração de

relatórios de requisitos completos .

As melhores soluções de gerenciamento de requisitos são fáceis de aprender, fáceis de usar,

acessíveis e transparentes. Também possuem excelentes funcionalidades de rastreabilidade,

versionamento e geração de relatórios. Esses recursos funcionam em conjunto para fornecer

a base de uma solução de classe mundial e o início de um processo de requisitos de melhores

práticas .

As melhores soluções de gerenciamento de requisitos são fáceis de aprender, fáceis de usar, acessíveis e transparentes.

162-PB0100-001 | S | 05/17 | © 2017 Micro Focus. Todos os direitos reservados. Micro Focus e o logotipo Micro Focus, entre outros, são marcas registradas ou marcas comerciais registradas da Micro Focus ou de suas subsidiárias ou afiliadas no Reino Unido, Estados Unidos e outros países. Todas as outras marcas pertencem a seus respectivos proprietários.

www.microfocus.com

Micro FocusArgentina+54 11 5258 8899

Brasil+55 11 3627 0900

Colombia+57 1 622 2766

México+52 55 5284 2700

Venezuela+58 212 267 6568

Micro FocusSede da empresaReino Unido+44 (0) 1635 565200

www.microfocus.com