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 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.