Antes de entrar no universo dos requisitos,
vamos entender um pouco o contexto de um projeto de software
e como os requisitos se encaixam nesse processo.
Quando iniciamos o processo de construção de um software,
precisamos levantar todas as características que as partes interessadas,
também conhecidas como stakeholders, desejam que esse software tenha.
Todas essas solicitações podem ser de naturezas bem diferentes,
por exemplo, uma tela com um layout específico,
um relatório que contém informações de vários departamentos
ou até mesmo a necessidade de que uma determinada transação ocorra
em um intervalo mínimo de tempo.
Fica claro que precisamos anotar todos esses desejos de modo organizado,
já que eles serão o ponto de partida para o projeto do nosso software.
Atualmente, a comunidade de software, formada pelos que produzem
e pelos que consomem software, atua com o paradigma dos projetos ágeis.
Esses projetos ágeis promovem entregas mais rápidas,
sejam entregas completas ou entregas parciais.
Já essas entregas permitem que os usuários aproveitem o valor do software
mesmo antes do projeto ser totalmente concluído.
Um processo ágil de desenvolvimento de software tem como ponto central
a entrega dele funcionando, empregando menos esforço em atividades
que não sejam a sua construção em si.
Com isso, o escopo dos stakeholders pode ser ajustado ao longo do projeto,
conforme a necessidade, é claro.
Agora que entendemos melhor esse processo ágil do desenvolvimento de software,
vamos revisitar brevemente o processo clássico, o modelo cascata.
O modelo cascata é composto por fases fixas,
onde todas as atividades de uma fase devem ser completamente finalizadas
para que a próxima comece.
Na fase de análise, fazemos a coleta e a organização dos requisitos
e, quando finalizada, o modelo não prevê a repetição dessas atividades durante o projeto.
Para efeito de comparação, no processo ágil,
essas atividades de coleta e organização de requisitos
podem acontecer repetidamente em qualquer momento do projeto.
Outra característica importante do processo ágil
é que ele ocorre em ciclos ou espirais.
Em cada espiral, os requisitos são revistos e complementados
se houver necessidade.
Além disso, as especificações técnicas são modeladas assim.
O incremento da solução é construído, testado e entregue para uso.
Um exemplo que ilustra o processo ágil com ciclos de entrega é o Scrum.
O ponto de partida é uma lista de requisitos
que o software precisa atender, ou seja, o backlog do produto.
A partir dele, são criadas atividades de modelagem, construção
e entrega dentro de um ciclo de trabalho conhecido como Sprint.
Ao fim desse ciclo se espera a entrega de uma parte do software para o cliente.
O projeto é composto por várias sprints,
onde cada uma implementa uma parte da relação dos requisitos
e os ajustes do backlog do produto podem ocorrer em qualquer momento.
Comentamos mais de uma vez que essa lista de requisitos
deve ser anotada e classificada.
Podemos classificar os requisitos de diversas maneiras,
mas ao final desse processo devemos ter necessário em mente
dois tipos de requisitos os funcionais e os não funcionais.
Os requisitos funcionais são aqueles que se relacionam
com uma funcionalidade, ou seja, um serviço que o software deve fornecer.
Por meio deles.
Entendermos quais dados o sistema deve guardar, recuperar e apresentar,
quais transações devem acontecer, como devem ser as interações
com os usuários, atendendo, é claro, as regras de negócio envolvidas.
Já os requisitos não funcionais recebem este nome
por serem de natureza oposta aos funcionais.
São os que se relacionam à performance, aspecto de interface
e usabilidade do software e condições de segurança.
Eles envolvem a solução como um todo.
Vale ressaltar que o conjunto dos requisitos funcionais
e não funcionais de um sistema é conhecido como requisitos de software.
Conhecendo esses requisitos, podemos delimitar o escopo do software
a ser construído, planejar o seu desenvolvimento
e ter bases para estimar qual o custo e o tempo envolvidos em sua construção.
Pronto, agora você já compreende o contexto de um projeto de software
e como ele serve de plano de fundo para os requisitos.