O Guia Mais Completo para Gerenciamento de Requisitos e Rastreabilidade
Glossário
Conteúdo
|
Siglas
|
Condições
|
Definição
|
|---|---|---|
|
RM
|
Gerenciamento de Requisitos
|
O processo de identificação, documentação, análise, rastreamento, priorização, aprovação e manutenção de requisitos para um projeto ou produto.
|
|
BRD
|
Documento de Requisitos de Negócios
|
Um documento formal que descreve os requisitos de negócios de alto nível para um projeto ou produto. Normalmente inclui informações sobre a necessidade do negócio, escopo, partes interessadas, requisitos funcionais, requisitos não funcionais, suposições, restrições, riscos e cronograma do projeto.
|
|
FRD
|
Documento de Requisitos Funcionais
|
Um documento detalhado que descreve os requisitos funcionais específicos para um projeto ou produto. Normalmente inclui informações sobre os recursos do sistema, requisitos do usuário, casos de uso, cenários, requisitos de dados e critérios de aceitação.
|
|
NFRD
|
Documento de Requisitos Não Funcionais
|
Um documento detalhado que descreve os requisitos não funcionais específicos para um projeto ou produto. Normalmente inclui informações sobre o desempenho do sistema, escalabilidade, disponibilidade, confiabilidade, segurança, capacidade de manutenção, usabilidade e acessibilidade.
|
|
SRS
|
Especificação de Requisitos de Software
|
Um documento abrangente que descreve os requisitos funcionais e não funcionais para um sistema de software. Geralmente inclui informações sobre a arquitetura, design, implementação, teste e implantação do sistema.
|
|
Caso de uso
|
Caso de uso
|
Uma técnica para capturar e descrever os requisitos funcionais de um sistema, definindo as interações entre o sistema e seus usuários ou outros sistemas. Normalmente inclui uma descrição das etapas executadas pelo usuário ou sistema para atingir uma meta ou tarefa específica.
|
|
Matriz de rastreabilidade
|
Matriz de rastreabilidade
|
Um documento que fornece um link rastreável entre os requisitos, design, implementação, teste e implantação de um sistema. Geralmente inclui informações sobre o relacionamento entre os requisitos e outros artefatos do sistema, como casos de teste, defeitos e solicitações de mudança.
|
|
Painel de controle de mudança
|
Painel de controle de mudança
|
Um grupo de partes interessadas responsável por avaliar, aprovar e gerenciar mudanças nos requisitos, design, implementação, teste e implantação de um sistema. Normalmente inclui representantes de vários departamentos, como negócios, desenvolvimento, testes e operações.
|
|
Elicitação de requisitos
|
Elicitação de requisitos
|
O processo de reunir e documentar os requisitos para um projeto ou produto das partes interessadas, usuários e outras fontes. Geralmente envolve técnicas como entrevistas, pesquisas, observações, grupos focais e sessões de brainstorming.
|
|
Stakeholder
|
Stakeholder
|
Uma pessoa ou grupo de pessoas que tem interesse no sucesso de um projeto ou produto. Normalmente inclui clientes, usuários, patrocinadores, empresários, desenvolvedores, testadores e equipe de suporte.
|
|
Priorização de Requisitos
|
Priorização de Requisitos
|
O processo de classificar os requisitos de um projeto ou produto em ordem de importância ou urgência. Normalmente, envolve a identificação dos requisitos críticos que devem ser atendidos primeiro e a atribuição de um nível de prioridade a cada requisito com base em seu valor comercial, viabilidade técnica e risco.
|
|
Ferramentas de gerenciamento de requisitos
|
Ferramentas de gerenciamento de requisitos
|
Um aplicativo de software usado para dar suporte ao processo de gerenciamento de requisitos. Ele normalmente inclui recursos como captura de requisitos, rastreabilidade, controle de versão, colaboração, relatórios e análises. Exemplos de ferramentas de gerenciamento de requisitos incluem Visure Solutions, IBM Rational DOORS, Jama Connect e HP ALM.
|
|
Linha de Base
|
Linha de Base
|
Um conjunto de requisitos aprovados que forma a base para desenvolvimento e teste adicionais de um sistema. Normalmente inclui os requisitos funcionais e não funcionais que foram acordados pelas partes interessadas e assinados pelo conselho de controle de mudanças.
|
|
Validação
|
Validação
|
O processo de avaliar se os requisitos de um sistema são completos, precisos e consistentes com as necessidades e expectativas das partes interessadas. Normalmente, envolve revisar os documentos de requisitos, realizar revisões das partes interessadas e verificar se o sistema atende aos requisitos especificados por meio de testes e outros métodos.
|
|
Verificação
|
Verificação
|
O processo de avaliar se o sistema atende aos requisitos especificados. Normalmente envolve testar o sistema em relação aos critérios de aceitação definidos nos documentos de requisitos e garantir que todos os requisitos foram implementados corretamente.
|
|
Objetivo
|
Objetivo
|
Os limites e objetivos de um projeto ou produto. Normalmente inclui informações sobre os recursos, funções e capacidades do sistema, bem como as restrições e limitações que devem ser levadas em consideração.
|
|
Análise de impacto
|
Análise de impacto
|
O processo de avaliação dos efeitos potenciais de uma mudança nos requisitos, design, implementação, teste ou implantação de um sistema. Normalmente envolve a identificação das áreas afetadas do sistema, avaliando os riscos e benefícios da mudança e determinando os recursos e cronogramas necessários para implementar a mudança.
|
|
Revisão de Requisitos
|
Revisão de Requisitos
|
Um processo formal para avaliar os documentos de requisitos para garantir que eles sejam completos, precisos e consistentes com as necessidades e expectativas das partes interessadas. Normalmente, envolve uma revisão por uma equipe de partes interessadas, incluindo desenvolvedores, testadores, analistas de negócios e especialistas no assunto, que fornecem feedback e identificam quaisquer problemas ou preocupações que precisam ser resolvidos.
|
|
Rastreabilidade de Requisitos
|
Rastreabilidade de Requisitos
|
A capacidade de rastrear e gerenciar o relacionamento entre os requisitos e outros artefatos do sistema, como documentos de design, casos de teste, defeitos e solicitações de mudança. Normalmente, envolve a criação de uma matriz de rastreabilidade ou outra ferramenta para garantir que todos os requisitos sejam considerados ao longo do processo de desenvolvimento e que quaisquer alterações nos requisitos sejam gerenciadas e documentadas adequadamente.
|
|
Linha de base de requisitos
|
Linha de base de requisitos
|
O conjunto de requisitos que foi aprovado pelas partes interessadas e forma a base para desenvolvimento e teste adicionais de um sistema. Normalmente inclui os requisitos funcionais e não funcionais, bem como quaisquer restrições, suposições e riscos que tenham sido identificados. A linha de base dos requisitos é usada como ponto de referência para gerenciar mudanças nos requisitos ao longo do processo de desenvolvimento.
|
|
Engenharia de Requisitos
|
Engenharia de Requisitos
|
A abordagem sistemática e disciplinada para elicitar, analisar, especificar, validar e gerenciar os requisitos de um projeto ou produto. Normalmente envolve o uso de várias técnicas, como entrevistas, pesquisas, casos de uso, cenários e protótipos, para garantir que os requisitos sejam completos, precisos e consistentes com as necessidades e expectativas das partes interessadas.
|
|
Documentação de Requisitos
|
Documentação de Requisitos
|
A coleção de documentos que descrevem os requisitos de um sistema, incluindo o documento de requisitos de negócios, documento de requisitos funcionais, documento de requisitos não funcionais, casos de uso, histórias de usuários e outros documentos relacionados. A documentação de requisitos fornece uma compreensão abrangente dos recursos, funções e capacidades do sistema, bem como das restrições, suposições e riscos que devem ser levados em consideração ao longo do processo de desenvolvimento.
|
|
BR
|
Requisitos de negócio
|
Os objetivos e metas de alto nível que um sistema deve atender para satisfazer as necessidades e expectativas das partes interessadas. Os requisitos de negócios geralmente se concentram nos processos de negócios, políticas e regras que o sistema deve suportar ou melhorar, em vez dos detalhes técnicos de como o sistema será implementado.
|
|
FR
|
Requisitos funcionais
|
As descrições detalhadas dos recursos, funções e capacidades que um sistema deve ter para satisfazer as necessidades e expectativas das partes interessadas. Os requisitos funcionais geralmente definem como o sistema se comportará ou responderá a entradas ou eventos específicos e podem incluir restrições, suposições e critérios de aceitação que devem ser atendidos para garantir que o sistema atenda aos requisitos das partes interessadas.
|
|
NFR
|
Requisitos não Funcionais
|
As descrições do desempenho, confiabilidade, segurança, usabilidade e outras qualidades do sistema que são necessárias para satisfazer as necessidades e expectativas das partes interessadas. Os requisitos não funcionais geralmente definem os atributos ou características do sistema, em vez de seus recursos ou funções específicos, e podem incluir restrições, suposições e critérios de aceitação que devem ser atendidos para garantir que o sistema atenda aos requisitos das partes interessadas.
|
|
História do usuário
|
História do usuário
|
Uma descrição breve e informal de um recurso ou função que um sistema deve ter para satisfazer as necessidades e expectativas das partes interessadas. As histórias de usuários geralmente seguem um modelo simples, como "Como [usuário], quero [recurso], para que [beneficie-se]". As histórias do usuário são usadas para capturar os requisitos em um formato simples e compreensível que pode ser facilmente comunicado e priorizado pelas partes interessadas e pela equipe de desenvolvimento.
|
|
Critérios de Aceitação
|
Critérios de Aceitação
|
Os critérios que um sistema deve atender para ser considerado aceitável ou satisfatório pelas partes interessadas. Os critérios de aceitação geralmente definem o comportamento esperado ou os resultados de um sistema em cenários ou casos de uso específicos e podem incluir medidas quantitativas ou qualitativas que devem ser atendidas para garantir que o sistema atenda às necessidades e expectativas das partes interessadas. Os critérios de aceitação são usados para validar o sistema em relação aos requisitos funcionais e não funcionais e garantir que ele atenda aos requisitos das partes interessadas.
|
|
ALM
|
Gerenciamento do ciclo de vida do aplicativo
|
Application Lifecycle Management é o procedimento de especificar, projetar, documentar e testar o aplicativo. Abrange todo o ciclo de vida do início ao fim do projeto. Começa com a ideia do aplicativo ao longo do desenvolvimento, passa pelo teste, implantação, suporte e, por fim, a experiência do usuário.
|
|
CMMI
|
Integração do modelo de maturidade de capacidade
|
O CMMI define um conjunto de melhores práticas para desenvolvimento de software, gerenciamento de projetos e gerenciamento organizacional que pode ajudar as organizações a melhorar a qualidade, eficiência e eficácia de seus processos de desenvolvimento de software.
|
|
MBSE
|
Engenharia de Sistemas Baseada em Modelos
|
Uma abordagem à engenharia de sistemas que usa modelos para representar, analisar, projetar e verificar sistemas complexos. O MBSE envolve a criação de um conjunto de modelos que capturam os requisitos, o comportamento, a arquitetura e outros aspectos importantes do sistema e o uso desses modelos para orientar o processo de desenvolvimento.
|
Não se esqueça de compartilhar esta postagem!
