Requisitos de Software
-
Upload
renato-ribeiro-silva -
Category
Documents
-
view
213 -
download
0
description
Transcript of Requisitos de Software
![Page 1: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/1.jpg)
Alexandre Monteiro
![Page 2: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/2.jpg)
Introduzir os conceitos de requisitos do usuário e do sistema
Descrever requisitos funcionais e não-funcionais
Explicar como requisitos de software devem ser organizados em um documento de requisitos
![Page 3: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/3.jpg)
Tanto pode ser uma declaração abstrata de alto nível de um serviço ou restrição do sistema quanto uma especificação funcional matemática detalhada
![Page 4: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/4.jpg)
Requisitos do Usuário◦ Declarações em linguagem natural com
diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes
Requisitos do Sistema◦ Documento estruturado com descrições
detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor
Especificação do Software◦ Descrição detalhada do software que serve
como base para projeto ou implementação. Escrito para desenvolvedores
![Page 5: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/5.jpg)
Requisitos Funcionais◦ Declarações sobre o que o sistema deve
oferecer, como o sistema deve reagir a determinadas entradas e como o sistema deve comportar-se em situações especiais
Requisitos Não-Funcionais◦ Restrições sobre funções ou serviços oferecidas
pelo sistema (tempo, processo de desenvolvimento, padrões, etc)
Requisitos de Domínio◦ Requisitos vindos do domínio da aplicação do
sistema e que refletem características desse domínio
![Page 6: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/6.jpg)
Descreve funcionalidade e serviços do sistema
Depende do tipo do software, usuários esperados e o tipo do sistema onde o software é usado
Requisitos funcionais do usuário devem ser declarações de alto nível sobre o que o sistema deve fazer
Requisitos funcionais do sistema devem descrever os serviços do sistema em detalhes
![Page 7: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/7.jpg)
O usuário poderá pesquisar todo o conjunto inicial de banco de dados ou selecionar um sub-conjunto dele
O sistema deve oferecer visualizadores apropriados para o usuário ler documentos armazenados
A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta
![Page 8: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/8.jpg)
Problemas podem surgir quando os requisitos não são estabelecidos precisamente
Requisitos ambíguos podem ser interpretados diferentemente por usuários e desenvolvedores
Considere o termo ‘visualizadores apropriados´◦ Visualizador de propósito especial para cada
tipo de documento diferente (Usuário)◦ Oferecer um visualizador de texto que mostra o
conteúdo do documento (Desenvolvedor)
![Page 9: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/9.jpg)
Em princípio, requisitos devem ser completos e consistentes
Completo◦ Descrições de todos os serviços
Consistência◦ Não deve haver conflitos e contradições nas
descrições dos serviços Na prática, torna-se impossível produzir
um documento de requisitos completo e consistente
![Page 10: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/10.jpg)
Definem propriedades e restrições do sistema (tempo, espaço, etc)
Requisitos de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento
Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil.
![Page 11: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/11.jpg)
Requisitos do Produto◦ Produto entregue deve comportar-se de forma
particular (velocidade de execução, confiabilidade, etc)
Requisitos Organizacionais◦ Conseqüência de políticas e procedimentos
organizacionais (padrões de processo usados, requisitos de implementação, etc)
Requisitos Externos◦ Conseqüência de fatores externos ao sistema e
ao processo de desenvolvimento (legislação, etc)
![Page 12: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/12.jpg)
Requisitos do Produto◦ Toda consulta ao banco de dados baseada em
código de barras não deve exceder 5 s Requisitos Organizacionais
◦ Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00
Requisitos Externos◦ O sistema não deve usar informações pessoais
do usuário com os operadores do sistema
![Page 13: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/13.jpg)
Requisitos não-funcionais podem ser muito difíceis de serem estabelecidos precisamente e requisitos imprecisos difíceis de verificar
Objetivo◦ Intenção geral do usuário (facilidade de uso)
Requisito não-funcional verificável◦ Declaração usando alguma medida que possa
ser testada objetivamente Objetivos são úteis aos desenvolvedores
uma vez que eles apresentam as intenções dos usuários do sistema
![Page 14: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/14.jpg)
Um objetivo do sistema◦ Sistema deve ser fácil de usar por usuários
experientes e organizado de forma a minimizar erros do usuário
Um requisito não-funcional verificável◦ Usuários experientes devem ser capazes de usar
toda a funcionalidade do sistema após 2h de treinamento. Após treinamento, erros não podem ultrapassar 2 por dia
![Page 15: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/15.jpg)
Derivados do domínio da aplicação e descrevem características do sistema e qualidades que refletem o domínio
Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas
Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se não prático
![Page 16: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/16.jpg)
Deve existir uma interface padrão com o usuário para todos os bancos de dados baseada no padrão ABC-98
Devido a restrições de direitos autorais, alguns documentos devem ser apagados assim que chegam. Dependendo dos requisitos do usuário, tais documentos devem ser impressos em impressora local ou remota.
![Page 17: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/17.jpg)
A desaceleração do trem deve ser computada através da fórmulaDtrem=Dcontrole+Dgradiente onde ...
![Page 18: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/18.jpg)
Entendimento◦ Requisitos são descritos na linguagem do domínio
da aplicação◦ Não é entendido pelos engenheiros de software
que vão desenvolver a aplicação Implicitude
◦ Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos
![Page 19: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/19.jpg)
Devem descrever requisitos funcionais e não-funcionais de tal forma que sejam entendíveis pelos usuários do sistema que não têm conhecimento técnico detalhado
Requisitos do usuário são definidos usando linguagem natural, tabelas e diagramas
![Page 20: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/20.jpg)
Propriedade MedidaVelocidade Transações processadas/seg
Tempo de resposta do usuário/eventoTamanho K bytes
No de chips de RAMFacilidade de uso Tempo de treinamento
No de quadros de ajudaConfiabilidade Tempo médio de falhas
Probabilidade de indisponibilidadeTaxa de ocorrência de falhas
Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destinoNo de sistemas destino
![Page 21: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/21.jpg)
O documento de requisitos é a declaração oficial do que é requerido dos desenvolvedores do sistema
Deve incluir uma definição e uma especificação dos requisitos
Deve declarar o que o sistema deve fazer e não como
![Page 22: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/22.jpg)
Adote um formato padrão e use-o para todos os requisitos
Use linguagem consistentemente. Use deverá para requisitos obrigatórios e deveria para os desejáveis
Use texto em negrito para identificar partes chave dos requisitos
Evite jargão de computação
![Page 23: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/23.jpg)
Especificações mais detalhadas dos requisitos do usuário
Serve de base para projetar o sistema Pode ser usado como parte do contrato do
sistema Geralmente expressos usando modelos do
sistema◦ UML
![Page 24: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/24.jpg)
Notação DescriçãoLinguagem Depende de formulários padrãonaturalestruturadaLinguagem Linguagem semelhante a ling. prog. mas comde descrição de recursos abstratos para especificar requisitosprojetoNotações Ling. gráfica com anotações de textográficas (Use-cases de UML)Especificações Ling. com sintaxe e semântica bem-definidasFormais (OBJ, Z, CSP, LOTOS)
![Page 25: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/25.jpg)
Usuário dabiblioteca
Fornecedor
Func. dabiblioteca
Serviços decatálogo
Admin. dousuário
Serviços deempréstimo
![Page 26: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/26.jpg)
![Page 27: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/27.jpg)
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 Índice
![Page 28: Requisitos de Software](https://reader035.fdocuments.in/reader035/viewer/2022070502/568c351e1a28ab023592ffda/html5/thumbnails/28.jpg)
Sommerville, I. Software Engineering Kruchten, P. The Rational Unified Process:
An Introduction