O que são requisitos?

Olá pessoas!
Vocês sabem o que são requisitos de software?

Num post anterior falei um pouco do que é escopo, introduzi o requisito em você caro leitor, falei um pouco da sua importância -a importância dos requisitos- e dos riscos de má definição dele. "Alguns assuntos foram deixados implícitos e não necessariamente foram apresentados nesta ordem, mas quem se importa"
Neste post, vamos falar com mais detalhes o que são esses tais requisitos, como são classificados, como levanta-los e o que mais eu achar importante.

Então pega a sua caneca de café e vem com o tio.

A criação de um software não é uma tarefa fácil, já sabemos disso. Não existe uma única forma de resolver um problema e além disso, precisamos de lidar com pessoas -as vezes, muitas pessoas- para avançar no desenvolvimento do projeto...

💭PAUSA PARA UM AVISO: titio é legal e vai falar umas coisas para vocês. Se a sua profissão exige que você interaja com pessoas -muito comum nos dias de hoje- fica esperto porque é aí que mora o problema. Dificilmente todo mundo da sua equipe terá o mesmo nível de conhecimento, assim ter uma equipe nivelada é uma tarefa difícil. Você também pode esbarrar no ego inflado de várias pessoas, que podem te ajudar ou não te ferrar. Não se engane, o seu colega de trabalho não é o seu amigo de infância. Além disso, seu cliente -a pessoa mais importante no seu trabalho- nem sempre sabe o que quer e mesmo quando sabe, muitas vezes não consegue exteriorizar o próprio desejo.

...o que torna o fator comunicação importantíssimo para o sucesso do projeto e, para dificultar ainda mais, muitas vezes não usamos técnicas eficientes para apoiar o processo de desenvolvimento do software.

É necessário entender a dimensão social no desenvolvimento de um projeto de software, o levantamento dos requisitos com o cliente é tarefa fundamental para um bom desenvolvimento do projeto. O processo de compreensão destes requisitos é tão importante quanto a correta documentação deles.

Um requisito de um sistema é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos

Ou seja, os requisitos delimitam o escopo -lembra dele- do sistema, isto é, o que faz parte e o que não faz parte do sistema.

Assim, requisitos que não refletem as reais necessidades do usuário, incompletos e/ou inconsistentes, mudanças de requisitos que já foram previamente aprovados e a dificuldade em chegar a um acordo entre os profissionais de TI e o usuário são os maiores problemas enfrentados na especificação de requisitos.

Um ponto que deve ser considerado e lembrado, é que os requisitos possuem uma característica de volatilidade, ou seja, sofrem modificações durante o desenvolvimento do sistema. Parece um conceito conflitante e, na verdade, é. Antigamente era comum a prática de congelar os requisitos levantados antes de iniciar a construção do sistema. Isto é, os requisitos considerados eram os mesmos do início ao fim do projeto.

Atualmente a volatilidade é um fato com o qual a equipe de desenvolvimento deve conviver, isso porque nos dias atuais, as organizações precisam se adaptar a mudanças cada vez mais rapidamente. Durante o período em que o sistema está em desenvolvimento, as tecnologias utilizadas, as expectativas do ciente, as regras do negócio mudam.

Ao menos que o sistema a ser desenvolvido seja bastante simples e estático, é praticamente impossível pensar em todos os detalhes no início. Além disso, quando o sistema entrar em produção e os usuários começarem a utiliza-lo, eles próprios descobrirão requisitos nos quais não haviam pensado inicialmente. Em suma, os requisitos de um sistema complexo inevitavelmente mudarão durante o seu desenvolvimento.

Durante o levantamento de requisitos, a equipe de desenvolvimento tenta entender o domínio do negócio -o que o negócio faz- que deve ser automatizado pelo sistema de software. O levantamento de requisitos compreende também um estudo exploratório -jeito pomposo de dizer que você vai ter que ir lá na empresa ver como as coisas funcionam- das necessidades dos usuários e da situação do sistema atual, se houver. Há várias técnicas utilizadas para isso, como por exemplo: leitura de obras de referência e livros texto, observações do ambiente do usuário, entrevistas com os usuários, entrevistas com especialistas do domínio -funcionários velhos de guerra que provavelmente utilizarão o seu sistema-, reutilização de análises anteriores, comparação com sistemas preexistentes do mesmo domínio do negócio.

O produto do levantamento de requisitos é o documento de requisitos, que declara os diversos tipos de requisitos do sistema. Normalmente esse documento é descrito em uma notação informal -a linguagem coloquial, sem tecnicismos e expressões típicas-.

A fim de exemplificar os vários tipos de requisitos em um projeto de sistema, utilizarei como exemplo o sistema do serviço de aluguel de bicicletas Bike Vitória atuante na cidade de Vitória/ES.

As principais seções de um documento de requisitos são listadas a seguir.

Requisitos Funcionais (RF): são os requisitos que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema, assim como o que deve sair do sistema.
Exemplos:

1. Cadastro das estações;
2. Cadastro de bicicleta;
3. Cadastro de usuários;
4. Cadastro de cartão de cartão transporte público;
5. Castro de cartão de crédito;
6. Atualizar dados do usuário;
7. Atualizar cartão de crédito;
8. Atualizar cartão de transporte público;
9. Efetuar o pagamento do passe da bicicleta através do cartão de crédito;
10. Efetuar o desbloqueio da bicicleta através do aplicativo;
11. Efetuar o desbloqueio da bicicleta através do telefone;
12. Identificar a estação mais próxima através do aplicativo;
13. Consultar a disponibilidade das bicicletas nas estações;
14. Consultar vagas disponíveis para devolução;
15. Consultar tempo de viagem;
16. Efetuar o bloqueio da bicicleta nas estações;

Requisitos não funcionais (RNF): são aqueles que expressam como deve ser feito (não confundir dom design). Em geral se relacionam com padrões de:

• Confiabilidade: corresponde a medidas quantitativas da confiabilidade do sistema, tais como o tempo médio entre falhas, recuperação de falhas ou quantidade de erros por milhares de linhas de código-fonte.
• Desempenho: requisitos que definem tempos de resposta esperados para as funcionalidades do sistema.
• Portabilidade: restrições sobre as plataformas de hardware e de software nas quais o sistema será implantado e sobre o grau de facilidade para transportar o sistema para outras plataformas.
• Segurança: limitações sobre a segurança do sistema em relação a acessos não-autorizados.
• Usabilidade: requisitos que se relacionam ou afetam a usabilidade do sistema. Exemplos incluem requisitos sobre a facilidade de uso e a necessidade ou não de treinamento dos usuários.

Exemplos:

1. O sistema fará atendimento através de sistema web, móvel (através de aplicativo) e por telefone;
2. O sistema deverá estar disponível 24h por dia;
3. O processamento do pagamento do passe deve ser computado imediatamente;
4. Aplicativo para smartphone;
5. Deverá funcionar em todas as principais plataformas web e móvel;
6. Deverá permitir a computação dos créditos no cartão de transporte municipal;
7. Deverá exigir a autenticação do usuário;
8. Deverá permitir o pagamento do passe com as principais operadoras de cartão de crédito;
9. Deverá possuir tutorial de primeiro acesso;

Regras de negócio ou Restrições: declaração de restrições impostas sobre o desenvolvimento do sistema. Restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com o usuário, componentes de hardware e software a serem adquiridos etc.
Exemplos:

1. O pagamento do passe deverá ser feito antes da retirada da bicicleta da estação e será feito por cartão de crédito ou através do cartão de transporte público;
2. O sistema deve estar disponível todos os dias de 6h às 23h para aluguel de bicicletas e 24h por dia para devolução de bicicletas;
3. Podem ser feitas viagens gratuitas de até 60 minutos de segunda a sábado, quantas vezes o usuário quiser, contanto que seja respeitado o intervalo mínimo de 15 minutos entre elas;
4. Podem ser feitas viagens gratuitas de até 90 minutos nos domingos e feriados, quantas vezes o usuário quiser, contanto que seja respeitado o intervalo mínimo de 15 minutos entre elas;
5. A não observância do intervalo de 15 minutos entre duas viagens, implicará na perda da condição de viagem não tarifada, sendo cobrado R$ 5,40 (cinco reais e quarenta centavos) por cada 60 minutos excedentes (90 minutos aos domingos e feriados);
6. Cada passe dá direito ao usuário de retirar apenas uma bicicleta. É possível utilizar até 5 passes de uma única vez, seja ele diário, mensal ou anual, desde que sejam adquiridos pelo aplicativo. Caso o passe seja adquirido pelo portal de voz, só será permitida a aquisição de um passe por vez para cada telefone celular utilizado;
7. Através do mapa inserido no aplicativo o usuário pode verificar quais estações estão com vagas disponíveis para devolução, mas também é possível ligar para a central de atendimento por voz que indicará qual a estação próxima e dará 15 minutos para que o usuário possa se deslocar até a estação disponível;
8. Serviço disponível apenas para maiores de 18 anos;
9. Os Usuários com Passe Mensal ou Anual podem liberar Bicicletas com outro celular ligando para 4003-0375 ou pelo aplicativo, informando o número do celular do seu Cadastro e a sua senha de acesso. Esta opção não está disponível para Usuários Anônimos que adquiriram passes pelo Portal de Voz;
10. Se, ao retirar a bike, o cliente perceber alguma inconformidade, poderá devolvê-la à estação e retirar outra bicicleta dentro de 5 minutos sem nenhuma tarifa;

Uma das formas de medir a qualidade de um sistema é através da sua utilidade. E um sistema será útil para seus usuários se atender aos requisitos definidos. Portanto, os requisitos devem ser expressos de uma maneira tal que eles possam ser verificados e comunicados a leitores técnicos e não-técnicos. A equipe técnica deve entender o documento de requisitos de tal forma a poder obter soluções técnicas apropriadas. Clientes devem entender esse documento para que possam priorizar o desenvolvimento dos requisitos, conforme a necessidade da organização.

Um ponto importante sobre o documento de requisitos é que ele não deve conter informações sobre as soluções técnicas que serão adotados para desenvolver o sistema. O enfoque prioritário do levantamento de requisitos é responder claramente à questão "O que o usuário necessita do novo sistema?"

FONTE:

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de sistemas orientados a objetos através da linguagem de modelagem unificada. [S.l.]: Campus, [20--?]. v. 1.
FALBO, Ricardo de Almeida. Engenharia de requisitos: notas de aula. 1. ed. Vitória, [201-]. 187 p. v. 1.
MACHADO, Felipe Nery. Análise e gestão de requisitos de software: onde nascem os sistemas. 2. ed. [S.l.]: Érica, [201-]. xx p. v. 1.