Engenharia de Software Engenharia de Requisitos (ER)

(1)

Engenharia de Software

Engenharia de Requisitos (ER)

Prof. Edison A M Morais

http://usuarios.cultura.com.br/eds/ eammorais2@gmail.com

(2)

Agenda

Definição de Engenharia de Requisitos Motivação

Perspectivas

Definição e Tipos de Requisitos Processo de ER

(3)

Defini

ç

_ç

ão

_ão

Também conhecida como:

◦ Análise de requisitos;

Análise de sistemas.

É a área responsável pela descoberta:

◦ Das reais necessidades dos clientes.

◦ Do comportamento externo de uma

solução que atenda a estas necessidades.

Domínio do Problema

(4)

Agenda

Perspectivas

(5)

Motiva

ç

_ç

ão

_ão

Segundo Brooks[5], a ER é a atividade

mais importante da construção de um

(6)

Sucesso

…

_…

(7)

Fracasso

…

_…

(8)

Motiva

ç

_ç

ão

_ão

ER também é

uma atividade

essencialmente

e acidentalmente

(9)

Dificuldades Essenciais

São aquelas inerentes à atividade

em si, por exemplo:

◦ Clientes não estarem convencidos da necessidade de um novo

software;

◦ Clientes não sabem exatamente o

que querem.

◦ Clientes com dificuldades para esclarecer seus objetivos.

(10)

Dificuldades Essenciais (cont...)

◦ Clientes dispersos, numerosos;

◦ Clientes com

Objetivos conflitantes,

Perspectivas diferentes,

Formações distintas;

(11)

Volatilidade dos Requisitos

Tipos de requisitos voláteis:

◦ Mutáveis

Originados a partir de mudanças no ambiente.

◦ Emergentes

(12)

Dificuldades Acidentais

São oriundas da falta de controle

sobre aquilo que precisa ser construído, por exemplo:

◦ Pouco esforço despendido no

levantamento de informações junto ao usuário;

◦ Documentação pobre sobre os requisitos obtidos;

(13)

Dificuldades Acidentais (cont...)

◦ Especificações incorretas dos

requisitos;

◦ Tendência em iniciar logo o processo

de desenvolvimento do software;

◦ Não existir tempo adequado para a elicitação;

◦ Preparação inadequada dos

(14)

Motiva

ç

_ç

ão

_ão

Nenhuma outra parte do desenvolvimento causa tantos

(15)

Agenda

Perspectivas

(16)

Perspectivas

◦

Perspectiva de

domínio

◦

Perspectiva

tecnológica

(17)

Perspectiva de Dom

í

_í

nio

_nio

Domínio do

problema

◦ Exploração detalhada de um

problema particular para determinar as necessidades de automação do usuário.

Domínio da

solução

◦ Especificação do comportamento externo de um sistema.

(18)

Perspectiva Tecnol

ó

_ó

gica

_gica

Existem vários mecanismos de

especificação:

◦ Linguagem natural;

◦ UML;

◦ Prototipação;

(19)

Perspectiva Temporal

◦ É uma das atividades iniciais da engenharia de software.

◦ Resulta no criação de um documento de

Especificação de Requisitos de Software (ERS).

Este documento deve ser atualizado

constantemente para obtenção de mais conhecimento sobre o problema.

(20)

Agenda

Perspectivas

(21)

Conceito de Requisito

Em software:

◦

“É a

CARACTERIZAÇÃO

do

que o sistema deverá fazer.”

Existem vários

tipos de

requisitos

que devem ser

(22)

Tipos de Requisitos

Fonte: [2]

(23)

Requisitos Funcionais

Segundo Somerville [5]:

◦ Descrevem o que o software deve fazer.

◦ Descrevem a função do sistema (entradas, saídas, exceções, etc.) detalhadamente.

◦ Geralmente especificados em Casos de Uso.

◦ Exemplos:

O usuários deve ser capaz de cadastrar seu cliente.

O aluno pode emitir o seu histórico escolar.

(24)

Requisitos

não

Funcionais

(25)

Agenda

Perspectivas

(26)

Processo de ER

Como deve ser este documento?

Como Conduzí-lo?

(27)

Caracter

í

_í

sticas da ERS

_{sticas da ERS}

Completo;

Consistente;

Não ambíguo;

Passível de ser testado (verificável);

Rastreável;

Modificável;

Utilizável durante operações e

(28)

Processo de ER

(29)

Atividades do Processo de ER

(30)

(31)

Elicitação de Requisitos

Elicitar (ou Eliciar):

◦ Descobrir;

◦ Tornar explícito;

◦ Obter o máximo de informações para o conhecimento de determinado assunto.

(32)

Elicitação de Requisitos

(33)

Elicitação de Requisitos

Exemplo de Processo de Elicitação de Requisitos

de Software

Obter Informações sobre o Domínio do Problema

Identificar Fontes de Informação (documentos, softwares antigos...) Identificar Usuários (Stakeholders) e Provedores de Requisitos

Identificar as Necessidades dos Usuários Administrar Conflitos entres os Usuários

Identificar Requisitos Funcionais Identificar Requisitos não Funcionais

(34)

Técnicas para Elicitação de

Requisitos

Reuniões Entrevistas Etnografia Protótipos

Pontos de Vista (

Viewpoints

) Cenários

(35)

Reuniões

Permitem a comunicação entre o

Engenheiro de Requisitos em os provedores de informações.

Pode ser conduzida de várias formas,

por exemplo:

◦ Brainstorming.

(36)

Reuniões

Brainstorming

(Tempestade de Ideias)

◦ Um grupo de pessoas é reunido;

◦ Um cenário simulado e um assunto é discutido.

◦ As pessoas participantes devem se sentir

confortáveis o bastante para discutir o assunto sem se sentirem intimidadas.

◦ Nenhuma idéia deve ser descartada. Em princípio todas podem ser boas idéias.

(37)

Reuniões

JAD (

Joint Application Development

)

◦ Visa reunir stakeholders em um workshop organizado para promover decisões.

◦ Objetivo:

Garantir comprometimento dos usuários com o levantamento dos requisitos do sistema.

◦ Sua aplicação é recomendada quando a

necessidade de consenso entre os usuários do sistema se torna fator importante para o

(38)

Entrevistas

É uma técnica que ajuda na captura de

conhecimento sobre o domínio do problema.

O uso de questionários é recomendado quando

os analistas identificam a necessidade de coletar informações de muitos usuários ao mesmo

tempo.

Quando aplicado, cada usuário responde o

questionário individualmente e posteriormente os requisitos são identificados através de

(39)

Entrevistas

Importante:

◦ Entrevistadores devem ser

open-minded, ou seja, devem saber ouvir os

stakeholders e não devem ter ideias pré-concebidas sobre requisitos.

◦ Não devem impor uma proposta ou intimidá-lo.

◦ Não se deve esperar que os usuários respondam a questionamentos muito

(40)

Etnografia

ETHNOS

◦ significa “povo”

GRAPHEIN

◦ significa “grafia”, ”escrita”, ”descrição”, “estudo descrito”.

Etimologicamente, a etnografia é o estudo

descrito de um povo.

Como pode ser usada em Eliciação de

(41)

Etnografia

Gasta-se um tempo considerável no

ambiente de trabalho observando:

◦ A rotina de trabalho dos usuários.

◦ Interações implícitas são reveladas (as pessoas não têm que explicar o seu trabalho).

◦ Fatores sociais e organizacionais importantes

◦ Os requisitos são derivados levando em

consideração a cooperação entre as atividades de outras pessoas

(42)

Protótipos

Consiste na criação de um protótipo do

software.

Descartáveis:

◦ São criados com a função de ilustrar para os usuários e/ou clientes do sistema o que o

analista entendeu sobre os requisitos que deverão ser contemplados no produto.

◦ Essa prototipagem deve ser feita rapidamente e ser concluída preferencialmente em curto prazo.

Evolutivos.

◦ São reaproveitados durante a construção do sistema.

(43)

Pontos de Vista (Viewpoints)

Stakeholders podem apresentar diferentes

formas de olhar para o problema.

Por exemplo:

◦ Sistema bancário com caixa automático

Serviços: extrato, transferências, saques, etc.

◦ Pontos de Vista

Clientes do banco

Representantes de outros bancos

Engenheiros de manutenção de HW e SW

Departamento de marketing, gestores e caixas do banco

(44)

Cenários

Cenários são descrições de como o

sistema é usado na prática.

Descrições de cenários

◦ O estado do sistema no início do cenário

◦ O fluxo normal de eventos no cenário

◦ O que pode sair errado e como é tratado

◦ Outras atividades concorrentes

◦ O estado do sistema no fim do cenário

(45)

Exemplo de Cenário -

Caixa Eletrônico Validate user Request PIN Select service Timeout Return card Invalid card Return card Stolen card Incorrect PIN Re-enter PIN Incorrect PIN Return card Card PIN Card present Account number PIN Account number Valid card User OK

(46)

(47)

Modelagem de Requisitos

(48)

Modelagem de Requisitos

Boas Pr

á

ticas

Análise Orientada a Objetos

(AOO);

ER executada em várias rodadas;

Revisões constantes com os usuários; Protótipos;

Alocação de 15% a 30% do esforço

(49)

Especifica

ç

_ç

ão de Requisitos

_{ão de Requisitos}

Modelagem

GERA

especificação.

Especificação: Documento ERS.

É um conjunto de documentos.

Ex.:

Documento Visão Especificação Suplementar Modelo de Domínio Casos de Uso + + +

(50)

Documento Visão

Objetivo

◦

Descrever as necessidades e

características de

alto nível

do

sistema.

◦

Ex.:

Visão geral do sistema.

Descrição dos usuários.

(51)

Especifica

ç

_ç

ão Suplementar

_{ão Suplementar}

Objetivo

◦

Descrever os

requisitos não

funcionais

do sistema

◦

Ex.:

Usabilidade

Confiabilidade

(52)

Modelo de Dom

í

_í

nio

_nio

É o resultado da Análise

Orientada a Objetos (

AOO

);

Objetivo:

◦ Auxiliar na compreensão e análise do problema.

Artefato

◦ Diagrama de Classe de Domínio

(53)

Diagrama de Classe de Dom

í

_í

nio

_nio

(54)

Casos de Uso

Representam

interações

entre

usuário

e

software

.

Caso de Uso A

Ator

Caso de Uso B

UC1. Caso de Uso 1 Descrição: ... Fluxo Básico: 1. O usuário solicita.... 2. O sistema disponibiliza...

UC1. Caso de Uso 1

Descrição: ... Fluxo Básico: 1. O usuário solicita.... 2. O sistema disponibiliza...

(55)

Casos de Uso

Exemplo

É recomendável associar um diagrama de atividades, Sequência e um protótipo.

(56)

Diagrama de Atividades

(57)

(58)

Validação de Requisitos

Segundo o Guia Geral do MPS.BR [8],

Validação de Requisitos é:

◦ Confirmar que um produto ou

componente de um produto atenderá seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.

A validação deve considerar os

(59)

Validação de Requisitos

Compreensibilidade

◦ O requisito está bem compreendido?

Completude

◦ Todas os requisitos pedidos pelo cliente estão incluídos?

Validade

◦ Os requisitos atendem as necessidades do cliente?

Consistência

(60)

Validação de Requisitos

Realismo

◦ Os requisitos podem ser implementados com o orçamento e tecnologia disponíveis?

Verificabilidade

◦ Os requisitos podem ser verificados?

Adaptabilidade

◦ O requisito pode ser mudado sem grande impacto em outros requisitos?

Rastreabilidade

(61)

Validação de Requisitos

Como é feita a validação na prática:

◦ Revisões de requisitos envolvendo usuários e analistas;

◦ Análise manual dos requisitos;

◦ Prototipação;

◦ Geração de casos de testes funcionais;

◦ Desenvolver casos de testes de unidade;

(62)

(63)

Gerência de Requisitos

Segundo o Guia Geral do MPS.BR [8],

Gerência de Requisitos é gerenciar:

◦ Os requisitos do produto.

◦ Os componentes do produto do projeto.

E identificar inconsistências entre:

◦ Os requisitos;

(64)

Gerência de Requisitos

Como fazer:

◦ GRE 1:

O entendimento dos requisitos é obtido junto aos fornecedores.

◦ GRE 2:

Os requisitos são validados com base em critérios objetivos.

Um comprometimento da equipe técnica com estes requisitos é obtido

(65)

Gerência de Requisitos

◦ GRE 3:

A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é

estabelecida e mantida

◦ GRE 4:

Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e

corrigir inconsistências em relação aos requisitos.

(66)

Gerência de Requisitos

◦ GRE 5:

Mudanças nos requisitos são gerenciadas ao longo do projeto.

(67)

Gerência de Requisitos

Rastreabilidade

(68)

Gerência de Requisitos

Rastreabilidade

Onde fica?

(69)

Gerência de Requisitos

Rastreabilidade

Conceito

◦ Preocupa-se com as relações entre os

requisitos, suas origens e o projeto do sistema.

◦ Gera a chamada Matriz de Rastreabilidade.

◦ Entre Requisitos

Ligações entre requisitos dependentes

◦ De Origem

Ligações dos requisitos aos stakeholders que propuseram estes requisitos

(70)

Gerência de Requisitos

M

atriz de Rastreabilidade

Entre os próprios Requisitos

(71)

Gerência de Requisitos

M

atriz de Rastreabilidade

Entre Requisitos Funcionais e Não

(72)

Gerência de Requisitos

M

atriz de Rastreabilidade

Fonte: [9] Entre Requisitos e Casos de Uso

◦ r1..rn: requisito 1 a n

(73)

Gerência de Requisitos

Tipos de

(74)

Gerência de Requisitos

Pr

(75)

Tarefa

Com seu grupo, crie os

seguintes documentos para o

software planejado nas aulas

anteriores:

◦

Documento Visão

◦

Especificação Suplementar

* O template destes documentos está disponível no site da

(76)

Referências Bibliogr

á

_á

ficas

_ficas

[1] Pressman, Roger. Engenharia de Software. 6ª Edição.

[2] Lucena, F. N. Requisitos de Software: Eliciar, Registrar e Ser

bem-sucedido. Disponível em http://www.inf.ufg.br/~fabio

[3] Queiróz, R. Silva, J. Eliciação e comunicação de requisitos em

domínios disjuntos: estudo de caso para automação na área médica. Disponível em http://www.scielo.br/scielo.php?pid=S0103-17592009000400014&script=sci_arttext. Acessado em Set/12.

[4] Brooks, Fred P. (1986). "No Silver Bullet — Essence and

Accident in Software Engineering". Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.

[5] Sommerville, Ian. Engenharia de Software, 8ª Edição. São

(77)

Referências Bibliogr

á

_á

ficas

_ficas

[6] NBR ISO/IEC 9126. Engenharia de Software – Qualidade de

Produto. Quality model. Válida a partir de 30.07.2003.

[7] IEEE. IEEE Recommended Practice for Software Requirements

Specifications. IEEE Standard 830 – 1998.

[8] MPS.BR. Guia Geral. Disponível em

http://www.softex.br/mpsbr/. Acessado em Set/12.

[9] Genvigir, E. C. Um Modelo para Rastreabilidade de Requisitos

de Software Baseado em Generalização de Elos e Atributos. Tese de Doutorado. São José dos Campos: INPE. – 2009.