Levantamento e Análise de Requisitos

Engenharia de Requisitos

Antes de entendermos como faz um bom levantamento e análise de requisitos, temos que entender que existe uma engenharia por trás, estudos e padrões complexos criado para que as informações do software seja coletado da maneira mais eficiente possível.

Processos de Engenharia de Requisitos

• Estudo e viabilidade — avaliar se o projeto é útil
• Levantamento de requisitos — atividade na qual os requisitos do sistemas a ser desenvolvido são levantados, tendo como perspectiva a visão do cliente
• Análise de requisitos — atividade na qual os requisitos são analisados e confirmados pelos stakeholders, tendo o ponto de vista técnico. Nesse momento é melhor detalhado os requisitos
• Especificação de requisitos — verificação (construído de forma correta) e validação (atende requisitos do cliente) do documento
• Gerenciamento de requisitos — processo de compreensão e controle das mudanças nos requisitos do sistema

Levantamento de Requisitos

É abordado a compreensão do problema e a necessidade do cliente. O objetivo é alinhar a visão do problema entre o usuário e os desenvolvedores, nessa etapa também é comum descobrir o que o sistema deve ou não fazer. É nessa etapa que o Analista de Sistemas é o responsável por fazer essa tradução entre o que o cliente deseja para o desenvolvedor. Juntos (Analista de Sistemas e Cliente) tentam definir as necessidades (requisitos).

Dentro desse processo, há uma engenharia para definir, documentar e manter os requisitos, incluindo técnicas, métodos e procedimentos para atender e gerenciar as necessidades do usuário relacionados ao sistema em estudo. Quando a comunicação não é bem-sucedida, o restante do projeto corre o risco de sofrer impactos durante o desenvolvimento. O SRS é um documento que descreve todas as características do produto e concentra todas as principais informações do projeto.

Os requisitos podem se originar de várias fontes e é papel do analista de sistema organizar e documentar todo esse levantamento

Todas as partes interessadas — incluindo clientes, vendedores, especialista de setor, desenvolvedor devem colaborar para juntar as informações necessárias. Lemebre-se de ser preciso ao descrever os requisitos; quanto mais detalhado for, melhor.

Técnicas para levantar um requisito

Há diversas técnicas para utilizar na etapa de descoberta de requisitos, podem ser estruturadas e metódicas ou até mesmo simples ações. Todas com um único objetivo: elencar todos os requisitos do sistema.

Entrevistas

Processo pode ser formal ou informal. Para a coleta de informação são feitas perguntas e os requisitos são encontrados nas resposta do entrevistado. As entrevistas podem seguir dois tipos, fechada (perguntas definidas anteriormente) e aberta (não há roteiro definido).

Levantamento orientado a ponto de vista

Consideração de vários pontos de vistas de diversos usuários envolvidos no projeto. O risco desse tipo de levantamento será o conflito entre requisitos.

Etnografia

Identifica os requisitos dentro do ambiente de trabalho dos usuários. o analista faz imersão no dia-a-dia e pode conhecer “pessoalmente” as necessidades dos clientes baseadas em suas necessidades reais. É uma boa alternativa para aplicativos que possuem processos longos ou em que o cliente não consiga expressa de forma detalhada.

Prototipagem

A prototipagem busca identificar as necessidades de forma rápida e visual. Sua vantagem é redução de risco na construção do sistema, uma vez que o usuário já verificou o que o analista captou nos requisitos dos produtos.

Brainstorming

Explosão de ideias. Reunião que permite que as pessoas sugiram ideias. Há duas fases, geração e avaliação.

• Geração: coletadas, não devem ser criticadas nem avaliadas.
• Avaliação: coletadas e discutidas.

O que é o SRS?

Um documento de requisito do sistema (System Requirement Software) é essencial para o desenvolvimento de software. Ele fornece uma descrição detalhada das necessidades e do requisitos de um projeto específico. Ele descreve os objetivos, escopos, informações básicas, detalhes do projeto, plano de implementação e outras atividades relacionadas.

Esse documento é importante pois serve como um contrato entre o cliente e o desenvolvedor para garantir que ambas as partes entendam as especificações e expectativas do produto que está sendo desenvolvido, além de tudo também ajuda a reduzir os riscos de novos ajustes e demandas durante a fase de desenvolvimento. Desse modo, contém o escopo de requisitos funcionais e não funcionais do sistema, deve ser claro, consistente e completo pois é usado no contrato com o cliente.

Contribuição do SRS no Levantamento de Requisitos

Nessa etapa ainda não existe a criação formal desse documento. Essa fase foca na coleta e descoberta que prepara o terreno para a análise e documentação dos requisitos.

Por isso é recomendado que exista uma preparação para essa reunião de levantamento. Utilize template de requisitos, faça pós-reuniões para revisar as anotações e garantir que todos os pontos foram definidos corretamente e utilize as demais abordagens para que sua base seja eficiente para a análise.

Análise de Requisitos

Essa etapa permite compreender a real necessidade do projeto e diminuir o espaço que existe entre as expectativas e compreensão dos desenvolvedores. Essa análise diminui a chance de retrabalho e permite estimar os custos e prazos de projetos muito mais próximo do real. Essas informações também são importantes para a melhor escolha do modelo do desenvolvimento.

É a fase onde você refina e documenta os requisitos coletados, detalhando:

• Requisitos Funcionais e Não Funcionais
• Restrições e Dependências
• Casos de Uso e Histórias do Usuário

Como Refinar SRS

O refinamento de uma SRS depende do tipo de proposta e de projeto. Existem diversos métodos e formas de fazer um SRS.

Importância do SRS na Escolha do Modelo do Processo

O SRS fornece uma visão clara e detalhada do que o software deve fazer. Ter um documento de requisitos bem definido ajuda a escolher o modelo de processo de desenvolvimento que melhor atende às necessidades do projeto. Depois de ter o SRS bem definido, a escolha do modelo do ciclo de vida de desenvolvimento deve considerar adaptabilidade às mudanças, complexidade do projeto e envolvimento de stakeholders.