37
Extração de Requisitos de Software SIMONE SENGER DE SOUZA [email protected] 1 ICMC/USP 2019

Extração de Requisitos de Software

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Extração deRequisitos de

Software

SIMONE SENGER DE SOUZA

[email protected]

1ICMC/USP 2019

Entendimento do Domínio

Extração e análise de requisitos

Especificação

Validação

Extração de Requisitos

Problemas (1)

3

Problemas (2)

4

Problemas (3)

5

Exercício:Gostaria que fosse construído um sistemapara monitorar a temperatura e a pressão depacientes da UTI, que deverão ficar ligadosonline à rede de computadores do hospital,que é formada por um computador principale vários terminais que monitoram ospacientes. Se a temperatura ou pressãopaciente lida pelo terminal se tornaremcríticas, o computador principal deverámostrar uma tela de alerta com um históricodas medidas realizadas para o paciente. Umaviso sonoro deve ser ativado nesse caso.

6

Definição de Requisito

Descrições do que o sistema deve fazer

Inclui: os serviços fornecidos pelo sistema, suas

qualidades específicas e suas restrições

operacionais.

Esses requisitos refletem as necessidades dos

clientes de um sistema.

7

Tipos de Requisitos

Requisitos Funcionais

Requisitos Não-Funcionais

8

Requisitos Funcionais -Exemplos

“O usuário deve conseguir fazer buscas em todo o acervo de materiais bibliográficos.”

“O sistema deve fornecer telas apropriadas para o usuário ler documentos disponíveis no repositório de documentos.”

“O sistema deve permitir o cadastro dos fornecedoresda loja”

“O sistema deve utilizar os dados obtidos a partir dos sensores e interpretá-los para realizar a navegação”

9

Requisitos Não-Funcionais

São requisitos que expressam:◦ Restrições que o software deve atender.

◦ Qualidades específicas que o software deve ter.

10

Requisitos Não-Funcionais

11

Exemplos

Requisito do Produto

◦ O sistemas deve ser robusto e tolerante a falhas, de forma a

continuar sua operação ou abortar de forma segura o modo

autônomo caso haja falha de um ou mais sistemas essenciais

Requisito Organizacional

◦ O processo de desenvolvimento do sistema e os produtos liberáveis

devem estar em conformidade com o padrão empresarial XYZ.

Requisito Externo

◦ Os operadores do sistema não devem ter acesso a dados que não

necessitem.

12

Defeitos em Descrição de Requisitos

▪ Defeitos de Omissão

▪ Defeitos de Fato Incorreto

▪ Defeitos de Inconsistência

▪ Defeitos de Ambiguidade

▪ Defeitos de Informação Estranha

13

Defeitos em Descrição de Requisitos

▪ Exemplo (1):

Se o número de dias que o usuário está em atraso com o livro é menor que uma semana, ele deve pagar uma taxa de R$ 1,00; se for maior que uma semana, a taxa é de R$ 0,50 por dia.

14

Defeitos em Descrição de Requisitos

▪ Exemplo (2):

O sistema deve apresentar o resultado o mais rápido possível

15

Defeitos em Descrição de Requisitos

▪ Exemplo (3):

Para o sistema computar a frequência na aula, o alunoprecisa estar com a carteirinha

16

Defeitos em Descrição de Requisitos

▪ Exemplo (4):

A matrícula na disciplina não pode ser realizada depois do período (matrícula fora do prazo).

17

Defeitos em Descrição de Requisitos

▪ Exemplo (5) – para sistema de aeronave:

◦ Para minimizar o peso, o número de chips do

sistema deve ser minimizado.

◦ …

◦ Para minimizar o consumo de energia, chips de

menor potência devem ser usados.

18

Validação de Requisitos

❑ Revisões técnicas formais

❑ Inspeção - Técnicas de leitura

19

Especificação de Requisitos▪ Documento de Requisitos (ver modelo IEEE)

▪ Modelagem de Casos de uso

▪ Cenários

▪ Histórias de usuários

▪ ...

20

21

• Envolve pessoal técnico trabalhando com os clientes para

descobrir sobre o domínio da aplicação, os serviços que o

sistema deve fornecer e sobre as restrições operacionais.

Extração de Requisitos

22

• De quem?

• Stakeholders – partes interessadas

• Usuários finais

• Gerentes

• Engenheiros envolvidos na manutenção

• Especialistas de domínio

• Representantes de sindicato ...

Extração de Requisitos

23

• De quem?

• Stakeholders – partes interessadas

• Usuários finais

• Gerentes

• Engenheiros envolvidos na manutenção

• Especialistas de domínio

• Representantes de sindicato ...

Extração de Requisitos

Técnicas de Extração de Requisitos

Algumas técnicas são propostas visando auxiliar a comunicação e a extração dos requisitos◦ Entrevistas

◦ Cenários

◦ Estórias do usuário

◦ Etnografia

◦ Prototipação

24

Extração de Requisitos: Entrevista

Em entrevista formal ou informal, a equipe de ER formula questões para os stakeholders sobre os sistemas que eles usam e o sistema a ser desenvolvido.

Dois tipos de entrevistas:◦ Entrevistas fechadas: um conjunto de questões predefinidas são

respondidas.

◦ Entrevistas abertas: não há um roteiro predefinido, uma variedade de assuntos são explorados com os stakeholders.

25

Extração de Requisitos: Entrevista

Planejamento da entrevista

Início: Questões livres de contexto (Quebrar o gelo!)◦ Quem está por trás da solicitação deste trabalho?

◦ Quem vai usar a solução?

◦ Qual será o benefício econômico para uma solução bem-sucedida?

26

Questões que ajudam a entender o problema:◦ Você pode me mostrar ou descrever o ambiente no qual a

solução será usada?

◦ Que tipo de saídas você considera importante?

◦ Que problemas existem para a solução de software?

◦ Existem questões de desempenho ou restrições que podem afetar o software?

27

Extração de Requisitos: Entrevista

Extração de Requisitos: Entrevista

Final: focalizam a efetividade da reunião◦ Você é a pessoa certa para responder a essas questões?

Suas respostas são “oficiais”?

◦ Minhas questões são relevantes para o problema que você tem?

◦ Estou formulando muitas questões?

◦ Alguém mais pode fornecer informação adicional?

◦ Tem alguma questão que não fiz que você julga pertinente?

28

Extração de Requisitos: EntrevistaEntrevistas são boas para obtenção de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema.

Entrevistas não são boas para a compreensão de requisitos de domínio

◦ Os engenheiros de requisitos podem não entender a terminologia específica de domínio;

◦ Alguns conhecimentos de domínio são tão especificos que as pessoas acham difícil explicar ou pensam que não valem a pena mencioná-los

29

Extração de Requisitos: EntrevistaENTREVISTAS EFETIVAS

Os entrevistadores devem ter mente aberta, desejarem ouvir os stakeholders e não ter idéiaspreconcebidas sobre os requisitos.

Eles devem induzir os entrevistados com uma questãoou uma proposta, e não simplesmente esperar que eles respondam a uma questão tal como ‘o que vocêquer?’

30

Extração de Requisitos: Cenários

CENÁRIOS

Cenários são exemplos reais de como um sistema pode ser usado.

Eles devem incluir◦ Uma descrição da situação inicial;

◦ Uma descrição do fluxo normal de eventos;

◦ Uma descrição do que pode dar errado;

◦ Informação sobre outras atividades concorrentes;

◦ Uma descrição do estado quando o cenário termina.

31

Extração de Requisitos: Cenários

Exemplos de cenário:

◦ Saque em caixa eletrônico

◦ Empréstimo de livro em biblioteca

◦ Compra de livro na internet

◦ Pilotar um avião

32

Extração de Requisitos: Estórias

São frases escritas na linguagem do cliente, sobre algo que a aplicação deve fazer.

Detalhes de cada estória não aparecem: ◦ uma estória é “uma promessa de uma conversa futura

entre cliente e desenvolvedores”.

33

Extração de Requisitos: Estórias

Exemplo de estórias

Para uma loja virtual:◦ “Um usuário possui um carrinho de compras no qual ele adiciona

produtos que quer comprar”

◦ “Um usuário faz o pagamento com cartão de crédito ou boleto bancário”

◦ “Um usuário lê comentários feitos por outros sobre os produtos da loja”

◦ “Um usuário recebe um e-mail de confirmação de compra quando efetua um pagamento”.

34

Extração de Requisitos: Estórias

As estórias conduzem a novas reuniões com usuários que podem ocorrer durante a fase de desenvolvimento.

Feitas em cartões (manuscritas) que serão fixados em painéis◦ Ajudam a acompanhar o desenvolvimento (estória

concluída, em desenvolvimento, não iniciado)

Auxiliam durante os testes de aceitação

35

Extração de Requisitos: Etnografia

Um analista observa e analisa como as pessoas realmente trabalham. ◦ As pessoas não explicam seu trabalho.

Fatores sociais e organizacionais de importância podem ser observados.

Estudos de etnografia têm mostrado que o trabalho é, geralmente, mais rico e mais complexo do que o sugerido pelos modelos simples de sistema.

36

Extração de Requisitos: Etnografia

Requisitos do sistema se originam do modo como as pessoas realmente trabalham ◦ Independem de como definições de processo sugerem que elas devam

trabalhar.

Ideal complementar com prototipação

37