Aula05-Análise de Requisitos

Engenharia de

Software

Juliana Paschoal Bueno

e-mail:

julianapb@gmail.com

site:

https://sites.google.com/site/engsoft2012/

Tópicos

Requisitos

• Requisitos são descrições dos serviços fornecidos pelo sistema.

• Requisitos devem refletir as necessidades do cliente.

• Exemplos:

• Consultar funcionários. • Fechar um pedido de venda.

Requisitos

• Requisitos podem ser divididos em dois tipos: • Funcionais.

• Não Funcionais.

• Qual a diferença entre os dois tipos de

requisitos?

Requisitos Funcionais

• Descrevem os serviços que o sistema deve oferecer.

• Como o sistema deve reagir em resposta a uma determinada entrada.

• Como o sistema deve comportar-se em determinadas situações.

• O requisito funcional deve ser COMPLETO e

CONSISTENTE.

• COMPLETO: deve incluir descrições de todas as funções requeridas pelo usuário/cliente.

• CONSISTENTE: não podem haver definições contraditórias.

Requisitos Funcionais

Requisitos Funcionais

• Exemplo de requisitos para uma livraria: 1.O sistema deve permitir a consulta de livros

pelo nome, editora ou ano de publicação. 2.O sistema deve permitir o cadastro de livros. 3.O sistema deve permitir a remoção de livros

cadastrados através do nome do mesmo.

4.O sistema deve permitir a alteração de dados dos livros cadastrados através do nome do mesmo.

Requisitos Não Funcionais

• Exemplo: confiabilidade, tempo de resposta. • Descrevem restrições do sistema.

• Exemplo: capacidade dos dispositivos de entrada e saída, apresentação dos dados na interface.

Requisitos Não Funcionais

• Requisitos não funcionais podem ser divididos em três grupos:

• Requisitos de produto. • Requisitos organizacionais. • Requisitos externos.

Requisitos Não Funcionais

• Requisitos de produto: especificam como o produto deve se comportar.

• Confiabilidade, segurança, usabilidade.

• Exemplo: O sistema só poderá ser acessado através da validação de usuário e login.

Requisitos Não Funcionais

• Requisitos organizacionais: requisitos da política e dos procedimentos organizacionais. • Padrões de processos utilizados.

• Exemplo: O processo de desenvolvimento do sistema e dos documentos a serem entregues devem estar em conformidade com o processo padrão de desenvolvimento da empresa.

Requisitos Não Funcionais

fatores externos ao sistema.

• Requisitos legislativos ou requisitos éticos. • Exemplo: O endereço e telefone dos

funionários não podem ser divulgados na intranet.

Análise de Requisitos

• Um programa pode ser muito bem projetado e muito bem codificado, se ele for mal analisado e mal especificado não irá satisfazer o cliente. • O que engloba a tarefa de análise de

requisitos?

• Resposta: descoberta, refinamento, modelagem e especificação.

• Atividade que reúne cliente e analista de requisitos.

Análise de Requisitos

• O analista age como indagador e o cliente tenta passar os conceitos de funções e desempenho do software que ele necessita.

• Problemas da atividade de levantamento de requisitos:

• Muito conteúdo.

• Interpretação errônea. • Ambiguidade

Análise de Requisitos

• A atividade de análise de requisitos permite que o engenheiro de software especifique:

• Funcionalidades do software. • Desempenho do software.

• Interface do software com outros elementos do sistema.

Análise de Requisitos

• O resultado da atividade de análise de requisitos permite ao projetista criar projetos de software. • O resultado da análise de requisitos também

permite que o cliente avalie o software depois de construído.

Análise de Requisitos

• A atividade de análise de requisitos pode ser dividida em 5 áreas: • Verificação do problema. • Avaliação e síntese. • Modelagem. • Especificação. • Revisão.

Análise de Requisitos

• O primeiro passo do analista de requisitos é estudar o problema e seu contexto.

• O segundo passo é estabelecer contato com a administração da organização e com os

usuários/clientes do software que será desenvolvido.

• Depois da comunicação com o cliente, o analista deve definir todas as funções do software.

Análise de Requisitos

• O analista também deve estabelecer as restrições do software.

• E por fim estabelecer as interfaces de entrada e saída.

• Depois de avaliar o problema e as informações de entrada e saída o analista trabalha em uma ou mais soluções.

• O correto é que o processo de levantamento, avaliação e especificação dure até cliente e desenvolvedor sentirem confiança no resultado final.

• O objetivo do analista é descobrir “o que” e não “como”.

• Quais dados o sistema produz, quais dados o sistema consome, quais funções o sistema deve executar e quais funções o sistema não deve executar.

Análise de Requisitos

Analista de Requisitos

• Pode possuir muitos títulos: engenheiro de sistemas, projetista de sistemas, programador, etc.

• O importante é possuir as seguintes características:

• Capacidade de absorver fatos pertinentes de fontes conflitantes ou confusas.

• Capacidade de entender o ambiente do usuário/cliente.

Analista de Requisitos

características:

• Capacidade de se comunicar bem na forma verbal e escrita.

• Capacidade de compreender conceitos abstratos e enxergar soluções.

Analista de Requisitos

• O analista se comunica com o cliente/usuário para levantar os requisitos do sistema.

• O analista se reúne com a equipe de

desenvolvimento para especificar os requisitos e identificar as soluções possíveis.

• O analista é a ponte entre cliente/usuário e equipe de desenvolvimento do software.

Especificação de Requisitos

• Uma boa especificação de requisitos permite um bom projeto de software.

Especificação de Requisitos

desejado.

• Especificação não deve representar “como” é realizado.

• As vezes é necessário descrever o ambiente que o software irá residir.

Especificação de Requisitos

forma como ele é percebido pelos usuários/clientes.

• A especificação deve ser completa e formal para permitir a validação de testes arbitrários.

Especificação de Requisitos

• Justificativa sobre a necessidade do software. • Descrição do escopo do problema.

• Requisitos e suas restrições.

• Condições de desempenho, segurança, etc. • Casos de uso.

Especificação de Requisitos

• Representação de um documento de requisitos: • Deve utilizar tópicos.

• Deve utilizar níveis de detalhamento.

• O conteúdo de uma especificação pode mudar muitas vezes, por isso é importante utilizar uma ferramenta CASE para especificação.

Especificação de Requisitos

documentação de requisitos, mas nenhum padrão único até hoje foi adotado.

• Padrão da disciplina:

• Breve descrição do problema. • Breve descrição da solução.

• Requisitos numerados (podem ser separados por assunto).

Especificação de Requisitos

• Requisitos funcionais iniciados por:

RF<numeração>.

• Requisitos não funcionais iniciados por:

RNF<numeração>.

• Exemplos:

• RF10 O sistema deve permitir ao aluno consultar as notas mensais e bimestrais de cada disciplina.

• RNF01 O tempo de resposta máximo do sistema deve ser de 30 segundos.

Validação de Requisitos

• Fase onde a especificação de requisitos é

revisada.

• O documento de requisitos deve ser revisado pelos analistas e clientes.

• Os participantes da validação devem garantir que os requisitos especificados sejam completos, consistentes e precisos.

Validação de Requisitos

• Exemplos de questões que devem ser consideradas:

• Foram descritas interfaces para todos os

elementos do sistema? • Os diagramas estão claros?

• As funções importantes permanecem dentro

do escopo e cada uma foi adequadamente descrita?

• As restrições de projeto são reais?

Validação de Requisitos

• Exemplos de questões que devem ser consideradas:

• Critérios de validação (do sistema) foram

declarados detalhadamente?

• Existem redundâncias ou omissões?

Validação de Requisitos

• O analista ainda deve prestar atenção nas características descritas abaixo e questioná-las:

• Uso de termos vagos “frequentemente”, “usualmente”, “as vezes”, “na maior parte”, etc.

• Uso de listas que não estejam completas

“etc”, “assim por diante”, “tal como”, “daí para frente”.

• Não permitir aberturas “… os códigos podem variar de 0 a 100…” Inteiros? Reais?

Validação de Requisitos

• O analista ainda deve prestar atenção nas características descritas abaixo e questioná-las:

• Declarações de certeza devem ser provadas

“nunca”, “nenhum”, “sempre”, “todos”. • Desenvolva dois exemplos pelo menos para

Validação de Requisitos

• Terminada a validação, a especificação de requisitos torna-se um contrato entre desenvolvimento e cliente.

• Modificações solicitadas pelo cliente devem ser avaliadas e vão causar aumento do prazo e do custo.

Gerência de Requisitos

• Requisitos de softwares complexos estão sempre sofrendo mudanças.

• Os requisitos podem sofrer alterações devido aos seguintes fatores:

• Sistemas grandes possuem muitos usuários. Pessoas diferentes possuem necessidades diferentes. Em um primeiro momento chega-se a um equilílibrio. Com o tempo percebe-chega-se que isso precisa ser mudado.

Gerência de Requisitos

• Os requisitos podem sofrer alterações devido aos seguintes fatores:

• Quem paga pelo software não é quem irá usá-lo. O cliente impõe restrições de

orçamento e isso pode dar conflito com as necessidades do usuário.

• A empresa e o ambiente técnico sofrem mudanças e o software deve refletir essas mudanças: novo hardware, novos sistemas, novas legislações, etc.

Gerência de Requisitos

• A gerência de requisitos é a atividade de

permitir e controlar mudanças nos requisitos do sistema.

• Ela deve ser feita em paralelo com a elicitação e especificação de requisitos.

Gerência de Requisitos

• Esta atividade deve considerar os seguintes aspectos em seu planejamento:

• Identificação dos requisitos Cada requisito deve ser identificado de maneira única.

• Gerenciamento de mudanças Esforço para avaliar o impacto e o custo das

mudanças.

Gerência de Requisitos

• Esta atividade deve considerar os seguintes aspectos em seu planejamento:

• Políticas de facilidade de rastreamento políticas para definição de relações entre requisitos e projeto.

• Suporte a ferramentas CASE

ferramentas para auxiliar o gerenciamento de requisitos.

Gerência de Requisitos

• Existem 3 tipos de rastreamento de requisitos que podem ser feitos:

• Requisito x Origem vincula o requisito a quem fez a proposta do mesmo.

• Requisito x Requisito vários requisitos são dependentes de outros requisitos.

• Requisito x Projeto vincular os requisitos aos módulos do projeto.

Gerência de Requisitos

• Para realizar os 3 tipos de mapeamentos podemos utilizar matrizes de rastreabilidade. • Para um mapeamento de requisito x requisito

em uma matriz as colunas e as linhas

representarão requisitos e a intersecção linha-coluna a dependência.

Gerência de Requisitos

• Com um ‘X’ marcamos as dependências entre os requisitos. • Exemplo: RF01 RF02 RF03 RF04 RF01 X X RF02 RF03 RF04 X

Gerência de Requisitos

• O gerenciamento de requisitos deve contemplar 3 fases:

• Análise e especificação da mudança

analisar o problema ou a mudança solicitada e especificar uma alteração.

• Análise e custo da mudança efeito da mudança é avaliado utilizando uma matriz. Custo é estimado no documento de requisitos, no projeto e na implementação.

• Implementação da mudança documento de requisitos, projeto e implementação são

Bibliografia

• “Engenharia de Software”

Autor: Roger S. Pressman

Editora: Pearson – Makron Books

• “Engenharia de Software”

Autor: Ian Sommerville

Editora: Pearson – Addison Wesley

• “Engenharia de Software – Os Paradigmas

Clássico e Orientado a Objetos” Autor: Stephen R. Schach

Editora: Mc Graw Hill

Bibliografia

• “Introdução ao RUP: Rational Unified Process”

Autor: Phillippe Kruchten