O que é análise e coleta de requisitos no SDLC?

what is requirement analysis

Este tutorial explica o que é análise de requisitos, etapas de análise de requisitos, exemplos e metas de coleta de requisitos no SDLC:

O desenvolvimento de software é uma tarefa gigantesca que cria um produto de software funcional.

O produto de software é construído de acordo com os requisitos do cliente. Em geral, este produto de software está em conformidade com o que o cliente / usuário final esperava, enquanto às vezes este produto não cumpre totalmente com o que o cliente / usuário final esperava.

O que você aprenderá:

• O que é análise de requisitos?
  • Estágios / etapas de análise de requisitos
    • # 1) Coleta de requisitos
    • # 2) Análise dos requisitos coletados
    • # 3) Documentação de requisitos analisados
  • Convertendo Requisitos de Negócios em Requisitos de Software
  • Compreendendo casos de requisitos não funcionais
  • Diferença entre requisitos de negócios e requisitos de software
• Conclusão
  • Leitura recomendada

O que é análise de requisitos?

Vamos entender a Análise de Requisitos com a ajuda de um exemplo.

Expectativa do cliente / usuário final:

O cliente / usuário final recebe:

Como você pode analisar pelas imagens acima, existe uma incompatibilidade no produto final com a expectativa do cliente. Isso pode ser devido a inúmeras razões, viz. implementação incorreta dos requisitos do cliente, design com falha, uma compreensão errada dos requisitos do cliente por programadores e equipe de qualidade, etc.

No entanto, como você pode ver, seja por qualquer motivo para a entrega incorreta do produto, o motivo principal vai para a exigência. Portanto, se a compreensão, captura, implementação e teste corretos dos requisitos fossem realizados, isso teria ajudado a mitigar a entrega incorreta e incompleta do produto ao cliente / usuário final.

Uma boa entrega de produto requer a coleta correta de requisitos, o exame eficiente dos requisitos que são reunidos e, finalmente, uma documentação clara dos requisitos, como pré-condição. Todo esse processo também é chamado de Análise de requisitos no ciclo de vida de desenvolvimento de software (SDLC)

Estágios / etapas de análise de requisitos

Como você pode ver, a Análise de Requisitos é a primeira atividade no SDLC seguida pela Especificação Funcional e assim por diante. A análise de requisitos é uma etapa vital no SDLC, pois ressoa com os testes de aceitação que são essenciais para a aceitação do produto pelos clientes.

Neste tutorial, vamos explicar como a análise de requisitos é feita no SDLC. Também veremos as várias etapas envolvidas, resultados, desafios e medidas corretivas na análise de requisitos.

A análise de requisitos começa com:

1. Recolha de requisitos que também é chamado de elicitação.
2. Isso é seguido por analisando os requisitos coletados para entender a correção e a viabilidade de converter esses requisitos em um possível produto.
3. E finalmente, documentando os requisitos coletados.

# 1) Coleta de requisitos

Para garantir que todas as etapas mencionadas acima sejam executadas de forma apropriada, requisitos claros, concisos e corretos devem ser obtidos do cliente. O cliente deve ser capaz de definir seus requisitos de forma adequada e o analista de negócios deve ser capaz de coletá-los da mesma forma que o cliente pretende transmitir.

Muitas vezes não é possível que a coleta de requisitos seja feita de forma eficiente por analistas de negócios do cliente. Isso pode ser devido à dependência de muitas pessoas relacionadas ao produto final esperado, ferramentas, ambiente, etc. Portanto, é sempre uma boa ideia envolver todas as partes interessadas que podem influenciar ou podem ser influenciadas pelo produto final.

O possível grupo de partes interessadas pode ser engenheiros de qualidade de software (tanto QC quanto QA), qualquer fornecedor terceirizado que possa fornecer suporte no projeto, usuário final para quem o produto se destina, programadores de software, outra equipe dentro da organização que pode fornecer um módulo ou plataforma de software, bibliotecas de software, etc. para desenvolvimento de produto.

Exemplo: Em uma organização, eles desenvolvem um produto ADAS (sistema de câmera surround-view para um OEM de prestígio) que precisa Pilha automática e Bootloader binários recebidos de outro fornecedor.

Envolver várias partes interessadas no estágio de coleta de requisitos ajuda a compreender as várias dependências umas das outras e qualquer possível conflito futuro pode ser evitado.

Às vezes, é uma boa ideia criar um modelo de protótipo do produto pretendido planejado e mostrá-lo ao cliente. Essa é uma excelente maneira de transmitir aos clientes qual produto eles estão esperando e qual será sua aparência mais tarde. Isso ajuda o cliente a visualizar o produto que está esperando e a apresentar requisitos claros.

A criação deste protótipo depende de dois tipos de produto:

1. Um produto semelhante pretendido pelos clientes existe dentro da organização.
2. Novo produto a ser desenvolvido.

(eu) No primeiro caso, é mais fácil mostrar ao cliente como seria o produto final e como seria desenvolvido. No ADAS automotivo, é possível mostrar aos clientes outro produto que já está no mercado e foi desenvolvido dentro da organização.

Por exemplo, Um sistema de câmera surround-view desenvolvido para um OEM (GM, Volkswagen, BMW, etc.) e pode ser exibido para outro OEM.

Observe , não é aconselhável mostrar o produto / proto produto ao cliente que está em desenvolvimento, pois isso pode violar o Acordo de Não Divulgação assinado com outro cliente para o qual o produto está sendo desenvolvido. Isso também pode resultar em uma disputa legal desnecessária.

Outro exemplo pode ser o do sistema de infoentretenimento, em desenvolvimento pela organização e que já está no mercado. Os analistas de negócios e outras partes interessadas dentro de uma organização podem planejar uma demonstração de workshop para o cliente, exibindo sistemas de infoentretenimento com HMI tangível, portas de conector de dispositivo, sandbox, etc.

Isso ajudará o cliente a entender como seria a aparência do produto final e fornecerá seus requisitos com muito mais clareza.

(ii) O segundo caso pode ser alcançado criando um modelo básico de trabalho fazendo codificação e montagem simples (a maioria dos recursos aqui são codificados em programas de software) ou criando um fluxograma ou diagrama que poderia convencer o cliente sobre a aparência do produto.

Em qualquer caso, seria uma pausa para o processo de coleta de requisitos, pois o cliente agora sabe o que deseja.

O analista de negócios agora pode organizar reuniões formais de elicitação de requisitos, onde todas as partes interessadas podem ser convidadas e, assim, pode anotar os vários requisitos fornecidos pelo cliente (em alguns casos, se as partes interessadas forem mais numerosas, um escriba separado pode ser nomeado para anotar o cliente requisitos ou histórias de usuário para que o analista de negócios possa se concentrar em moderar a reunião).

Os requisitos recolhidos podem ser na forma de histórias de usuários (em desenvolvimento ágil), casos de uso, documentos de linguagem natural do cliente, diagramas, fluxogramas, etc. As histórias de usuários estão se tornando populares no ciclo de vida de desenvolvimento de software moderno. As histórias de usuário são basicamente um conjunto de entradas do cliente em sua linguagem natural.

Exemplo de coleta de requisitos: No sistema de câmera de visão surround ADAS, uma possível história de usuário poderia ser: “Como um usuário, devo ser capaz de ver o que há no retrovisor do meu carro”.

Pode haver muitos 'porque,' perguntas feitas em cada história de usuário, o que ajudará o cliente a fornecer informações mais detalhadas sobre o requisito.

Na história do usuário acima, se um cliente disser 'Como um usuário, devo ser capaz de ver o que há no retrovisor do meu carro', fazendo uma pergunta 'porque ”Poderia dar“ Como um usuário, devo ser capaz de ver o que há no retrovisor do meu carro, para que eu possa estacionar meu carro com segurança ”.

Fazendo a pergunta 'porque' também ajuda na criação de requisitos objetivos e atômicos a partir de enormes declarações em linguagem natural fornecidas pelo cliente. Isso pode ser facilmente implementado posteriormente no código.

melhor software de máquina virtual para windows

Outra forma de reunir o requisito é na forma de casos de uso . Um caso de uso é uma abordagem passo a passo para alcançar um determinado resultado. Isso não diz como o software funcionará na entrada do usuário, mas sim o que se espera das entradas do usuário.

Exemplo:

# 2) Análise dos requisitos coletados

Coleta de requisitos pós, análise de requisitos começa. Nesta fase, várias partes interessadas sentam e fazem uma sessão de brainstorming. Eles analisam os requisitos recolhidos e procuram viabilidade para implementá-los. Eles discutem entre si e qualquer ambiguidade é resolvida.

Esta etapa é importante no processo de análise de requisitos devido aos seguintes motivos principais:

(eu) O cliente pode fornecer alguns requisitos que podem ser impossíveis de implementar devido a várias dependências.

Exemplo: Clientespode pedir para visualizar o sistema de câmera com um recurso de câmera retrovisor que ajudará em estacionamento o carro. O cliente também pode solicitar o Reboque recurso de engate que também usa a câmera traseira para funcionar.

Se o cliente declarar a necessidade de que a câmera retrovisor para estacionamento a assistência deve funcionar em todos os momentos, sem exceção, então o Reboque recurso nunca funcionaria e vice-versa.

(ii) Um analista de negócios pode ter entendido o requisito do cliente diferente de como um programador teria interpretado.

Uma vez que os programadores pensam como especialistas técnicos, é sempre possível que os requisitos do cliente sejam incorretamente convertidos em especificações funcionais que mais tarde serão incorretamente transformadas em documentos de arquitetura e design e, subsequentemente, em código. O impacto é exponencial e por isso deve ser verificado.

Uma possível medida corretiva poderia ser seguindo um método ágil de desenvolvimento de software, seguindo casos de uso que o cliente fornece, etc.

# 3) Documentação de requisitos analisados

Assim que a análise dos requisitos for concluída, a documentação dos requisitos é iniciada. Vários tipos de requisitos resultam da análise de requisitos.

Alguns deles são:

(eu) Especificação de requisitos do cliente.

(ii) Requisito de arquitetura de software.

Exemplo:

(iii) Requisito de design de software.

Exemplo:

como abrir um arquivo jar com java

(4) Especificação de requisitos funcionais (derivada diretamente das especificações do cliente).

Exemplo: “Quando o usuário toca no ícone do Bluetooth no Infotainment HMI, a tela do Bluetooth deve ser exibida”

(v) Especificação de requisitos não funcionais (viz. Desempenho, estresse, carga, etc.).

Exemplo: “Deve ser possível emparelhar 15 dispositivos Bluetooth com sistema de infoentretenimento sem degradação do desempenho do sistema”.

(nós) Requisitos de interface do usuário.

Exemplo: “Na tela do sintonizador FM, deve ser fornecido um botão para selecionar diferentes estações”

Os requisitos acima são registrados e documentados em ferramentas de gerenciamento de requisitos, como IBM DOORS, HP QC. Às vezes, as organizações têm suas ferramentas personalizadas de gerenciamento de requisitos para reduzir custos.

Vamos agora dar uma olhada no processo de conversão Requisitos de negócio para Requisitos de software (funcional e não funcional).

Convertendo Requisitos de Negócios em Requisitos de Software

Os requisitos de negócios, conforme discutido acima, são requisitos de alto nível que falam sobre o que o usuário final deseja de uma ação definida no sistema de software. Não é possível desenvolver todo o sistema de software com base nesses requisitos, pois não é mencionada uma descrição detalhada de como o sistema ou componente de software será implementado.

Portanto, os requisitos de negócios devem ser divididos em requisitos de software mais detalhados que serão detalhados em requisitos funcionais e não funcionais.

Para fazer isso, as seguintes etapas podem ser seguidas:

1. Divida os requisitos de negócios de alto nível em histórias de usuário detalhadas.
2. Derivando um fluxograma para definir o fluxo de atividades.
3. Fornecer a condição que justifica as histórias de usuário derivadas.
4. Diagramas de wireframe para explicar o fluxo de trabalho dos objetos.
5. Definição de requisitos não funcionais fora dos requisitos de negócios.

Vamos começar tomando um exemplo de sistema de infoentretenimento automotivo.

O requisito de negócios diz: “O usuário final deve ser capaz de acessar a caixa do widget de navegação do sistema de informação e lazer HMI e deve ser capaz de definir o endereço de destino”.

Portanto, as etapas listadas acima podem ser implementadas como:

# 1) Divida os requisitos de negócios de alto nível em histórias de usuário detalhadas.

Vamos converter esse requisito de negócios em uma história de usuário de alto nível, “ Como usuário, devo poder acessar a caixa do widget de navegação para inserir o endereço de destino ”. Esta história de usuário conta o que é necessário para o usuário final. Tentaremos definir como implementar este requisito.

Vamos começar fazendo possíveis perguntas a esta viz de história de usuário.

1. Quem são os usuários?
2. Como posso acessar o Navigation, onboard (do cartão SD) ou do SmartPhone?
3. Que tipo de entradas de destino posso inserir?
4. Devo ter permissão para entrar no destino mesmo quando o carro está no estacionamento?

Essas são histórias de usuários de nível mais detalhadas derivadas de histórias de usuários de alto nível e nos ajudariam a obter mais informações sobre nossos requisitos de negócios.

Neste ponto, podemos pegar uma das sub-histórias do usuário e começar a questionar. Deixe-nos levar (no. 3):

1. Posso inserir entradas de destino, como coordenadas geográficas, endereço postal, por reconhecimento de voz, etc.?
2. Preciso de GPS para inserir geo-coordenadas?
3. Posso inserir o endereço de destino atual pesquisando no histórico de endereços?

# 2) Derivar um fluxograma para definir o fluxo de atividades.

Agora podemos ver que o requisito de negócios é dividido em casos de uso muito detalhados que podem ser marcados no fluxograma como abaixo:

# 3) Fornecer condições que justifiquem histórias de usuários derivadas.

Podemos ver que informações mais detalhadas estão surgindo devido à decomposição do requisito de negócios de alto nível em histórias de usuário de baixo nível detalhadas e ao fluxograma. A partir deste fluxograma, podemos obter os detalhes técnicos necessários para a implementação viz.

• O tempo de carregamento da tela para exibir a entrada de destino deve ser de 1 segundo.
• O teclado de entrada de destino deve ter caracteres alfanuméricos e símbolos especiais.
• O botão ativar / desativar GPS deve estar presente na tela de entrada do destino de navegação.

As informações acima satisfazem as histórias de usuários e possibilitam que o requisito seja testado de forma discreta e mensurável, evitando qualquer confusão com o requisito ao ser implementado como recursos.

# 4) Diagramas de wireframe para explicar o fluxo de trabalho dos objetos.

Do caso de uso acima, iremos derivar um diagrama de wireframe que tornará a interface do usuário mais clara.

# 5) Definição de requisitos não funcionais fora dos requisitos de negócios.

É imperativo que os requisitos de software detalhados sejam derivados de requisitos de negócios de alto nível, mas muitas vezes apenas os requisitos funcionais são identificados, o que indica como um sistema se comportará para uma determinada entrada / ação do usuário.

No entanto, os requisitos funcionais não esclarecem o desempenho dos sistemas e outros parâmetros qualitativos como disponibilidade, confiabilidade, etc.

Exemplos:

a) Tomaremos o exemplo do sistema de infoentretenimento automotivo acima.

Se o motorista (usuário final) do carro reproduz música de USB e a orientação de navegação está em andamento, também recebe uma chamada via Bluetooth no modo mãos-livres e carrega na CPU e o consumo de RAM aumenta para um nível máximo conforme vários processos rodando em segundo plano.

Neste ponto, se o motorista tocar em uma interface de tela sensível ao toque do sistema de infoentretenimento para rejeitar uma chamada recebida via SMS de resposta automática (da mesma forma que fazemos em nossos telefones celulares), o sistema deve ser capaz de realizar esta tarefa e não deve travar ou travar. Este é o desempenho do sistema quando a carga é alta e testamos a disponibilidade e a confiabilidade.

b) Outro caso é o cenário de estresse.

Tomemos um exemplo, o sistema de infoentretenimento recebe SMSs consecutivos (talvez 20 SMS em 10 segundos) através do telefone Bluetooth conectado. O sistema de informação e lazer deve ser capaz de lidar com todos os SMS recebidos e em nenhum momento deve perder nenhuma notificação de SMS recebida na HMI de informação e lazer.

Os exemplos acima são casos de requisitos não funcionais que não puderam ser testados apenas por meio dos requisitos funcionais. Embora às vezes, os clientes deixem de fornecer esses requisitos não funcionais. É responsabilidade da organização fornecer-lhes essas informações, quando um produto é entregue ao cliente.

Compreendendo casos de requisitos não funcionais

A tabela abaixo explica os requisitos não funcionais:

Os requisitos não funcionais, ao contrário dos requisitos funcionais, levam todo o ciclo de vida de um projeto para serem implementados, pois são implementados de forma incremental nos respectivos Sprints Ágeis ou em diferentes iterações.

Portanto, é assim que derivamos os Requisitos de Software dos Requisitos de Negócios.

Diferença entre requisitos de negócios e requisitos de software

Vimos acima como derivar requisitos de software de requisitos de negócios de alto nível. Os requisitos de software permitem que o programador e o engenheiro de teste desenvolvam o sistema e o testem com eficiência. Portanto, agora sabemos que os requisitos de negócios são requisitos de linguagem natural do cliente de alto nível, enquanto os requisitos de software são requisitos de baixo nível detalhados que ajudam na implementação do sistema de software.

Vejamos a diferença detalhada entre os dois tipos de requisitos.

Conclusão

A análise de requisitos é a espinha dorsal de qualquer modelo SDLC.

Um problema perdido durante a análise de requisitos e detectado no teste de unidade pode custar dezenas de milhares de dólares para uma organização e esse custo pode levar a milhões de dólares se vier do mercado como um retorno de chamada (em 2017, fabricante de airbag cobrado dos EUA, Takata a multa de US $ 1 bilhão devido à explosão de airbags).

A organização acabaria realizando tarefas de controle de danos, como análise de causa raiz, preparação de 5 documentos de porquê, análise de árvore de falhas, documento 8D, etc. em vez de se concentrar no desenvolvimento e qualidade de software.

No pior dos casos, a organização seria arrastada para ações judiciais movidas pelo cliente se o recurso afetado for relacionado à segurança / proteção, como acesso de segurança, airbag, ABS (sistema de travagem antibloqueio), etc.

Leitura recomendada

• Fases, metodologias, processos e modelos SDLC (ciclo de vida de desenvolvimento de software)
• Características dos requisitos funcionais e requisitos não funcionais
• Como testar a especificação de requisitos de software (SRS)?
• 5 erros mortais no gerenciamento de requisitos e como superá-los
• Como testar um aplicativo sem requisitos?
• Medidas para SSDLC (ciclo de vida de desenvolvimento de software seguro)
• Modelo espiral - O que é modelo espiral SDLC?
• O que é SDLC Waterfall Model?