Requisitos- Análise e Especificação

Transcrição

1 Requisitos- Análise e Especificação Patrícia Macedo Joaquim Filipe João Ascenso Engenharia de Software 2005/2006 EST, Setúbal Fase de definição de requisitos 1

2 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 3 Fase de Requisitos Terminologia Análise de requisitos Actividade de compreeender as necessidades do consumidor Especificação de requisitos Documento 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 deseja Diferença de tempo entre o desejo inicial e as necessidades futuras Processo longo e difícil Engenharia de Software 4 2

3 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ção Podem ser a base para o próprio contrato deste modo devem ser definidos em detalhe Engenharia de Software 5 Técnicas de análise de requisitos Entrevistar o cliente Criar cenários de utilização Criar protótipos Observar o consumidor Identificar os principais papeis/funções Fazer pesquisa Construir glossários Questionar! Questionar! Questionar! Engenharia de Software 6 3

4 Especificação dos requisitos Serve como ponto de referência entre o consumidor e o produtor de software Definem 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 Plataformas Linguagens de implementação Define as qualidades do software Engenharia de Software 7 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 Engenharia de Software 8 4

5 Estrutura do Documento de Especificação de Requisitos 1. Introdução 2. Sumário Executivo 3. Contexto da aplicação 4. Requisitos Funcionais 5. Requisitos Ambientais 6. Requisitos de Qualidade 7. Recursos 8. Riscos potenciais & alterações futuras 9. Documentos de referência e glossários Engenharia de Software 9 Introdução Para quê este documento? Para quem foi criado? Quem o criou? Outline Engenharia de Software 10 5

6 Sumário Executivo Descrição pequena, sucinta, concisa, directo ao assunto Não mais do que uma página Identifica os objectivos principais Identifica as funcionalidades chave Identifica os riscos/obstáculos principais Engenharia de Software 11 Contexto da aplicação Descreve 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 pessoas Fornece uma abstracção para cada um destes aspectos, caracterizando as propriedades e comportamentos que são relevantes Identifica dogmas fundamentais Engenharia de Software 12 6

7 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 13 Exemplo de Identificação dos Requisitos Funcionais Programa para gerir uma empresa de floricultura Mó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. Engenharia de Software 14 7

8 Exemplo UML Diagrama de Casos de Utilização Engenharia de Software 15 Requisitos ambientais Plataformas Hardware Sistemas operativos, tipos de máquinas, memória, espaço em disco Software CORBA, Jini, DCOM, Linguagen(s) de programação Normas Engenharia de Software 16 8

9 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 17 Requisitos de Qualidade Atributo de qualidade Caracteristica Um atributo é uma qualidade que descreve um sistema quantitivamente. [Tom Gilb] Importante - Uma qualidade deve ser sempre mensurável. Engenharia de Software 18 9

10 Exemplo de Classificação dos atributos de Qualidade Atributos de qualidade de um Sistema de Software Desempenho (Work-ability) Capacidade de processamento Capacidade de armazenamento Capacidade de resposta (responsiviness) Disponibilidade Fiabilidade Manutibilidade Integridade Adaptabilidade Extensibilidade Portatibilidade Usabilidade Facilidade de Aprendizagem Eficiência na Utilização Resistencia a erros Satisfação Engenharia de Software 19 Recursos Identifica todos os recursos especificados como requisito do sistema Classes de Recursos Tempo 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 sistema Pessoas 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 Engenharia de Software 20 10

11 Exemplos: Exemplo de Recursos RC 1 - O sistema não poderá custar mais de 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 21 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ça Estas 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 Engenharia de Software 22 11

12 Documentos de Referência e Glossário Glossário Definições precisas dos termos utilizados ao longo do documento de requisitos Documentos de referência Ponteiros para processos e ferramentas existentes a serem utilizados pela organização Ponteiros para software existente que permite a mesma funcionalidade Ponteiros para literatura relevante Engenharia de Software 23 Observações Este documento é estruturado de forma a endereçar os princípios fundamentais: Rigor Separação de assuntos Modularidade Abstracção Antecipação de mudança Generalidade Incrementalidade Nem todos os projectos requerem todas as secções deste documento Engenharia de Software 24 12

13 Exemplo de Motivação - Honda Civic Engenharia de Software 25 Ficha técnica do Honda civic 1.4i-DSI 1.8 i-vtec 2.2 ictdi Motor 4 cil. linha, transv., diant. 4 cil. linha Diesel Cilindrada (cc) Potência máxima (cv/rpm) Binário máximo (Nm/rpm) Velocidade máxima (km/h) km/h (s) Consumos (l/100 km) Extraurbano/combinado /urbano / / / / / / ,6 8,9 8,6 4,9/5,9/7,6 5,2/6,4/8,2 4,3/5,1/6,6 Engenharia de Software 26 13

14 Especificação de atributos - template Nome do atributo: Escala- especificação da escala de medida Teste descrição do teste a utilizar para fazer a medida Pior caso valor mínimo para aceitação do sistema Planeado valor que se espera atingir Actual valor actual de referencia (muitas vezes não está determinado) Engenharia de Software 27 Exemplo - Manutenbilidade Escala - minutos para fazer reparação do software. Teste Unitátrio - 10 reparações consecutivas a cada um dos módulos Sistema 50 reparações de falhas introduzidas aleatóriamente no sistema Pior caso 10 minutos Planeado 5 minutos Actual(sistema antigo) 30 minutos Engenharia de Software 28 14

15 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 29 Métrica Definiçã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 produto Mé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 Engenharia de Software 30 15

16 Medidas para avaliar o desempenho Capacidade de Processamento - unidades por tempo Transações por segundo Bytes por nó e por segundo Registo por segundo Capacidade de resposta tempo por acções Tempo 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 registo Imagens coloridas por disquete Caracteres por linha Engenharia de Software 31 Medidas de Disponibilidade Fiabilidade tempo médio entre falhas Manutenbilidade 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. Engenharia de Software 32 16

17 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 33 Medidas de Usabilidade Facilidade de Aprendizagem- o tempo necessário para aprender a usar um sistema até um determinado nivel de desempenho Eficiê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 hora Número de consulta sobre bibliografia realizados por hora Número de clientes introduzidos no sistema correctamente or dia. Satisfação de utilização Grau de satisfação de utilização Percentagem de utilizadores que apos 4 semanas de utilização referm que preferem utilizar este sistema ao anterior Grau 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. Engenharia de Software 34 17

18 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 35 Testes para medir a Capacidade de Processamento Registo de registo de todas as actividades e respectivos tempos de ocorrencia. Computer logging Manual 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. Engenharia de Software 36 18

19 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 pergunta 2. Tempo de inicialização do programa 3. Tempo de produção de um relatório 4. Tempo para compreender uma resposta dada pelo computador e prosseguir para a acção seguinte. Engenharia de Software 37 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ção da capacidade de armazenamento consumidos por outro software. Engenharia de Software 38 19

20 Testes para medir a Disponibilidade Considerar os aspectos Software Hardware Humanos 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 39 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. Engenharia de Software 40 20

21 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 41 Testes para medir a Usabilidade Facilidade de Aprendizagem Pedir 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. Engenharia de Software 42 21