Levantamento de Requisitos

FEAPAAnálise e Projeto de Sistemas 1Prof. Osiel Marlon

Levantamento de Requisitos

REQUISITOS: Objetivos ou restrições estabelecidas por clientes e

usuários do sistema que definem as diversas propriedades do sistema

Condição ou capacidade necessária que o software deve possuir:

– para que o usuário possa resolver um problema ou atingir um objetivo

– para atender as necessidades ou restrições da organização ou de outros componentes do sistema.

Engenharia de Requisitos

É um ramo da [Engenharia de Software] que se dedica ao estudo de soluções para levantamento, desambiguação, análise e especificação de requisitos para projetos de desenvolvimento de software.

O levantamento e análise de requisitos engloba aquelas tarefas que procuram determinar as necessidades ou condições para que um determinado produto (de software) Seja construído ou alterado.

Será necessário lidar com requisitos conflituosos ou contraditórios e os interesses de cada pessoa com interesse no projeto ("stakeholders").

Engenharia de Requisitos

Os requisitos devem ser mensuráveis (a sua cobertura), testáveis, relacionados com necessidades identificadas do negócio ou domínio de aplicação, e definidos a um nível de detalhe suficiente para serem usados nas ulteriores atividades da engenharia de software.

Requisitos do usuário, do sistema e do software [Sommerville, 2004] Requisitos do usuário – Declarações, em linguagem natural e diagramas, sobre os

serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes.

Requisitos do sistema – Estabelecem detalhadamente as funções e restrições do

sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor.

Especificação de software – Especificação abstrata e precisa do software, indicando o

que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento.

Problemas Comuns Os envolvidos* não sabem o que eles realmente querem. Se expressam num vocabulário diferente dos desenvolvedores. Os envolvidos podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os

requisitos. Novos requisitos podem surgir durante o processo de

levantamento/análise/especificação. Novos envolvidos podem vir a participar do process. Podem haver mudanças externas – ambiente ou regras de

negócios.

*Stakeholders: Envolvidos ou partes interessadas

DIFICULDADES DE COMUNICAÇÃO:

“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer...”

Uma compreensão completa dos requisitos do SI é

fundamental para um bem-sucedido

desenvolvimento.

Levantamento de Requisitos

Os projetos de SI fracassam mais freqüentemente

por resolverem certo o problema errado do que

propriamente resolver errado o problema certo.

Importância do Levantamento de Requisitos:

Projeto e codificação perfeitos são de pouco uso

quando existem erros nos requisitos.

O analista formaliza as necessidades do usuário,

atuando como ponte entre ele e os implementadores do sistema.

Custo da Ambiguidade:

Fase em que se encontra Proporção do custo

Requisitos 1Projeto 3-6Codificação 10Testes de desenvolvimento 15-40

Testes de aceitação 30-70Operação 40-1000

Como descrever os requisitos? A especificação dos requisitos deve ser:

– Completa – deve descrever tudo o que é necessário – Consistente – não deve haver conflitos e contradições – Não-ambígua – não deve levar a interpretações

diferentes por desenvolvedores e usuários. • Depende da precisão da linguagem utilizada

– Linguagem natural, informal – apropriada para os requisitos do usuário e do sistema.

– Linguagens gráficas, semi-formais – apropriada para os requisitos do sistema e do software.

– Linguagens formais – apropriada para uma especificação formal de software em métodos formais.

Requisitos funcionais Descrição das diversas funções que clientes e

usuários querem ou precisam que o software ofereça.

• Exemplos: – "o software deve possibilitar o cálculo dos gastos

diários, semanais, mensais e anuais com pessoal". – "o software deve emitir relatórios de compras a cada

quinze dias" – "os usuários devem poder obter o número de

aprovações,reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

Requisitos não-funcionais

Propriedades de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras

São exemplos de requisitos não-funcionais: "a base de dados deve ser protegida para acesso apenas de

usuários autorizados". "o tempo de resposta do sistema não deve ultrapassar 30

segundos". "o software deve ser operacionalizado no sistema Linux" "o tempo de desenvolvimento não deve ultrapassar seis meses".

TIPOS DE REQUISITOS (revisão)TIPOS DE REQUISITOS (revisão)

Requisitos funcionais – dizem o que o sistema deve fazer. Exs.:Requisitos funcionais – dizem o que o sistema deve fazer. Exs.: Suporte a formataçõesSuporte a formatações

Formatação por parágrafoFormatação por parágrafo

Formatação por caractereFormatação por caractere

Requisitos não-funcionais – indicam as limitações no sistema e em seu Requisitos não-funcionais – indicam as limitações no sistema e em seu desenvolvimentodesenvolvimento

Ser executado em várias plataformasSer executado em várias plataformas Funcionar em um computador com 64 Mb de RAMFuncionar em um computador com 64 Mb de RAM Estar pronto em seis mesesEstar pronto em seis meses

Tipos de requisitos não funcionais

Requisitos de dados

Requisitos ambientais Ambiente físico Ambiente social Ambiente organizacional Ambiente técnico

Requisitos do usuário

Requisitos de usabilidade

.CUIDADOS NA ANÁLISE DE REQUISITOS CUIDADOS NA ANÁLISE DE REQUISITOS Se perguntar não sobre COMO deve ser feita alguma tarefa para

construir o sistema, mas sobre O QUE é exigido

Estar preparado para ambiguidades: “sei que você acredita que entendeu o que acha que eu disse, mas não estou

certo de que percebe que aquilo que ouviu não é o que eu pretendia dizer…”

Etapas que antes eram construídas posteriormente devem ser pensadas em conjunto com a análise:

Construção do manual do usuário Plano dos testes de usabilidade

Atividade

Considerando o Bloco de Notas – descreva os requisitos funcionais e não-funcionais para a criação do sistema.