terça-feira, agosto 29, 2006

FDD e requisitos

Em algumas listas/fóruns sobre FDD, nacionais e internacionais, vezes se tem perguntado sobre qual o tratamento dado pela FDD (Feature-Driven Development) aos requisitos de software. Para avaliarmos isso, vamos antes fazer uma rápida revisão sobre os conceitos das disciplinas relacionadas aos requisitos, que são definidas pela Engenharia de Requisitos. De acordo com o SEI, no CMMI for Development 1.2, o propósito do Desenvolvimento de Requisitos é produzir e analisar requisitos para clientes, produtos e componentes de produtos, enquanto o do Gerenciamento de Requisitos é gerenciar os requisitos de projetos e produtos e identificar inconsistências entres esses requisitos e os planos dos projetos. Dentro destas disciplinas temos os seguintes tipos de requisitos:
1. Requisitos de Negócio: Expressa "por que" estamos fazendo esse sistema.
2. Requisitos de Usuário: Expressa "quem" faz "o que" no sistema.
3. Requisitos Funcionais: Expressa "como" o sistema atende aos requisitos de usuário.
4. Requisitos Não-Funcionais: Expressa expectativas quanto a funcionalidade do sistema(performance, amigabilidade, escalabilidade, portabilidade, etc.)

Para quem conhece o conceito de features da FDD, percebe que elas são requisitos funcionais. Sendo assim podemos afirmar que tais requisitos emergem nas fases 01(Develop Overall Model) e 02(Build Feature List) e são detalhados(quando necessário) na fase 04(Design By Feature) do ciclo da FDD. Outros tipos de requisitos devem ser desenvolvidos (e gerenciados) fora do ciclo do FDD, servindo então de matéria-prima para as fases. Portanto, se você gosta de escrever use cases (ou outro formato de requisitos de usuário) e entende que seu uso é válido para o projeto em questão, vá em frente! No entanto não inclua esta tarefa em nenhuma das fases da FDD, o seu uso no ciclo será como documentação de estudo para a tarefa Study Documents, presente nas fases 01(Develop Overall Model) e 04(Design By Feature).

Nenhum comentário: