Análise de Negócios - Guia Rápido

O que é análise de negócios?

Análise de negócios é o conjunto de tarefas, conhecimento e técnicas necessárias para identificar as necessidades de negócios e determinar soluções para problemas de negócios corporativos. Embora a definição geral seja semelhante, as práticas e procedimentos podem variar em vários setores.

Na indústria de tecnologia da informação, as soluções geralmente incluem um componente de desenvolvimento de sistemas, mas também podem consistir em melhoria de processos ou mudança organizacional.

A análise de negócios também pode ser realizada para entender o estado atual de uma organização ou para servir de base para a identificação das necessidades de negócios. Na maioria dos casos, entretanto, a análise de negócios é realizada para definir e validar soluções que atendam às necessidades, metas ou objetivos de negócios.

Quem é um analista de negócios?

Um analista de negócios é aquele que analisa uma organização ou domínio de negócios (real ou hipotético) e documenta seus negócios, processos ou sistemas, avaliando o modelo de negócios ou sua integração com a tecnologia. No entanto, os títulos organizacionais variam, como analista, analista de negócios, analista de sistemas de negócios ou talvez analista de sistemas.

Por que um analista de negócios?

As organizações empregam análise de negócios pelos seguintes motivos -

  • Compreender a estrutura e a dinâmica da organização na qual um sistema será implantado.

  • Para entender os problemas atuais na organização alvo e identificar potenciais de melhoria.

  • Para garantir que o cliente, o usuário final e os desenvolvedores tenham um entendimento comum da organização-alvo.

Na fase inicial de um projeto, quando os requisitos estão sendo interpretados pelas equipes de solução e design, o papel de um analista de negócios é revisar os documentos de soluções, trabalhar em estreita colaboração com os designers de soluções (equipe de TI) e gerentes de projeto para garantir que os requisitos são claros.

Em uma organização de TI típica de grande porte, especialmente em um ambiente de desenvolvimento, você pode encontrar equipes de entrega no local e offshore com as funções mencionadas acima. Você pode encontrar um “Analista de Negócios” que atua como uma pessoa-chave que deve vincular as duas equipes.

Às vezes, ele interagia com os usuários de negócios e, às vezes, com usuários técnicos e, finalmente, com todas as partes interessadas nos projetos para obter a aprovação e aceno final antes de prosseguir com a documentação.

Conseqüentemente, o papel do BA é crucial para o início efetivo e bem-sucedido de qualquer projeto.

Papel de um analista de negócios de TI

O papel de um analista de negócios começa com a definição e o escopo das áreas de negócios da organização, em seguida, eliciando os requisitos, analisando e documentando os requisitos, comunicando esses requisitos às partes interessadas apropriadas, identificando a solução certa e, em seguida, validando a solução para descobrir se requisitos atendem aos padrões esperados.

Como é diferente de outras profissões?

A análise de negócios é diferente da análise financeira, gerenciamento de projetos, garantia de qualidade, desenvolvimento organizacional, testes, treinamento e desenvolvimento de documentação. No entanto, dependendo da organização, um Analista de Negócios pode executar algumas ou todas essas funções relacionadas.

Os analistas de negócios que trabalham exclusivamente no desenvolvimento de sistemas de software podem ser chamados de analistas de negócios de TI, analistas de negócios técnicos, analistas de negócios online, analistas de sistemas de negócios ou analistas de sistemas.

A análise de negócios também inclui o trabalho de ligação entre as partes interessadas, equipes de desenvolvimento, equipes de teste, etc.

Ciclo de Vida de Desenvolvimento de Software

O Ciclo de Vida de Desenvolvimento de Software (SDLC) é um processo seguido em um projeto de software, dentro de uma organização de software. Consiste em um plano detalhado que descreve como desenvolver, manter, substituir e alterar ou aprimorar software específico. Ele define uma metodologia para melhorar a qualidade do software e o processo geral de desenvolvimento.

  • SDLC é um processo usado por analistas de TI para desenvolver ou redesenhar um sistema de software de alta qualidade, que atenda tanto aos requisitos do cliente quanto do mundo real.

  • Ele leva em consideração todos os aspectos associados de teste de software, análise e manutenção pós-processo.

As fases importantes do SDLC são descritas na ilustração a seguir -

Estágio de Planejamento

Cada atividade deve começar com um plano. Falhar no planejamento é planejar para falhar. O grau de planejamento difere de um modelo para outro, mas é muito importante ter um entendimento claro do que iremos construir criando as especificações do sistema.

Definindo Estágio

Nesta fase, analisamos e definimos a estrutura do sistema. Definimos a arquitetura, os componentes e como esses componentes se encaixam para produzir um sistema funcional.

Estágio de Projeto

No projeto do sistema, as funções e operações do projeto são descritas em detalhes, incluindo layouts de tela, regras de negócios, diagramas de processo e outras documentações. A saída deste estágio descreverá o novo sistema como uma coleção de módulos ou subsistemas.

Palco de construção

Esta é a fase de desenvolvimento. Começamos a geração de código com base no design do sistema usando compiladores, interpretadores, depuradores para dar vida ao sistema.

Implementação

A implementação faz parte do estágio de construção. Nesta fase, iniciamos a geração de código com base no design do sistema usando compiladores, interpretadores, depuradores para dar vida ao sistema.

Estágio de Teste

À medida que diferentes partes do sistema são concluídas; eles são submetidos a uma série de testes. ele é testado em relação aos requisitos para garantir que o produto esteja realmente atendendo às necessidades abordadas durante a fase de requisitos.

  • Planos e casos de teste são usados ​​para identificar bugs e garantir que o sistema está funcionando de acordo com as especificações.

  • Nesta fase, diferentes tipos de teste como teste de unidade, teste manual, teste de aceitação e teste de sistema são feitos.

Rastreamento de defeitos em testes

Os relatórios de teste de software são usados ​​para comunicar os resultados dos planos de teste executados. Sendo este o caso, um relatório deve conter todas as informações de teste que pertencem ao sistema atual sendo testado. A integridade dos relatórios será verificada em sessões de acompanhamento.

O teste de um projeto visa cumprir dois objetivos principais -

  • Detecte falhas e defeitos no sistema.

  • Detecte inconsistência entre requisitos e implementação.

O fluxograma a seguir descreve o Defect Tracking Process -

Para atingir os objetivos principais, a estratégia de teste para o sistema proposto geralmente consiste em quatro níveis de teste.

São testes de unidade, testes de integração, testes de aceitação e testes de regressão. As subseções a seguir descrevem esses níveis de teste, quais funções da equipe de desenvolvimento são responsáveis ​​por desenvolvê-los e executá-los e os critérios para determinar sua integridade.

Desdobramento, desenvolvimento

Após o término da fase de teste, o sistema é liberado e entra no ambiente de produção. Uma vez que o produto é testado e pronto para ser implantado, ele é lançado formalmente no mercado apropriado. Às vezes, a implantação do produto acontece em estágios de acordo com a estratégia de negócios da organização.

O produto pode primeiro ser lançado em um segmento limitado e testado no ambiente de negócios real (UAT - teste de aceitação do usuário). Então, com base no feedback, o produto pode ser lançado como está ou com melhorias sugeridas no segmento de mercado-alvo.

Processo Pós SDLC

Após o lançamento do produto no mercado, é feita a manutenção da base de clientes existente.

Uma vez no ambiente de produção, o sistema sofrerá modificações devido a bugs não detectados ou outros eventos inesperados. O sistema é avaliado e o ciclo é repetido para manutenção do sistema.

Papel do analista de negócios durante o processo SDLC

Como podemos ver no diagrama abaixo, BA está envolvido em direcionar os requisitos de negócios e convertê-los em requisitos de solução.

Ele está envolvido na tradução dos recursos da solução em requisitos de software. Em seguida, lidera a fase de análise e design, dita o desenvolvimento do código e, a seguir, segue a fase de teste durante a correção do bug como agente de mudança na equipe do projeto e, por fim, atende aos requisitos do cliente.

Análise de Negócios - Funções

A função de um analista de negócios em um projeto de TI pode ser múltipla. É possível que os membros da equipe do projeto tenham várias funções e responsabilidades. Em alguns projetos, o BA pode assumir as funções de Analista de Business Intelligence, Designer de Banco de Dados, Especialista de Garantia de Qualidade de Software, Testador e / ou Instrutor quando os recursos disponíveis são limitados.

Também é possível que um Coordenador de Projetos, um Líder de Desenvolvimento de Aplicativos ou um Desenvolvedor assuma a função de Analista de Negócios em projetos específicos.

A Análise de Negócios se sobrepõe fortemente à análise dos requisitos do negócio para funcionar normalmente e otimizar como funcionam. Alguns exemplos de Análise de Negócios são -

  • Criando Arquitetura de Negócios
  • Preparando um Caso de Negócio
  • Realizando avaliação de risco
  • Elicitação de requisitos
  • Análise de Processo de Negócios
  • Documentação de Requisitos

Principais funções de um BA

Uma função importante da maioria dos analistas de negócios é a ligação entre os desenvolvedores de negócios e técnicos. Os analistas de negócios trabalham junto com os clientes de negócios para reunir / definir os requisitos de um sistema ou processo para melhorar a produtividade e, ao mesmo tempo, trabalhar com as equipes técnicas para projetar e implementar o sistema / processo.

Como colaborador

A principal responsabilidade de um BA é contribuir para o desenvolvimento de usuários de negócios / usuários-chave na identificação de problemas, necessidades e funções de negócios, entender as preocupações e requisitos das partes interessadas para identificar oportunidades de melhoria e contribuir com dados de negócios para desenvolver o caso de negócios para o projeto de desenvolvimento de sistema.

Como facilitador

Um analista de negócios também deve facilitar / coordenar a elicitação e análise de requisitos, colaborando e se comunicando com as partes interessadas e para gerenciar suas expectativas e necessidades, e garantir que os requisitos sejam completos, inequívocos e mapeá-los para as necessidades de negócios em tempo real de uma organização.

Como analista

Outra função importante seria avaliar o sistema proposto e a prontidão organizacional para a implementação do sistema e fornecer suporte aos usuários e coordenar com a equipe de TI.

Para ajudar a revisar e fornecer entradas para o design do sistema de TI proposto a partir da perspectiva de negócios, resolvendo problemas / conflitos entre as partes interessadas, ajude a organizar UAT abrangente e de qualidade auxiliando os usuários no desenvolvimento de casos de teste e ajude a organizar o treinamento com o objetivo de garantir que sistema de TI implantado que é capaz de atender às necessidades e requisitos de negócios, bem como perceber os benefícios previstos.

Planejar e monitorar as atividades de análise de negócios para desenvolvimento de escopo, cronograma e abordagem para realizar as atividades relacionadas à análise de negócios para o projeto de desenvolvimento de sistema de TI, monitorar o progresso, coordenando com o gerente de projeto interno e relatar sobre receita, lucratividade, riscos e problemas onde quer que apropriado.

Principais responsabilidades de um analista de negócios

O conjunto de responsabilidades de um analista de negócios exigiria que ele cumprisse funções diferentes em diferentes fases de um projeto e são elucidadas a seguir -

Fase de Iniciação

Esta fase marcará o início de um novo projeto e um analista de negócios variará as seguintes responsabilidades -

  • Auxiliar na realização da análise de custo-benefício do projeto.
  • Entenda o caso de negócios.
  • Verifique a viabilidade da solução / projeto / produto.
  • Ajuda na criação do termo de abertura do projeto.
  • Identifique as partes interessadas no projeto.

Fase de planejamento

Esta fase envolverá a coleta de requisitos e planejamento, como o projeto será executado e gerenciado. Suas responsabilidades incluirão as funções abaixo -

  • Eliciando os requisitos
  • Analise, organize e documente os requisitos.
  • Gerenciar requisitos criando casos de uso, RTM, BRD, SRS, etc.
  • Avalie as soluções propostas.
  • Faça a ligação e melhore a comunicação com as partes interessadas.
  • Auxiliar na formulação dos planos de gerenciamento do projeto.
  • Ajudar a encontrar o escopo do projeto, restrições, suposições e riscos.
  • Auxiliar no projeto da experiência do usuário da solução.

Fase de Execução

Esta fase marca o desenvolvimento da solução de acordo com os requisitos levantados. As responsabilidades incluem -

  • Explique os requisitos para a equipe de TI / desenvolvimento.

  • Esclarecer dúvidas, preocupações quanto à solução proposta a ser desenvolvida.

  • Discuta e priorize as mudanças no escopo do projeto e obtenha um acordo.

  • Crie scripts de teste beta para o teste inicial.

  • Compartilhar os módulos em desenvolvimento com as partes interessadas e solicitar seu feedback.

  • Cumprir prazos e gerenciar as expectativas dos stakeholders.

  • Resolver conflitos e gerenciar as comunicações com a equipe do projeto.

Fase de monitoramento e controle

Nesta fase, o projeto é medido e controlado quanto a eventuais desvios dos planos iniciais. Esta fase ocorre simultaneamente à fase de execução.

  • Desenvolver scripts de teste e conduzir módulo abrangente e teste de integração.

  • Realização de UAT (teste de aceitação de uso) e criação de relatórios de teste.

  • Obtenha aceitação / aprovação das entregas do cliente.

  • Explique as solicitações de mudança para a equipe de desenvolvimento.

  • Monitore o desenvolvimento das solicitações de mudança e verifique sua implementação de acordo com o objetivo do projeto.

Fase de Fechamento

Esta fase marca o encerramento do projeto. As responsabilidades são -

  • Apresentar o projeto concluído ao cliente e obter sua aceitação.

  • Crie manuais de treinamento do usuário, qualquer material funcional e outros guias de instrução.

  • Realizar testes de integração elaborados no ambiente de produção.

  • Crie documentações do produto final, documente as lições aprendidas do projeto.

O que um BA deve entregar?

Um analista de negócios serve como ponte entre os usuários de negócios e o pessoal técnico de TI. Sua presença contribuirá significativamente para o sucesso dos projetos de TI. Há muitos benefícios em ter um analista de negócios dedicado. Um analista de negócios dedicado pode -

  • Oferece um escopo de projeto claro do ponto de vista do negócio.

  • Desenvolva casos de negócios sólidos e estimativas mais realistas de recursos e benefícios de negócios.

  • Elabora melhores relatórios sobre o escopo, planejamento e gerenciamento do projeto em termos de custos e cronograma, especialmente para projetos de TI de grande escala.

  • Produz requisitos claros e concisos, que por sua vez, ajuda a fornecer requisitos mais claros e precisos, se o projeto de TI for terceirizado.

  • Obtenha as reais necessidades de negócios dos usuários e gerencie com eficácia as expectativas dos usuários.

  • Melhora a qualidade do design do sistema de TI proposto para que ele atenda aos requisitos do usuário.

  • Garante a qualidade do sistema desenvolvido antes de repassar aos usuários finais para revisão e aceitação.

  • Organiza testes de qualidade abrangentes nos sistemas entregues e fornece feedback para o pessoal técnico de TI.

Análise de Negócios - Ferramentas e Técnicas

Um analista de negócios deve estar familiarizado com várias ferramentas analíticas e tecnologias relacionadas quando você está usando o chapéu BA. Quero dizer, se você está mantendo esta posição.

Como já aprendemos antes, a análise de negócios é um processo onde você tenta entender uma empresa e identificar oportunidades, áreas problemáticas, problemas e conhecer uma ampla gama de pessoas com ampla gama de funções e responsabilidades, como CEO, VP, Diretor e compreender seus requisitos de negócios.

Fundamentalmente, existem 3 tipos de análise de negócios que podemos categorizar em -

  • Strategic Analysis- A análise estratégica de negócios trata do trabalho de pré-projeto. É o método ou processo de identificar problemas de negócios, elaborando estratégias, metas e objetivos de negócios, ajudando a alta administração. Ele fornece relatórios de informações de gerenciamento para um processo de tomada de decisão eficaz.

  • Tactical Analysis - Envolve o conhecimento de técnicas específicas de análise de negócios a serem aplicadas no momento certo no projeto apropriado.

  • Operational Analysis- Neste tipo de análise de negócios, estamos focados no aspecto do negócio, alavancando a tecnologia da informação. É também um processo de estudo de sistemas operacionais com o objetivo de identificar oportunidades de melhoria do negócio.

Para cada tipo de análise, existe um conjunto de ferramentas disponíveis no mercado e baseadas nas necessidades e requisitos organizacionais, estas devem ser utilizadas.

No entanto, para materializar os requisitos de negócios em informações compreensíveis, um bom BA aproveitará as técnicas de Apuração de Fatos, Entrevistas, Revisão de Documentação, Questionários, Amostragem e Pesquisa em suas atividades do dia-a-dia.

Requisitos funcionais e não funcionais

Podemos dividir um requisito em dois tipos principais, como requisitos funcionais e não funcionais.

Para todos os projetos de tecnologia, os requisitos funcionais e não funcionais devem ser segregados e analisados ​​separadamente.

Definir a ferramenta adequada e uma técnica apropriada pode ser um desafio assustador. Esteja você fazendo um aplicativo totalmente novo ou fazendo alterações em um aplicativo existente. Considerar a técnica certa para o processo funcional é uma arte por si só.

Uma visão geral das técnicas de análise de negócios amplamente utilizadas que estão atualmente no mercado -

Processos Técnicas Entregáveis ​​do processo (resultados)
Para determinar os requisitos funcionais e não funcionais
  • Sessões JAD
  • Cenários e casos de uso
  • Modelagem Organizacional
  • Modelagem de Escopo
  • Decomposição Funcional
  • Interviews
  • Observação (Job Shadowing)
  • Grupos de foco
  • Aceitação e Avaliação
  • Diagramas de Seqüência
  • Histórias de usuários
  • Brainstorming
  • Storyboarding
  • Prototyping
  • Passo a passo estruturado
  • Análise de Eventos
  • Análise de regras de negócios
  • Workshops de Requisitos
  • Análise de risco
  • Análise de causa raiz

Business Requirements Documents -

  • Requisitos de negócios e funcionais
  • Requisitos não Funcionais
  • Regras do negócio
  • Matriz de rastreabilidade de requisitos

Common Template -

  • Documento de Requisitos de Negócios

Aplicabilidade de ferramentas e processos

Embora haja uma variedade de ferramentas e procedimentos disponíveis para analistas de negócios, tudo depende das práticas atuais da organização e de como eles gostariam de usá-las.

Por exemplo, root-cause analysis é usado quando há um requisito para se aprofundar em uma determinada área ou função importante.

No entanto, o documento de requisitos de negócios é a maneira mais popular e aceita de colocar os requisitos em formato de documentação.

Nos capítulos subsequentes, discutiremos algumas das técnicas acima em profundidade.

Análise de Negócios - Sessão JAD

Joint Application Development (JAD) é um processo usado para coletar requisitos de negócios durante o desenvolvimento de novos sistemas de informação para uma empresa. O processo JAD também pode incluir abordagens para aumentar a participação do usuário, acelerando o desenvolvimento e melhorando a qualidade das especificações. A intenção de uma sessão JAD é reunir especialistas no assunto / analista de negócios ou especialista em TI para trazer soluções.

Analista de negócios é aquele que interage com todo o grupo e reúne as informações, analisa e produz um documento. Ele desempenha um papel muito importante na sessão JAD.

Uso de uma Sessão JAD

As sessões do JAD são workshops facilitados e altamente estruturados que reúnem os tomadores de decisão do cliente e a equipe de TI para produzir resultados de alta qualidade em um curto período.

Em outras palavras, uma Sessão JAD permite que clientes e desenvolvedores cheguem rapidamente a um acordo sobre o escopo básico, objetivos e especificações de um projeto ou, no caso, não cheguem a um acordo, o que significa que o projeto precisa ser reavaliado.

Simplificando, as sessões JAD podem

  • Simplify - Consolida meses de reuniões e telefonemas em um workshop estruturado.

  • Identify - Problemas e participantes

  • Quantify - Necessidades de informação e processamento

  • Clarify - Cristalizar e esclarecer todos os requisitos acordados na sessão.

  • Unify - A saída de uma fase de desenvolvimento é a entrada para a próxima.

  • Satisfy- Os clientes definem o sistema; portanto, é o sistema deles. A participação compartilhada traz uma parcela do resultado; eles se comprometem com o sucesso dos sistemas.

Participantes em uma Sessão JAD

Os participantes envolvidos em uma sessão JAD são os seguintes -

Patrocinador executivo

Um patrocinador executivo é a pessoa que conduz o projeto - o proprietário do sistema. Eles normalmente são de cargos mais altos e são capazes de tomar decisões e fornecer a estratégia, o planejamento e a direção necessários.

Especialista no assunto

Esses são os usuários de negócios e especialistas externos necessários para um workshop de sucesso. Os especialistas no assunto são a espinha dorsal da sessão JAD. Eles conduzirão as mudanças.

Facilitador

Ele preside a reunião; ele identifica problemas que podem ser resolvidos como parte da reunião. O facilitador não contribui com informações para a reunião.

Usuários-chave

Usuários-chave ou também chamados de superusuários, em alguns casos, têm sido usados ​​de forma intercambiável e ainda diferem de empresa para empresa. Os usuários-chave geralmente são os usuários de negócios mais alinhados ao projeto de TI e responsáveis ​​pela configuração dos perfis dos membros da equipe durante os projetos.

Por exemplo: suponha que John seja um usuário-chave e Nancy, Evan, usuários de um sistema SAP. Nesse caso, Nancy e Evan não têm acesso para alterar a funcionalidade e o perfil, enquanto John, sendo um usuário principal, tem acesso para editar o perfil com mais autorizações.

A abordagem JAD, em comparação com a prática mais tradicional, é pensada para levar a tempos de desenvolvimento mais rápidos e maior satisfação do cliente, pois o cliente está envolvido em todo o processo de desenvolvimento. Em comparação, na abordagem tradicional de desenvolvimento de sistemas, o desenvolvedor investiga os requisitos do sistema e desenvolve um aplicativo, com a entrada do cliente consistindo em uma série de entrevistas.

Técnicas de coleta de requisitos

As técnicas descrevem como as tarefas são realizadas em circunstâncias específicas. Uma tarefa pode ter nenhuma ou uma ou mais técnicas relacionadas. Uma técnica deve estar relacionada a pelo menos uma tarefa.

A seguir estão algumas das técnicas de coleta de requisitos bem conhecidas -

Debate

Brainstorming é usado na coleta de requisitos para obter o máximo de idéias possível de um grupo de pessoas. Geralmente usado para identificar possíveis soluções para problemas e esclarecer detalhes de oportunidades.

Análise de Documentos

Revisar a documentação de um sistema existente pode ajudar na criação de documentos de processo AS – IS, bem como conduzir a análise de lacunas para o escopo de projetos de migração. Em um mundo ideal, estaríamos até revisando os requisitos que impulsionaram a criação do sistema existente - um ponto de partida para documentar os requisitos atuais. Nuggets de informações geralmente estão enterrados em documentos existentes que nos ajudam a fazer perguntas como parte da validação da integridade dos requisitos.

Amostra

Um grupo de foco é uma reunião de pessoas que representam os usuários ou clientes de um produto para obter feedback. O feedback pode ser coletado sobre necessidades / oportunidades / problemas para identificar requisitos ou pode ser coletado para validar e refinar requisitos já eliciados. Essa forma de pesquisa de mercado é diferente do brainstorming, pois é um processo gerenciado com participantes específicos.

Análise de interface

As interfaces de um produto de software podem ser humanas ou de máquina. A integração com sistemas e dispositivos externos é apenas outra interface. As abordagens de design centrado no usuário são muito eficazes para garantir a criação de softwares utilizáveis. Análise de interface - revisar os pontos de contato com outros sistemas externos é importante para garantir que não negligenciemos os requisitos que não são imediatamente visíveis aos usuários.

Entrevista

Entrevistas com partes interessadas e usuários são críticas para a criação de um ótimo software. Sem entender os objetivos e expectativas dos usuários e partes interessadas, é muito improvável que os satisfaçam. Também temos que reconhecer a perspectiva de cada entrevistado, para que possamos pesar e abordar adequadamente suas contribuições. Ouvir é a habilidade que ajuda um grande analista a obter mais valor de uma entrevista do que um analista médio.

Observação

Ao observar os usuários, um analista pode identificar um fluxo de processo, etapas, pontos problemáticos e oportunidades de melhoria. As observações podem ser passivas ou ativas (fazer perguntas enquanto observa). A observação passiva é melhor para obter feedback sobre um protótipo (para refinar os requisitos), onde a observação ativa é mais eficaz para obter uma compreensão de um processo de negócios existente. Qualquer abordagem pode ser usada.

Prototipagem

A prototipagem é uma técnica relativamente moderna para coleta de requisitos. Nesta abordagem, você reúne os requisitos preliminares que usa para construir uma versão inicial da solução - um protótipo. Você mostra isso ao cliente, que lhe fornece requisitos adicionais. Você muda o aplicativo e circula com o cliente novamente. Esse processo repetitivo continua até que o produto atenda à massa crítica de necessidades de negócios ou por um número acordado de iterações.

Workshops de Requisitos

Workshops podem ser muito eficazes para coletar requisitos. Mais estruturado do que uma sessão de brainstorming, as partes envolvidas colaboram para documentar os requisitos. Uma maneira de capturar a colaboração é com a criação de artefatos de modelo de domínio (como diagramas estáticos, diagramas de atividades). Um workshop será mais eficaz com dois analistas do que com um.

Engenharia reversa

Quando um projeto de migração não tem acesso a documentação suficiente do sistema existente, a engenharia reversa identificará o que o sistema faz. Ele não identificará o que o sistema deve fazer e não identificará quando o sistema fizer a coisa errada.

Questionário de pesquisa

Ao coletar informações de muitas pessoas - muitas para entrevistar com restrições de orçamento e tempo - uma pesquisa ou questionário pode ser usado. A pesquisa pode forçar os usuários a selecionar uma das opções, avaliar algo (“Concordo totalmente, concordo ...”) ou ter perguntas abertas que permitem respostas de forma livre. O design da pesquisa é difícil - as perguntas podem influenciar os entrevistados.

Documento de Requisitos Funcionais

O Documento de Requisitos Funcionais (FRD) é uma declaração formal dos requisitos funcionais de um aplicativo. Ele tem o mesmo propósito de um contrato. Aqui, os desenvolvedores concordam em fornecer os recursos especificados. O cliente concorda em considerar o produto satisfatório se ele fornecer os recursos especificados no FRD.

Os requisitos funcionais capturam o comportamento pretendido do sistema. Este comportamento pode ser expresso como serviços, tarefas ou funções que o sistema deve executar. O documento deve ser adaptado para atender às necessidades de um projeto específico. Eles definem coisas como cálculos do sistema, manipulação e processamento de dados, interface do usuário e interação com o aplicativo.

O Documento de Requisitos Funcionais (FRD) tem as seguintes características -

  • Isso demonstra que o aplicativo agrega valor em termos de objetivos de negócios e processos de negócios nos próximos anos.

  • Ele contém um conjunto completo de requisitos para o aplicativo. Não deixa espaço para ninguém presumir nada que não esteja declarado no FRD.

  • É solução independente. O ERD é uma declaração do que o aplicativo deve fazer - não de como ele funciona. O FRD não compromete os desenvolvedores com um design. Por esse motivo, qualquer referência ao uso de uma tecnologia específica é totalmente inadequada em um FRD.

O requisito funcional deve incluir o seguinte -

  • Descrições de data para ser inserido no sistema

  • Descrições de operations realizado por cada tela

  • Descrições de work-flows realizado pelo sistema

  • Descrições de system reports ou outras saídas

  • Quem pode entrar no data no sistema?

  • Como o sistema atende aplicável regulatory requirements?

A especificação funcional foi projetada para ser lida por um público geral. Os leitores devem compreender o sistema, mas nenhum conhecimento técnico deve ser exigido para compreender este documento.

Entregáveis ​​de Requisitos Funcionais

Um Documento de Requisitos de Negócios (BRD) consiste em -

  • Functional Requirements- Um documento contendo requisitos detalhados para o sistema que está sendo desenvolvido. Esses requisitos definem os recursos e capacidades funcionais que um sistema deve possuir. Certifique-se de que quaisquer suposições e restrições identificadas durante o Caso de Negócio ainda sejam precisas e atualizadas.

  • Business Process Model - Um modelo do estado atual do processo (modelo "como está") ou um conceito de como o processo deve se tornar (modelo "ser")

  • System Context Diagram - Um diagrama de contexto mostra os limites do sistema, entidades externas e internas que interagem com o sistema e os fluxos de dados relevantes entre essas entidades externas e internas.

  • Flow Diagrams (as-is or to-be)- Os diagramas representam graficamente a sequência de operações ou a movimentação de dados para um processo de negócios. Um ou mais diagramas de fluxo são incluídos dependendo da complexidade do modelo.

  • Business Rules and Data Requirements - As regras de negócios definem ou restringem alguns aspectos do negócio e são usadas para definir restrições de dados, valores padrão, intervalos de valores, cardinalidade, tipos de dados, cálculos, exceções, elementos necessários e integridade relacional dos dados.

  • Data Models - Diagramas de relacionamento de entidade, descrições de entidade, diagramas de classe

  • Conceptual Model - Exibição de alto nível de diferentes entidades para uma função de negócios e como elas se relacionam entre si.

  • Logical Model - Ilustra as entidades, atributos e relacionamentos específicos envolvidos em uma função de negócios e representa todas as definições, características e relacionamentos de dados em um ambiente de negócios, técnico ou conceitual.

  • Data Dictionary and Glossary - Uma coleção de informações detalhadas sobre os elementos de dados, campos, tabelas e outras entidades que compõem o modelo de dados subjacente a um banco de dados ou sistema de gerenciamento de dados semelhante.

  • Stakeholder Map- Identifica todas as partes interessadas que são afetadas pela mudança proposta e seu nível de influência / autoridade para os requisitos. Este documento foi desenvolvido na fase de originação da Metodologia de Gerenciamento de Projetos (PMM) e é propriedade do Gerente de Projeto, mas precisa ser atualizado pela equipe do projeto à medida que novos / alterados Stakeholders são identificados ao longo do processo.

  • Requirements Traceability Matrix - Uma tabela que ilustra links lógicos entre requisitos funcionais individuais e outros tipos de artefatos do sistema, incluindo outros Requisitos Funcionais, Casos de Uso / Histórias de Usuário, Arquitetura e Elementos de Design, Módulos de Código, Casos de Teste e Regras de Negócios.

Especificação de Requisitos de Software

Uma Especificação de Requisitos de Software (SRS) é um documento usado como meio de comunicação entre os clientes. Uma especificação de requisito de software em sua forma mais básica é um documento formal usado na comunicação dos requisitos de software entre o cliente e o desenvolvedor.

Um documento SRS concentra-se em WHAT precisa ser feito e evita cuidadosamente a solução (how to do) Ele serve como um contrato entre a equipe de desenvolvimento e o cliente. Os requisitos neste estágio são escritos usando a terminologia do usuário final. Se necessário, posteriormente uma especificação formal de requisitos será desenvolvida a partir dele.

O SRS é uma descrição completa do comportamento de um sistema a ser desenvolvido e pode incluir um conjunto de casos de uso que descreve as interações que os usuários terão com o software.

Objetivo do SRS

SRS é uma ferramenta de comunicação entre Cliente / Cliente, Analista de Negócios, Desenvolvedores de Sistemas, Equipes de Manutenção. Também pode ser um contrato entre comprador e fornecedor.

  • Isso dará uma base sólida para a fase de design
  • Suporta gerenciamento e controle de projetos
  • Ajuda no controle e evolução do sistema

Uma especificação de Requisito de software deve ser Completa, Consistente, Rastreável, Não Ambígua e Verificável.

O seguinte deve ser abordado na especificação do sistema -

  • Defina as funções dos sistemas
  • Definir o Particionamento Funcional de Hardware / Software
  • Defina a especificação de desempenho
  • Definir o particionamento de desempenho de hardware / software
  • Definir requisitos de segurança
  • Definir a interface do usuário (manual do usuário)
  • Fornece desenhos / instruções de instalação
  • Modelo de especificação de requisito de software

Histórico de Revisão

Encontro Descrição Autor Comentários
<data> <Versão 1> <Seu nome> <Primeira revisão>

Aprovação de Documento

A seguinte especificação de requisitos de software foi aceita e aprovada pelo seguinte -

Assinatura Nome impresso Título Encontro
<Seu nome> Lead Software Eng.
David Instrutor

Análise de Negócios - Casos de Uso

Um dos nove diagramas da UML é o Diagrama de caso de uso. Esses não são apenas requisitos importantes, mas necessários para projetos de software. É basicamente usado em ciclos de vida de software. Como sabemos, existem várias fases no ciclo de desenvolvimento e a fase mais usada para casos de uso seria durante a fase de coleta de requisitos.

O que é um caso de uso?

Um caso de uso descreve uma sequência de ações, executadas por um sistema que fornece valor a um ator. O caso de uso descreve o comportamento do sistema sob várias condições, conforme ele responde a uma solicitação de uma das partes interessadas, chamada deprimary actor.

O ator é quem do sistema, ou seja, ele é o usuário final.

Na engenharia de software e sistemas, um caso de uso é uma lista de etapas, geralmente definindo interações entre uma função (conhecida na UML como um "ator") e um sistema, para atingir um objetivo. O ator pode ser um ser humano ou um sistema externo.

Um caso de uso especifica o fluxo de eventos no sistema. Está mais preocupado com o que é executado pelo sistema para realizar a sequência de ações.

Benefícios de um caso de uso

Um caso de uso oferece os seguintes benefícios -

  • É um meio fácil de capturar o requisito funcional com foco no valor agregado ao usuário.

  • Os casos de uso são relativamente fáceis de escrever e ler em comparação com os métodos de requisitos tradicionais.

  • Os casos de uso forçam os desenvolvedores a pensar da perspectiva do usuário final.

  • O caso de uso envolve o usuário no processo de requisitos.

A anatomia de um caso de uso

Nome : nome descritivo que ilustra a finalidade do caso de uso.

Descrição : descreve o que o caso de uso faz em algumas frases.

Ator : Liste todos os atores que participam do caso de uso.

Pré-condição : Condições que devem ser atendidas antes de iniciar o caso de uso.

Fluxo de eventos : Descrição da interação entre o sistema e o ator.

Pós-condição : Descreva o estado do sistema após o término de um caso de uso.

Orientação para modelo de caso de uso

Documente cada caso de uso usando o modelo fornecido no final deste capítulo. Esta seção fornece uma descrição de cada seção do modelo de caso de uso.

Identificação de caso de uso

  • Use-Case ID- Dê a cada caso de uso um identificador numérico exclusivo, em forma hierárquica: XY Casos de uso relacionados podem ser agrupados na hierarquia. Os requisitos funcionais podem ser rastreados até um caso de uso rotulado.

  • Use-Case Name- Declare um nome conciso e orientado a resultados para o caso de uso. Eles refletem as tarefas que o usuário precisa ser capaz de realizar usando o sistema. Inclui um verbo de ação e um substantivo. Alguns exemplos -

    • Visualize as informações do número da peça.

    • Marque manualmente a origem do hipertexto e estabeleça o link para o destino.

    • Faça um pedido de um CD com a versão de software atualizada.

Histórico de caso de uso

Aqui, mencionamos sobre os nomes das pessoas que são os stakeholders do documento Usecase.

  • Created By - Forneça o nome da pessoa que inicialmente documentou este caso de uso.

  • Date Created - Insira a data em que o caso de uso foi documentado inicialmente.

  • Last Updated By - Forneça o nome da pessoa que executou a atualização mais recente na descrição do caso de uso.

  • Date Last Updated - Insira a data em que o caso de uso foi atualizado mais recentemente.

Definição de Caso de Uso

A seguir estão as definições dos principais conceitos de Caso de Uso -

Ator

Um ator é uma pessoa ou outra entidade externa ao sistema de software que está sendo especificado, que interage com o sistema e executa casos de uso para realizar tarefas. Diferentes atores geralmente correspondem a diferentes classes de usuários, ou funções, identificadas na comunidade de clientes que usará o produto. Nomeie o (s) ator (es) que realizarão este caso de uso.

Descrição

Forneça uma breve descrição do motivo e do resultado desse caso de uso, ou uma descrição de alto nível da sequência de ações e do resultado da execução do caso de uso.

Condições prévias

Liste todas as atividades que devem ocorrer, ou quaisquer condições que devem ser verdadeiras, antes que o caso de uso possa ser iniciado. Numere cada pré-condição.

Examples

  • A identidade do usuário foi autenticada.
  • O computador do usuário tem memória livre suficiente disponível para iniciar a tarefa.

Condições de postagem

Descreva o estado do sistema na conclusão da execução do caso de uso. Numere cada condição de postagem.

Examples

  • O documento contém apenas tags SGML válidas.
  • Preço do item no banco de dados foi atualizado com novo valor.

Prioridade

Indique a prioridade relativa de implementação da funcionalidade necessária para permitir que este caso de uso seja executado. O esquema de prioridade usado deve ser o mesmo usado na especificação de requisitos de software.

Frequência de uso

Estime o número de vezes que esse caso de uso será executado pelos atores por alguma unidade de tempo apropriada.

Curso Normal de Eventos

Forneça uma descrição detalhada das ações do usuário e respostas do sistema que ocorrerão durante a execução do caso de uso sob condições normais esperadas. Essa sequência de diálogo levará, em última análise, à realização da meta declarada no nome e na descrição do caso de uso. Esta descrição pode ser escrita como uma resposta à pergunta hipotética, “Como faço para <realizar a tarefa declarada no nome do caso de uso>?” Isso é melhor feito como uma lista numerada de ações executadas pelo ator, alternando com as respostas fornecidas pelo sistema.

Cursos alternativos

Documente outros cenários de uso legítimos que podem ocorrer neste caso de uso separadamente nesta seção. Indique o curso alternativo e descreva quaisquer diferenças na sequência de etapas que ocorrem. Numere cada curso alternativo usando o ID do caso de uso como um prefixo, seguido por “AC” para indicar “Curso alternativo”. Exemplo: XYAC.1.

Exceções

Descreva quaisquer condições de erro previstas que podem ocorrer durante a execução do caso de uso e defina como o sistema deve responder a essas condições. Além disso, descreva como o sistema deve responder se a execução do caso de uso falhar por algum motivo imprevisto. Numere cada exceção usando o ID do caso de uso como um prefixo, seguido por “EX” para indicar “Exceção”. Exemplo: XYEX.1.

Inclui

Liste todos os outros casos de uso incluídos (“chamados”) por este caso de uso. A funcionalidade comum que aparece em vários casos de uso pode ser dividida em um caso de uso separado, que é incluído por aqueles que precisam dessa funcionalidade comum.

Requisitos especiais

Identifique quaisquer requisitos adicionais, como requisitos não funcionais, para o caso de uso que pode precisar ser tratado durante o design ou implementação. Isso pode incluir requisitos de desempenho ou outros atributos de qualidade.

Suposições

Liste todas as suposições feitas na análise que levaram à aceitação desse caso de uso na descrição do produto e redigindo a descrição do caso de uso.

Notas e questões

Liste todos os comentários adicionais sobre este caso de uso ou quaisquer questões pendentes restantes ou TBDs (a serem determinados) que devem ser resolvidos. Identifique quem resolverá cada problema, a data de vencimento e qual será a resolução final.

Gerenciamento de mudanças e controle de versão

O controle de versão é o gerenciamento de alterações em documentos, grandes sites da Web e outras coleções de informações. As alterações são geralmente identificadas por um número ou código de letra, denominado como número de revisão ou nível de revisão. Cada revisão está associada a um carimbo de data / hora e a uma pessoa que faz a alteração.

Diagramas de caso de uso

Uma parte importante da Unified Modeling Language (UML) são os recursos para desenhar diagramas de caso de uso. Os casos de uso são usados ​​durante a fase de análise de um projeto para identificar e particionar a funcionalidade do sistema. Eles separam o sistema em atores e casos de uso. Atores representam funções que podem ser desempenhadas por usuários do sistema.

Esses usuários podem ser humanos, outros computadores, peças de hardware ou até mesmo outros sistemas de software. O único critério é que eles devem ser externos à parte do sistema que está sendo particionada em casos de uso. Eles devem fornecer estímulos para aquela parte do sistema, e devem receber resultados dele.

Os casos de uso representam as atividades que os atores executam com a ajuda do seu sistema na busca de um objetivo. Precisamos definir o que esses usuários (atores) precisam do sistema. O caso de uso deve refletir as necessidades e objetivos do usuário e deve ser iniciado por um ator. Negócios, atores, clientes que participam do caso de uso de negócios devem estar conectados ao caso de uso por associação.

Desenho de diagramas de casos de uso

A Figura abaixo mostra como um caso de uso pode se parecer com a forma esquemática UML. O próprio caso de uso se parece com um oval. Os atores são desenhados como pequenas figuras de palitos. Os atores são conectados ao caso de uso por linhas.

Use-case 1 - O balconista verifica um item

  • O cliente coloca o item no balcão.
  • «Usa» Swipe UPC Reader.
  • O sistema procura o código UPC na descrição e preço do item de aquisição do banco de dados
  • O sistema emite um bipe audível.
  • O sistema anuncia a descrição e o preço do item sobre a saída de voz.
  • O sistema adiciona preço e tipo de item à fatura atual.
  • O sistema adiciona preço para corrigir o subtotal do imposto

Portanto, a relação «usa» é muito parecida com uma chamada de função ou uma sub-rotina.

O caso de uso usado dessa maneira é chamado de caso de uso abstrato porque não pode existir por si mesmo, mas deve ser usado por outros casos de uso.

Exemplo ─ Caso de uso de retirada

O objetivo de um cliente em relação à nossa máquina de venda automática de dinheiro (ATM) é retirar dinheiro. Então, estamos adicionandoWithdrawalcaso de uso. Retirar dinheiro da máquina de venda automática pode envolver um banco para as transações a serem feitas. Então, também estamos adicionando outro ator -Bank. Os dois atores que participam do caso de uso devem ser conectados ao caso de uso por associação.

A máquina de venda automática de dinheiro fornece um caso de uso de Retirada para o cliente e atores do Banco.

Relações entre atores e casos de uso

Os casos de uso podem ser organizados usando os seguintes relacionamentos -

  • Generalization
  • Association
  • Extend
  • Include

Generalização entre casos de uso

Pode haver instâncias em que os atores estão associados a casos de uso semelhantes. Nesse caso, um caso de uso Filho herda as propriedades e o comportamento do uso pai. Portanto, precisamos generalizar o ator para mostrar a herança das funções. Eles são representados por uma linha sólida com uma grande ponta de seta triangular oca.

Associação entre casos de uso

As associações entre atores e casos de uso são indicadas em diagramas de casos de uso por linhas sólidas. Uma associação existe sempre que um ator está envolvido em uma interação descrita por um caso de uso.

Ampliar

Existem algumas funções que são acionadas opcionalmente. Nesses casos, o relacionamento de extensão é usado e a regra de extensão é anexada a ele. Uma coisa a lembrar é que o caso de uso base deve ser capaz de executar uma função sozinho, mesmo se o caso de uso de extensão não for chamado.

O relacionamento estendido é mostrado como uma linha tracejada com uma ponta de seta aberta direcionada do caso de uso estendido para o caso de uso estendido (base). A seta é rotulada com a palavra-chave «extend».

Incluir

Ele é usado para extrair fragmentos de casos de uso que são duplicados em vários casos de uso. Ele também é usado para simplificar grandes casos de uso, dividindo-os em vários casos de uso e para extrair partes comuns dos comportamentos de dois ou mais casos de uso.

Inclui o relacionamento entre os casos de uso que é mostrado por uma seta tracejada com uma ponta de seta aberta do caso de uso base para o caso de uso incluído. A seta é rotulada com a palavra-chave «incluir».

Os casos de uso tratam apenas dos requisitos funcionais de um sistema. Outros requisitos, como regras de negócios, requisitos de qualidade de serviço e restrições de implementação, devem ser representados separadamente.

O diagrama mostrado abaixo é um exemplo de diagrama de caso de uso simples com todos os elementos marcados.

Princípios básicos para a aplicação bem-sucedida de casos de uso

  • Mantenha a simplicidade contando histórias
  • Seja produtivo sem perfeição
  • Entenda o quadro geral
  • Identificar oportunidade de reutilização para casos de uso
  • Foco no valor
  • Construa o sistema em fatias
  • Entregue o sistema em incrementos
  • Adapte-se para atender às necessidades da equipe

Modelo de caso de uso

Aqui, mostramos um modelo de exemplo de um caso de uso que um analista de negócios pode preencher para que as informações possam ser úteis para a equipe técnica apurar informações sobre o projeto.

ID de caso de uso:
Nome do caso de uso:
Criado por: Última atualização por
Data Criada: Data da Última Atualização
Ator:
Descrição:
Pré-condições:
Pós-condições:
Prioridade:
Frequência de uso:
Curso normal de eventos:
Cursos Alternativos:
Exceções:
Inclui:
Requisitos especiais:
Suposições:
Notas e problemas:

Análise de Negócios - Gerenciamento de Requisitos

A coleta de requisitos de software é a base de todo o projeto de desenvolvimento de software. Solicitar e reunir requisitos de negócios é uma primeira etapa crítica para cada projeto. Para preencher a lacuna entre os requisitos técnicos e de negócios, os analistas de negócios devem compreender totalmente as necessidades de negócios dentro do contexto dado, alinhar essas necessidades com os objetivos de negócios e comunicar adequadamente as necessidades aos interessados ​​e à equipe de desenvolvimento.

Os principais interessados ​​desejam que alguém possa explicar os requisitos do cliente / cliente em inglês simples. Isso os beneficiará por compreender o valor em alto nível? Esta será a área de foco principal, pois eles tentarão mapear a documentação com os requisitos e como o BA poderia se comunicar da melhor maneira possível.

Por que os projetos falham

Existem muitos motivos pelos quais os projetos falham, mas algumas das áreas comuns incluem o seguinte -

  • Falha de mercado e estratégia
  • Falhas Organizacionais e de Planejamento
  • Falhas de qualidade
  • Falhas de liderança e governança
  • Falhas de habilidades, conhecimento e competência
  • Falhas de engajamento, trabalho em equipe e comunicação

O cerne da questão é que os projetos estão cada vez mais complexos, as mudanças ocorrem e a comunicação é um desafio.

Por que equipes de sucesso fazem gerenciamento de requisitos

O gerenciamento de requisitos é sobre como manter sua equipe in-sync e fornecendo visibility para o que está acontecendo dentro de um projeto.

É fundamental para o sucesso de seus projetos que toda a sua equipe entenda o que você está construindo e por quê - é assim que definimos o gerenciamento de requisitos. O “porquê” é importante porque fornece contexto para os objetivos, feedback e decisões que estão sendo tomadas sobre os requisitos.

Isso aumenta a previsibilidade de sucessos futuros e problemas potenciais, permitindo que sua equipe corrija rapidamente quaisquer problemas e conclua com sucesso seu projeto no prazo e dentro do orçamento. Como ponto de partida, é importante que todos os envolvidos tenham um entendimento básico do que são requisitos e como gerenciá-los.

Vamos começar com o básico

Um requisito é uma condição ou capacidade necessária para uma parte interessada resolver um problema ou atingir um objetivo. Uma condição ou capacidade que deve ser atendida ou possuída por um sistema ou sistema. Componente para satisfazer um contrato, padrão, especificação ou outros documentos impostos formalmente.

Um requisito pode ser expresso com texto, esboços, maquetes ou modelos detalhados, qualquer informação que melhor comunique a um engenheiro o que construir e a um gerente de QA o que testar. Dependendo do seu processo de desenvolvimento, você pode usar terminologia diferente para capturar os requisitos.

Os requisitos de alto nível às vezes são chamados simplesmente de needs ou goals. Dentro das práticas de desenvolvimento de software, os requisitos podem ser chamados de “casos de uso”, “recursos” ou “requisitos funcionais”. Ainda mais especificamente dentro de metodologias de desenvolvimento ágil, os requisitos são frequentemente capturados comoepics e stories.

Independentemente de como sua equipe os chama ou do processo que você usa; requisitos são essenciais para o desenvolvimento de todos os produtos. Sem definir claramente os requisitos, você pode produzir um produto incompleto ou com defeito. Ao longo do processo, pode haver muitas pessoas envolvidas na definição de requisitos.

Uma parte interessada pode solicitar um recurso que descreve como o produto agregará valor na solução de um problema. Um designer pode definir um requisito com base na aparência ou no desempenho do produto final do ponto de vista da usabilidade ou da interface do usuário.

Um analista de negócios pode criar um requisito de sistema que adere a restrições técnicas ou organizacionais específicas. Para os sofisticados produtos e aplicativos de software em construção de hoje, geralmente são necessários centenas ou milhares de requisitos para definir suficientemente o escopo de um projeto ou lançamento. Portanto, é imperativo que a equipe seja capaz de acessar, colaborar, atualizar e testar cada requisito até a conclusão, pois os requisitos mudam e evoluem naturalmente com o tempo durante o processo de desenvolvimento.

Agora que definimos o valor do gerenciamento de requisitos em um alto nível, vamos nos aprofundar nos quatro fundamentos que cada membro da equipe e todas as partes interessadas podem se beneficiar ao compreender -

  • Planejando bons requisitos: “O que diabos estamos construindo?”
  • Colaboração e adesão: “Basta aprovar a especificação, já!”
  • Rastreabilidade e gerenciamento de mudanças: “Espere, os desenvolvedores sabem que isso mudou?”
  • Garantia de qualidade: “Olá, alguém testou isso?”

Todos sabem o que estamos construindo e por quê? Esse é o valor do gerenciamento de requisitos.

Colaboração e aceitação das partes interessadas

Todos estão por dentro? Temos aprovação sobre os requisitos para seguir em frente? Essas questões surgem durante os ciclos de desenvolvimento. Seria ótimo se todos concordassem com os requisitos, mas para grandes projetos com muitos stakeholders, isso geralmente não acontece. Tentar fazer com que todos concordem pode atrasar as decisões ou, pior, nem tomar decisões. Obter consenso em todas as decisões nem sempre é fácil.

Na prática, você não quer necessariamente “consenso”, você quer “adesão” do grupo e aprovação daqueles que estão no controle para que você possa levar o projeto adiante. Com o consenso, você está tentando fazer com que todos se comprometam e concordem com a decisão. Com a adesão, você está tentando fazer com que as pessoas apoiem a melhor solução, tomem uma decisão inteligente e façam o que é necessário para seguir em frente.

Você não precisa que todos concordem que a decisão é a melhor. Você precisa de todos para apoiar a decisão. A colaboração da equipe pode ajudar a receber suporte nas decisões e no planejamento de bons requisitos.

As equipes colaborativas trabalham muito para garantir que todos tenham interesse nos projetos e forneçam feedback. As equipes colaborativas compartilham ideias continuamente, normalmente têm uma comunicação melhor e tendem a apoiar as decisões tomadas porque há um senso compartilhado de comprometimento e compreensão dos objetivos do projeto.

É quando os desenvolvedores, testadores ou outras partes interessadas se sentem "fora do circuito" que surgem os problemas de comunicação, as pessoas ficam frustradas e os projetos atrasam. Uma vez que todos tenham aderido ao escopo de trabalho, é imperativo que os requisitos sejam claros e bem documentados. Manter o controle de todos os requisitos é onde as coisas ficam complicadas.

Imagine ter uma lista de tarefas de um quilômetro e meio que envolve a colaboração de várias pessoas para ser concluída. Como você manteria todos esses itens em ordem? Como você rastrearia como uma alteração em um item afetaria o resto do projeto? É aqui que a rastreabilidade e o gerenciamento de mudanças agregam valor.

Bom planejamento de requisitos

Então, o que é um bom requisito? Um bom requisito deve ser valioso e acionável; deve definir uma necessidade, bem como fornecer um caminho para uma solução. Todos na equipe devem entender o que isso significa. Os requisitos variam em complexidade.

  • Um bom Documento de Requisitos pode fazer parte de um grupo com requisitos de alto nível divididos em sub-requisitos.

  • Eles também podem incluir especificações muito detalhadas que incluem um conjunto de requisitos funcionais que descrevem o comportamento ou componentes do produto final.

  • Bons requisitos precisam ser concisos e específicos e devem responder à pergunta: "do que precisamos?" Em vez de "como podemos atender a uma necessidade?"

  • Os bons requisitos garantem que todas as partes interessadas entendam sua parte do plano; se as peças não estiverem claras ou forem mal interpretadas, o produto final pode estar com defeito ou falhar.

A prevenção de falhas ou má interpretação dos requisitos pode ser auxiliada pelo recebimento de feedback da equipe continuamente ao longo do processo, conforme os requisitos evoluem. Colaboração contínua e adesão de todos são a chave para o sucesso.

Coleta e Análise de Requisitos

Um requisito é uma condição ou capacidade necessária para uma parte interessada resolver um problema ou atingir um objetivo organizacional; uma condição ou capacidade que deve ser satisfeita ou possuída por um sistema.

A análise de requisitos em engenharia de software cobre as tarefas que vão para determinar as necessidades ou condições para atender a um produto novo ou alterado, levando em consideração os possíveis requisitos conflitantes de várias partes interessadas, analisando, documentando, validando e gerenciando requisitos de software ou sistema.

Os requisitos devem ser -

  • Documented
  • Actionable
  • Measurable
  • Testable
  • Traceable

Os requisitos devem estar relacionados às necessidades ou oportunidades de negócios identificadas e definidos com um nível de detalhe suficiente para o design do sistema.

Um analista de negócios reúne informações através da observação dos sistemas existentes, estudando os procedimentos existentes, discussões com os clientes e usuários finais. O analista também deve ter habilidades imaginativas e criativas na ausência de um sistema funcional. Analisar os requisitos coletados para encontrar os links ausentes é a análise de requisitos.

Abordagem de Elicitação

Para eliciar os objetivos, pergunte ao especialista de negócios, ao gerente de desenvolvimento e ao patrocinador do projeto as seguintes perguntas -

  • Que objetivos de negócios da empresa este projeto ajudará a alcançar?

  • Por que estamos fazendo este projeto agora?

  • O que acontecerá se fizermos isso mais tarde?

  • E se não fizermos nada?

  • Quem se beneficiará com este projeto?

  • As pessoas que se beneficiarão com isso o consideram a melhoria mais importante que pode ser feita neste momento?

  • Deveríamos estar fazendo um projeto diferente em vez disso?

Os objetivos possíveis podem ser reduzir custos, melhorar o atendimento ao cliente, simplificar o fluxo de trabalho, substituir tecnologia obsoleta, testar uma nova tecnologia e muitos outros. Além disso, certifique-se de entender exatamente como o projeto proposto ajudará a cumprir o objetivo declarado.

Diferentes tipos de requisitos

Os tipos mais comuns de requisitos pelos quais um analista de negócios está interessado são os seguintes -

Requisitos de negócio

Os requisitos de negócios são as atividades críticas de uma empresa que devem ser executadas para atender aos objetivos organizacionais enquanto permanecem independentes da solução. Um documento de requisitos de negócios (BRD) detalha a solução de negócios para um projeto, incluindo a documentação das necessidades e expectativas do cliente.

Requisitos do usuário

Os requisitos do usuário devem especificar os requisitos específicos que o usuário espera / deseja do software a ser construído a partir do projeto de software. Um requisito do usuário deve ser verificável, claro e conciso, completo, consistente, rastreável, viável.

O documento de requisitos do usuário (URD) ​​ou especificação de requisitos do usuário é um documento geralmente usado na engenharia de software que especifica o que o usuário espera que o software seja capaz de fazer.

Requisitos de sistema

Os requisitos do sistema tratam da definição dos requisitos e pré-requisitos de recursos de software que precisam ser instalados em um computador para fornecer o funcionamento ideal de um aplicativo.

Requisitos funcionais

Os requisitos funcionais capturam e especificam o comportamento pretendido específico do sistema que está sendo desenvolvido. Eles definem coisas como cálculos do sistema, manipulação e processamento de dados, interface do usuário e interação com o aplicativo e outras funcionalidades específicas que mostram como os requisitos do usuário são satisfeitos. Atribua um número de identificação exclusivo para cada requisito.

Requisitos não Funcionais

Requisito não funcional é aquele que especifica critérios que podem ser usados ​​para julgar a operação de um sistema ao invés de comportamentos específicos. A arquitetura do sistema fala sobre o plano de implementação de requisitos não funcionais.

Os requisitos não funcionais falam sobre como o sistema deve ser ou podem ser mencionados como “o sistema deve ser”. Os requisitos não funcionais são chamados de qualidades do sistema.

Requisitos de transição

Os requisitos de transição descrevem os recursos que a solução deve cumprir para facilitar a transição do estado atual da empresa para um estado futuro desejado, mas que não serão necessários depois que a transição for concluída.

Eles são diferenciados de outros tipos de requisitos porque são sempre de natureza temporária e não podem ser desenvolvidos até que uma solução existente e uma nova sejam definidas. Eles normalmente cobrem a conversão de dados de sistemas existentes, lacunas de habilidades que devem ser abordadas e outras mudanças relacionadas para atingir o estado futuro desejado. Eles são desenvolvidos e definidos por meio de avaliação e validação da solução.

Rastreabilidade e gerenciamento de mudanças

A rastreabilidade de requisitos é uma forma de organizar, documentar e controlar todos os seus requisitos, desde a geração da ideia inicial até a fase de teste.

A matriz de capacidade de rastreamento de requisitos (RTM) fornece um método para rastrear os requisitos funcionais e sua implementação durante o processo de desenvolvimento. Cada requisito é incluído na matriz junto com seu número de seção associado.

Conforme o projeto avança, o RIM é atualizado para refletir o status de cada requisito. Quando o produto está pronto para o teste do sistema, a matriz lista cada requisito, qual componente do produto o atende e qual teste verifica se ele foi implementado corretamente

Incluir colunas para cada um dos seguintes no RTM -

  • Descrição do requisito
  • Referência de requisito no FRD
  • Método de verificação
  • Referência de requisitos no plano de teste

Example- Conectar os pontos para identificar as relações entre os itens em seu projeto. É um conector de fluxo a jusante comum.

Objetivos de negócios do teste de design de requisitos de ideia

Você deve ser capaz de rastrear cada um de seus requisitos de volta ao seu objetivo de negócios original.

Rastreando os requisitos, você é capaz de identificar o efeito cascata das mudanças, ver se um requisito foi concluído e se está sendo testado corretamente. A rastreabilidade e o gerenciamento de mudanças fornecem aos gerentes tranquilidade e a visibilidade necessária para antecipar problemas e garantir a qualidade contínua.

Garantia da Qualidade

Receber os requisitos corretamente na primeira vez pode significar melhor qualidade, ciclos de desenvolvimento mais rápidos e maior satisfação do cliente com o produto. O gerenciamento de requisitos não apenas ajuda você a acertar, mas também ajuda sua equipe a economizar dinheiro e muitas dores de cabeça durante o processo de desenvolvimento.

Requisitos concisos e específicos podem ajudá-lo a detectar e corrigir problemas no início, em vez de mais tarde, quando é muito mais caro corrigir. Além disso, pode custar até100 times mais para corrigir um defeito posteriormente no processo de desenvolvimento, depois que ele foi codificado, do que corrigir no início enquanto um requisito.

Ao integrar o gerenciamento de requisitos em seu processo de garantia de qualidade, você pode ajudar sua equipe a aumentar a eficiência e eliminar o retrabalho. Além disso, é no retrabalho que ocorre a maioria dos problemas de custo.

Em outras palavras, as equipes de desenvolvimento estão desperdiçando a maior parte de seus orçamentos em esforços que não são executados corretamente na primeira vez. Por exemplo, um desenvolvedor codifica um recurso com base em um documento de especificação antigo, apenas para saber mais tarde, que os requisitos para aquele recurso mudaram. Esses tipos de problemas podem ser evitados com as melhores práticas de gerenciamento de requisitos eficazes.

Em resumo, o gerenciamento de requisitos pode soar como uma disciplina complexa, mas quando você o reduz a um conceito simples - trata-se de ajudar as equipes a responder à pergunta: "Todos entendem o que estamos construindo e por quê?" Dos analistas de negócios, gerentes de produto e líderes de projeto aos desenvolvedores, gerentes de QA e testadores, junto com as partes interessadas e clientes envolvidos - muitas vezes a causa raiz do fracasso do projeto é um mal-entendido do escopo do projeto.

Quando todos estão colaborando e têm total contexto e visibilidade para as discussões, decisões e mudanças envolvidas com os requisitos ao longo do ciclo de vida do projeto, é quando o sucesso acontece de forma consistente e você mantém a qualidade contínua. Além disso, o processo é mais suave, com menos atrito e frustração para todos os envolvidos.

Note- A pesquisa mostrou que as equipes de projeto podem eliminar 50-80% dos defeitos do projeto gerenciando os requisitos de maneira eficaz. De acordo com o instituto de engenharia de software Carnegie Mellon, “60-80 por cento do custo de desenvolvimento de software está em retrabalho”.

Obtendo a aprovação dos requisitos

A aprovação dos requisitos formaliza o acordo das partes interessadas do projeto de que o conteúdo e a apresentação dos requisitos, conforme documentado, são precisos e completos. O acordo formal reduz o risco de que, durante ou após a implementação, uma parte interessada introduza um novo requisito (anteriormente não encontrado).

A obtenção da aprovação dos requisitos normalmente envolve uma revisão final face a face dos requisitos, conforme documentado, com cada parte interessada do projeto. Ao final de cada revisão, a parte interessada é solicitada a aprovar formalmente o documento de requisitos revisado. Esta aprovação pode ser registrada fisicamente ou eletronicamente.

A obtenção da aprovação dos requisitos é normalmente a tarefa final na Comunicação de Requisitos. O Analista de Negócios exigirá a saída da (s) Revisão (ões) de Requisitos Formais, incluindo acomodação de quaisquer comentários ou objeções que foram levantados durante o processo de revisão.

Análise de Negócios - Modelagem

Um modelo de negócios pode ser definido como uma representação de um negócio ou solução que geralmente inclui um componente gráfico junto com texto de suporte e relacionamentos com outros componentes. Por exemplo, se temos que entender o modelo de negócios de uma empresa, gostaríamos de estudar as seguintes áreas, como -

  • Valores fundamentais da empresa
  • O que serve?
  • O que é diferente?
  • Seus principais recursos
  • Relacionamentos principais
  • Seus canais de entrega

Com a ajuda de técnicas de modelagem, podemos criar uma descrição completa das estruturas organizacionais, processos e informações existentes e propostas usadas pela empresa.

O Modelo de Negócio é um modelo estruturado, assim como um blueprint para o produto final a ser desenvolvido. Fornece estrutura e dinâmica para o planejamento. Ele também fornece a base para o produto final.

Objetivo da Modelagem de Negócios

A modelagem de negócios é usada para projetar o estado atual e futuro de uma empresa. Este modelo é usado pelo Analista de Negócios e pelas partes interessadas para garantir que eles tenham um entendimento preciso do modelo atual “no estado em que se encontra” da empresa.

É usado para verificar se as partes interessadas têm um entendimento compartilhado do “futuro da solução” proposto.

A análise de requisitos faz parte do processo de modelagem de negócios e forma a área de foco central. Os requisitos funcionais são coletados durante o “estado atual”. Esses requisitos são fornecidos pelas partes interessadas em relação aos processos de negócios, dados e regras de negócios que descrevem a funcionalidade desejada que será projetada no Estado Futuro.

Executando Análise de GAP

Depois de definir as necessidades de negócios, o estado atual (por exemplo, processos de negócios atuais, funções de negócios, características de um sistema atual e serviços / produtos oferecidos e eventos aos quais o sistema deve responder) deve ser identificado para entender como pessoas, processos e tecnologia, estrutura e a arquitetura estão apoiando os negócios, buscando contribuições da equipe de TI e outras partes interessadas relacionadas, incluindo proprietários de negócios.

Uma análise de lacunas é então realizada para avaliar se há alguma lacuna que impeça de atingir as necessidades de negócios, comparando o estado atual identificado com os resultados desejados.

Se não houver lacuna (ou seja, o estado atual é adequado para atender às necessidades de negócios e resultados desejados), provavelmente não será necessário lançar o projeto de TI. Caso contrário, devem ser identificados os problemas / questões que precisam ser resolvidos para preencher a lacuna.

Podem ser utilizadas técnicas como Análise SWOT (Forças, Fraquezas, Oportunidades e Ameaças) e análise de documentos.

Para avaliar o sistema proposto

BA deve auxiliar a equipe do projeto de TI na avaliação do sistema de TI proposto para garantir que ele atenda às necessidades do negócio e maximize os valores entregues às partes interessadas. BA também deve revisar a prontidão da organização para apoiar a transição para o sistema de TI proposto para garantir uma implementação de sistema sem problemas.

BA deve ajudar a equipe de projeto de TI a determinar se a opção de sistema proposta e o design de sistema de alto nível podem atender às necessidades de negócios e fornecer valor de negócios suficiente para justificar o investimento. Se houver mais de uma opção de sistema, BA deve trabalhar com a equipe de TI para ajudar a identificar os prós e contras de cada opção e selecionar a opção que oferece o maior valor comercial.

Princípios orientadores para modelagem de negócios

O papel principal da modelagem de negócios é principalmente durante o estágio de iniciação e elaboração do projeto e desaparece durante o estágio de construção e transição. Tem a ver principalmente com aspectos analíticos de negócios combinados com mapeamento técnico do aplicativo ou solução de software.

  • Domain and User variation- O desenvolvimento de um modelo de negócios freqüentemente revelará áreas de desacordo ou confusão entre as partes interessadas. O analista de negócios precisará documentar as seguintes variações no modelo atual.

  • Multiple work units perform the same function- Documentar as variações no modelo AS-IS. Isso pode ser divisões ou geografias diferentes.

  • Multiples users perform the same work- Diferentes partes interessadas podem realizar trabalhos semelhantes de maneiras diferentes. A variação pode ser o resultado de diferentes conjuntos de habilidades e abordagens de diferentes unidades de negócios ou o resultado de diferentes necessidades de partes interessadas externas atendidas pela empresa. Documente as variações no modelo AS-IS.

  • Resolution Mechanism- O analista de negócios deve documentar se a solução ToBe acomodará as inconsistências no modelo de negócios atual ou se a solução exigirá padronização. As partes interessadas precisam determinar qual abordagem seguir. O modelo To-Be refletirá sua decisão.

Exemplo de função de BA na modelagem de sistemas ERP

Um analista de negócios deve definir um processo de negócios padrão e configurá-lo em um sistema ERP que é de importância fundamental para uma implementação eficiente. Também é dever de um BA definir a linguagem dos desenvolvedores em linguagem compreensível antes da implementação e, então, utilizar as melhores práticas e mapeá-las com base nos recursos do sistema.

Um requisito para o sistema é a análise de ajuste GAAP, que deve balancear entre -

  • A necessidade de mudanças técnicas, que são os aprimoramentos para se conseguir identidade com a prática existente.

  • Mudanças efetivas, que estão relacionadas à reengenharia de processos de negócios existentes para permitir a implementação da funcionalidade padrão e a aplicação de modelos de processo.

Analista Funcional de Negócios

A especialização no domínio geralmente é adquirida ao longo de um período por estar no “negócio” de fazer coisas. Por exemplo,

  • UMA banking associate ganha conhecimento de vários tipos de contas que um cliente (pessoa física e jurídica) pode operar junto com o fluxo detalhado do processo de negócios.

  • A insurance sales representative pode compreender as várias etapas envolvidas na aquisição de uma apólice de seguro.

  • UMA marketing analyst tem mais chances de compreender as principais partes interessadas e processos de negócios envolvidos em um sistema de Gerenciamento de Relacionamento com o Cliente.

  • Um analista de negócios envolvido em capital marketsO projeto deve ter especialização no assunto e um forte conhecimento de ações, renda fixa e derivativos. Além disso, ele deve ter lidado com back office, front office e exposição prática na aplicação de modelos de gestão de risco.

  • UMA Healthcare Business Analyst é necessário ter conhecimento básico de métricas de utilização e finanças da saúde dos EUA, experiência técnica e compreensão de EDI 837/835/834, diretrizes HIPAA, codificação ICD - 9/10 e códigos CPT, LOINC, conhecimento SNOMED.

Alguns analistas de negócios adquirem conhecimento de domínio testando aplicativos de negócios e trabalhando com os usuários de negócios. Eles criam um ambiente de aprendizagem propício por meio de suas habilidades interpessoais e analíticas. Em alguns casos, eles complementam seu conhecimento de domínio com algumas certificações de domínio oferecidas por AICPCU / ​​IIA e LOMA na área de seguros e serviços financeiros. Existem outros institutos que oferecem certificação em outros domínios.

Outras Atividades Principais

Após um exame completo dos processos de negócios atuais, você pode oferecer assistência altamente profissional na identificação da abordagem ideal de modelagem do sistema.

  • Organizar a elaboração de uma descrição formalizada e uniforme dos processos de negócio de forma a garantir a automação eficiente do sistema.

  • Auxílio às suas equipes no preenchimento de questionários padrão para o sistema em questão, conforme possam ser fornecidos pelos desenvolvedores.

  • São definidos os requisitos de participação em reuniões de trabalho junto dos desenvolvedores.

  • Verifique e controle se os requisitos definidos por você foram devidamente “reproduzidos” e registrados nos documentos que descrevem o futuro modelo no sistema (Blueprints).

  • Elaboração de dados e auxílio na prototipagem do sistema.

  • Auxílio na preparação de dados para migração de listas e saldos no formato exigido pelo sistema.

  • Revisão do protótipo de configuração para conformidade com os requisitos definidos pelos proprietários do processo de negócios.

  • Atuando como recurso de suporte às suas equipes de TI na preparação de dados e desempenho real dos testes funcionais e de integração no sistema.

Na próxima seção, discutiremos brevemente sobre algumas das populares ferramentas de modelagem de negócios usadas por grandes organizações em ambientes de TI.

Ferramenta 1: Microsoft Visio

MS-Visio é um software de desenho e diagramação que ajuda a transformar conceitos em uma representação visual. O Visio fornece formas, símbolos, planos de fundo e bordas predefinidos. Basta arrastar e soltar elementos em seu diagrama para criar uma ferramenta de comunicação profissional.

Step 1 - Para abrir um novo desenho do Visio, vá para o menu Iniciar e selecione Programas → Visio.

Step 2 - Mova o cursor sobre “Business Process” e selecione “Basic Flowchart”.

A captura de tela a seguir mostra as principais seções do aplicativo MS-Visio.

Vamos agora discutir a utilidade básica de cada componente -

A- as barras de ferramentas na parte superior da tela são como outros programas da Microsoft, como Word e PowerPoint. Se você já usou esses programas antes, pode notar algumas funcionalidades diferentes, que exploraremos mais tarde.

Selecionar a Galeria de Diagramas de Ajuda é uma boa maneira de se familiarizar com os tipos de desenhos e diagramas que podem ser criados no Visio.

B- O lado esquerdo da tela mostra os menus específicos para o tipo de diagrama que você está criando. Neste caso, vemos -

  • Formas de seta
  • Backgrounds
  • Formas de fluxograma básico
  • Fronteiras e títulos

C - O centro da tela mostra a área de trabalho do diagrama, que inclui a página do diagrama real, bem como alguns espaços em branco adjacentes à página.

D- O lado direito da tela mostra algumas funções de ajuda. Algumas pessoas podem optar por fechar esta janela para aumentar a área da área de trabalho do diagrama e reabrir as funções de ajuda quando necessário.

Ferramenta 2: arquiteto empresarial

O arquiteto corporativo é uma ferramenta de modelagem e design visual baseada em UML. A plataforma suporta o projeto e construção de sistemas de software, modelando processos de negócios e modelando domínios baseados na indústria. Ele é usado por empresas e organizações não apenas para modelar a arquitetura de seus sistemas. Mas para processar a implementação desses modelos em todo o ciclo de vida de desenvolvimento do aplicativo.

A intenção do arquiteto corporativo é determinar como uma organização pode atingir com mais eficácia seus objetivos atuais e futuros.

O arquiteto corporativo tem quatro pontos de vista que são os seguintes -

  • Business perspective - A perspectiva do negócio define os processos e padrões pelos quais o negócio opera no dia a dia.

  • Application Perspective - A perspectiva da aplicação define as interações entre os processos e padrões usados ​​pela organização.

  • Information Perspective - Isso define e classifica os dados brutos como arquivos de documentos, bancos de dados, imagens, apresentações e planilhas que a organização necessita para operar com eficiência.

  • Technology Prospective - Isso define o hardware, sistemas operacionais, programação e soluções de rede usados ​​pela organização.

Ferramenta 3: Rational Requisite Pro

O processo de obter, documentar, organizar, controlar e alterar os Requisitos e comunicar essas informações às equipes do projeto para garantir que as mudanças iterativas e imprevistas sejam mantidas durante todo o ciclo de vida do projeto.

Monitorar o status e controlar as mudanças na linha de base do requisito. Os elementos primários são controle de mudanças e rastreabilidade.

O Requisite Pro é usado para as atividades acima e propósitos de administração do projeto, a ferramenta é usada para consultar e pesquisar, Visualizando a discussão que fazia parte do requisito.

No Requisite Pro, o usuário pode trabalhar no documento de requisito. O documento é um arquivo MS-Word criado no aplicativo Reqpro e integrado ao banco de dados do projeto. Os requisitos criados fora do Requisite pro podem ser importados ou copiados para o documento.

No Requisite Pro, também podemos trabalhar com rastreabilidade, aqui é uma relação de dependência entre dois requisitos. Rastreabilidade é uma abordagem metódica para gerenciar mudanças, vinculando requisitos que estão relacionados entre si.

O Requisite Pro facilita o rastreamento de alterações em um requisito em todo o ciclo de desenvolvimento, portanto, não é necessário revisar todos os documentos individualmente para determinar quais elementos precisam ser atualizados. Você pode visualizar e gerenciar relacionamentos suspeitos usando uma Matriz de Rastreabilidade ou uma visualização em Árvore de Rastreabilidade.

Os projetos do Requisite Pro nos permitem criar uma estrutura de projeto na qual os artefatos do projeto são organizados e gerenciados. Em cada projeto, o seguinte está incluído.

  • Informações gerais do projeto
  • Packages
  • Informação geral do documento
  • Tipos de documentos
  • Tipos de requisitos
  • Atributos de requisitos
  • Valores de atributos
  • Rastreabilidade entre projetos

O Requisite Pro permite que vários usuários acessem os mesmos documentos e banco de dados do projeto simultaneamente, portanto, o aspecto de segurança do projeto é muito crucial. A segurança evita o uso do sistema, dano potencial ou perda de dados devido ao acesso de usuário não autorizado a um documento do projeto.

Recomenda-se que a segurança esteja habilitada para todos os projetos do RequisitePro. Isso garante que todas as alterações no projeto sejam associadas ao nome de usuário adequado do indivíduo que fez a alteração, garantindo assim que você tenha uma trilha de auditoria completa para todas as alterações.