Requisitos do Usuário e do Sistema

De acordo com Sommerville (2011, p. 59), os requisitos de software podem ser diferenciados entre requisitos do usuário e do sistema. Os requisitos do usuário definem quais serviços o sistema oferecerá a seus usuários e as restrições com as quais deverá operar, e isso é feito usando diagramas ou linguagem natural. Os requisitos de sistema são descrições mais detalhadas destas funções, serviços e restrições operacionais do sistema de software. O autor afirma que muitos problemas da Engenharia de Requisitos ocorrem pela falha na distinção e separação entre esses diferentes níveis de descrição.

Requisitos do Usuário

São os requisitos funcionais e não funcionais do sistema sob o ponto de vista do usuário. Em geral apresentam problemas como falta de clareza, confusão e fusão, ou seja, requisitos diferentes escritos como um único requisito.

Requisitos do Sistema

São descrições mais detalhadas dos requisitos do usuário. São a base para que os engenheiros de software possam fazer o projeto do sistema. Servem como base para um contrato destinado à implementação do sistema.

Engenharia de Requisitos

Requisitos de software e sua importância dentro da Engenharia de Requisitos. As etapas e principais conceitos e definições ligadas à Engenharia de Requisitos serão apresentados.

Requisitos e Engenharia de Requisitos

Caro aluno, a Engenharia de Requisitos (ER) pode ser vista como uma subárea da Engenharia de Software, cujo principal objetivo é a obtenção de uma especificação correta e completa dos requisitos de um sistema de software.

De acordo com Pressman (2011, p. 127), na perspectiva do processo de software, a Engenharia de Requisitos é uma ação de engenharia de software que começa durante a atividade de Comunicação (ou Especificação) e continua durante a atividade de Modelagem, devendo ser adaptada às necessidades do processo, do projeto, do produto e das pessoas envolvidas.

Para que o processo de desenvolvimento de software seja bem-sucedido é fundamental que haja uma compreensão completa dos requisitos de software. Tanto o desenvolvedor como o cliente desempenham um papel ativo na análise e especificação dos requisitos. O desenvolvedor age como indagador, consultor e solucionador de problemas e o cliente tenta traduzir os conceitos relativos ao desempenho do software que ele tem concebido apenas em sua mente, tarefa que é, às vezes, bastante complicada e nebulosa, em detalhes concretos.

Mas, afinal, o que são os requisitos?

De acordo com Sommerville (2011, p. 57), requisitos são descrições do que o sistema deve fazer, os serviços que oferece e as restrições relativas ao seu funcionamento. Os requisitos têm por objetivo:

• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer;
• Oferecer aos desenvolvedores uma compreensão melhor do sistema a ser desenvolvido;
• Delimitar o sistema;
• Planejar o desenvolvimento do sistema;
• Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.

A Engenharia de Requisitos tem se tornado cada vez mais necessária para resolver os problemas encontrados nas organizações com relação à definição de sistemas. De acordo com a Regra 10 de Myers, o custo de um defeito tende a ser 10 vezes maior a cada fase de projeto em que ele avança; isso significa que, quanto antes um defeito for encontrado; mais barato é para corrigir (ALMEIDA, 2016). A figura ilustra este fato.

Custo de correção de defeitos em software. Fonte: ALMEIDA, 2016

Como pode ser visto na figura, o custo aumenta com o tempo de descoberta do problema, mas tem origem na especificação dos requisitos. Muitas vezes os defeitos são descobertos pelo próprio cliente, mesmo antes da entrega do produto, quando ele participa ativamente. Os requisitos deficientes são considerados uma das maiores causas de falhas nos projetos de software.

Processo Unificado/RUP

O Processo Unificado (PU) ou Unified Process (UP) surgiu como um processo para o desenvolvimento de software visando à construção de sistemas orientados a objetos. De acordo com Pressman (2011, p. 71), o PU busca aproveitar os melhores recursos dos modelos de processos tradicionais unidos aos melhores princípios do desenvolvimento ágil de software. 

 

 

Processo Unificado. Fonte: Lightspring/shutterstock

De acordo com IBM (2006), o PU foi modelado usando o Software Process Engineering Metamodel (SPEM), que é um padrão para modelagem de processos baseado em UML – Unified Modeling Language. De uma maneira geral, podemos assim caracterizar o Processo Unificado:

• é um framework genérico de um processo de desenvolvimento;
• é baseado em componentes;
• utiliza toda a definição da UML;
• é dirigido pelos use cases, centrado na arquitetura, iterativo e incremental (conceitos-chave).

De acordo com Sommerville (2011, p. 34), o RUP – Rational Unified Process – é derivado de trabalhos da UML – Unified Modeling Language – e do Processo Unificado, reunindo elementos de modelos de processo genéricos, trazendo boas práticas de especificação para o projeto e ainda apoiando a prototipação e a entrega incremental. É um processo iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos por causa da maneira organizada e consistente que oferece na condução de um projeto.

Sommerville (2017) descreve o RUP como um framework descrito em três perspectivas:

• Dinâmica, que mostra as fases ao longo do tempo;
• Estática, que mostra as atividades ao longo do processo;
• Prática, que sugere boas práticas a serem utilizadas.

A figura ilustra as fases e os workflows do RUP. 

Fases e Workflows do Processo Unificado. Fonte: baseado em IBM (2006, p. 4)

Fases – Perspectiva dinâmica

O RUP organiza suas iterações em quatro fases principais, que Sommerville (2011) assim define:

Concepção: o objetivo desta fase é definir um caso de negócio para o sistema. São elencadas todas as entradas externas, que se referem a pessoas e sistemas, define-se como estas interagem com o sistema e as interações são definidas. A ideia é ter uma visão inicial do problema, estimar de forma vaga o esforço e os prazos e determinar se o projeto é viável e merece uma análise mais profunda, ou então se deve ser descartado.

Elaboração: na fase de elaboração todos (ou a grande maioria) dos requisitos são levantados em detalhes, o framework arquitetural do sistema é definido, o plano de projeto é desenvolvido e os maiores riscos do projeto são identificados. Ao fim desta fase, deseja-se que 90% dos requisitos tenham sido levantados em detalhes, podendo formar um conjunto de casos de uso da UML, que o planejamento e a arquitetura do sistema tenham sido descritos e que os principais riscos tenham sido tratados, de forma que haja condições para se fazer estimativas mais realistas.

Construção: esta fase envolve o projeto, implementação e testes do sistema. O sistema é cosntruído por partes e integrado e, no final, uma versão do sistema já deve estar funcionando, junto com uma documentação a ser entregue ao cliente.

Transição: esta fase realiza a transferência do sistema do ambiente de produção, ou seja, dos desenvolvedores, para o ambiente real de utilização, ou seja, para os usuários. Ao final da fase, a implantação deve estar concluída e o sistema deve estar funcionando, com a documentação adequada, no ambiente operacional.

Workflows – Perspectiva Estática

Workflow

Fonte: Rawpixel.com/shutterstock

A visão estática do RUP dá prioridade às atividades que ocorrem no processo de desenvolvimento, denominadas workflows. Um workflow é uma coleção de atividades relacionadas que estão ligadas à maior área de interesse dentro do processo, podendo ser modeladas por meio de diagramas da UML. São 6 workflows centrais e 3 workflows de apoio, cujos objetivos são:

1. Modelagem de Negócios: entender a estrutura e a dinâmica da organização para a qual o produto será desenvolvido; identificar problemas correntes na organização e possíveis aperfeiçoamentos; assegurar que o cliente, o usuário final e os desenvolvedores possuam a mesma compreensão da empresa; produzir os requisitos de sistemas necessários para suportar os objetivos da organização. Os processos de negócio são modelados usando casos de uso de negócios.
2. Requisitos: estabelecer e manter o consentimento entre clientes e stakeholders sobre o que o sistema deve fazer; fornecer uma melhor compreensão dos requisitos aos desenvolvedores; definir os limites do sistema; fornecer as bases para o planejamento das iterações, estimativas de custo e tempo de desenvolvimento; definir as interfaces do sistema baseado nas necessidades e objetivos dos usuários. Os atores que interagem com o sistema são identificados e casos de uso são utilizados para modelar os requisitos do sistema.
3. Análise e Design: transformar os requisitos dentro de um projeto do que será o sistema; desenvolver uma arquitetura robusta para o sistema; adaptar o projeto para ajustá-lo ao ambiente de implementação. O modelo de projeto é criado e documentado utilizando diagramas que definem os modelos de arquitetura, de componentes, de objetos e de sequência.
4. Implementação: preparar a organização do código em termos de implementação de subsistemas, organizados em camadas; implementar classes e objetos em termos de seus componentes; testar os componentes desenvolvidos como unidades; integrar os resultados obtidos por implementadores individuais (ou equipes) em um sistema executável. Os componentes do sistema são implementados e estruturados em subsistemas de implementação, podendo ser utilizada geração automática de código.
5. Teste: verificar a interação entre os objetos; verificar a integração de todos os componentes de software; verificar se todos os requisitos foram implementados corretamente; verificar os defeitos e assegurar que eles foram tratados antes da entrega do produto. O teste de sistema segue a conclusão da implementação.
6. Implantação: descrever as atividades associadas à verificação para que o produto esteja disponível ao usuário final. Um release (versão) do sistema é produzido e instalado no ambiente de trabalho dos usuários.
7. Gerenciamento de Configuração e Mudança: identificar itens de configuração; restringir alterações para aqueles itens; auditar as alterações neles feitas; definir e gerenciar as alterações daqueles itens. Este workflow de apoio gerencia as mudanças do sistema.
8. Gerenciamento de Projeto: fornecer uma estrutura para gerenciamento de projeto de software; fornecer um guia prático para planejamento, recrutamento, execução e monitoramento de projeto; fornecer uma estrutura para o gerenciamento de riscos. Este workflow de apoio gerencia o desenvolvimento do sistema.
9. Ambiente: identificar as atividades necessárias para configurar o processo para o projeto; descrever as atividades requeridas para desenvolver as guias mestras no suporte ao projeto; fornecer para a organização de desenvolvimento de software o ambiente de processos e ferramentas que suportarão a equipe de desenvolvimento. Este workflow de apoio está ligado à disponibilização de ferramentas adequadas para o desenvolvimento.
   

Engenharia de Software. Fonte: emojoez/shutterstock

Perspectiva prática

O RUP indica seis boas práticas de Engenharia de Software a serem aplicadas no desenvolvimento de sistemas de software, que são assim descritas por Sommerville (2011):

1. Desenvolver software de forma interativa.
2. Gerenciar os requisitos.
3. Usar arquiteturas baseadas em componentes.
4. Modelar o software usando diagramas e modelos visuais.
5. Verificar a qualidade do software.
6. Controlar as mudanças do software.

Apesar de apresentar diversas vantagens, o RUP é um processo complexo, envolve custos mais altos e requer equipe de desenvolvimento maior e mais especializada. Não é um modelo adequado para o desenvolvimento de software embarcado, por exemplo.

Modelos Ágeis

As definições modernas de desenvolvimento de software ágil evoluíram a partir de meados de 1990 como parte de uma reação contra métodos caracterizados por uma regulamentação complexa e rígida e contra a regimentação e o sequenciamento usado no modelo em cascata. O objetivo era desburocratizar os procedimentos que tornavam as etapas dos processos lentas, o que era contrário ao modo de trabalho usual dos engenheiros de software.

Inicialmente, os métodos ágeis foram denominados de “métodos leves”. Em 2001, Kent Beck e 16 outros notáveis profissionais da área de Engenharia de Software se reuniram, adotaram o nome métodos ágeis e publicaram o Manifesto Ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Esses veteranos formaram a Agile Alliance,ou Aliança Ágil, uma organização não lucrativa que promove e fomenta o desenvolvimento ágil. (BECK, 2001)

 

 

 

Agilidade.
Fonte: kentoh/shutterstock

Os membros da Aliança Ágil, declararam assim os princípios da metodologia em seu manifesto:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Fonte: SOMMERVILLE (2011, p. 40)

Os principais modelos baseados na concepção de Desenvolvimento Ágil incluem o Scrum, criado em 1986, o ASD – Adaptive Software Development, o FDD – Feature Driven Development, o DSDM – Dynamic Systems Development Method de 1995, o Crystal e a XP – eXtremeProgramming ou Programação Extrema, criados em 1996.

O Desenvolvimento Ágil de Software - Agile Software Development, envolve uma metodologia que visa minimizar os riscos por meio de desenvolvimentos em curtos períodos ou iterações, como mostra a figura (que é baseada no Scrum). A iteração típica envolve o desenvolvimento em fases curtas, de 1 a 4 semanas, envolvendo todas as tarefas necessárias para implantar uma funcionalidade. Considerando-se o período curto de cada iteração, a comunicação mantida entre os stakeholders é em tempo real sendo, preferencialmente, tratada por meio verbal (embora documentada), ou face a face, visando minimizar entendimentos parciais ou errôneos. Para tanto é necessário estabelecer um local físico (uma sala) onde toda a equipe necessária ficará focada no projeto.

Alguns críticos do processo ágil afirmam que o maior risco deste tipo de abordagem é a baixa qualidade ou mesmo inexistência de documentação do projeto por causa da interação humana face a face que, se por um lado traz agilidade na comunicação, por outro traz a informalidade nas definições. Assim sendo, é necessário um bom acompanhamento do gestor do projeto para garantir a qualidade dos trabalhos, independente do processo utilizado.

Etapas do Desenvolvimento Ágil (Scrum)

Fonte: http://www.sstecnologia.com.br/

De uma forma geral, os processos ágeis atendem aos projetos de software que, normalmente, apresentam:

• Dificuldade em prever com antecedência quais requisitos vão persistir e quais serão modificados, bem como prever quais prioridades dos clientes sofrerão mudanças ao longo do projeto;
• Intercalação das etapas de projeto e construção, que vão sendo realizadas juntas de modo que os modelos de projeto vão sendo comprovados na medida em que são criados;
• Análise, projeto, construção e testes não são tão previsíveis, do ponto de vista do planejamento, como seria desejado.

A metodologia ágil vem gerando grande debate, fazendo muitos desenvolvedores apaixonados e muitos outros críticos ferrenhos. Mas temos que manter a imparcialidade profissional e questionarmos o que realmente tem que ser observado, como:

• Qual é a melhor forma de se alcançar a agilidade nos processos e práticas do desenvolvimento de software?
• Como construir softwares que satisfaçam as necessidades do cliente e possua características de qualidade que permitam sua extensão e ampliação para satisfazer as necessidades do cliente no longo prazo?

Aconteceu

O que são essas tais de metodologias Ágeis?

Adotar uma metodologia ágil pode trazer muitos benefícios, mas nós costumamos dizer que o ágil não é a bala de prata, ou seja, apenas aplicar por exemplo o SCRUM ou algumas de suas práticas ágeis por si só não vai resolver os seus problemas, mas evidenciar suas fraquezas para que você possa identificar e atuar sobre elas. Cabe, então, à equipe atuar de forma proativa e desejar as mudanças para que os benefícios que o ágil pode proporcionar possa valer de verdade.

 Dentre as principais causas de falha na adoção de uma metodologia ágil estão:

• Filosofia ou a cultura da empresa que conflitam com os valores e princípios do agile;
• Falta de suporte gerencial para apoiar as mudanças; É preciso desejar as mudanças;
• Falta de experiência ou treinamento insuficiente no novo processo; É preciso tornar-se capaz de trabalhar de maneira ágil;
• Boicote, falta de comprometimento da própria equipe. É preciso reconhecer que há espaço para melhorias e desejá-las;

Aplicar o ágil não é uma tarefa fácil. Exige determinação e disciplina.

É UMA MUDANÇA DE COMPORTAMENTO.

Leia o artigo completo em: <www.ibm.com>

Modelo de Métodos Formais

Os métodos formais são técnicas baseadas em formalismos matemáticos que podem ser usados para a especificação, desenvolvimento e verificação de sistemas de software. Seu uso para o desenvolvimento de software é motivado pela base que fornecem garantindo confiabilidade e robustez a um projeto, uma vez que executam análises matemáticas apropriadas. No entanto, o alto custo do uso de métodos formais restringe o seu uso ao desenvolvimento de sistemas de alta integridade, no qual há alta probabilidade das falhas conduzirem à perda de vidas ou sérios prejuízos (como nas missões espaciais e no controle de voos, por exemplo). 

Ônibus espacial

Exemplo de sistema crítico. Fonte: Everett Historical/shutterstock

No modelo de Métodos Formais, também conhecido como Engenharia de Software Cleanroom (Sala Limpa), uma questão fundamental é garantir que o software é realmente uma solução para o problema proposto. Para realizar tal tarefa deve-se primeiro construir um modelo da solução (especificação) utilizando uma linguagem formal. (FACIN, 2002). Tendo este modelo formal como base, o método permite:

• realizar provas matemáticas que garantem que este modelo possui as propriedades requisitadas (verificação);
• analisar se a solução proposta é aceitável do ponto de vista de desempenho, indicando quais as melhores estratégias para implementação a serem seguidas;
• validar o modelo através de simulações;
• realizar o desenvolvimento do software, sendo possível provar que a implementação está correta (geração de código correto).

Dentre os vários métodos de especificação formal existentes, destacam-se o método Z, que já foi utilizado em várias aplicações práticas, e o método de gramáticas de grafos, por possuir uma linguagem visual de representação e descrever com naturalidade fenômenos de sistemas concorrentes.

De uma maneira mais abrangente, podemos caracterizar assim o modelo de Métodos Formais:

• Permite especificar, desenvolver e verificar um software através de uma rigorosa notação matemática;
• Fornece um mecanismo para eliminar muitos problemas encontrados nos outros modelos, como ambiguidade, incompletude e inconsistência, que podem ser descobertos e corrigidos mais facilmente através de análise matemática;
• Promete o desenvolvimento de software livre de defeitos;
• Consome muito tempo de desenvolvimento e é muito caro.

Como poucos desenvolvedores possuem o conhecimento necessário para utilizá-lo, são requeridos muitos cursos e treinamentos. É difícil usar tais modelos matemáticos formais como meio de comunicação com a maioria dos clientes. Assim, como já dissemos, sua área de aplicação é muito restrita, abrangendo, principalmente, aplicações críticas.

Modelos de Processo – Parte 2

Os Modelos de Processo Especializados que consideram as características de um ou mais modelos: o Desenvolvimento Baseado em Componentes, o Método Formal, o Processo Unificado, e faremos uma descrição geral dos Métodos Ágeis de Desenvolvimento.

Desenvolvimento Baseado em Componentes

O Desenvolvimento Baseado em Componentes ou CBD – Component-Based Development, também é conhecido como Component-Based Software Engineering (CBSE) ou simplesmente como Componente de Software. Os desenvolvedores costumam utilizar componentes de software que são encontrados em bibliotecas de uso gratuito, mas alguns também utilizam componentes que ficam disponíveis para compra. Estes componentes são conhecidos como COTS – Commercial-Off-The-Shelf, ou Software Comercial de Prateleira. Geralmente estes componentes oferecem funcionalidades com interfaces bem definidas, que podem ser facilmente integrados no software sendo desenvolvido.

 

 

 

Desenvolvimento basedo em componentes. Fonte: Sentavio/shutterstock

O método de Desenvolvimento Baseado em Componentes incorpora as características de construção de componentes de biblioteca ao Modelo Espiral. De natureza evolucionária, adota uma abordagem iterativa para a criação de software. Assim, o modelo constrói aplicações a partir de componentes de software previamente preparados. As atividades de modelagem e construção começam com a identificação de componentes candidatos. Esses componentes podem ser projetados como módulos de software convencional ou como classes, ou pacotes de classes, orientadas a objeto.

No paradigma orientado a objetos uma classe encapsula dados e algoritmos, que também podem ser utilizados para manipular os dados. Através desta abordagem uma biblioteca de classes pode ser construída com as classes identificadas no desenvolvimento do software, e a partir de então toda iteração da espiral deverá verificar o conteúdo da biblioteca que pode ser reutilizado.

De acordo com Pressman (2011, p. 69), o modelo de Desenvolvimento Baseado em Componentes leva ao reuso de software, e a reusabilidade fornece aos engenheiros vários benefícios, como redução no tempo do ciclo de desenvolvimento e dos custos do projeto.

Modelos Incrementais de Processo

Há diversas situações em que os requisitos iniciais do software estão razoavelmente bem definidos, mas o escopo global do processo de desenvolvimento claramente elimina uma abordagem puramente linear ou sequencial. Adicionalmente pode haver a necessidade de se fornecer rapidamente um conjunto limitado de funcionalidades do software aos usuários e depois refinar, melhorar e expandir aquela funcionalidade em versões mais avançadas do software. Nestes casos, os modelos de processo que produzem software em incrementos são os mais indicados.

Os processos incrementais que discutiremos aqui incluem o Modelo Incremental e o Modelo RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação), com base em Pressman (2011).

Modelo Incremental

O modelo incremental aplica elementos do modelo em cascata, mas de forma interativa. Este modelo, assim como a prototipagem, é incremental, mas o que o diferencia da prototipagem é o fato de ele ter como objetivo apresentar um produto operacional a cada incremento realizado. Este processo pode ser visto na figura.

Modelo de Processo Incremental. Fonte: baseado em (PRESSMAN, 2010)

Esse modelo é muito útil quando a empresa não possui mão de obra disponível, em um dado período, para uma implementação completa, dentro do prazo estipulado.

De uma forma geral, o Modelo Incremental apresenta as características:

• Combina elementos do Modelo em Cascata (aplicado repetitivamente) com a filosofia iterativa da Prototipação;
• Aplica sequências lineares de uma forma racional à medida que o tempo passa;
• Cada sequência linear produz um incremento do software e pode gerar uma entrega parcial do produto;
• Os primeiros incrementos são versões simplificadas do produto final;
• O primeiro incremento é chamado de “núcleo do produto” (core).

Um exemplo clássico de aplicação do Modelo Incremental é o desenvolvimento de um processador de texto. Para este projeto as etapas incrementais poderiam ser assim definidas:

1. Primeiro Incremento: poderia efetuar as funções de controle de versões de arquivos, edição e produção de documentos.
2. Segundo Incremento: adicionaria capacidade de edição e de produção de documentos mais sofisticados.
3. Terceiro Incremento: incluiria a verificação sintática e gramatical.
4. Quarto Incremento: adicionaria a capacidade avançada de disposição de página.

Note que todo o processo pode se repetir até que um produto completo seja produzido.

Modelo RAD - Rapid Application Development

O modelo RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação) é uma adaptação do modelo em Cascata, mas que enfatiza um desenvolvimento extremamente rápido. A alta velocidade é conseguida por meio de uma abordagem de construção baseada em componentes, ou seja, o sistema é modularizado.

Se os requisitos forem bem definidos e o objetivo do projeto for restrito, a equipe pode criar um sistema plenamente funcional em pouco tempo.

O RAD se enquadra no modelo de atividades de arcabouço do Modelo em Cascata:

• Comunicação: atividade em que se entende o problema de negócio, as características das informações e é realizado o levantamento de requisitos.
• Planejamento: atividade essencial. Várias equipes trabalham em paralelo em diferentes funções.
• Modelagem: estabelece representações de projeto que servem como base para a atividade de construção. Abrange três fases:
1. Modelagem de negócio
2. Modelagem de dados
3. Modelagem de processo
• Construção: faz uso de componentes de software preexistentes e geração de códigos.
• Emprego (ou implantação): estabelece a base para iterações subsequentes, se necessárias.

A figura apresenta a representação esquemática do modelo RAD em relação ao modelo sequencial tradicional.

Modelo RAD x Modelo Tradicional. Fonte: http://www-old.novulo.com/Rad.aspx

As situações de desenvolvimento mais adequadas para se utilizar o Modelo RAD incluem:

• Projetos em que os requisitos estão bem definidos, o objetivo do sistema é restrito e se deseja criar um “sistema plenamente funcional” dentro de períodos muito curtos (por exemplo, de 60 a 90 dias);
• Projetos em que há fortes restrições de tempo impostas pelo cliente;
• Aplicações que podem ser modularizadas de forma que cada função principal possa ser completada em menos de 3 meses;
• Projetos em que cada função principal possa ser alocada para uma equipe distinta e depois integradas para formar o todo do produto.

Mas a utilização do modelo RAD também pode implicar em problemas. Para projetos grandes, mas mensuráveis, o RAD requer um número elevado de recursos humanos que sejam suficientes para criar um número adequado de equipes. Além disso, o RAD requer um comprometimento entre desenvolvedores e clientes para que as atividades possam ser realizadas rapidamente e o sistema seja concluído em um tempo curto. Se o comprometimento for abandonado por qualquer das partes, o projeto falhará. O uso do RAD também não é apropriado quando os riscos técnicos são grandes (por exemplo, quando a aplicação faz uso de uma nova tecnologia).