Processos

e
Requisitos
 QUANDO NÃO USAR MÉTODOS
ÁGEIS?

Em outras palavras, sistemas de

qualquer área podem se beneficiar de
pelo menos algumas das práticas
propostas por métodos ágeis. Por outro
lado, existem práticas que não são
recomendadas para determinados tipos
de sistemas, organizações e contextos.
 DESIGN INCREMENTAL

Para um design eficaz, a equipe

deve ter uma visão inicial clara;
Caso contrário, em domínios
complexos ou com custos futuros
elevados, comece com análise
antes das implementações
iterativas.
 HISTÓRIAS DO USUÁRIO.

Histórias de requisitos são uma

abordagem ágil, refinada com o
envolvimento diário de um
representante do cliente. Contudo,
em projetos totalmente novos para
a equipe de desenvolvimento, uma
projeção detalhada no início pode
ser crucial.
ENVOLVIMENTO DO CLIENTE

Em situações onde os requisitos do

sistema são obtidos e bem
conhecidos pela equipe de
desenvolvimento, a presença de um
Representante dos Clientes ou
Doador do Produto não é
necessária.
 DOCUMENTAÇÃO LEVE E
SIMPLIFICADA.
Em alguns setores, é obrigatório ter
documentações abrangentes de
requisitos e projetos. Por exemplo, em
áreas críticas como a medicina e o
transporte, onde falhas podem ter
consequências fatais, é comum a
necessidade de certificação por
entidades externas, o que pode requerer
documentação minuciosa, além do
TIMES AUTO-ORGANIZÁVEIS. código-fonte.

Os tempos ágeis operam com

autonomia e empoderamento
durante as iterações, dispensando
prestações de contas diárias aos
gerentes e executivos.
 CONTRATOS COM ESCOPO
ABERTO
Em contratos de escopo aberto, a remuneração é
por hora trabalhada, resultando na incerteza
sobre funcionalidades, prazo e custo no momento
da assinatura. Isso pode ser desconfortável para
organizações sem experiência em
desenvolvimento ágil ou com referências
confiáveis. Além disso, práticas ágeis com equipes
pequenas e iterações, mesmo de duração mais
longa, são amplamente exigidas na maioria dos
projetos de software.
 REQUISITOS

Requisitos definem o que um sistema deve fazer

e sob quais restrições. Requisitos relacionados
com a primeira parte dessa definição o que um
sistema deve fazer, ou seja, suas funcionalidades
são chamados de Requisitos Funcionais. Já os
requisitos relacionados com a segunda parte
sob que restrições são chamados de Requisitos
Não-Funcionais.
 REQUISITOS

A definição de requisitos é fundamental na

construção de sistemas de software, conforme
enfatizado por Frederick Brooks. Um sistema
bem projetado e implementado pode ser inútil se
não atender às necessidades dos usuários.
Problemas na elaboração de requisitos também
resultam em custos significativos, incluindo
retrabalho e possíveis rejeições pelos usuários
devido a requisitos mal especificados.
 REQUISITOS
Requisitos funcionais, na maioria das vezes, são especificados em
linguagem natural. Por outro lado, requisitos não-funcionais são
especificados de forma quantitativa.
O uso de métricas evita especificações vagas, como "o sistema deve ser
rápido e ter alta disponibilidade". É preferível definir metas específicas,
como 99,99% de disponibilidade e um tempo de resposta máximo de 1
segundo para 99% das transações em janelas de 5 minutos.
Autores como Ian Sommerville categorizam requisitos em requisitos de
usuário (escritos por usuários em linguagem natural) e requisitos de sistema
(técnicos, escritos por desenvolvedores). Os requisitos do usuário estão
relacionados ao problema, enquanto os requisitos do sistema são
aproximados da solução, detalhando protocolos e especificações técnicas,
como no caso de um sistema bancário que define requisitos de
transferência entre bancos a partir de um requisito de usuário inicial.