Aula 1 - Requisitos

(1)

Analise de Sistemas

Requisitos

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

(2)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO:Engenharia

de Requisitos

◦Fundamentos de requisitos de

software. Tipos e classificação dos requisitos.

◦Processo de engenharia de requisitos: conceitos, fases e atividades.

◦Técnicas para elicitação, identificação e especificação de requisitos.

◦Técnicas para validação e gerenciamento de requisitos.

(3)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO: Modelagem de Diagrama de Classes

◦Diagrama de Classes: elementos, notação e

exemplos. Diagrama de Objetos: elementos, notação e exemplos. Diagrama de Estruturas Compostas:

elementos, notação e exemplos.

◦Modelagem do Diagrama de Classes: especificação do diagrama com a notação básica - ênfase nas

operações.

◦Modelagem do Diagrama de Classes: especificação do diagrama com a notação básica - ênfase nos

atributos.

◦Modelagem do Diagrama de Classes: especificação do diagrama com a notação complementar - ênfase nos atributos e operações.

(4)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO: Modelagem de

Use Cases

◦Introdução do Processo Unificado: fases e

atividades. Introdução à UnifiedModelingLanguage 2.0 (UML): evolução, características, visão geral das técnicas de modelagem estruturais e

comportamentais e mecanismos gerais da notação.

◦Modelagem de Diagramas de Use Cases - nível fácil.

◦Modelagem de Use Cases - Diagrama de Use Cases: elementos, notação e exemplos.

◦Modelagem de Use Cases - Documentação de Use Cases: descrição em alto nível de abstração.

(5)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO: Processos de

Negócio de Software

◦Introdução à engenharia de software e a análise de sistemas. Fundamentos de processos de negócio. Visão geral das áreas de negócio de uma

organização.

◦Processos de negócio - Business ProcessModeling (BPM) e Business ProcessModeling

◦Notation (BPMN): conceitos, características e implantação.

◦Técnicas para modelagem de processos de negócios: especificação de fluxogramas.

◦Técnicas para modelagem de processos de negócios: Fluxograma - elementos, notação e tipos linear e

(6)

Pré-Aula

 Reflexão

 Você sabem o que é requisitos?  Entendem quando alguém fala

dos requisitos?

◦Requisitos Funcionais?

◦_{Requisitos Não Funcionais?} ◦Regras de Negocio?

(7)

Pré-Aula

 Requisitos

 Um entendimento completo dos requisitos de software é

essencial para o sucesso do

desenvolvimento do software.

Não importa quão bem projetado ou quão bem codificado seja, um

sistema mal analisado e

(8)

Pré-Aula

 Análise de requisitos é um processo de

descoberta, refinamento, modelagem e especificação.

 O escopo do software, inicialmente

estabelecido pelo Analista de Sistemas e

refinado durante o planejamento do projeto de software, é aperfeiçoado em detalhes.

 Modelos, diagramas, fluxos, fluxogramas são

criados para ajudar na compreensão do problema.

 O analista e o usuário desempenham um

papel ativo na análise e especificação de requisitos.

(9)

Pré-Aula

 O cliente (ou usuário) tenta

reformular um conceito de função e desempenho de software, às

vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e

(10)

Pré-Aula

 Entretanto, a análise e

especificação de requisitos pode parecer uma tarefa relativamente simples, mas as aparências

enganam. O grau comunicação é elevado.

 Daí, surgem as oportunidades de

interpretações errôneas e informações falsas. A

(11)

Pré-Aula

 O dilema com o qual se depara um

analista pode ser mais bem entendido, repetindo-se a

declaração de um cliente anônimo:

 “Sei que você acredita que

entendeu o que acha que eu

disse, mas não estou certo que percebeu que aquilo que ouviu não é o que eu pretendia

(12)

(13)

Pré-Aula

 Identificação e Elicitação de

Requisitos

 Identificação e elicitação de

requisitos é uma tarefa que parece simples, mas, não devemos nos

enganar, às vezes, para obtermos algumas informações é exigido

muita dedicação, persistência e técnica.

(14)

Pré-Aula

 Por que o “elicitação” é

importante:

 O sucesso no desenvolvimento de um

projeto de software depende basicamente da elicitação de

requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema.

(15)

Pré-Aula

 Entretanto, esta atividade, nem sempre está presente no

processo de desenvolvimento, raramente ela é elaborada de forma metodológica,

geralmente tem uma abordagem intuitiva

(16)

Pré-Aula

 Cuidado com :” geralmente

tem uma abordagem intuitiva.”

 Sua intuição pode não ser

realmente o que o cliente deseja.

(17)

Pré-Aula

 Identificação dos Requisitos:

Tipos de Requisitos

 Os requisitos podem ser divididos em duas categorias básicas :

(18)

(19)

Pré-Aula

 Requisitos Funcionais: ◦ Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções necessárias para atender os objetivos do sistema.  Exemplo: ◦ Cadastrar Clientes; ◦ Fazer Análise de Crédito; ◦ Fazer uma Transação com Banco de Dados; ◦ Cadastrar um Registro de Atendimento; ◦ Imprimir Relatório...

(20)

Pré-Aula

 Requisitos Não Funcionais: ◦ Os requisitos não funcionais dizem respeito as características do software, exemplos: performance, portabilidade, segurança, usabilidade e etc. Estas características descrevem também a qualidade do serviço.  Exemplo:

◦ O sistema deve usar

gráficos comparativos do aproveitamento do aluno com a média da turma;

◦ O sistema deve usar

cores na construção dos gráficos;

◦ As cores utilizadas

devem ser vermelho e preto;

◦ O tempo de resposta na elaboração do relatório não pode ser superior a 15 segundos.

(21)

Pré-Aula

 Regras de Negocio

 Regras do Negócio são declarações

sobre a forma da empresa fazer negócio.

 Elas refletem políticas do negócio.  Organizações têm políticas para

satisfazer os objetivos do

negócio,satisfazer clientes, fazer bom uso dos recursos, e obedecer às leis ou convenções gerais do negócio.

(22)

Pré-Aula

 As regras de negocio representam o

comportamento da organização dentro do sistema.

 É a regra de negócio que especifica

as particularidades das funcionalidades a serem desenvolvidas.

 As regras de negocio ajudam a

entender o funcionamento da empresa e obviamente o funcionamento do

(23)

Pré-Aula

 As regras de negocio tem relação com o comportamento da organização e desejável que este comportamento seja refletido no sistema.  EXEMPLO:  Ao se cadastrar no nossa loja física

todo cliente tem

que apresentar um CPF valido; ◦ No desenvolvimento do sistema durante o cadastro do cliente obrigatoriamente ele tem que possuir um CPF valido.

(24)

Pré-Aula

 Como Diferenciar :

◦Requisitos Funcionais?

◦Requisitos não Funcionais ? ◦Regras de Negocio;

 Resposta:

◦São Ações que o meus sistema tem que apresentar;

◦São características do meu sistema;

◦Normalmente tem haver com o problema em sí e não ao sistema.

(25)

Pré-Aula

 Sobre os Trabalhos:

◦As vezes uma imagem vale mais que mil palavras:

(26)

Pré-Aula

 Reflexão:

 O que são Requisitos?

 Um requisito é definido como "uma condição ou uma

capacidade com a qual o sistema deve estar de acordo".

(27)

Pré-Aula

 Requisitos dizem quais são as características que um sistema deve apresentar.

 E a partir dos requisitos que temos a definição de quais

atividades, quais características ou mesmo quais regras o sistema tem que possuir.

(28)

Pré-Aula

 Os requisitos são passados pelo cliente.

 O Cliente normalmente não sabe o que quer.

 O Analista tem que tentar tirar ao máximo as informações passadas pelo cliente.

(29)

Pré-Aula

 Exercício 10 Minutos

 Pense no seguinte cenário você e seus

amigos decidiram abrir uma lan-house, vocês já tem 20 computadores, espaço, impressora tudo que é necessário para o funcionamento, exceto... O sistema que vai fazer controle de todo o funcionamento.

 Pense numa lista de requisitos que são

necessários para atender as necessidades de vocês. Neste momento não precisa preocupar com requisitos funcionais, não funcionais ou regras de negocio. Pense no que o sistema tem que ter.

(30)

Pré-Aula

 Resolução da Turma de Sexta Feira

(31)

Aula

 Definições de requisito (segundo IEEE)

◦1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um

problema ou alcançar um objetivo.

◦2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente.

◦3) Uma representação documentada de uma condição ou capacidade.

(32)

Aula

 Um entendimento completo dos requisitos de software é

essencial para o sucesso do

desenvolvimento do software.

Não importa quão bem projetado ou quão bem codificado seja, um

sistema mal analisado e

(33)

Aula

 O escopo do software, inicialmente

estabelecido pelo Analista de Sistemas e refinado durante o planejamento do projeto de software, é aperfeiçoado em detalhes.

 Modelos, diagramas, fluxos são criados para ajudar na compreensão do

problema.

 O analista e o usuário desempenham um papel ativo na análise e

(34)

Aula

 O cliente (ou usuário) tenta

reformular um conceito de função e desempenho de software, às

vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e

(35)

Aula

 Entretanto, a análise e

especificação de requisitos pode parecer uma tarefa relativamente simples, mas as aparências

enganam. O grau comunicação

é elevado. Daí, surgem as

oportunidades de interpretações errôneas e informações falsas. A

(36)

Aula

 Da perspectiva da Engenharia de

Software, a “elicitação” de requisitos é talvez a mais parte mais critica do

processo de desenvolvimento de software.

 Estudos indicam que os requisitos, só detectados depois do software

implementado ou erros na análise de requisitos, são até 20 vezes mais

caros de se corrigir que qualquer outro

(37)

(38)

Aula

 O que pode acontecer quando

os requisitos estão mal feitos?

 Ariane 5;

(39)

Aula

 A elicitação de requisitos

corresponde a identificar junto aos clientes/usuários quais são os

objetivos do sistema, o que deve ser acompanhado, como o

sistema se encaixa‟ no contexto das necessidades do negócio e,

finalmente, como será a utilização do sistema no dia-a-dia.

(40)

Aula

 “A parte mais árdua na construção

de um software consiste

exatamente em identificar o que

construir. Nenhuma outra parte do

trabalho compromete tanto o

resultado do trabalho se

elaborado de forma incorreta.

Nenhuma outra parte oferece tanta

dificuldade para efetuar correções posteriores. "

(41)

Aula

 Apesar de parecer simples, trata-se de um

processo extremamente complexo. Algumas das razões desta dificuldade:

 Problemas de escopo:

◦Os limites do sistema são geralmente definidos de

forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários;

 Problemas de compreensão:

◦Os clientes/usuários geralmente não estão

completamente certos das necessidades, têm uma pouca compreensão ou do domínio do seu negócio, omitem informações que julgam óbvias e etc.

 Problemas de volatilidade:

(42)

Aula

 Para ajudar a superar estes

problemas, os desenvolvedores devem abordar os requisitos de forma simples, prática e

organizada. Alguns passos são

recomendados para atividade de Elicitação de Requisitos de

(43)

Aula

◦Avaliar a viabilidade técnica e de

negócio para o sistema proposto;

◦Identificar as pessoas que vão auxiliar a

especificar os requisitos e compreender seus preconceitos organizacionais;

◦_{Definir o ambiente técnico no qual o}

sistema será instalado;

◦_{Identificar regras de domínio que}

limitam a funcionalidade ou

desempenho do software que será construído;

(44)

Aula

◦Definir um ou mais métodos de elicitação de requisitos;

◦_{Solicitar participação de várias}

pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista;

◦_{Identificar claramente a justificativa de}

existência para cada requisito registrado;

◦Identificar requisitos ambíguos que serão candidatos a prototipação.

(45)

Aula

 Objetivos da Elicitação de

Requisitos:

 Obter conhecimento relevante

para o problema e prover o mais correto entendimento de o que é esperado do software/sistema;

(46)

(47)

Aula

 Por que o “elicitação” é importante:

 O sucesso no desenvolvimento de um projeto de

software depende basicamente da elicitação de requisitos, pois, é a base que permitirá ao

Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir

propostas que possam contribuir para a solução do problema.

 Entretanto, esta atividade, nem sempre está

presente no processo de desenvolvimento, raramente ela é elaborada de forma

metodológica, geralmente tem uma

(48)

Aula

 Cuidado com :” geralmente

tem uma abordagem intuitiva.”

 Sua intuição pode não ser

realmente o que o cliente deseja.

(49)

Aula

 Principais características de uma “boa elicitação de requisitos”:

 Definir as técnicas de coleta de requisitos

baseadas em fatores operacionais, táticos e financeiros;

 Criar um planejamento com objetivo de alcançar

as metas estabelecidas, tais como: Prazos, Custos e Qualidade;

 Promover a integração e o comprometimento de

todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usuários e o Patrocinador.

 Identificar os documentos e procedimentos que

(50)

Aula

Elicitação Boa Elicitação Ruim Bom Diagnóstico Diagnóstico ineficiente Soluções eficientes Soluções medíocres

Satisfação dos usuários

Insatisfação dos usuários

Melhoria dos processos e redução de custo

Problemas operacionais e financeiros

(51)

Aula

 As informações podem ser identificadas

ou encontradas em diversas fontes: ◦Usuários; ◦Documentos; ◦Especificações técnicas; ◦Clientes; ◦Sistemas legados ◦Patrocinadores; ◦Analista de Negócio;

◦“Domain Experts” - Especialista em uma ou mais área de negócio.

(52)

Aula

 Existem várias técnicas, todas elas possuem seus próprios conceitos, vantagens e desvantagens, que podem ser usada nesta atividade entre elas estão: ◦Reuniões formais; ◦Reuniões informais; ◦Entrevistas; ◦Questionários; ◦Workshop; ◦Brainstorming;

◦JAD (Join Application Development) ◦Fast;

◦Análise de Documentos;

(53)

Aula

 Quais as informações que devo

identificar, levantar e coletar ?

◦ Após a atividade de

Identificação/Elicitação de Requisitos, através de alguma técnica formal ou informal, as seguintes informações que devemos obter são:

◦Entendimento do problema,

identificação da lista dos principais

usuários, lista dos principais Requisitos, identificação dos Riscos e as Restrições do software.

(54)

Aula

 Daí podemos organizar as

informações da seguinte maneira:

◦Contexto (Declaração do problema

e Diagrama de Contexto);

◦Identificação dos usuários e

entidades externas;

◦_{Identificação dos Requisitos;}

◦_{Identificação dos Riscos ;}

(55)

Aula

◦Contexto:

 _{Após o entendimento do problema podemos}

escrever a Declaração do Problema e também desenhar um diagrama de contexto.

◦Declaração do problema:

 _{É uma “descrição narrativa”, que apresenta de}

forma concisa e clara às necessidades dos usuários.

 _{Esta narrativa também deve descrever o cenário}

atual e as necessidades futuras.

 _{A linguagem usada neste documento pode ser}

técnica ou de negócios, entretanto, evite o usar jargões que não se enquadram no escopo do problema.

(56)

Aula

 Identificação dos Requisitos:

◦Identificar as funcionalidades do

software que deve ter para atender as necessidades do usuário.

◦Para identificar você pode fazer as seguintes perguntas:

 _{O que o software deve fazer ?}

(57)

Aula

 Devemos identificar também as principais

características do software como:

◦Performance:

 Qual é tempo de resposta adequado ?

◦Segurança:

 Quais são os requisitos de segurança que

o software precisa?

◦Usabilidade:

 O software deve seguir a identidade

visual da empresa, as interfaces devem ser intuitivas e amigáveis

(58)

Aula

 Os requisitos encontrados não devem ser descritos neste

momento, precisamos apenas identificá-los, ou seja, é uma informação de alto nível.

(59)

Pôs- Aula

 Para Semana que vem

apresentação de seminário.  Estudar os dois casos

comentados em sala de aula:

◦_{Ariane 5;} ◦_Therac-25;

(60)

Pôs- Aula

 Montar uma apresentação que tem como objetivo:

◦_{Explicar os problemas que}

aconteceram devido as 2 casos; ◦_{Quais foram os problemas de}

Requisitos;

◦_{Colocar um ponto critico, Como que} a má analise de requisitos ou o

descuido com os mesmo levou a tantos prejuízos.

(61)

Pôs- Aula

 Exercício – 30 Minutos

 Faça um levantamento inicial dos requisitos necessários para o

desenvolvimento do seguinte sistema. Pense somente nas necessidades sem dividir nas categorias.

(62)

Pôs- Aula

 _{Uma cooperativa de taxistas solicitou a construção de um sistema}

de informação para facilitar e agilizar o seu funcionamento. Esta cooperativa possui vários associados e motoristas. A diferença existente entre estas duas categorias está na propriedade do veículo. Assim, o associado é dono de pelo menos um táxi,

enquanto o motorista não necessariamente precisa possuir um táxi para estar vinculado à cooperativa. O cadastro dos associados e motoristas da cooperativa, assim como de seus veículos, deverá fazer parte do sistema que será desenvolvido. Além disso, a

cooperativa mantém vários convênios. O cadastro destes convênios também deverá fazer parte do sistema. No momento do cadastro de um convênio, deverão ser informados os modelos e as marcas de veículos aceitos pelo convênio. Cada veículo pode atender a mais de um convênio. Quando uma solicitação de táxi for

cadastrada no sistema, um táxi deverá ser alocado para atendê-la. Para que um táxi seja selecionado para atender a uma solicitação, é necessário que seu modelo e sua marca sejam aceitos pelo

convênio. A verificação dessas restrições, assim como a atribuição de um táxi para atender a uma solicitação também devem ser

incorporados ao sistema. Considere que esta cooperativa de taxistas atende apenas convênios.

(63)

(64)

Referencias

 http://1.bp.blogspot.com/-GTiLnQxvJvM/U1cdVaYPjcI/AAAAAAAABkk/4kuIzmiwL8c /s1600/fluxogrma+1.jpg  https:// www.oficinadanet.com.br/imagens/post/10652/td_com o_entender.png  http://www.citisystems.com.br/fluxograma/  http://www.venki.com.br/blog/como-desenhar-um-flu xograma /  http://www.blogdaqualidade.com.br/como-fazer-um-f luxograma /  http://www.blogdaqualidade.com.br/fluxograma-de-pr ocesso /

 PEINADO, Jurandir; GRAEML, Alexandre

Reis. Administração da produção:operações industriais e de serviços. Curitiba: UnicenP, 2007.

 SLACK, Nigel et al. Administração de

(65)

Referencias

 SOMMERVILLE, Ian (org.).

Engenharia de Software. 9ª

ed. São Paulo: PEARSON, 2011.  PRESSMAN, Roger S..

Engenharia de Software. 7ª

ed. São Paulo: Makron Books, 2007.