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