Upload
dinhthuan
View
244
Download
0
Embed Size (px)
Citation preview
1
Requisitos- Análise e Especificação
Patrícia MacedoJoaquim FilipeJoão Ascenso
Engenharia de Software 2005/2006EST, Setúbal
Fase de definição de requisitos
2
Engenharia de Software 3
Fase de Requisitos: O que é ?
O processo de estabelecer os serviços que o consumidor necessita por parte de um sistema
i.e. descrições das tarefas e restrições que o software deve possuir
Um requisito tanto pode ser um conceito abstracto como uma especificação matemática detalhada de um sistema.
Engenharia de Software 4
Fase de RequisitosTerminologia
Análise de requisitosActividade de compreeender as necessidades do consumidor
Especificação de requisitosDocumento a descrever as necessidades do consumidor
Os requisitos tratam das necessidades do consumidor, não do que o consumidor pretende
Muitas das vezes o consumidor não sabe o que desejaDiferença de tempo entre o desejo inicial e as necessidades futurasProcesso longo e difícil
3
Engenharia de Software 5
Análise de Requisitos
Engenharia de Sistemas vs Engenharia de Software
Que papel têm o software no sistema completo ?Tendência: o software está em todo o lado
Até nos chips de computador
A análise de requisitos pode ter objectivos diferentes:
Podem ser a base para uma contrato – deste modo devem estar abertos a interpretaçãoPodem ser a base para o próprio contrato – deste modo devem ser definidos em detalhe
Engenharia de Software 6
Técnicas de análise de requisitos
Entrevistar o clienteCriar cenários de utilizaçãoCriar protótiposObservar o consumidorIdentificar os principais papeis/funçõesFazer pesquisaConstruir glossáriosQuestionar! Questionar! Questionar!
4
Engenharia de Software 7
Especificação dos requisitosServe como ponto de referência entre o consumidor e o produtor de softwareDefinem as funcionalidades do sistema sem especificar a forma como estas devem ser alcançadas
Define o “quê ?”Não define o “como”
Define requisitos ambientais do software para guiar os programadores
PlataformasLinguagens de implementação
Define as qualidades do software
Engenharia de Software 8
Será Necessário ?
Uma especificação de requisitos é a fonte para todos os passos futuros do ciclo de vida do software
É a base para um entendimento mútuo entre:Consumidor (o que pretende)Produtor de software (o que constrói)
Identifica dogmas fundamentaisÉ melhor construí-lo correctamente
Após a entrega, algum software é rejeitado pelos consumidores
As alterações são baratasÉ melhor fazê-las agora do que mais tarde
5
Engenharia de Software 9
Estrutura do Documento de Especificação de Requisitos
1. Introdução2. Sumário Executivo3. Contexto da aplicação4. Requisitos Funcionais5. Requisitos Ambientais6. Requisitos de Qualidade7. Recursos8. Riscos potenciais & alterações futuras9. Documentos de referência e glossários
Engenharia de Software 10
Introdução
Para quê este documento ?Para quem foi criado ?Quem o criou ?Outline
6
Engenharia de Software 11
Sumário Executivo
Descrição pequena, sucinta, concisa, directo ao assunto
Não mais do que uma página
Identifica os objectivos principaisIdentifica as funcionalidades chaveIdentifica os riscos/obstáculos principais
Engenharia de Software 12
Contexto da aplicaçãoDescreve o contexto em que o software vai ser usado
Quanto é que o ambiente muda como resultado da introdução do software?“Modelo do Mundo”
Identifica todos os aspectos que o sistema influencia
Objectos, processos, outro software, hardware e pessoasFornece uma abstracção para cada um destes aspectos, caracterizando as propriedades e comportamentos que são relevantes
Identifica dogmas fundamentais
7
Engenharia de Software 13
Requisitos Funcionais
Identifica todos os conceitos, funções, características e informações que o sistema deve fornecer aos utilizadores
O que é que o sistema deve fazer?Que informação o sistema deve possuir ?O que é que é suposto acontecer quando algo corre mal?
Um esboço da interface faz parte dos requisitos funcionais
Engenharia de Software 14
Exemplo de Identificação dos Requisitos Funcionais
Programa para gerir uma empresa de floriculturaMódulo Viveiro:RF1 -Permite a introdução de flores ou plantas no viveiro.RF2 - Envia a informação relativa às plantas ou flores prontas a colocar no mercado, neste caso, a informação é enviada às lojas. É enviada uma mensagem contendo os seguintes dados: Nome, Cor, Quantidade, Preço, Loja Destino.Modulo Lojas:RF3 - Permitir a consulta de Flores ou Plantas disponíveis na loja.RF4 - Actualiza os dados aquando da venda ou recepção de novas plantas ou flores.RF 4- Controla os limites de armazém das Lojas. Cada loja não poderá receber mais que a sua capacidade de armazenamento.
8
Engenharia de Software 15
ExemploUML
Diagrama de Casos
de Utilização
Engenharia de Software 16
Requisitos ambientais
PlataformasHardware
Sistemas operativos, tipos de máquinas, memória, espaço em disco
SoftwareCORBA, Jini, DCOM, …
Linguagen(s) de programaçãoNormas
9
Engenharia de Software 17
Exemplo de Especificação de Requisitos Ambientais
RA 1 - Hardware: Computador baseado num CPU de arquitectura x86, com um mínimo de 2mb de Disco Rígido, e cerca de 32mb de RAM.RA 2 - Software: Sistema Operativo GNU/Linux.RA 3 - Linguagem Programação: C
Engenharia de Software 18
Requisitos de QualidadeAtributo de qualidade Caracteristica
“Um atributo é uma qualidade que descreve um sistema quantitivamente”. [Tom Gilb]
Importante - Uma qualidade deve ser sempre mensurável.
10
Engenharia de Software 19
Exemplo de Classificação dos atributos de Qualidade
Atributos de qualidade de um Sistema de SoftwareDesempenho (Work-ability)
Capacidade de processamentoCapacidade de armazenamentoCapacidade de resposta (responsiviness)
DisponibilidadeFiabilidadeManutibilidadeIntegridade
AdaptabilidadeExtensibilidadePortatibilidade
UsabilidadeFacilidade de AprendizagemEficiência na UtilizaçãoResistencia a errosSatisfação
Engenharia de Software 20
RecursosIdentifica todos os recursos especificados como requisito do sistema
Classes de RecursosTempo – Quanto tempo, calendarização.Pessoas – quantas pessoas e que pessoas.
Pessoas para desenvolver o projecto (Especificação de nº de homem /ano)Pessoas para manter o sistemaPessoas para operaro sistema
Dinheiro – custos e planeamento dos custos. O orçamento disponível para o projecto pode ser um requisito essencial.Ferramentas – Todas os recursos materias (computadores, ferramentas de software, mesas, impressoars etc.) necessários
11
Engenharia de Software 21
Exemplo de Recursos
Exemplos: RC 1 - O sistema não poderá custar mais de 10000 euros.RC 2 - O sistema deverá poder ser operado apenas por uma pessoa.RC 3 - O sistema deverá ser entregue até ao dia 10 de Junho.RC 4 - A Documentação deverá ser produzida utilizando a ferramenta de software da Rational Rose.
Engenharia de Software 22
Riscos potenciais & alterações futuras
Qualquer projecto sofre riscosÉ muito importante identificar os riscos de forma a que o consumidor e o produtor (!) estejam conscientes da sua presença
Qualquer projecto sofre mudanças ao longo do tempo
É muito importante identificar as alterações possíveis à partida de forma a que o consumidor e o produtor (!) estejam conscientes da sua presençaEstas alterações podem ser simplesmente algumas melhorias ao produto
Um dos requisitos pode ser construir o produto de forma que este possa acomodar alterações futuras
12
Engenharia de Software 23
Documentos de Referência e Glossário
GlossárioDefinições precisas dos termos utilizados ao longo do documento de requisitos
Documentos de referênciaPonteiros para processos e ferramentas existentes a serem utilizados pela organizaçãoPonteiros para software existente que permite a mesma funcionalidadePonteiros para literatura relevante
Engenharia de Software 24
Observações
Este documento é estruturado de forma a endereçar os princípios fundamentais:
RigorSeparação de assuntos
ModularidadeAbstracção
Antecipação de mudançaGeneralidadeIncrementalidade
Nem todos os projectos requerem todas as secções deste documento
13
Engenharia de Software 25
Exemplo de Motivação - HondaCivic
Engenharia de Software 26
Ficha técnica do Honda civic
4,3/5,1/6,6 5,2/6,4/8,24,9/5,9/7,6Consumos (l/100 km)Extra-urbano/combinado/urbano
8,6 8,914,60-100 km/h (s)
205 205170Velocidademáxima (km/h)
340/2000174/4300119/2800Binário máximo(Nm/rpm)
140/4000 140/630083/5700Potência máxima(cv/rpm)
2204 17991339Cilindrada (cc)
4 cil. linha Diesel4 cil. linha, transv., diant.Motor
2.2 iCTDi1.8 i-VTEC1.4i-DSI
14
Engenharia de Software 27
Especificação de atributos -template
Nome do atributo:Escala- especificação da escala de medidaTeste – descrição do teste a utilizar para fazer a medidaPior caso – valor mínimo para aceitação do sistemaPlaneado – valor que se espera atingirActual – valor actual de referencia (muitas vezes não está determinado)
Engenharia de Software 28
Exemplo - Manutenbilidade
Escala - minutos para fazer reparação do software.Teste –
Unitátrio - 10 reparações consecutivas a cada um dos módulosSistema – 50 reparações de falhas introduzidas aleatóriamente no sistema
Pior caso – 10 minutosPlaneado – 5 minutosActual(sistema antigo) – 30 minutos
15
Engenharia de Software 29
Medir
Na especificação dos Requistos de um sistema, as qualidades pretendidas e os recursos disponíveis devem ser quantificados.A quantificação implica uma medida.Exemplo: Queremos quantificar a obsedidade de uma pessoa.
1. Temos que definir como vamos quantificar essa obesidade: Ratio Peso/Altura
2. Temos que definir como vamos medir o Peso e a Altura.3. Temos definir a partir de que valores (definir uma escala e um
nivel de aceitação) consideramos a pessoa obesa.
Engenharia de Software 30
MétricaDefinição- Medida quantitativa para do grau de posse de um atributo de um produto ou de um processo.
O domínio das Métricas de Software divide-se em:Métricas para avaliar o produtoMétricas para avaliar o processo.Métricas para avaliar o projecto.
Para a especificação de requisitos de qualidade do sistema a desenvolver vamos estudar as métricas para medir quantitativamente os atributos de qualidade do sistema. As restantes métricas serão estudadas posteriormente
16
Engenharia de Software 31
Medidas para avaliar o desempenhoCapacidade de Processamento - unidades por tempo
Transações por segundoBytes por nó e por segundoRegisto por segundo
Capacidade de resposta –tempo por acçõesTempo desde o contacto telefonico ser estabelecido até a resposta satisfatória ao cliente ser dada.Tempo desde a selecção do produto, até à entrega do produto.Tempo desde o pedido de emissão de recibo até à entrega desse.
Capacidade de armazenamento - unidades de armazenamento por contentor
Bytes por registoImagens coloridas por disqueteCaracteres por linha
Engenharia de Software 32
Medidas de Disponibilidade
Fiabilidade – tempo médio entre falhasManutenbilidade – tempo médio de reparação
tempo médio para reparar 9 de 10 erros.tempo médio para reparar um byte num ficheiro.Tempo medio recuperar a base de dados com 100 erros colocados aleatoriamente
Integridade – percentagem de tempo que o sistema está isento de “ataques” intencionais ou premeditados.
17
Engenharia de Software 33
Medidas de Adaptabilidade
Extensabilidade – tempo, custo para realizar alterações sem prejuizo das restantes qualidades
Possibilidade de duplicar o número de registo na base de dados, sem prejuízo para a disponibilidade, fiabilidade e integridade do sistema como o custo de 5 homens dia.
Portabilidade - Percentagem complementar do esforço para transferir o sistema em relação ao esforço de construir um novo
O sistema deve ser 99% portavel para qualquer PC com placa processadora com capacidade igual ou superior a …O sistema deve ser 95% portável para o Sistema operativo Linux.
Engenharia de Software 34
Medidas de Usabilidade
Facilidade de Aprendizagem- o tempo necessário para aprender a usar um sistema até um determinado nivel de desempenhoEficiência de utilização – mede a produtividade para realizar um conjunto de tarefas, apos treino adequado
Número de paginas de texto escritas e formatadas por hora.Número de registos de IRS introduzidos por horaNúmero de consulta sobre bibliografia realizados por horaNúmero de clientes introduzidos no sistema correctamente or dia.
Satisfação de utilização – Grau de satisfação de utilizaçãoPercentagem de utilizadores que apos 4 semanas de utilização refermque preferem utilizar este sistema ao anteriorGrau médio de satisfação (escala 0-5) sobre a satisfação de utilização do sistema, apos 3 semanas de uso regular do mesmo.
18
Engenharia de Software 35
Métodos para medir as características de qualidade
Em seguida indicaremos alguns métodos para medir as características de qualidade relativamente ao: Desempenho, Disponibilidade, Adaptabilidade, Usabilidade.
Nota: Para cada uma das caracteristicas existem diversos métodos para as medir. Apresentam-se em seguida alguns exemplos.
Engenharia de Software 36
Testes para medir a Capacidade de Processamento
Registo de registo de todas as actividades e respectivos tempos de ocorrencia.
Computer loggingManual logging
Análise estatistica dos dados recolhidos
Possíveis Perigos: Os dados não devem ser recolhidos perante um pico de actividade, pois podem distorcer os resultados.
logging - registo de todas as actividades e respectivos tempos.
19
Engenharia de Software 37
Testes para medir a Capacidade de Resposta
Medir o tempo entre o evento pergunta e resposta. Seleccionar quais os pontos que se vai medir.
Exemplos para possíveis pontos de teste:1. Tempo de resposta do computador a uma determinada
pergunta2. Tempo de inicialização do programa3. Tempo de produção de um relatório4. Tempo para compreender uma resposta dada pelo
computador e prosseguir para a acção seguinte.
Engenharia de Software 38
Testes para medir a Capacidade de Armazenamento
A capacidade de armazenamento vem normalmente já definida no dispositivo físico em questão. Nesta característica é importante determinar qual é a capacidade útil de armazenamento de dados. Possíveis Perigos: Normalmente a capacidade útil não é um valor constante, pois depende da varaiçãoda capacidade de armazenamento consumidos por outro software.
20
Engenharia de Software 39
Testes para medir a Disponibilidade
Considerar os aspectosSoftwareHardwareHumanos
O tempo efectivo em que o sistema estádisponível é registado durante um período de vários dias (30 dias por exemplo). Recorre-se ao logging e análise do mesmos.
Engenharia de Software 40
Testes para medir a Fiabilidade
Um conjunto de “inputs” é introduzido no sistema e são analisados os outputs, para verificar o sistema se comporta conforme o esperado. (se realiza as funções esperadas)Para testar a fiabilidade de base de dados recorre-se a programas para testar intensivamente os registos.Testar a fiabilidade de um programa écomplexo e demorado. O planeamento do testes é imprescindivél.
21
Engenharia de Software 41
Testes para medir a Manutenbilidade
Com o sistema em funcionamento, introduzem-se artificialmente erros de vários tipos e regista-se o tempo que se demora a colocar o sistema novamente operacional.Para calculo de manutenbilidade deve considera-se o total do tempo, desde que o erro é detectado, ou o sistema deixa de operar correctamente até o sistema estar a trabalhar novamente de forma correcta.
Engenharia de Software 42
Testes para medir a Usabilidade
Facilidade de AprendizagemPedir o tempo médio que um grupo de pessoa com a formação base adequada, demora para operar correctamente o sistema. A avaliação se a pessoa sabe trabalhar correctamente com o sistema pode ser feita através de um teste , onde um conjunto de actividades são solicitadas ao utilizador.