-
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, necessariamente,
-
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, entendemos 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 esse nome por serem
de natureza oposta aos funcionais.
-
São os que se relacionam à performance,
a aspectos 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.
