You are on page 1of 9

Levantamento de Requisitos

André Luiz Moura Júnior Universo

Engenharia de Software. 2003. 2004. capítulo 5.. capítulo 2. Engenharia de Software: Fundamentos.. 2002.Bibliografia  PAULA-FILHO. 2ª ed. 5ª ed. Roger S. IEEE. Rio de Janeiro: McGraw Hill. Wilson de Pádua. . capítulos 10 e 11. PRESSMAN.Livros    Técnicos e Científicos. Transparências da professora Maria Augusta Vieira Nelson – PUC-Minas. SWEBOK: Guide to the Software Engineering Body of Knowledge. Rio de Janeiro: LTC . Métodos e Padrões.

descoberta de requisitos.  Outras terminologias:   .  restrições relacionadas ao produto de software. elicitação de requisitos. quais são os efeitos que o sistema deve ter.Levantamento de Requisitos  Conjunto de atividades da Engenharia de Requisitos que tem como objetivo descobrir:  mais informações sobre o domínio da aplicação.   sobre o domínio do problema.

Dimensões do Levantamento de Requisitos .

Dimensões do Levantamento de Requisitos • Compreender o domínio da aplicação: ▫ conhecimento geral de onde o sistema será implantado. • Compreender o contexto de negócio: ▫ entendimento de como os sistemas interagem e contribuem de forma geral com os objetivos do negócio do cliente. • Compreender as necessidades e restrições dos interessados. • Compreender o problema a ser resolvido: ▫ entendimento dos detalhes específicos do problema do cliente e dos usuários. .

 para descrever suas tarefas.  o que um produto de software pode oferecer. etc. podem ser relutantes em tomar decisões. .‫‏‬  Usuários podem ter dificuldades.   em seus próprios termos. mesmos termos com significados diferentes.Dificuldades  Clientes e usuários:  nem sempre sabem.    podem não saber exatamente o que desejam. Problemas com a própria linguagem utilizada:  ambígua. geralmente expressam os requisitos.

Dificuldades  Especialistas no domínio da aplicação podem entender tão bem a área. Os requisitos podem mudar durante o projeto de desenvolvimento de software:   novos interessados no produto de software podem surgir.  Diferentes interessados no produto de software.  .   O escopo do sistema pode não estar bemdefinido. o processo de negócio pode mudar.  que não tornam todos os requisitos explícitos. podem ter requisitos conflitantes.

 Por não ser a especialidade dos analistas de requisitos.  Analistas de requisitos podem concentrar-se em informações desnecessárias neste momento.  também podem influenciar os requisitos do sistema.Dificuldades  Fatores políticos e organizacionais.  o próprio processo de levantamento de requisitos do software.  as características do domínio da aplicação podem não ser entendidas de forma suficiente. por exemplo.  relacionadas.  para produzir uma especificação de requisitos satisfatória. . ao projeto arquitetural do sistema.  Analistas de requisitos podem não dominar.

. • Requisitos: ▫ funcionais. • Critérios de aceitação desses requisitos. • Vocabulário do domínio da aplicação.O que Deve ser Levantado? • Objetivo do sistema. ▫ de processo. ▫ de projeto. ▫ não-funcionais.