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