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

Este Tutorial Explica o Que é Análise de requisitos, Análise de requisitos Passos, Exemplos E Metas de Coleta de requisitos em SDLC:

desenvolvimento de Software é uma monstruosa tarefa que cria um trabalho de produto de software.

o produto de software é construído conforme a exigência de cliente. Principalmente, este produto de software está em conformidade com o que o cliente final/Usuário esperava, enquanto às vezes este produto não está em total conformidade com o que o cliente/usuário final esperava.

o Que É Análise de requisitos?

vamos entender a análise de requisitos com a ajuda de um exemplo.

Cliente/usuário Final expectativa:

Cliente/usuário Final receber:

Como você pode analisar a partir de acima de imagens, que há uma incompatibilidade no produto final e a expectativa do cliente. Isso pode ser devido a inúmeras razões, viz. implementação incorreta dos requisitos do cliente, design defeituoso, 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 errada do produto, o principal motivo vai para a exigência. Portanto, se o entendimento correto dos Requisitos, a captura, a implementação e os testes fossem feitos, isso teria ajudado a mitigar a entrega incorreta e incompleta do produto ao Cliente/Usuário Final.

uma boa entrega de produtos requer a coleta correta de requisitos, o exame eficiente dos Requisitos reunidos e, finalmente, a documentação clara dos Requisitos, como condição prévia. Todo este processo é também chamado de Análise de requisitos no Desenvolvimento de Software Ciclo de Vida (SDLC)

Análise de requisitos Fases/Etapas

Como você pode ver, Análise de requisitos é a primeira atividade em SDLC seguido da Especificação Funcional e assim por diante. A análise de requisitos é um passo vital no SDLC, pois ressoa com testes de aceitação que são críticos para a aceitação do Produto pelos clientes.

neste tutorial, explicaremos 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. reunião de requisitos, que também é chamada de elicitação.
2. isso é seguido pela análise dos 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) reunião de requisitos

para garantir que todas as etapas mencionadas acima sejam executadas adequadamente, requisitos claros, concisos e corretos devem ser coletados do cliente. O cliente deve ser capaz de definir seus requisitos corretamente e o analista de negócios deve ser capaz de coletá-lo 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. Assim, é sempre uma boa ideia envolver todos os stakeholders que poderiam influenciar ou poderiam ser influenciados pelo produto final.

Os possíveis participantes do grupo de Qualidade de Software engineers (ambos de QA e QC), qualquer fornecedor de terceiros, que poderiam dar suporte no projeto, o usuário final para quem o produto se destina, programadores de software, outra equipe dentro da organização que podem fornecer um módulo ou plataforma de software, bibliotecas de software, etc. para o desenvolvimento de produtos.

exemplo: em uma organização, eles desenvolvem um produto ADAS (surround-view camera system para um OEM de prestígio) que precisa de binários AUTOSAR stack e Bootloader recebidos de outro fornecedor.

envolver várias partes interessadas no estágio de coleta de requisitos ajuda a entender várias dependências entre si e qualquer possível conflito futuro pode ser evitado.

às vezes, é uma boa ideia criar um modelo protótipo do produto pretendido planejado e mostrá-lo ao cliente. Esta é uma excelente maneira de transmitir aos clientes qual produto eles estão esperando e como pode parecer mais tarde. Isso ajuda o cliente a visualizar o produto que está esperando e ajuda-o a apresentar requisitos claros.

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

1. um produto semelhante que os clientes pretendiam, existe dentro da organização.
2. novo produto a ser desenvolvido.

(i) 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 de visão surround desenvolvido para um OEM (GM, Volkswagen, BMW, etc.) e pode ser apresentado a outro OEM.

observe que não é aconselhável mostrar o produto / proto ao cliente que está em desenvolvimento, pois pode violar o contrato de não divulgação assinado com outro cliente para quem esse produto está sendo desenvolvido. Também pode resultar em uma briga legal desnecessária.

outro exemplo poderia ser o do sistema de infoentretenimento, sendo desenvolvido pela organização, e já está no mercado. 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 IHM tangível, portas de conector de dispositivo, sandbox, etc.

isso ajudará o cliente a entender como o produto final ficaria e fornecer seus requisitos com muito mais clareza.

(ii) o segundo caso pode ser alcançado criando um modelo de Trabalho Básico Fazendo codificação e montagem simples (principalmente os recursos aqui são codificados em programas de software), ou criando um fluxograma ou diagrama que poderia convencer o cliente como o produto ficaria.

em qualquer caso, seria um respiro para o processo de coleta de requisitos, pois o cliente agora sabe o que quer.

O analista de negócios podem agora organizar um requisito formal elicitação de reuniões, onde todos os interessados poderão ser convidados e, portanto, pode anotar os vários requisitos fornecidos pelo cliente (em alguns casos, se os atores são mais em número, um escriba poderia ser nomeado para anotar os requisitos do cliente ou usuário histórias para que o analista de negócios pode concentrar-se em moderar a reunião).

os requisitos reunidos 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. Histórias de usuários são basicamente um conjunto de entradas de clientes em sua linguagem natural.

exemplo de coleta de requisitos: no sistema de câmera adas surround-view, uma possível história de usuário poderia ser:”como usuário, eu deveria ser capaz de ver o que está lá no retrovisor do meu carro”.

pode haver muitas perguntas “Por Que” feitas em cada história de usuário, o que ajudará o cliente a fornecer informações mais detalhadas sobre o requisito.

acima de história de usuário, se um cliente diz “Como um usuário, eu deveria ser capaz de ver o que está lá no retrovisor do meu carro”, perguntando “por que” poderia dar “Como um usuário, eu deveria ser capaz de ver o que está lá no retrovisor do meu carro, de modo que eu posso estacionar o meu carro com segurança”.

fazer a pergunta “por que” também ajuda na criação de requisitos objetivos e atômicos a partir de declarações de linguagem natural gigantescas fornecidas pelo cliente. Isso pode ser facilmente implementado posteriormente no código.

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 diz o que se espera das entradas do Usuário.

exemplo:

#2) analisando requisitos reunidos

pós coleta de requisitos, a análise dos Requisitos começa. Nesta fase, várias partes interessadas se sentam e fazem uma sessão de brainstorming. Eles analisam os requisitos reunidos e buscam viabilidade para implementá-los. Eles discutem uns com os outros e qualquer ambiguidade é resolvida.

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

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

exemplo: os clientes podem pedir para cercar-ver o sistema de Câmera com um recurso de Câmera Retrovisor que ajudará no estacionamento do carro. O cliente também pode solicitar o recurso de engate do Trailer, que também usa a câmera traseira para funcionar.

se o CLIENTE declarar a exigência de que a câmera retrovisor para assistência ao estacionamento funcione o tempo todo, sem exceção, o recurso de reboque nunca funcionará e vice-versa.

(II) um analista de negócios pode ter entendido a exigência do cliente de forma diferente de como um programador teria interpretado.

como os programadores pensam como especialistas técnicos, é sempre possível que os requisitos do cliente sejam convertidos incorretamente em especificações funcionais que posteriormente serão feitas incorretamente em documentos de arquitetura e design e posteriormente em código. O impacto é exponencial e, portanto, deve ser verificado.

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

#3) documentando os requisitos analisados

uma vez que a análise dos Requisitos é feita, a documentação do requisito é iniciada. Vários tipos de requisitos saem da análise de requisitos.

alguns destes são:

(i) Especificação da exigência de cliente.

(ii) exigência de arquitetura de Software.

exemplo:

(iii) exigência do projeto de Software.

exemplo:

(iv) Especificação Funcional da exigência (derivada diretamente das especificações do cliente.)

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

(v) especificação de requisito não funcional (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”.

(vi) requisitos da Interface do Usuário.

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

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

vamos agora olhar para o processo de conversão de requisitos de Negócios Para Requisitos de Software (funcional e não-funcional).

Converter Requisitos de negócios em requisitos de Software

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. Desenvolver todo o sistema de software com base nesses requisitos não é possível, pois uma descrição detalhada de como o sistema ou componente de software será implementado não é mencionada.

assim, os requisitos de negócios devem ser divididos em requisitos de software mais detalhados que serão mais detalhados para 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 para histórias de usuários detalhadas.
2. derivando um fluxograma para definir o fluxo de atividades.
3. fornecendo 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. definir 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 de widget de navegação do sistema de Infotainment 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 para histórias de usuários detalhadas.

vamos converter esse requisito de negócios em uma história de usuário de alto nível: “como usuário, devo ser capaz de Acessar a caixa do widget de navegação para que eu possa inserir o endereço de destino”. Esta história de usuário conta o que é necessário para o usuário final. Vamos tentar definir como implementar esse requisito.

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

1. quem são os usuários?
2. Como posso acessar a navegação, a bordo (do cartão SD) ou do SmartPhone?
3. que tipo de entradas de destino posso inserir?
4. devo entrar no destino mesmo quando o carro está no estacionamento?

estas são histórias de Usuários de nível mais detalhado 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. Vamos tomar (não. 3):

1. posso inserir entradas de destino como Coordenadas geográficas, endereço Postal, via reconhecimento de fala, etc.?
2. preciso de GPS para inserir Coordenadas geográficas?
3. posso inserir o endereço de destino atual pesquisando no histórico de endereços?

#2) derivando 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 detalhadas de Usuários de baixo nível e no 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 seg.
• o teclado de entrada de destino deve ter caracteres alfanuméricos e símbolos especiais.
• o botão de alternância ativar/desativar GPS deve estar presente na tela de entrada de destino de navegação.

as informações acima satisfazem as histórias do Usuário e tornam possível que o requisito seja testado de forma discreta e mensurável, evitando qualquer confusão com o requisito enquanto está sendo implementado como recursos.

#4) diagramas de Wireframe para explicar o fluxo de trabalho dos objetos.

do caso de uso acima, derivaremos 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 são identificados requisitos funcionais que dizem como um sistema se comportará com 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 driver (usuário final) do carro toca música de USB e orientação de navegação está em andamento, também recebe uma chamada via Bluetooth no modo mãos-livres, em seguida, carregar na CPU e consumo de RAM aumenta para um nível máximo como vários processos estão sendo executados em segundo plano.

neste ponto, se o driver tocar em uma interface touchscreen do sistema de infotainment para rejeitar a chamada recebida via SMS de resposta automática (da mesma forma que fazemos em nossos telefones celulares), o sistema deve ser capaz de executar esta tarefa e não deve travar ou travar. Este é o desempenho do sistema quando a carga é alta e testamos disponibilidade e confiabilidade.

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

tome um exemplo, o sistema de infotainment recebe de volta para trás SMSs (talvez 20 SMS dentro de 10 seg) via telefone Bluetooth conectado. O sistema de Infotainment deve ser capaz de lidar com todos os SMS recebidos e em nenhum momento deve perder qualquer uma das notificações SMS recebidas no Infotainment HMI.

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

Entendimento de Requisitos Não-funcionais os Casos de

a tabela A seguir explica os requisitos não-funcionais:

requisitos Não – funcionais, ao contrário de requisitos funcionais, faça o ciclo de vida completo de um projeto para ser implementado, pois eles 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 detalhados de baixo nível que ajudam na implementação do sistema de software.Vamos analisar 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 perdida durante a análise de requisitos e pego 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 ele vem do mercado como uma chamada de retorno (em 2017, EUA cobrado para o condutor fabricante, Takata uma 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, preparando 5 Por Que documentos, análise de árvore de falhas, documento 8D, etc. em vez de se concentrar no desenvolvimento de software e na qualidade.

na pior das hipóteses, a organização seria arrastada para ações judiciais movidas pelo cliente se o recurso afetado for relacionado à segurança/segurança, como acesso à segurança, airbag, ABS (Sistema de frenagem antibloqueio), etc.