Requisitos de software são as descrições de serviços, funcionalidades e restrições que um sistema deve oferecer. O levantamento de requisitos de um sistema é feito nas etapas iniciais de um projeto de software, antes da concepção do produto em si. É no levantamento que elucidamos junto aos clientes e usuários do sistema quais são as necessidades da aplicação, portanto, é crucial que todos os envolvidos estejam alinhados sobre essas necessidades e que os requisitos estejam bem escritos e de fácil entendimento.
Entretanto, escrever bons requisitos é algo complexo. As necessidades dos clientes mudam a todo momento, em parte porque vivemos em um mundo por si só instável e em constante mudança. Além disso, em muitas empresas não temos apenas um desenvolvedor responsável pelo sistema, e sim toda uma equipe, e cada pessoa pode ter um entendimento diferente de algo que foi solicitado pelo usuário. E mais, muitas vezes o próprio cliente não tem certeza sobre o que ele precisa!
Pensando pelo lado do desenvolvedor de software, caso trabalhar em time ágil o desenvolvedor não será apenas a pessoa que escreve código, ele também irá participar de outras etapas do ciclo de vida do software, podendo realizar suas contribuições. E mesmo que não participe, também cabe à ele ter um olhar crítico ao receber uma tarefa para ser desenvolvida, não apenas fazendo o que está escrito, mas avaliando se de fato aquilo faz sentido e agrega valor. Além disso, caso os requisitos não sejam atendidos de forma satisfatória, irá gerar um retrabalho ao desenvolvedor posteriormente.
Por isso, existem as técnicas e processos de modelagem dos sistemas e criação de requisitos que nos auxiliam no entendimento do problema, na avaliação dos riscos e definição da solução, de uma maneira que seja mais fácil unir todas as informações necessárias e com maior precisão.
O processo de escrita de requisitos pode envolver várias etapas, sendo as principais: Levantamento, Registro, Validação e Verificação. A forma que será implementado depende da empresa e das necessidades do sistema.
De forma resumida, temos dois tipos principais de requisitos:
Requisitos de usuário:
São declarações em linguagem natural com diagramas, de quais serviços são esperados do sistema e as restrições sob as quais ele deve operar, escritos para serem lidos por qualquer usuário.Requisitos de sistema:
Definem as funções, os serviços e as restrições operacionais do sistema, de forma precisa e pontuando exatamente o que será implementado, e são escritos para serem lidos por usuários finais, arquitetos de sistemas e desenvolvedores.
Exemplo de requisito de usuário e de sistema de biblioteca:
Requisito de usuário
O usuário irá acessar o acervo da biblioteca e realizar a busca de livros, com base em diferentes critérios de pesquisa.
Requisitos de sistema
1 - O sistema deve permitir que os usuários filtrem sua busca por título do livro, categoria, data de publicação, autor e disponibilidade.
2 - Após a pesquisa, serão exibidos os resultados apresentando as informações resumidas de título, autor, categoria e disponibilidade.
3 - O sistema deverá possuir a opção de ordenação dos resultados de pesquisa por ordem alfabética, publicação mais recente e publicação mais antiga.
Os requisitos(de usuário ou de sistema) também podem ser classificados em requisitos funcionais, requisitos não funcionais e requisitos de domínio.
- Requisitos funcionais: São declarações das funcionalidades do sistema e de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Também podem estabelecer explicitamente o que o sistema não deve fazer.
O exemplo de requisitos de usuário e de sistema de biblioteca mencionado anteriormente, se tratam de requisitos funcionais.
- Requisitos não funcionais: São restrições sobre os serviços ou as funções oferecidos pelo sistema. Normalmente, aplicam-se ao sistema como um todo e incluem restrições de timing, restrições sobre o processo de desenvolvimento e padrões, restrições técnicas, etc.
Exemplo de requisito não funcional do sistema de biblioteca:
Ao realizar a pesquisa por títulos na biblioteca, o tempo de resposta da consulta não deve exceder 3 segundos em condições normais de uso.
- Requisitos de domínio São provenientes do domínio da aplicação, refletem as características e as restrições desse domínio. Podemos pensar como aquilo que é comum a todos os sistemas daquele nicho. No caso de uma biblioteca, um requisito de domínio poderia se referir ao empréstimo de livros, algo que é comum a toda biblioteca.
Tipos de escrita de requisitos
A escrita de requisitos pode ser abordada de várias maneiras, dependendo das necessidades do projeto e das metodologias utilizadas.
Na abordagem descritiva ou tradicional por exemplo, os requisitos são documentados em detalhes antes do início do desenvolvimento. Isso inclui documentos extensos, como especificações de requisitos de software que descrevem o que o sistema deve fazer em termos claros e específicos.
Já na abordagem ágil, os requisitos são frequentemente escritos de forma mais leve e flexível, geralmente sendo escritos em forma de histórias de usuário, que são declarações simples e informais de necessidades do cliente.
Técnicas de Levantamento de Requisitos
Seja qual for a abordagem de escrita de requisitos, diversas técnicas podem ser utilizadas no levantamento de requisitos para que seja mais simples entender e visualizar o sistema antes de ser totalmente desenvolvido.
Alguns exemplos de técnicas:
Entrevistas: Consiste em conversas direcionadas com os clientes/usuários com um propósito específico e com formato “pergunta-resposta”, com o objetivo de descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinião e as expectativas do entrevistado sobre o sistema.
Questionários: Utilizar questionários direcionados aos futuros usuários para obter informações sobre os mesmos e sobre o sistema.
Observação: Consiste em observar o comportamento e o ambiente dos indivíduos de vários níveis organizacionais. Por exemplo, em um sistema de biblioteca poderia ser útil observar os bibliotecários ou os clientes de uma biblioteca física, além dos gestores, para capturarmos o que realmente é feito no dia a dia deles e qual tipo de suporte computacional é necessário.
Análise de documentos: pela análise de documentos existentes na organização, podemos obter informações e detalhes difíceis de conseguir por entrevista e observação.
Cenários: Montar cenários de interação entre o usuário final e o sistema, simulando a interação entre eles.
Prototipagem: Criar uma versão preliminar do sistema, muitas vezes não operacional e descartável, que é apresentada ao usuário para observar reações iniciais e obter sugestões.
Dinâmicas de Grupo: Podem ser utilizadas diversas técnicas que exploram dinâmicas de grupo para a descoberta e o desenvolvimento de requisitos, como por exemplo o Brainstorming, que reúne representantes de diferentes grupos de interessados para gerar o maior número possível de ideias.
Uma vez identificados e negociados, a documentação dos requisitos (seja na abordagem tradicional onde são criados os documentos de requisitos ou na criação das histórias de usuários na abordagem ágil) é útil ao desenvolvermos o sistema, ao testarmos e ao gerarmos a documentação das funcionalidades. Além disso, também pode servir de base e registro para mudanças que são realizadas ao longo do tempo, auxiliando no preparo e planejamento dessas mudanças.
Top comments (0)