Carlos Eugênio Palma da Purificação
Carlos Eugênio Palma da Purificação
Conteúdo
Histórico
Problemas
Evolução
Análise Estruturada
Análise Estruturada
Análise Essencial
Histórico
Crise do Software 70s
Criação artesanal – desenho de telas e arquivos
Problemas de execução – bugs
Prazos, custos e qualidade
Sistemas legados sem documentação
Sistemas legados sem documentação
Insatisfação de usuários
Empresas dependentes de software
Proposição da “Engenharia de Software” – 68
Surgimento de Metodologias de Desenvolvimento de
Software
Análise Estruturada
Análise Essencial
Introdução
Definição de Análise.
Relacionamento Usuário-Analista.
Análise
Auxilia no entendimento do software
Gestão de complexidade Diminuição de Custos Diminuição de Riscos Melhora de Qualidade Melhora de Qualidade Melhora de Comunicação
Análise Estruturada – estuda as funções focado nos processos.
Diagrama de fluxo de dados. Dicionário de Dados.
Especificação lógica dos processos.
Análise Essencial – processos, dados e controle – lista de eventos.
Análise Orientada a Objetos – conceitos mais próximos das
Análise Estruturada
Diagrama de Fluxo de Dados
Representa um sistema manual, automático ou ambos.
Perspectiva de funções com ênfase nos processos.
Elementos:
Entidades externas
Depósito de dados
Processo
Fluxo de dados
Diagramas
Diagrama de Contexto
Explosões: Diagrama Zero, Diagramas Extendidos
Especificação lógica do processo.
Análise Estruturada
Diagrama de Contexto 1 2 Diagrama Zero 2 1.1 1.2 2.1 2.2 Diagrama 1 Diagrama 2 Especificação da lógica dos processos Processo 1.1 Processo 1.2 Processo 2.1 Processo 2.2Análise Essencial
Adiciona informações sobre controle baseado em uma lista de eventos externos . O modelo essencial inicial assume que não existem restrições de implementação. Modelos:
Ambiental – fronteira entre o sistema e o ambiente externo.
Diagrama de Contexto Lista de Eventos
Comportamental – comportamento do sistema.
Comportamental – comportamento do sistema. Diagrama de Fluxo de Dados
Dicionário de Dados
Especificação dos processos
Informação – dados que o sistema necessita armazenar ou recuperar.
Diagrama de Entidade e Relacionamento. Dicionário de Dados.
Implementação – extende o modelo inicial levando em conta a implementação. Fronteiras da aplicação
Tempo de execução
Capacidade de armazenamento. Comunicação.
Análise Orientada a Objetos
Segundo Yourdon, “Um sistema construído usando um
método Orientado a Objetos é aquele cujos
componentes são partes encapsuladas de dados e
funções, que podem herdar atributos e
funções, que podem herdar atributos e
comportamentos de outros componentes da mesma
natureza, e cujos componentes comunicam-se entre si
por meio de mensagens.”
Análise Orientada a Objetos
Modelagem focada em objetos que simulam entidades do mundo real.
Objetos mantém seu estado e operam sobre tais dados.
Representação do estado é privado e não pode ser acessado pelo mundo exterior.
Design de objetos, seus dados, operações e relacionamentos.
Usa a Unified Modeling Language para representar o sistema.
Usa a Unified Modeling Language para representar o sistema.
Vários modelos mostrando aspectos diferentes das entidades:
Casos de Uso Classes e Objetos Colaboração Atividades Estados Componentes Execução Implantação
Requisitos de Software
Summerville:
“Processo de estabelecer serviços que o cliente requer de um sistema e
as restrições sobre as quais o sistema opera e é desenvolvido.”
“Os requisitos, desta forma, são descrições dos serviços do sistema e
restrições que são estabelecidas durante a fase de levantamento dos
requisitos.”
requisitos.”
“Propriedade que deve ser exibida por um software desenvolvido ou
adaptado de forma a resolver um problema do mundo real”
Pode expressar uma necessidade ou uma restrição, é tipicamente
identificado unicamente, deve ser tão claro e sem ambigüidade quanto
possível, deve poder ser verificável dentro das restrições existentes de
recursos.
São tipicamente uma combinação complexa de requisitos de diferentes
pessoas, de diferentes níveis da organização e do ambiente em que o
software irá operar.
Requisitos de Software
É iniciado no começo do projeto e refinado ao longo do
ciclo de vida.
É composto de elicitação, análise, especificação e validação.
É fundamentalmente interdisciplinar.
É fundamentalmente interdisciplinar.
Recebe informações de atividades tais como marketing e
estudos de viabilidade.
Necessita ser adaptado para o contexto da organização e do
projeto.
Requisitos de Software
Varia desde uma sentença de alto nível sobre o que o
sistema deve fazer até uma especificação matemática
de uma funcionalidade.
Por exemplo, pode servir a duas funções:
Por exemplo, pode servir a duas funções:
Definição em alto nível dos serviços do sistema para uma
licitação.
Detalhamento do entendimento dos analistas das
Tipos de Requisitos
Requisitos de usuários
Sentenças em linguagem natural, acompanhadas de diagramas sobre as funções do
sistema e suas restrições operacionais. São escritos para o usuário final do sistema. Requisitos de Sistema
Documento detalhado sobre as funções do sistema, serviços e restrições
operacionais. Define o que deve ser implementado podendo servir como contrato operacionais. Define o que deve ser implementado podendo servir como contrato entre o contratante e contratado.
Requisitos funcionais
Definições do que o sistema deve fornecer, como o sistema deve reagir a entradas de dados específicas e como o sistema deve se comportar em situações específicas.
Requisitos não funcionais
Restrições sobre os serviços ou funções oferecidas pelo sistema como tempo de
resposta, ambiente, processo de desenvolvimento de software a ser seguido, padrões de documentação e outros.
Requisitos de domínio
Requisitos que vêem do domínio da aplicação e que refletem as características destes
Requisitos Funcionais
Descreve uma funcionalidade ou serviço do sistema.
Depende do tipo de software, usuários finais e ambiente onde é utilizado.
Requisitos funcionais do usuário podem ser definições de alto nível sobre o que o sistema deve fazer, mas requisitos funcionais do sistema devem descrever os serviços em detalhes.
Exemplos:
Exemplos:
O usuário deve poder procurar em todas as bases de dados disponíveis ou
escolher algum grupo dentre elas.
A aplicação deve prover interfaces apropriadas para o usuário poder ler
documentos armazenados no repositório de documentos.
Toda ordem de compra deve ter um identificador único que pode ser utilizado
Problemas nos Requisitos
Geralmente problemas acontecem quando os requisitos não são suficientemente precisos.
Requisitos ambíguos podem ser interpretados diferentemente pelo usuário e desenvolvedor.
Por exemplo, o termo “visualizador apropriado” pode ser interpretado:
Pelo usuário – visualizador especial para cada tipo de documento. Pelo usuário – visualizador especial para cada tipo de documento.
Pelo desenvolvedor – visualizador de texto para mostrar o conteúdo do
documento.
Os requisitos devem ser completos e consistentes.
Exemplo:
Completo: “Deve incluir descrições de todos os recursos necessários”
Consistente: “Não deve haver conflitos nas descrições dos recursos do sistema”
Na prática, é praticamente impossível produzir documentos totalmente completos e consistentes.
Requisitos não funcionais
Definem propriedades ou restrições do sistema, como por exemplo,
segurança, tempo de resposta e requisitos de armazenamento.
Podem incluir utilização de ferramentas específicas, linguagem de
programação ou metodologia de desenvolvimento.
Podem ser mais críticos do que requisitos funcionais. Por vezes, se não
forem atendidos o sistema se torna inútil.
Classificação:
Classificação:
Requisitos de produto – especificam que o produto produzido deve se comportar de
uma maneira particular, por exemplo, velocidade de execução, resistência a falhas, etc.
Requisitos organizacionais – são consequência de políticas organizacionais, por
exemplo, padrões de documentos e processos, requisitos de implementação, padrões de código e nomenclatura, etc.
Requisitos exeternos – aqueles que surgem de fatores que são externos ao sistema e
ao seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade com outros aplicativos ou ambientes, requisitos legais, etc.
Tipos de Requisitos não
Funcionais
Problemas com objetividade
Requisitos não funcionais podem ser muito difíceis de
definir precisamente e definições imprecisas de requisitos
podem ser difíceis de verificar. Por exemplo:
Um desejo vago do usuário: Facilidade de uso.
Um desejo vago do usuário: Facilidade de uso.
Requisito não funcional verificável
Utiliza alguma forma de medição em que o requisito pode ser objetivamente
mensurado e testado, por exemplo, máximo de 10 segundos de resposta para cada tela.
Conflitos entre requisitos não funcionais são comuns
em sistemas complexos.
Requisitos - Processo
Papel chave em termos do custo e tempo de um
produto de software
Suporte e Gerência do Processo
Recursos
Treinamentos
Treinamentos
Ferramentas
Qualidade e Melhoria do Processo
Padrões e modelos de melhoria
Medições e benchmarking
Requisitos - Elicitação
“Trata da origem dos requisitos e de como os engenheiros de software podem coletá-los”
Identificação dos stakeholders
Estabelecimento do relacionamento entre equipe de
desenvolvimento e cliente
Fontes:
Objetivos gerais e de alto nível do software Conhecimento do domínio Stakeholders Stakeholders Ambiente Operacional Ambiente Organizacional Técnicas: Entrevistas Cenários Protótipos Encontros Facilitados Observação
Requisitos de Software
-Análise
“Trata da detecção e resolução de conflitos entre requisitos, definição da fronteira e da interação com o ambiente, elaboração dos requisitos do sistema para derivar requisitos do software”
Classificação dos requisitos
Classificações já apresentadas Prioridade
Escopo Estabilidade
Negociação dos requisitos
Consenso Consenso Rastreabilidade Modelagem Conceitual
Fluxos de Dados e Controle Dados
Estados
Interações com usuário Objetos
Fatores que influenciam a escolha do modelo:
Natureza do problema
Conhecimento do engenheiro de software O processo de requisitos do cliente
Requisitos de Domínio
Derivados do domínio da aplicação e descreve as características do sistema e características que refletem o domínio.
São novos requisitos funcionais que restrigem requisitos funcionais já definidos ou especificam computações específicas.
Se requisitos de domínio não forem satisfeitos o sistema pode ser tornar inutilizável.
Exemplos:
Deve existir uma interface entre todos os bancos baseado no padrão X.
Por causa de restrições legais os documentos devem ser deletados imediatamente depois que forem Por causa de restrições legais os documentos devem ser deletados imediatamente depois que forem
analisados pelo sistema. Problemas:
Entendimento
Geralmente são especificados na linguagem do domínio da aplicação.
Possivelmente não vai ser entendido por analistas do sistema sem prévio treinamento no domínio da
aplicação.
Elucidação
Os usuários atuantes no negócio entendem tão bem o requisito que não sentem necessidade de maiores
Requisitos do Usuário
Devem descrever aspectos funcionais e não funcionais de uma maneira
que eles sejam entendidos pelos usuários do sistema que não possuem
conhecimento técnico específico.
Requisitos do usuário são definidos utilizando linguagem natural,
tabelas e diagramas já que estes podem ser facilmente entendidos por
todos os usuários.
todos os usuários.
Problemas da linguagem natural:
Falta de clareza – é difícil atingir um alto grau de precisão sem tornar o
documento de difícil leitura.
Mistura de requisitos – requisitos funcionais e não funcionais tendem a
ser misturados.
Condensação de requisitos – muitos requisitos diferentes tendem a ser
Alternativas da LN
Notation Description
Structured natural language
This approach depends on defining standard forms or templates to express the requirements specification.
Design description language s
This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. This approach is not now widely used although it can be useful for interface
specifications. specifications. Graphical
notations
A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT. Now, use-case descriptions and sequence d iagrams are commonly used .
Mathematical specifications
These are notations based on mathematical concep ts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. Howeve r, most customers don’t understand formal specifications and a re reluctant to accept it as a system contract.
Baseado em Formulário
Insulin Pump/Control Software/SRS/3.3.2Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1) Source Current sugar reading from sensor. Other readings from memory. Outputs CompDose Ğ the dose in insulin to be delivered
Destination Main control loop
Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can be delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed. Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin.. Post-condition r0 is replaced by r1 then r1 is replaced by r2
Tabular
Condition
Action
Sugar level falling (r2 < r1)
CompDose = 0
Sugar level stable (r2 = r1)
CompDose = 0
Sugar level increasing and rate of
increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of
increase stable or increasing. ((r2-r1)
(r1-r0))
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
Especificação de Interface
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter void initialize ( Printer p ) ;
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ; void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; } //PrintServer
Boas práticas
Defina um formato padrão e utilize-o para todos os
requisitos.
Use a linguagem de uma forma conviniente e correta.
Use a ferramenta de marcação de texto para identificar
partes importantes dos requisitos. Cuidado para não
Use a ferramenta de marcação de texto para identificar
partes importantes dos requisitos. Cuidado para não
exagerar.
Conceitos Chave
Requisitos definem o que o sistema deve fazer e restrições em sua operação e implementação.
Requisitos funcionais são serviços que o sistema deve prover.
Requisitos não funcionais são restrições ao sistema que está sendo desenvolvido ou ao seu processo de desenvolvimento.
Requisitos de usuário são definições de alto nível sobre o que o sistema deve fazer. Devem ser escritos utilizando linguagem natural, tabelas e diagramas.
Requisitos de usuário são definições de alto nível sobre o que o sistema deve fazer. Devem ser escritos utilizando linguagem natural, tabelas e diagramas.
Requisitos de sistema são destinados a comunicar as funções que o sistema deve prover.
O documento de requisitos de software é um acordo sobre os requisitos do sistema.
O padrão IEEE é útil como um modelo inicial para definição de padrões mais específicos de documentos de requisitos de sistema.
