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.