requisitos- análise e especificaçãoltodi.est.ips.pt/es/index_files/pdf/6especificação de...

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.


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


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


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


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


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


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


Introdução

Para quê este documento ?Para quem foi criado ?Quem o criou ?Outline

6


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


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


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


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


ExemploUML

Diagrama de Casos

de Utilização


Requisitos ambientais

PlataformasHardware

Sistemas operativos, tipos de máquinas, memória, espaço em disco

SoftwareCORBA, Jini, DCOM, …

Linguagen(s) de programaçãoNormas

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


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


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


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


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.


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


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


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


Exemplo de Motivação - HondaCivic


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


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)


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


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.


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


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


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


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.


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


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.


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


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.


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


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.


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


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.


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.

requisitos- análise e especificaçãoltodi.est.ips.pt/es/index_files/pdf/6especificação de...

Documents