A3-Eng.Requisitos

(1)

Engenharia de Requisitos

(ER)

Profª. Larissa Natália V. Caneiro

https://sites.google.com/site/proflarissa

carneiro

(2)

Definiçã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 Domínio da Solução 2

(3)

_{Muitos erros nos requisitos podem ser}

detectados cedo no ciclo de desenvolvimento;

_{Erros típicos incluem fatos incorretos,}

omissões, inconsistências e ambiguidade;

_{Erros nos requisitos constituem uma das}

maiores preocupações da industria de software. Por que?

(4)



_{Quanto mais tarde um erro é}

detectado, maior o custo de

corrigi-lo;



_{Muitos erros são realizados durante}

(5)

5

Motivação



A ER é a

parte mais difícil

da

construção de um software.



Nenhuma outra parte do

desenvolvimento causa tantos

danos

se feita de forma errada.



Nenhuma outra parte é tão

difícil de ser corrigida

.

*F. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, vol 20(4):10-19, april,1987.

(6)

Determina o sucesso…

(7)

Ou o fracasso…

(8)

Na Engenharia de

Software...

(9)



Entender requisitos nem sempre

é uma tarefa fácil.

• _Ex:

_{“ O valor total deverá ser}

retirado do último lançamento”

• _Pergunta

_{– último lançamento no}

arquivo do banco de dados, ou

último lançamento em um arquivo

temporário?

(10)

A. M. Morais 10

Dificuldades do Processo



Volatilidade

dos requisitos;



Clientes

dispersos,

numerosos

;



Clientes com

objetivos

conflitantes

,

perspectivas

e

formações distintas

;



Clientes com

dificuldades

(11)

_{Entender e atender as necessidades e os}

desejos dos clientes;

_{Prover ao engenheiro de software,}

métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o software deve atender;

_{Buscar as primeiras informações sobre o}

sistema;

_Melhor _entendimento _dos

(12)



Natureza

• _{A Especificação dos Requisitos do}

Software (ERS) é o

documento oficial

de descrição dos requisitos de um

projeto de software.

(13)

 _{Características contidas na E.R.S.}

• Funcionalidade: O que o software deverá fazer?

• Interfaces Externas: Como o software interage com as pessoas, com o hardware do sistema, com outros sistemas e outros produtos?

• _Desempenho_: _Qual _a _velocidade _de

processamento, o tempo de resposta e outros parâmetros de desempenho requeridos pela natureza da aplicação?

• _{Outros atributos}_{: Quais as considerações sobre}

confiabilidade que devem ser observadas?

• Restrições impostas pela aplicação: Existem limites a serem obedecidos como linguagem de implementação, limites de recursos?

(14)



É trabalho do analista entender

os requisitos e fornecer uma

solução adequada.



Para isso, ele precisa entender o

negócio do cliente:

• _{Quem serão os usuários?}

• _{Qual a influência dos usuários?}

• _{Quais serão as restrições?}

(15)



Descobrir/Modelar a visão da

empresa para o sistema



Levantar requisitos



Organizar requisitos



Planejar o desenvolvimento

• _Métricas

• _Cronograma

• _Recursos

(16)

 O que a empresa quer com o projeto?  Porque ele está sendo proposto?

 Porque a empresa vai gastar dinheiro com o projeto?

 _{O projeto é realizável?}

 A equipe de desenvolvimento tem condições de realizar este projeto?

 O cliente tem dinheiro para pagar o desenvolvimento?

 _{Há tempo disponível?}  Comprar ou construir?

(17)

_{Entender o problema}

Utilizar técnicas para elicitar os requisitos: questionários, entrevistas, documentos...

_{Modelar o problema}

Representar o nosso entendimento do problema utilizando técnicas para

modelagem: MER, casos de uso...

_{Analisar o problema}

(18)

O objetivo do processo de engenharia de requisitos é criar e manter um documento de requisitos de sistema.

_{Estudo de viabilidade;} _{Elicitação e Analise;} _{Especificação;}

(19)

_{Analisar se o projeto é viável, de um ponto}

de vista tecnológico e organizacional.

 _{Será que o sistema contribui para os objetivos}

da organização?

 _Dadas _as _restrições _{tecnológicas,}

organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associados ao projeto, será que o sistema pode ser implementado?

 _{Caso haja necessidade de integração entre}

(20)



_{Compreensão do domínio}

_{É muito importante para o analista}

compreender o domínio no qual a organização e o projeto se inserem, quanto maior for o

conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e os

stakeholders (partes interessadas).



_{Identificação e análise de problemas}



_{Identificação de stakeholders e outras}

fontes de informação



_{Captura (coleta de dados)}

(21)

 Dificuldades associadas:

• _{Não há muito tempo para realizar a elicitação;} • _{Inadequada preparação dos engenheiros;}

• _{Os stakeholders não estão convencidos da} necessidade do sistema;

• _{Os requisitos identificados podem não ser viáveis} (do ponto de vista econômico ou tecnológico);

• _{Diferentes stakeholders podem expressar os} mesmos requisitos de formas diferentes sendo necessário, através de um bom conhecimento de domínio, identificar essas situações.

(22)

 A validação de requisitos dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja.

 Processo de verificação no documento de requisitos: • Verificação de validade; • Verificações de consistência; • Verificações de completeza; • Verificações de realismo; • Facilidade de Verificação.

(23)

Perspectivas

• _Perspectiva

_{de domínio}

• _Perspectiva

_tecnológica

• _Perspectiva

_temporal

(24)

Perspectiva de Domínio



Domínio do

problema

• _{Exploração detalhada do}

problema para determinar as

necessidades do usuário.



Domínio da

solução

• _{Especificação do}

comportamento externo de um

sistema.

(25)

A. M. Morais 25

Perspectiva Tecnológica



Existem vários mecanismos

de especificação:

• _{Linguagem natural;}

• _UML;

• _{Prototipação;}

(26)

A. M. Morais 26

Perspectiva Temporal



É uma das

atividades iniciais

da engenharia de software

.



Resulta na criação de um

documento de

E

specificação de

R

equisitos de

S

oftware (

ERS

).

• _{Deve ser}

_atualizado

constantemente

para obtenção de

mais conhecimento sobre o

(27)

Perspectiva Temporal

27 Engenharia de Software

Processo de Desenvolvimento de Software

Impleme n-tação Teste Implan-tação Atividades- Gerência de Configuração; - Gerência de Riscos; - Métricas; - Estimativas; - Revisões Técnicas Formais. Outros Processos Contidos no Processo Principal Análise de Requisito s Projeto

(28)

Requisito



O que é um REQUISITO?

• _{Em software: “É a}

CARACTERIZAÇÃO

do que o

sistema deverá fazer.”



Existem vários

tipos de

requisitos

que devem ser

analisados…

(29)

Tipos de Requisitos

(30)

A. M. Morais 30

Processo de ER

Como deve ser este documento?

(31)

A. M. Morais 31

Características desejáveis para o ERS



Documento ERS

completo

;



Documento ERS

não ambíguo

;



Documento ERS

passível de ser

(32)

Modelagem de Requisitos

(33)

Modelagem de Requisitos

Boas Práticas



Análise Orientada a Objetos;



ER executada em várias

rodadas;



Revisões constantes com os

usuários;



Protótipos;



Alocação de 15% a 30% do

esforço total do processo.

(34)

Específicação de

Requisitos



Modelagem

GERA

especificação.



Especificação: Documento ERS.



É um conjunto de documentos.



Ex.:

34

Documen

to Visão

Especifica

ção

Suplement

ar

Modelo

de

Domínio

Casos de

Uso

+ + +

(35)

Documento Visão



Objetivo

• _{Descrever as necessidades}

e características de

alto

nível

do sistema.

• _Exs.:



_{Visão geral do sistema.}



_{Descrição dos usuários.}



_{Requisito funcionais.}

(36)

Especificação

Suplementar



Objetivo

• _{Descrever os requisitos não}

funcionais do sistema

• _Exs.:



_Usabilidade



_{Confiabilidade}



_Performance

36

(37)

Modelo de Domí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 (UML)}

(38)



Requisitos funcionais:

• correspondem à listagem de todas as coisas que o sistema deve fazer;

• representa o comportamento que um

sistema deve apresentar diante de certas ações de seus usuários.



Requisitos não funcionais:

• são restrições que se coloca sobre como o sistema deve realizar seus requisitos

funcionais;

• determinados aspectos de comportamento (tempo de respostas, tempo médio entre falhas).

(39)

 Explícitos

• _{São descritos em um documento que lista os}

requisitos de um produto (especificação de requisitos);

• _{Possuem conhecimento do usuário.}

 Normativos

• _{São aqueles que decorrem de leis, regulamentos,}

padrões e outros tipos de normas a que o tipo de produto deve obedecer.

 _Implícitos

• _{São expectativas dos clientes e usuários, que são}

cobradas por esses, embora não-documentadas;

• _{são efetuados pelo sistema sem o conhecimento}

(40)

 Missão

• O ponto focal do escopo de um

produto é a missão dele.

• A declaração da missão delimita as

responsabilidades do produto e

sintetiza o comprometimento entre cliente e fornecedor.

08/02/21 Engenharia de Software 40

Apoio informatizado ao controle de vendas, de compras, de fornecedores e de estoque da Mercearia Pereira & Pereira Comercial LTDA, denominada Merci.

(41)



Limites

• _{Deve-se determinar os limites}

do produto, ou seja, o que o

produto não fará.

(42)

 Limites

• _{O Merci não fará vendas parceladas e} só receberá dinheiro ou cheque.

• _{O Merci só fará a Emissão de Nota fiscal} durante a Operação de Venda.

• _{O Merci não fará um cadastro de}

clientes.

• _{O preço de venda deverá ser calculado}

pela mercearia Pereira & Pereira Comercial LTDA, e informado ao Merci. • _{O Merci não terá ajuda on-line.}