Requisitos

 Introduzir os conceitos de requisitos do usuário e

do sistema

 Descrever requisitos funcionais e não-funcionais  Explicar como os requisitos de software podem

 Requisitos Funcionais e Não-Funcionais  Requisitos do usuário

 Requisitos do Sistema

 Especificação da Interface

 O processo de definição dos serviços que o

cliente requer para um sistema e as restrições sob as quais o sistema deve operar e ser

desenvolvido.

 Os requisitos, por si próprios, são as descrições

dos serviços do sistema e as restrições que são geradas durante o processo de engenharia de requisitos.

 Pode variar de uma declaração abstrata de alto

nível até uma restrição do sistema para a especificação de uma fórmula matemática detalhada.

 É inevitável que os requisitos sirvam para duas

funções

 Pode ser a base para lances de um contrato – logo

precisa ser aberta à interpretações;

 Pode ser a base para o próprio contrato – logo precisa

ser definida em detalhes;

 Ambas as afirmações podem ser chamadas de

“Se uma companhia deseja contratar uma empresa para o desenvolvimento de um grande projeto de software, é preciso que sejam definidas as suas necessidades de maneira suficientemente abstrata que não seja uma solução pré-definida. Os requisitos devem ser escritos de maneira que diversas empresas possam participar de uma licitação, ofertando, possivelmente, diferentes formas de atender às necessidades da organização do cliente. Uma vez que a licitação for vencida, o contratado precisa escrever uma definição mais detalhada do sistema para o cliente, de maneira que este possa entender e validar o que será feito pelo software. Ambos os documentos podem ser chamados de documentos de requisitos para o sistema.”

 Requisitos dos usuários

 Afirmações abstratas em linguagem natural mais

diagramas dos serviços que o sistema proverá e suas restrições operacionais. Escrito para o cliente.

 Requisitos do Sistema

 Um documento estruturado definindo descrições

detalhes das funcionalidades do sistema, serviços e restrições operacionais. Define o que deve ser

implementado de maneira que este pode ser parte do contrato entre o contratante e o contratado.

Definição dos requisitos do usuário

O software deve prover formas de representar e acessar arquivos externos criados por outras ferramentas.

Definição dos requisitos do sistema

1.1 O usuário poderá definir o tipo de arquivo externo

1.2 Cada tipo de arquivo externo pode ter uma ferramenta associada a ser aplicado ao arquivo.

1.3 Cada arquivo externo pode ser representado por um ícon específico no display do usuário

1.4 Facilidades devem ser providas para cada ícone que represente uma ferramenta externa definida pelo cliente.

1.5 Quando um usuário seleciona um ícone representando um arquivo

externo, o efeito da seleç!ao é aplicar a ferramenta associada com o tipo de arquivo externo representado pelo ícone selecionado.

Client managers System end-users Client engineers Contractor managers System architects

System end-users Client engineers System architects Software developers

Client engineers (perhaps) System architects Software developers User requirements System requirements Software design specification Requisitos de usuário Requisitos de sistema Especificação do Projeto de software Gerentes do cliente

Usuários finais do sistema Engenheiros do cliente Gerentes do contratado Arquitetos do Sistema

Usuários finais do sistema Engenheiros do cliente Arquitetos do Sistema Desenvolvedores do Software Engenheiros do cliente (?) Arquitetos do Sistema Desenvolvedores do Software

 Requisitos Funcionais

 Declarações de serviços que o sistema deve prover, como o

sistema deve reagir a entradas particulares e como o sistema deve reagir em situações particulares.

 Requisitos Não-Funcionais

 Restrições nos serviços ou funções oferecidas pelo sistema

como restrições de tempo, restrições no processo de desenvolvimento, padrões, etc.

 Requisitos de domínio

 Requisitos que parte do domínio de aplicação do sistema e

 Descrevem funcionalidades ou serviços do

sistema.

 Dependem do tipo do software, usuários

esperados e o tipo de sistema no qual o software será usado.

 Requisitos funcionais do usuário podem ser

definidos como definições de alto-nível de que o sistema deve fazer mas requisitos funcionais do sistema devem descrever os serviços do sistema em detalhes.

 O usuário deve ser capaz de procurar tanto

dentro de todas as bases de dados, como em um subconjunto destas bases.

 O sistema deve prover visualizadores adequados

para que os usuários leiam documentos em um repositório de documentos.

 Todo pedido deve ter alocado um identificador

único (ORDER_ID) o qual deve ser usado para que o cliente copie o documento para uma área de armazenamento permanente do usuário.

 Problemas acontecem quando os requisitos não

são definidos com precisão.

 Requisitos ambíguos podem ser interpretados de

forma diferente pelos desenvolvedores e usuários.

 Considere o termo ‘visualizadores adequados’

 Interpretação do usuário – Visualizador de propósito

geral para cada tipo diferente de documento;

 Interpretação do desenvolvedor – prover um

visualizador de textos que mostre o conteúdo do documento.

 Inicialmente, os requisitos devem ser tanto

completos quanto consistentes.

 Completude

 Devem conter descrições de todas as facilidades

requisitadas.

 Consistência

 Não devem haver conflitos ou contradições nas

descrições das facilidades do sistema.

 Na prática, é impossível produzir um documento de

 Estes definem propriedades do sistema e

restrições, ex. Confiança, tempo de resposta, requisitos de armazenamento. Restrições são

capacidades de E/S, representações do sistema, etc.

 Requisitos de processos podem também ser

especificadas como o sistema CASE usado, a linguagem de programação ou o método de desenvolvimento.

 Requisitos não-funcionais podem ser mais críticos

que requisitos funcionais. Caso estes não sejam atendidos, o sistema pode ser inútil.

 Requisitos dos produtos

 Requisitos que especificam que o produto entregue se

comportará de uma determinada maneira, ex. Velocidade de execução, confiabilidade, etc.

 Requisitos Organizacionais

 Requisitos que são consequencia de políticas de uma

organização ex., padrões no processo, requisitos de implementação, etc.

 Requisitos Externos

 Requisitos que devem de fatores que são externos ao sistema

e ao seu processo de desenvolvimento, ex. Interoperabilidade, requisitos legislativos, etc.

Performance requirements Space requirements Usability requirements Efficiency requirements Reliability requirements Portability requirements Interoperability requirements Ethical requirements Legislative requirements Implementation requirements Standards requirements Delivery requirements Safety requirements Privacy requirements Product requirements Organisational requirements External requirements Non-functional requirements

 Requisitos do Produto

8.1 A interface com o usuário devem ser implementados como um HTML simples sem frames ou applets java.

 Requisitos Organizacionais

9.3.2 O processo de desenvolvimento do sistema e entrega de documentos devem estar em conformidade com os padrões de processo e entregas definidos no XYZCo-SP-STAN-95.

 Requisitos Externos

7.6.5 O sistema não deve ceder nenhuma informação pessoal sobre os

clientes, exceto seus nomes e números de referências aos operadores do sistema.

 Requisitos Não-Funcionais podem ser bem difíceis de

serem precisamente definidos e pode ser difícil verificar requisitos imprecisos.

 Objetivo

 Uma intenção geral do usuário como facilidade de uso.

 Requisito não-funcional verificável

 Uma afirmação usando alguma medida que seja testada

objetivamente.

 Objetivos ajudam os desenvolvedores na medida que

estes entendem melhor as intenções dos usuários do sistema.

 Objetivo do sistema

 O Sistema deve ser fácil de ser utilizado e controles

avançados devem ser organizados de maneira que minimizem os erros.

 Requisitos não-funcionais verificáveis.

 Controladores experientes devem ser capazes de utilizar

todas as funções do sistema após um total de duas horas de treinamento. Depois deste treinamento, a média de erros não deve exceder dois por dia.

 Conflitos entre requisitos não-funcionais

diferentes são comuns em sistemas complexos.

 Sistema espacial

 Para minimizar o peso, o número de chips separados

no sistema devem ser minimizados.

 Para minimizar o consumo de energia, chips de baixo

consumo devem ser usados.

 Entretanto, usar chips de baixo consumo pode

significar que mais chips precisam ser utilizados. Qual o requisito mais crítico?

 Derivado do domínio da aplicação e descrevem as

características do sistema que refletem o domínio.

 Requisitos de domínio podem ser novos requisitos

funcionais, restrições em requisitos existentes ou definir cálculos específicos.

 Se requisitos de domínio não forem satisfeitas, o

 Deve haver uma interface com usuário para todos

os bancos de dados baseados no padrão Z39.50.

 Devido a restrições de copyright, alguns

documentos devem ser apagados imediatamente na chegada. Dependendo dos requisitos do usuário, estes documentos serão tanto impressos localmente no servidor do sistema ou roteados para a impressora da rede.

 A desaceleração de um trem pode ser calculada a

partir de:

 D_trem = D_controle + D_gradiente

onde Dgradiente is 9.81ms2 * gradiente

compensado/alpha e onde os valores de 9.81ms2

/alpha são conhecidamente diferentes para tipos diferentes de trens.

 Entendimento

 Requisitos são expressos na linguagem do domínio da

aplicação;

 Frequentemente, isto não é entendido pelos

engenheiros de software durante o desenvolvimento do sistema.

 Implicações

 Especialistas do domínio entendem tão bem a área

que não pensam em explicitar os requisitos do domínio.

 Devem descrever requisitos funcionais e

não-funcionais de maneira que sejam entendíveis pelos usuários do sistema que não possuem conhecimento técnico.

 Requisitos de usuário são definidos utilizando

linguagem natural, tabelas e diagramas, uma vez que estes são compreendidos por todos os

 Pouca clareza

 Precisão é difícil sem fazer o documento difícil de ser

lido.

 Confusão de requisitos

 Requisitos funcionais e não-funcionais tendem a ser

trocados.

 União de Requisitos

 Muitos requisitos diferentes podem ser

2.6 Facilidades da grade Posicionamento de entes no diagrama,

o usuário pode mover a grade em centímetros ou polegadas, através de opção no painel de controle. No início a grade estará desligada. a grade pode ser ligada ou desligada a qualquer momento durante uma sessão de edição e pode ser trocada entre centímetros e

polegadas a qualquer momento. Uma opção de grid deve ser

provida em uma visão reduzida-para-caber mas o número de linhas da grade mostradas serão reduzidas para evitar o preenchimento de pequenos diagramas com linhas da grade.

 Os requisitos da grade misturam três diferentes tipos

de requisitos

 Requisitos funcionais conceituais (necessidade da grade);  Requisitos não-funcionais (unidades da grade);

 Crie um formato padrão e use-o para todos os

requisitos.

 Use a linguagem de forma consistente. Use Deve

para requisitos obrigatórios, pode para requisitos desejáveis.

 Destaque no texto as principais partes do

requisito.

 Especificações mais detalhadas das funções do

sistema, serviços e restrições que os requisitos do usuário.

 Eles são destinados a serem a base para o

projeto do sistema.

 Eles podem ser incorporados ao contrato do

sistema.

 Requisitos do sistema podem ser definidos ou

ilustrados usando modelos de sistema (capítulo 8 do Sommerville).

 A princípio, requisitos devem reportar o que o

sistema deve fazer e o projeto como ele deve fazer.

 Na prática, requisitos e projeto são inseparáveis

 Uma arquitetura de sistema pode ser projetada para

estruturar os requisitos;

 O sistema pode inter-operar com outros sistemas que

gerem requisitos do projeto;

 O uso de um projeto específico pode ser um requisito

 Ambiguidade

 OS leitores e escritores dos requisitos devem

interpretar as mesmas palavras da mesma maneira. LN é naturalmente ambígua portanto isto é muito difícil.

 Sobre-flexibilidade

 A mesma coisa pode ser dita de diversas formas

diferentes na espeficicação.

 Falta de modularização

 Estruturas LN são inadequadas para estruturar os

 A liberdade do escritor dos requisitos é limitada

por um padrão predefinido de requisitos.

 Todos os requisitos são escritos de forma

padronizada.

 A terminologia usada na descrição pode ser

limitada.

 A vantagem é que a maior parte da

expressividade em linguagem natural é mantida mas é imposto um certo grau de uniformidade à especificação.

 Definição da função ou entidade

 Descrição das entradas e de onde elas vem.  Descrição das saídas e para onde elas vão.  Indicações de outras entidades necessárias.  Pré e pós condições (Se for o caso).

 Usada para complementar a linguagem natural.  Particularmente útil quando é preciso definir

diversos conjuntos de ações alternativas possíveis.

 Modelos gráficos são mais úteis quando é

necessário mostrar como os estados mudam ou quando é necessário descrever uma sequencia de ações.

 Diferentes modelos gráficos são explicados no

 Estes mostram a sequencia dos eventos que

ocorrem quando existe alguma interação com o sistema.

 O diagrama é lido de cima para baixo para se ver

a ordem das ações.

 Saque do dinheiro em um caixa eletrônico

 Valida o cartão;

 Processa a requisição;  Completa a transação.

ATM Database Card Card number Card OK PIN request PIN Option menu <<exception>> invalid card Withdraw request Amount request Amount Balance request Balance <<exception>> insufficient cash Debit (amount) Debit response Card Card removed Cash Cash removed Receipt Validate card Handle request Complete transaction

 A maioria dos sistemas deve operar com os outros

sistemas as interfaces de operação devem ser especificadas como parte dos requisitos.

 Três tipos de interface podem ser definidos

 Interfaces Procedurais;

 Estruturas de dado que são trocadas;  Representação dos dados.

 Notações formais são técnicas efetivas para

interface PrintServer {

// defines an abstract printer server

// requires: interface Printer, interface PrintDoc

// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter 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

 O documento de requisitos é o comprovante

oficial do que é requerido dos desenvolvedores do sistema.

 Devem incluir uma definição dos requisitos do

usuário e uma especificação dos requisitos do sistema.

 NÃO é um documento de projeto. Sempre que

possível, ele deve definir o QUÊ será o sistema ao invés de COMO ele fará.

Use the requirements to develop validation tests for

the system Use the requirements document to plan a bid for the system and to plan the system development process

Use the requirements to understand what system is to

be developed System test engineers Managers System engineers

Specify the requirements and read them to check that they

meet their needs. They specify changes to the

requirements System

customers

Use the requirements to help understand the system and the relationships between its

parts System

maintenance engineers

 Definem uma estrutura genérica para o

documento de requisitos que devem ser instanciadas para cada sistema específico.

 Introdução.

 Descrição geral.

 Requisitos específicos.  Apendice.

 Prefácio  Introdução  Glossário

 Definição dos requisitos do usuário  Arquitetura do sistema

 Especificação dos requisitos do sistema  Modelos do sistema

 Evolução do sistema  Apêndices

 Requisitos definem o que o sistema deve fazer e

define as restrições de operação e implementação.

 Requisitos funcionais definem os serviços que o

sistema deve prover.

 Requisitos não-funcionais restringem o sistema que

está sendo desenvolvido e o processo de desenvolvimento que deve ser usado.

 Requisitos de usuário são afirmações em alto-nível de

que o sistema deve fazer. Requisitos de usuário

podem ser escritos usando linguagem natural, tabelas e diagramas.

 Requisitos de sistema são destinados a comunicar as

funções que o sistema deve prover.

 O documento dos requisitos do software é um acordo

sobre os requisistos do sistema.

 O padrão IEEE é um ponto de partida para a definição