Eng.ª do Software - 2. Requisitos

ENGENHARIA DO SOFTWARE I

Manuel Menezes de Sequeira

DCTI, ISCTE-IUL

[email protected], D6.02

As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de

Sequeira.

mailto:[email protected]

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE8/Presentations/index.html



Engenharia do Software I 2

Sumário

RequisitosFuncionais e não funcionaisDo utilizadorDo sistemaEspecificação da interfaceDocumento de requisitos de software

2009/2010


Requisitos

2009/2010


Requisitos Um projecto de software tem origem numa

ideia deUma outra empresaUma entidade estatalUm outro departamentoVocê

Requisitos Indicam o que o sistema fará e com que restriçõesParte fundamental da comunicação com o clienteÉ comum integrarem contrato entre as partes!

2009/2010


Engenharia de requisitos

Processo de definição

Dos requisitos do cliente quanto aos serviços a fornecer por um sistema

Das restrições sob as quais o sistema será desenvolvido e operará

A ver na próxima aula.

2009/2010


Tipos de requisitos Do utilizador

Afirmações em língua natural bem como diagramas acerca dos serviços a fornecer pelo sistema e acerca das suas restrições operacionais

Redigido para os clientes

Do sistemaDocumento estruturado com descrições

pormenorizadas das funções, serviços e restrições operacionais do sistema

Define o que deve ser implementado de uma forma que lhe permite ser parte de do contrato com o cliente

2009/2010


Definição e especificação: exemplos Definição de requisito do utilizador

1. “O software fornecerá formas de representar e aceder a arquivos externos criados por outras aplicações”

Especificação de requisito do sistema1. “Serão fornecidos ao utilizador mecanismos para especificar o tipo

dos arquivos externos.

2. Cada tipo de arquivo externo poderá ter associada uma ferramenta que poderá ser aplicada a arquivos desse tipo.

3. Cada tipo de arquivo externo poderá ser representado no ecrã do utilizador usando um ícone específico.

4. Deverão ser fornecidos mecanismos que permitam que o utilizador especifique o ícone associado a cada tipo de arquivo.

5. Quando o utilizador seleccionar um ícone, a ferramenta associada ao tipo de arquivo correspondente deverá ser aplicada ao arquivo representado pelo ícone seleccionado.”

2009/2010

8Engenharia do Software I

Leitores dos requisitos

Requisitos do utilizador

Requisitos do sistema

Especificação do desenho do software

• Gestores de cliente• Utilizadores finais• Engenheiros do cliente• Gestores de contratação• Arquitectos de sistema

• Utilizadores finais• Engenheiros do cliente• Arquitectos de sistema• Desenvolvedores de software

• Engenheiros do cliente (talvez)

• Arquitectos de sistema• Desenvolvedores de software

2009/2010


Especificações… mas a que nível? Especificações mais

próximas do utilizador são (normalmente) mas fáceis de perceber por ele…

…mas mais difíceis de perceber pelo desenvolvedor…

…e vice versa

Cliente

Sistema em execução


Requisitos do sistema

Desenho

Cliente

2009/2010


Requisitos funcionais e não funcionais Requisitos funcionais – Declarações acerca dos serviços

que o sistema deverá fornecer, da forma como deve reagir a entradas específicas e da forma como se deve comportar em situações particulares

Requisitos não funcionais – Declarações acerca das restrições sobre os serviços ou funções oferecidos pelo sistema, incluindo restrições temporais, restrições no processo de desenvolvimento, normas a aplicar, etc.

Requisitos de domínio – Requisitos com origem no domínio de aplicação do sistema e reflectindo características desse domínio

2009/2010


Requisitos funcionais Descrevem a funcionalidade ou serviços do sistema

Dependem do tipo de software, dos utilizadores espectáveis e do tipo de sistema no qual o software será usado

Requisitos funcionais Requisitos funcionais do utilizador – Podem ser

declarações de alto nível acerca do que o sistema deve fazer

Requisitos funcionais do sistema – Devem descrever os serviços do sistema em pormenor

2009/2010


O sistema LIBSYS

Fornece uma interface única de acesso a um conjunto de bases de dados de artigos em diferentes bibliotecas

Utilizadores podem procurar, descarregar e imprimir esses artigos para uso pessoal

2009/2010


Exemplos de requisitos funcionais “O utilizador poderá pesquisar em todo o conjunto

inicial de bases de dados ou num subconjunto de bases de dados por ele definido.”

“A cada encomenda será atribuído um identificador único (ORDER_ID) que o utilizador poderá copiar para a área de armazenamento permanente da conta.”

“O sistema disponibilizará ao utilizador visualizadores apropriados para a leitura de documentos no arquivo de documentos.”

2009/2010


Imprecisão dos requisitos Considere-se a expressão “visualizadores

apropriados” Intenção do utilizador – Um visualizador especializado

para cada tipo específico de documento Interpretação do desenvolvedor – Um visualizador de

texto que mostra o conteúdo do documento

Requisitos ambíguos podem ser interpretados de forma diferente por desenvolvedores e utilizadores

Requisitos imprecisos dão origem a problemas

2009/2010


Completude e consistência de requisitos Por princípio os requisitos devem ser

simultaneamente completos e consistentes

Completude – Devem incluir descrições de todas os mecanismos e funcionalidades requeridos

Consistência – Não deve haver qualquer conflito ou contradição na descrição das funcionalidades e mecanismos do sistema

Na prática é impossível produzir um documento de requisitos completo e consistente

2009/2010


Requisitos não funcionais Definem propriedades e restrições do sistema

Propriedades – Requisitos de fiabilidade, tempo de resposta, armazenamento, etc.

Restrições – Capacidade dos dispositivos de E/S, representações do sistema, etc.

Também podem ser especificados requisitos de processo obrigando à utilização de um dado sistema CASE, de uma dada linguagem de programação ou de um dado método de desenvolvimento

Requisitos não funcionais podem ser mais críticos que requisitos funcionais! Se não forem cumpridos, o sistema é inútil

2009/2010


Classificações não funcionais Requisitos de produto – Especificação que o sistema

fornecido tem de se comportar de determinada forma, e.g., velocidade de execução ou fiabilidade

Requisitos organizacionais – São consequência de políticas e procedimentos organizacionais, e.g., normas processuais usadas ou requisitos de implementação

Requisitos externos – Têm origem em factores externos ao sistema e ao seu processo de desenvolvimento, e.g., requisitos de interoperabilidade ou requisitos legislativos

2009/2010

18Engenharia do Software I

Tipos de requisitos não funcionais

Requisitos não funcionais

De produto Organizacionais Externos

Usabilidade

Eficiência

Fiabilidade

Portabilidade

Fornecimento

Implementação

Normas

Interoperabilidade Éticos

Legislativos

Privacidade Segurança

Desempenho Espaço

2009/2010


Exemplos de requisitos não funcionais Requisito de produto

“A interface com o utilizador do LIBSYS será implementada usando HTML simples, sem frames nem applets Java.”

Requisito organizacional “O processo de desenvolvimento do sistema e os

documentos entregáveis estarão de acordo com o processo de entregáveis definidos no XYZCo-SP-STAN-95.”

Requisito externo “O sistema não revelará aos operadores do sistema

qualquer informação pessoal acerca dos clientes para além do seu nome e número de referência.”

2009/2010


Metas e requisitos Requisitos não funcionais podem ser muito difíceis de

especificar com precisão e requisitos imprecisos podem ser difíceis de verificar

Meta – Uma intenção geral do utilizador, tal como a facilidade de utilização

Requisito não funcional verificável – Uma declaração recorrendo a uma medida que pode ser objectivamente testada

As metas são úteis para os desenvolvedores, uma vez que exprimem as intenções dos utilizadores do sistema

2009/2010


Exemplos Meta

“O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de modo a minimizar erros do utilizador.”

Requisito não funcional verificável“Controladores experientes devem ser capazes

de usar todas as funcionalidades do sistema após duas horas de treino. Após este treino, o número médio de erros cometidos por utilizadores experientes não pode exceder dois erros diários.”

2009/2010


Medidas de requisitosPropriedade Medida

Velocidade • Transacções processadas por segundo• Tempo de resposta ao utilizador/evento• Tempo de refrescamento do ecrã

Tamanho • Tamanho máximo em MB• Número de circuitos ROM

Facilidade de utilização

• Tempo de treino• Número de ecrãs de ajuda

Fiabilidade • Tempo médio entre falhas• Probabilidade de indisponibilidade• Taxa de ocorrência de falhas• Disponibilidade

Robustez • Tempo de rearranque após falha• Percentagem de eventos levando a falhas• Probabilidade de corrupção de dados em caso de falha

Portabilidade • Percentagem de instruções dependendo do sistema alvo• Número de sistemas alvo

2009/2010


Interacção entre requisitos Em sistemas complexos é comum haver

conflitos entre requisitos não funcionais

Sistema espacialPara minimizar o peso é necessário minimizar o

número de circuitos integrados separados do sistema

Para minimizar o consumo devem usar-se circuitos integrados de baixo consumo

No entanto, usar circuitos de baixo consumo pode implicar ter de usar um maior número de circuitos. Qual é o requisito mais crítico?

2009/2010


Requisitos do domínio Derivam do domínio da aplicação e

descrevem características do sistema que reflectem esse domínio

Podem ser novos requisitos funcionais, restrições a requisitos existentes ou definir computações específicas

Se não forem satisfeitos, o sistema pode não ser realizável

2009/2010


Requisitos de domínio do LIBSYS “Devido a restrições quanto a direitos de

autor, alguns documentos têm de ser eliminados logo que cheguem. Dependendo dos requisitos do utilizador, estes documentos serão impressos localmente no servidor do sistema para envio manual ao utilizador ou encaminhados para uma impressora de rede.”

2009/2010


Problemas com requisitos de domínio Compreensíveis?

Requisitos expressos na linguagem do domínio da aplicação

Muitas vezes os engenheiros de software que desenvolvem o sistema não os compreendem

Explícitos?Especialistas do domínio conhecem-no tão

bem que nem pensam em tornar explícitos os requisitos do domínio

2009/2010



Devem descrever requisitos funcionais e não funcionais de tal modo que sejam compreensíveis por utilizadores do sistema que não tenham conhecimento técnico pormenorizado

Definidos usando linguagem natural, tabelas e diagramas que possam ser compreendidos por todos os utilizadores

2009/2010


Problemas da linguagem natural Falta de clareza – É difícil ser preciso

sem tornar o documento difícil de ler

Confusão – Requisitos funcionais e não funcionais tendem a ser confundidos

Amálgama – Diferentes requisitos podem ser expressos em conjunto

2009/2010


Requisito do LIBSYS

“O LIBSYS fornecerá um sistema contabilístico que manterá registos de todos os pagamentos efectuados pelos utilizadores do sistema. Os gestores do sistema poderão configurar este sistema de modo a que utilizadores regulares possam ser beneficiados com preços especiais.”

2009/2010


Linhas de orientação para a redacção de requisitos Escolha um formato padrão e use-o para todos

os requisitos

Use a língua de uma forma consistente. Use o futuro (shall) para todos os requisitos obrigatórios e “é desejável” (should) para todos os requisitos desejáveis

Enfatize as partes cruciais do requisito

Evite usar calão informático

2009/2010


Requisitos de sistema

Especificações mais pormenorizadas do que as dos requisitos do utilizador das funções, serviços e restrições do sistema

Pretende-se que sirvam de base para o desenho do sistema

Podem ser incorporadas no contrato do sistema

2009/2010


Requisitos e desenho Em princípio

Requisitos declararam o que o sistema deve fazer Desenho descreve como o sistema o faz

Na prática são inseparáveisPode desenhar-se uma arquitectura do sistema

para estruturar os requisitosSistema poder interoperar com outros sistemas

que geram requisitos de desenhoA utilização de um desenho específico pode ser

um requisito do domínio

2009/2010


Alternativas à especificação em linguagem natural Notação Descrição

Linguagem natural estruturada

Especificação dos requisitos depende da definição de formulários ou modelos padronizados.

Linguagem de especificação de desenho

Linguagem semelhante a linguagem de programação, mas mais abstracta, especifica os requisitos definindo um modelo operacional do sistema. Abordagem pouco usada. Pode ser útil na especificação de interfaces.

Notações gráficas Usa-se linguagem gráfica, com anotações textuais, para definir requisitos funcionais do sistema. Diagramas de casos de uso e diagramas de sequência do UML são comuns.

Especificações formais (matemáticas)

Notações baseadas em conceitos matemáticos como máquinas de estados finitas ou conjuntos. Permitem especificações não ambíguas. Reduzem conflitos com cliente acerca de funcionalidades. Maioria dos clientes não compreende a linguagem e tem relutância em aceitar como parte do contrato especificações nela expressas.

2009/2010


Especificações em linguagem estruturada Liberdade do redactor dos requisitos limitada por

modelo pré-definido para definir requisitos

Requisitos escritos de forma normalizada

Terminologia usada na descrição pode ser limitada

Mantém-se quase intacta expressividade da língua natural mas impõe-se alguma uniformidade nas especificações

2009/2010


Especificações baseadas em modelos Estrutura

Definição da função ou entidadeDescrição de entradas e sua origemDescrição de saídas e seu destinoIndicação de outras entidades requeridasPré e pós-condições (se apropriado)Efeitos laterais da função (se houver)

2009/2010


Um exemploInsulin Pump/Control Software/SRS/3.3.2

Function 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.

Side-effects None

2009/2010


Especificação tabular

Usada como suplemento à língua natural

Particularmente útil quando é necessário definir vários possíveis cursos de acção

2009/2010


Um exemploCondition 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 CompDose = 0 then CompDose = MinimumDose

2009/2010


Modelos gráficos

Para mostrar mudanças de estado

Para descrever uma sequência de acções

2009/2010


Diagramas de sequência

Mostram sequência de eventos durante interacção de utilizador com sistema

Tempo decorre de cima para baixo

Levantamento de dinheiro de um ATMValidar cartãoLidar com o pedidoCompletar a transacção

2009/2010


Diagrama de sequência de um levantamento de ATM

2009/2010


Especificação de interfaces Maioria dos sistemas operam com outros sistemas

Especificação de interfaces entre sistemas é parte dos requisitos

Pode ser necessário definir interfaces de três tipos Procedimentais Estruturas de dados trocadas Representação de dados

Notações formais são técnica eficaz de especificar interfaces

2009/2010


Exemplo/*

* Defines an abstract printer server.

* Requires: interfaces Printer and PrintDocument

* Provides: initialize, print, displayPrintQueue,

* cancelPrintJob, switchPrinter */interface PrintServer {

void initialize(Printer printer);void print(Printer printer, PrintDocument document);void displayPrintQueue(Printer printer);void cancelPrintJob(Printer printer,

PrintDocument document);void switchPrinter(Printer printer1,

Printer printer2, PrintDocument document);}

2009/2010


Documento de requisitos Declaração oficial daquilo que se requer

dos desenvolvedores do sistema

Deve incluirDefinição dos requisitos de utilizadorEspecificação dos requisitos do sistema

Não é um documento de desenhoAfirma o que o sistema deve fazer……e não como o deve fazer

2009/2010

46

Utilizadores do documento de requisitosQuem Para quê

Clientes do sistema Especificam os requisitos e lêem-nos para garantir que suprem as suas necessidades. Especificam alterações aos requisitos.

Gestores Usam o documento para fazerem a sua proposta e para planearem o processo de desenvolvimento do sistema.

Engenheiros de sistemas Usam os requisitos para desenvolverem testes de validação para o sistema.

Engenheiros de testes de sistemas

Usam os requisitos para desenvolverem testes de validação para o sistema.

Engenheiros de manutenção de sistemas

Usam os requisitos para melhor compreenderem o sistema e as relações entre as suas partes.

2009/2010 Engenharia do Software I


A reter Requisitos – Declaram o que o sistema

deve fazer e definem restrições à sua operação e implementação

Requisitos funcionais – Declaram os serviços que o sistema deve fornecer

Requisitos não funcionais – Restringem o sistema em desenvolvimento ou o processo de desenvolvimento

2009/2010


A reter Requisitos do utilizador – Declarações de alto

nível acerca do que o sistema deve fazer. Expressos usando linguagem natural, tabelas e diagramas.

Requisitos do sistema – Destinam-se a comunicar as funções que o sistema deve fornecer

Documento de requisitos – Declaração dos requisitos do sistema acordada entre as partes

2009/2010

A ler

Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006

Capítulo 6

Capítulo 7

2009/2010 49Engenharia do Software I

Date post:	24-Jan-2015
Category:	Education
Upload:	manuel-menezes-de-sequeira
View:	10,289 times
Download:	0 times

Eng.ª do Software - 2. Requisitos

Education