IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire.

IDENTIFICANDO REQUISITOS

ENGENHARIA DE SOFTWAREProf.: José Eduardo Freire

Engenharia de Software: Teoria e PráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall

Identificando requisitos

Requisito: é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos

Não importa se a funcionalidade do sistema é nova ou antiga, cada sistema tem um propósito, geralmente expresso em termos do que o sistema pode fazer.

Vejamos a figura a seguir:


Engenharia de Software: Teoria ePráticaShari Lawrence Pfleeger Capítulo 4 Prentice Hall

Figura 4.1



Pesquisa da Standish Group relata as causas dos projetos terem falhados: (350 empresas) requisitos incompletos: 13,1% falta de envolvimento dos usuários: 12,4% falta de recursos: 10,6% expectativas não realistas: 9,9% falta de apoio aos executivos: 9,3% modificações nos requisitos e especificações: 8,7% falta de planejamento: 8,1% o sistema não era mais necessário: 7,5%



Três categorias de requisitos: 1-) requisitos que devem ser totalmente

satisfeitos 2-) requisitos que são altamente desejáveis, mas

não necessários 3-) requisitos que são possíveis, mas poderiam

ser eliminados



Exemplo: Um sistema de cobrança de cartões de crédito deve ser capaz de relacionar as despesas atuais, somá-las e solicitar o pagamento para uma certa data, esses são requisitos da categoria 1. Mas ele pode também separar as despesas por tipo de compra, para auxiliar o comprador a entender os padrões de compra, esses são da categoria 2. O sistema de cobrança pode imprimir os créditos em preto e os débitos em vermelho, categoria 3.



OS REQUISITOS IDENTIFICAM “O QUE”O SISTEMA DEVE FAZER, E O PROJETO IDENTIFICA O “COMO FAZER”.

Vamos analisar a figura a seguir, que apresenta as atividades do processo de desenvolvimento de software:



Figura 4.2


Documentos de requisitos Definição dos requisitos: listagem completa

de tudo que o cliente espera que o sistema proposto faça (feita de modo que o cliente entenda)

Especificação dos requisitos: redefine os requisitos em termos técnicos apropriados para o desenvolvimento do projeto do sistema (analista de requisitos)


Documentos de requisitos

Gerência de configuração: correspondência direta entre os dois requisitos, que controlam: os requisitos que definem o que o sistema deverá

fazer os módulos de projeto que são gerados a partir

dos requisitos o código do programa que implementa o projeto os testes que verificam a funcionalidade do

sistema os documentos que descrevem o sistema


Requisitos funcionais versus não-funcionais Funcional: descreve uma

interação entre o sistema e seu ambiente

Exemplos: o sistema dever ter

comunicação com um sistema ‘x’ externo

Quais estados devem ser encontrados para uma mensagem ser enviada

Não-funcional: descreve uma restrição do sistema que limita nossas opções para criar uma solução para o problema

Exemplos: Contracheques distribuídos

em não mais que quatro horas depois de os dados iniciais terem sido lidos

Sistema limita o acesso a gerentes seniores


Tipos de requisitos Ambiente físico Interfaces Usuários e fatores humanos Funcionalidade Documentação Dados Recursos Segurança Garantia de qualidade


Ambiente físico

Onde o equipamento funcionará? Esse funcionamento se dará em um ou

vários locais? Existe alguma restrição ambiental, tal como

temperatura, umidade ou interferência magnética?


Interfaces

A entrada tem origem em outro ou outros sistemas?

A saída vai para outro ou outros sistemas? Existe uma maneira preestabelecida pela

qual os dados devem ser formatados? Existe alguma mídia definida?


Os usuários e os fatores humanos

Quem utilizará o sistema? Haverá diversos tipos de usuário? Qual o nível de habilidade de cada tipo de usuário? Que tipo de treinamento será necessário para cada

tipo de usuário? Que facilidade o usuário terá para entender e

utilizar o sistema? Qual será a dificuldade para que os usuários utilize

inadequadamente o sistema?


Funcionalidade

O que o sistema realizará? Quando o sistema o fará? Existem diversos modos de operaçãp? Como e quando o sistema pode ser

modificado ou aprimorado? Existem limitações quanto à velocidade de

execução, ao tempo de resposta, ou à saída?


Documentação

Que documentação é necessária? Essa documentação deve ser on-line, no

formato de livro, ou ambos? A que público se destina cada tipo de

documentação?


Dados

Qual deverá ser o formato dos dados de entrada e saída?

Com que freqüência eles serão enviados ou recebidos?

Que precisão devem ter? Com que grau de precisão os cáculos devem ser

feitos? Qual será o fluxo de dados do sistema/ Existem dados que devem ser mantidos por

algum tempo?


Recursos

Que materiais, pessoal ou outros recursos são necessários para construir, utilizar e manter o sistema?

Que habilidades os desenvolvedores devem ter?

quanto espaço físico será ocupado pelo sistema?

Quais são os requisitos quanto à energia, ao aquecimento ou condicionamento de ar?


Recursos

Existe um cronograma definido para o desenvolvimento?

Existe um limite de custo para o desenvolvimento ou para a aquisição de hardware ou software?


Segurança

O acesso ao sistema ou às informações deve ser controlado?

Como os dados de um usuário serão isolados dos de outros usuários?

Como os programas dos usuários serão isolados de outros programas e do sistema operacional?

Com que freqüência será feito o backup dos sistema?


Segurança

As cópias de segurança devem ser armazenadas em um local diferente?

Devem ser tomadas precauções contra fogo, danos provocados pela água, ou ocorrência de roubo?


Garantia da qualidade

Quais são os requisitos quanto a confiabilidade, disponibilidade, manutenibilidade, segurança e outros atributos de qualidade?

Como as características do sistema devem ser demonstrada para os outros?

O sistema deve detectar e isolar defeitos? Qual é o tempo médio entre falhas, que foi

determinado? Existe um tempo máximo permitido para reiniciar o

sistema, depois de uma falha?


Garantia da qualidade

Como o sistema pode incorporar modificações no projeto?

A manutenção meramente corrigirá os erros ou também incluirá o aprimoramento do sistema?

Que medidas de eficiência serão aplicadas à utilização dos recursos e ao tempo de resposta?

Com que facilidade o sistema se deslocará de um local para outro, ou de um tipo de computador para outro?


Fontes de Requisitos


Figura 4.3


Características dos Requisitos Estão corretos? São consistentes? Estão completos? São realistas? Cada requisito descreve algo necessário ao

cliente? Podem ser verificados? Podem ser rastreados?


Estão Corretos?

Engenheiros de software, analistas de sistemas, clientes e outros envolvidos devem analisar os requisitos para garantir que eles foram definidos sem erros.


São Consistentes?

Por exemplo, se um requisito informa que, no máximo, 10 usuários podem utilizar o sistema ao mesmo tempo, e outro requisito diz que, em certa situação, pode haver 20 usuários simultaneamente, esses requisitos são inconsistentes.

Dois requisitos são inconsistente, se for impossível satisfazer aos dois simultaneamente.


Estão Completos?

O conjunto de requisitos é completo, se todos os possíveis estados, mudança de estado, entradas, produtos e restrições estiverem descritos por algum requisito.

Diz que a descrição de um sistema é externamente completa, se a descrição contém todas as propriedades do ambiente desejado pelo cliente.

É internamente completa, se não houver referências indefinidas entre os requisitos.


São Realistas?

O que o cliente está pedindo pode realmente ser feito pelo sistema.

Todos os requisitos deverão ser analisados, a fim de assegurar que eles sejam possíveis.


Descreve algo necessário para o cliente?

Algumas vezes, um requisito limita os desenvolvedores desnecessariamente ou inclui funções que não estão diretamente relacionadas com o problema em questão.

Deve-se rever os requisitos, de forma a manter somente requisitos que atuam diretamente na resolução do problema do cliente.


Podem ser Verificados?

Planejar testes que demonstrem que os requisitos foram satisfeitos.


Podem ser Rastreados?

Cada função do sistema pode ser rastreada para um conjunto de requisitos que a exige?

É fácil identificar o conjunto de requisitos que trata de um aspecto específico do sistema?


Como expressar os requisitos

Descrições estáticas Não descreve como os relacionamentos se

modificam ao longo do tempo. Uma descrição do sistema lista as entidades

ou os objetos do sistema, seus atributos e seus relacionamentos com cada um dos outros.


Maneiras de descrever um sistema estaticamente

Referência indireta: um sistema pode ser descrito com uma referência indireta ao problema e sua solução estar implícita e não declarada.

Relações de recorrência :uma condição inicial é definida, e a transformação de uma certa condição na condição seguinte é descrita em termos das condições previamente definidas. (sistema que acompanha a disseminação de uma doença)



Definição axiomática: adequado para o desenvolvimento de sistemas especialistas, uma vez que o comportamento de tal sistema envolve a geração de novas informações a partir de declarações de conhecimento básico sobre um assunto específico.

Expressão como uma linguagem: linguagem de programação, por exemplo.



Abstração de Dados: é uma técnica para descrever para que servem os dados, em vez de como eles se parecem ou de que modo são chamados.


Abstração de dados


Figura 4.4


Descrição Dinâmica

Quando se descreve um sistema em termos das relações entre suas entidades, não há um modo fácil de explicar como o sistema reage às coisas que modificam o seu comportamento em determinado período.

Por isso os engenheiros de software tem desenvolvido técnicas para visualizar o sistema em termos de mudanças que ocorrem com o decorrer do tempo.



Tabelas de Decisão: algumas vezes, é conveniente descrever um sistema como um conjunto de condições possíveis, satisfeitas pelo sistema em determinado momento, de regras para reagir aos estímulos quando certos conjuntos de condições são satisfeitas, e de ações a serem tomadas, como resultado.


Descrições dinâmicas: caso de admissão de calouros - EUA Tabelas de decisão



Descrição Funcional e diagramas de transição: pode-se visualizar um sistema de maneira semelhante a um conjunto de estados, em que o sistema reage a certos eventos possíveis.




Figura 4.5


Descrições dinâmicas Descrição funcional e tabelas de transição


Descrições dinâmicas: notação em UML


Figura 4.7


Descrições dinâmicas: diagrama de transição para reservas de hotel


Figura 4.8


Descrições dinâmicas

Tabelas de eventos: pode-se representar os estados e as transições de um sistema em uma forma tabular diferente.


Descrições dinâmicas Tabelas de eventos


Descrições dinâmicas

Redes de Petri: quando diversos eventos ocorrem de uma vez, algumas vezes um sistema deve realizar processamento paralelo. (emergência de um hospital)


Figura 4.10


Abordagem orientada a objetos

Muito se tem pesquisado segundo este enfoque, que representa o mundo real com objetos e suas interações.

Busca-se a solução dos problemas através de uma modelagem orientada a objetos, conforme mostra a Figura a seguir.



Modelagem

SistemasProblemas Soluções

Mundodos

Objetos



Na AOO a interação entre o usuário e o sistema é baseada em mensagens, que correspondem, na análise estruturada moderna, à associação dos fluxo de dados com os eventos que documentam as solicitações do usuário.



Os grandes problemas da análise de sistemas em quase todos os sistemas estão relacionados com: a compreensão do domínio do problema, comunicação dos fatos, evolução contínua e reutilização.

O desenvolvedor precisa compreender e modelar o domínio do problema, especialmente no caso de sistemas grandes e complexos.

A partir do domínio do problema, concentrar-se-á nos aspectos específicos do seu problema, ou seja, na descrição das responsabilidades do sistema que está sendo considerado, estabelecendo dessa forma as fronteiras do sistema.



Foco está nos dados e nas operações sobre os dados, e não sobre procedimentos.

É baseada na modelagem de objetos do mundo real.

Concentra-se, basicamente, na visão externa do objeto separando seu comportamento de sua implementação (abstração)

Consiste em capturar as informações essenciais das entidades ou objetos envolvidos no contexto do sistema sendo desenvolvido. (abstração)



O que é um objeto? Uma entidade que você pode

reconhecer Uma abstração de um objeto do mundo

real Uma estrutura composta de dados

(“estado local”) e operações (executa processamentos)

Recebe e envia mensagens.



Exemplo de objeto: empregado de uma firma

Estado:Todo empregado tem um nome, carteira de identidade, CIC, endereco, seção na qual trabalha, salário, etc.

Comportamento: Pode-se alterar o salário de um empregado, imprimir seu endereço, etc.



Exemplo de objeto abstrato: ListaEstado Número de elementos. Elementos componentes Comportamento Elementos podem ser inseridos e removidos. Consultar informação exemplos de uso: agenda telefônica; cadastro

de produtos; lista de espera de um vôo...



classe Pessoa

objeto Maria objeto Pedro



Cada entidade no sistema é um objeto. Um método ou uma operação é uma ação que

pode ser realizada pelo objeto ou pode acontecer com o objeto.

Usuário CLASSE: USUÁRIODADOS

OPERAÇÕES



Encapsulamento: maneira pela qual os métodos formam um limite de proteção em torno do objeto (os objetos podem ser manipulados somente por meio de seus métodos)


Abordagem orientada a objetos - Encapsulamento



Hierarquias de classe de objetos estimulam a herança.



Herança é o mecanismo para expressar a similaridade entre Classes, simplificando a definição de Classes iguais a outras que já foram definidas.

Este princípio permite representar membros comuns, serviços e atributos uma só vez, assim como especializar estes membros em casos específicos.



Pessoa

Estudante Professor Funcionário Diretor




Figura 4.12



Polimorfismo: mesmo método para diferentes objetos, cada qual com diferentes comportamentos


MODELAGEM DE SISTEMAS

MODELAR UM SISTEMA significa identificar seus componentes, suas características e comportamentos e o relacionamento entre estes componentes.

Em sistemas OO: Componentes = Entidades Características = Atributos Comportamento = Métodos Relacionamento = Mensagens


Notações de requisitos adicionais Diagramas de fluxo de dados: o diagrama

mostra os dados que fluem para dentro do sistema, como eles são transformados e como eles saem do sistema.

A ênfase é sempre no fluxo dos dados, não no fluxo de controle.

Veja alguns símbolos usados para construir um diagrama:


Notações de requisitos adicionais


Figura 4.14


Notações de requisitos adicionais


Figura 4.15


Prototipação de requisitos Protótipo descartável: exploratório Protótipo evolutivo: base de uma parte ou todo o

software (protótipo para interface) Protótipo rápido: entender os requisitos o decidir

sobre o projeto final.


Documentação de requisitos Documento de definição de requisitos: o que o

cliente gostaria de ver: propósito geral fundamentos e objetivos de desenvolvimento do

sistema descrição da abordagem características detalhadas ambiente operacional

Documento de especificação de requisitos: o que o desenvolvedor precisa saber


Participantes no processo de requisitos

Monitores do contrato Clientes e usuários Gerentes de negócios Projetistas Testadores


Revisão dos requisitos Rever metas e objetivos estabelecidos para o sistema Comparar requisitos metas o objetivos Descrever o ambiente operacional Examinar

interfaces fluxo de informações funções

Verificar omissões, imperfeições e inconsistências Documentar riscos Discutir sobre como o sistema será testado


Escolhendo uma técnica de especificação de requisitos

Aplicabilidade Possibilidade de implementação Testabilidade/simulação Avaliabilidade Manutenibilidade Modularidade Nível de abstração/expressividade Solidez

• Verificabilidade• Segurança durante a execução• Maturidade da ferramenta• Imprecisão• Curva de aprendizado• Maturidade técnica• Modelagem de dados• Disciplina


Fechando o Semestre!!!

A engenharia de software depende muito mais das pessoas do que das fórmulas complicadas, como ocorre nas demais engenharias.

O conhecimento dos princípios da orientação a objetos é de fundamental importância, principalmente porque nos ajuda a pensar em objetos e não apenas em dados ou funções, como era no paradigma tradicional de desenvolvimento de software.


Bibliografia

PFLEEGER, Shari Lawrence. Engenharia de Software. Ed: Prentice Hall. São Paulo, 2004.

Cap. 4 Identificando Requisitos

IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire.

Documents

Transcript of IDENTIFICANDO REQUISITOS ENGENHARIA DE SOFTWARE Prof.: José Eduardo Freire.