65
REQUISITOS DE SISTEMAS PROF. Horacio Ribeiro Aula 06: REVISÃO REQUISITOS DE SISTEMAS REQUISITOS DE SISTEMAS

Reqsist REV1

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Reqsist REV1

REQUISITOS DE SISTEMAS PROF. Horacio Ribeiro

Aula 06: REVISÃO

REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS

Page 2: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Conteúdo Programático desta aula•REVISÃO DOS PRINCIPAIS CONCEITOS APRESENTADOS

NAS AULA 1 ATÉ AULA 5

Page 3: Reqsist REV1

Aula 1- requisitos de sistemas

Page 4: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

FRACASSOS DE PROJETOS

E OS MOTIVOS ???

Situação Desenvolvimento de SoftwareManaging Software Requirements:

A Use Case Approach, Second Edition, 2003

31% dos projetos são cancelados antes de serem completados

52,7% dos projetos custam 189% de sua estimativa inicial

Page 5: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

CUSTOS DE MODIFICAÇÕES

DEVE-SE EVITAR ERROS E FALTA DE DEFINIÇÕES

Page 6: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Uma condição ou capacidade necessitada por um usuário para resolver um problema ou alcançar um objetivo;

Requisitos do Sistema:

Page 7: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Page 8: Reqsist REV1

DETERMINAÇÃO DE OBJETIVOS

REQUISITOS

Page 9: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

CADA OBJETIVO OU SUBOBJETIVO

TEM UM CONJUNTO DE REQUISITOS

Page 10: Reqsist REV1
Page 11: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

OS REQUISITOS SÃO ORGANIZADOS EM GRUPOS.

CADA GRUPO DE REQUISITOS É ATENDIDO POR UMA FUNCIONALIDADE NO SISTEMA.

PARA CADA FUNCIONALIDADE DEVE-SE FAZER UMA ESPECIFICAÇÃO

OBJETIVO

REQUISITOS

FUNCIONALIDADES

ESPECIFICAÇÃO

Page 12: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Aplicando o conhecimentoOBJETIVO: UM SISTEMA PARA AOPOAR O DEPARTAMENTO DE VENDAS NAS SEGUINTES FUNÇÕES:-ATENDER O CLIENTE- EMITIR O TOTAL DE COMISSOES DE VENDAS.

-NECESSIDADES DO USUARIO:- TER ACESSO AOS PEDIDOS DE UM CLIENTE.- TER ACESSO AOS DADOS DO CLIENTE--TER ACESSO AS INFORMAÇÕES DE PAGAMENTO

-FUNCIONALIDADES:- -UM CADASTRO DE CLIENTES COM AS FUNÇOES.....--UM CADASTRO DE VENDAS COM AS FUNÇOES....-- UM CADASTRO DE PAGAMENTOS REALIZADOS....-.......

Page 13: Reqsist REV1

Aula 2- Requisitos de Domínio e de usuário

Page 14: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Page 15: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

O sistema também tem Objetivos correspondentes

O uso do sistema faz com que os Objetivos possam ser alcançados ou falhem

Objetivos podem ser divididos em sub-objetivos

Normalmente existem hierarquias de objetivos, onde se vê Níveis dos Objetivos

Hierarquias e Navies de Objetivos

Page 16: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Tipos de RequisitosFuncionais

o que o sistema faz para satisfazer as necessidades de seu usuário

Não Funcionais

Atributos técnicos que um sistema deve possuir para atender os requisitos funcionais

Restrições

Restrições que o sistema deve satisfazer, e que afetam igualmente os dois primeiros tipos.

Page 17: Reqsist REV1

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessárias que o software deve possuir (1)para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

(def. Wikipédia)

Requisitos funcionais

Page 18: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Requisitos não Funcionais (alguns)

•Usabilidade (facilidade de uso pelos usuários)•Confiança ( freqüência e resistência a falhas, capacidade de recuperação, predibilidade, precisão )•Desempenho (capacidade, taxas em relação ao tempo, de precisão: velocidade, disponibilidade, tempo de resposta, uso de memória )•Suporte ( capacidade manter o sistema atualizado, em termos de testes, manutenção, versões )•Aparência ( estética, visual, design gráfico )•Operacional ( o ambiente no qual será usado; ambiente operacional, condições do usuário, sistemas relacionados)•Segurança ( confidencialidade, integridade, disponibilidade )

Page 19: Reqsist REV1

Requisitos de Sistemas:

Definem, detalhadamente, as funções, os serviços e as restrições operacionais do  sistema. O documento de requisitos do sistema deve ser preciso. Ele deve definir exatamente o que será implementado. Requisitos de Usuários: São declarações, em linguagem natural com diagramas, de quais serviços são esperados do sistema e as restrições sobre as quais ele deve operar 

Page 20: Reqsist REV1

Requisitos de usuário

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 detalhadoRequisitos do usuário são definidos usando linguagem natural (evitar), tabelas e diagramas

Problemas

- Interpretações da linguagem natural-- completude e entendimento da tarefa--participação do usuário

Page 21: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINAPropriedades dos requisitos (1)

•Validade: requisitos identificados individualmente (isto é, junto a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas.

•Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema

-Verificar em três dimensões:

- por tipo de ator

- por tipo de serviço

- por tipo de ambiente

Page 22: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINAPropriedades dos requisitos (1)

•Consistência: não devem existir conflitos entre os requisitos identificados.Deve-se também validar os requisitos em duas dimensões: - legal - cultural

•Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.

•.Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.

Page 23: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Propriedades dos requisitos (2)

•Verificabilidade:

de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.

Definir condições de testabilidade e verificação do requisito.

Page 24: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Propriedades dos requisitos (3)

•Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.

Requisito 1usuário

usuário

usuário

Funcionalidade 1.1

Modulo 1.1.1 Programa

1.1.1.1

Page 25: Reqsist REV1

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

Requisitos de dominio

Page 26: Reqsist REV1

Aula 3 requisitos – qualidade – engenharia de requisitos

Page 27: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Qualidade de sistemas e os requisitos

conceito da palavra “sistema”,

seqüência de atividades, e conjunto de “coisas” para atingir um objetivo

soma:

software + hardware + procedimentos

Page 28: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

O processo de levantamento de requisito está vinculado para garantir qualidade no produto que vamos entregar.

Para qualquer empresa, ter qualidade nos seus processos para seu é ter uma estratégia competitiva, principalmente para aquela que desenvolve software.

Page 29: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

“Qualidade de software deve ser compreendido e empreendido como um processo sistêmico que precisa está presente todas as etapas e artefatos produzidos, visando a garantia da conformidade de processos e produtos mediante aos requisitos definidos.”

Page 30: Reqsist REV1

Sommerville (2011, pág. 60), destaca que os requisitos devem especificar todos os intentos do cliente, e que sejam de forma clara – os quais denominam pelo conceito de completude e consistência.  De maneira geral, os requisitos são classificados em três tipos. São eles: Funcionais;

Não funcionais; e

Interface. (vamos definir) 

Page 31: Reqsist REV1

estudo de viabilidade -> documento de analise do projeto

elicitação e análise de requisitos -> documento que mostra cada forma de registrar ações, telas,...

especificação de requisitos -> especificação padronizada de cada requisito

validação de requisitos) - > validação nos aspectos de completude e consistência.

Page 32: Reqsist REV1

Aula 4 IDENTIFICAÇÃO DOS STAKEHOLDERS. TÉCNICAS DE LEVANTAMENTO DE REQUISITOS

Page 33: Reqsist REV1

Existem indivíduos que estão relacionados direta ou indiretamente com um software.

Eles nem precisam fazer uso do sistema, mas mesmo assim, ele é afetado em algum aspecto.

São denominamos stakeholders.

Page 34: Reqsist REV1

Um requisitos funcional está sempre associado a um ou vários stakeholders.

Nem sempre é uma atividade fácil conseguir identificar o que realmente deve ser um requisito funcional ou não funcional.

Page 35: Reqsist REV1

A palavra vem de da seguinte composição:

•Stake: interesse, participação, risco.

•Holder: aquele que possui.

Page 36: Reqsist REV1

Segundo Summerville (2009), podemos definir da seguinte forma:

“Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.”

Page 37: Reqsist REV1

Podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de software::

Gerente de Projeto – Responsável em organizar e conduzir as equipes em suas responsabilidades. Como gestor, precisa manter harmonia no desenvolvimento do projeto, supervisionando a execução das tarefas, observar os processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc.

Analista de Sistema – Responsável em analisar quais as características o que deverá ter o produto a ser desenvolvido para atingir o objetivo final, ou seja, o que o cliente espera. Para isso, busca analisar as especificidades inerentes ao determinado software.

Programador – São os responsável por escrever as linhas de códigos que construirão a identidade lógica do software.

Page 38: Reqsist REV1

Podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de software::(continuação)

Patrocinador – Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto. Ele será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de software.

Cliente (usuário) – É aquele que, a partir de uma necessidade, faz a encomenda de um software. Portanto, é quem vai usufruir do produto a ser entregue; seja ele apenas um ou um grupo de usuários.

Page 39: Reqsist REV1

Primeiros cuidados:

- o gerente de projeto deve observar bem seus objetivos

-e não procurar stakeholders por todos lados, o que culminará em um cenário difícil de gerenciar.

-Deve haver limitação no escopo daqueles que afetam e/ou serão afetados pelo projeto.

-influência dos stakeholders em um projeto de software, suas relações e inter-dependência na concepção e uso de um determinado sistema.

Page 40: Reqsist REV1

Ações com stakeholders

Com influencia política

Sem influencia política

Com interesse No sistema

Sem interesse No sistema

ALIADOS

COLABORADORES OPOSITORES

INIMIGOS

Page 41: Reqsist REV1

Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:

•Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;

•Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;

•Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;

Page 42: Reqsist REV1

o problema de não saber especificar corretamente o que o sistema deverá fazer é muito rotineiro:

(a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer transmitir para o analista;

(b) requisitos identificados, mas que não exprimem a realidade;

(c) não estão em concordância com os requisitos informados por pessoas diferentes, são constantes na elaboração dos requisitos.

Um stakeholder ou informação errada afetará em perda de tempo e dinheiro É preciso aferir e revisar os requisitos.

Page 43: Reqsist REV1

EtnografiaA etnografia é uma técnica de observação, aonde o analista buscar uma familiarização do cliente, seus valores, sua história. Ela pode ser utilizada para compreender os requisitos sociais e organizacionais, que facilitem compreensão da política organizacional e da sua cultura.

O observador é inserido no ambiente de trabalho. Diariamente são realizadas anotações das tarefas observadas.

Esta técnica tem por principal objetivo em auxiliar na descoberta de requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais.

Tem eficácia em atuar na descoberta da maneira como as pessoas realmente trabalham, além do contexto de integração e colaboração entre o stakeholder . 

Page 44: Reqsist REV1

Workshops

Trata-se de uma técnica de elicitação desenvolvida em grupo, usada em uma reunião estruturada.

São integrantes do grupo que participaram do workshop: •Equipe de analistas.•Seleção dos stakeholders mais envolvidos no contexto em que o sistema atuará.

principal estratégia acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores. As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.

Page 45: Reqsist REV1

Entrevistas

A entrevista é tradicionalmente mais simples de utilizar, produz bons resultados na fase inicial de obtenção de dados.

Organizar a entrevista:

- Os membros da equipe devem ter funções : redator, condutor, revisor....

•O entrevistador dê margem ao entrevistado para expor as suas idéias.

•Ter um plano de entrevista para que seja mantido o foco no cerne do assunto principal.

•Evita que a entrevista fique longa, deixando o entrevistado cansado e não produzindo bons resultados.

Page 46: Reqsist REV1

Questionários

Existem vários tipos de questionários :• múltipla escolha, •lista de verificação •questões com espaços em branco.

quando há diversos grupos de usuários que podem estar em diversos locais diferentes do país elaboram-se pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais.

Page 47: Reqsist REV1

Brainstorming

Brainstorming é uma técnica para geração de idéias.

Uma idéia preliminar gerada serve como incentivo para que outras apareçam, sejam concordantes ou não.

Pode ser estabelecida uma ou várias reuniões.

Os participantes devem ser encorajados a dar, e combinar ou enriquecer as idéias de outros e, para isso, é necessário que todas as idéias permaneçam visíveis a todos os participantes.

Page 48: Reqsist REV1

PrototipagemFazer um protótipo para explorar requisitos vinculados a um produto que possua aspectos críticos. Implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto.

requisitos desenvolver validar

acertar

fim

Page 49: Reqsist REV1

JAD (Joint Application Design).

É uma técnica destinada a promover cooperação, entendimento e trabalho em grupo entre os usuários desenvolvedores.

A idéia é criar uma visão compartilhada do produto de software .Ela ajuda os usuários e desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido.

Page 50: Reqsist REV1

Outras técnicas:

-simuladores

-mapas mentais

- Determinação de cenários

-oficinas de requisitos

- Casos de uso

Page 51: Reqsist REV1

Aula 05: DOCUMENTAÇÃO DE REQUISITOS DE SOFTWARE

Page 52: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

A documentação registra todo o conteúdo extraído no levantamento de requisitos.

Retrata as especificações a serem seguidas no desenvolvimento de software.

Este é o que denominamos que documento de requisitos de software.

Existem “templates “ para desenvolver estes documentos.

Modelos de PRAXIS _RUP _ PROPRIETÁRIOS

Page 53: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

De acordo com Sommerville (2009),

“o documento de requisitos de software, às vezes chamado de Especificação de Requisitos de Software (SRS – do inglês Software Requerimento Specification), é uma declaração oficial do que os desenvolvedores do sistema devem implementar”.

Page 54: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Uma especificação de requisitos não é apenas um documento técnico, que será lido apenas pelos analistas de sistemas e os programadores.

Sommerville (2009) esclarece sobre tal realidade, tratando claramente sobre a diversidade do perfil de usuários, que vão desde a cúpula organizacional até aqueles vinculados à tecnologia da informação e comunicação. (todos os tipos e stakeholders)

Page 55: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

exemplo abaixo, retirado do livro do PFLEEGER (Engenharia de Software – Teoria e Prática – 2ª Edição, pág. 140):

Em 1995, a Organização Australiana de Defesa e Tecnologia relatou os resultados de uma pesquisa sobre problemas com especificação de requisitos na Marinha.

Um dos problemas destacados foi a disparidade no nível das especificações.

-alguns requisitos foram especificados em um nível alto - outros em um nível muito baixo.

Page 56: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Analistas:

•Algumas vezes, os analistas de requisitos utilizaram diferentes estilos de escrita, especialmente em área diferentes do sistema.

•A diferença de experiência entre os analistas levou a diferentes níveis de detalhes nos requisitos.

•Na tentativa de reutilizar os requisitos a partir de sistemas anteriores, os analistas empregaram diferentes formatos e estilos de escrita.

•Os analistas, algumas vezes, mesclaram requisitos com soluções parciais, levando a sérios problemas para o projeto de uma solução com boa relação custo-benefício.

Page 57: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Analistas:

•Freqüentemente os requisitos foram excessivamente especificados, quando os analistas identificaram tipos específicos de computadores e linguagens de programação assumiram uma solução específica ou impuseram processos e protocolos não apropriados.

•Algumas vezes, os requisitos foram pouco especificados, especialmente ao descreverem o ambiente de operação, manutenção, simulação para treinamento, computação administrativa e tolerância a falhas.

Page 58: Reqsist REV1

Sommerville (2009) na Figura 1, são estes exemplos de usuários de um documento de requisitos de software:

Page 59: Reqsist REV1

Segundo estrutura Sommerville (2009) –

Capítulo Descrição

Prefácio Deve definir os possíveis leitores do documento e

descrever seu histórico de versões, incluindo uma

justificativa para a criação de uma nova versão e um

resumo das mudanças feitas em cada versão.

Introdução Deve descrever a necessidade para o sistema. Deve

descrever brevemente as funções do sistema e explicar

como ele vai funciona com outros sistemas. Também

deve descrever como o sistema atende aos objetivos

globais do negócio ou estratégicos da organização que

encomendou o software.

Page 60: Reqsist REV1

Segundo estrutura Sommerville (2009) –

Capítulo Descrição

Glossário Deve definir os termos técnicos usados no documento.

Não deve conter suposições sobre o conhecimento ou

experiência do leitor.

Definição de

requisitos de

usuário

Deve descrever os serviços oferecidos ao usuário. Os

requisitos não funcionais do sistema também devem ser

descritos nessa seção. Essa descrição pode usar

linguagem natural, diagramas ou outras notações

compreensíveis para os clientes. Normas produtos que

devem ser seguidos devem sem especificados.

Modelos do

sistema

Pode incluir modelos gráficos do sistema que mostram

relacionamentos entre os componentes do sistema, o

sistema e seu ambiente.

Page 61: Reqsist REV1

Segundo estrutura Sommerville (2009) –

Capítulo Descrição

Evolução do

sistema

Deve descrever os pressupostos fundamentais em que

o sistema se baseia, bem como quaisquer mudanças

previstas, em decorrência da evolução do hardware, de

mudanças nas necessidades do usuário, etc. Essa

seção é útil para projetistas de sistemas, pois pode

ajudá-los a evitar decisões capazes de restringir

possíveis mudanças futuras no sistema.

Page 62: Reqsist REV1

Segundo estrutura Sommerville (2009) –

Capítulo Descrição

Apêndices Deve fornecer informações detalhadas e especificas em

relação à aplicação em desenvolvimento, além das

descrições de hardware e banco de dados, por

exemplo. Os requisitos de hardware definem as

configurações mínimas do sistema. Requisitos de

banco de dados, definem a organização lógica dos

dados usados pelo sistema e os relacionamentos entre

esses dados.

Índice Vários índices podem ser incluídos no documento.

Pode haver, além de um índice alfabético normal, um

índice de diagramas, de funções, dentre outros que

sejam pertinentes.

Page 63: Reqsist REV1

essa proposta não é única e definitiva, podendo sofrer adaptações, inclusões e exclusões, a depender da necessidade do cliente dos responsáveis pela sua criação e de padrões de documentação das empresas

Page 64: Reqsist REV1

Na próxima aula:

Material complementar para estas aulas no site:

www. Espacodoprofessor.com -- escolher a opção professor - - escolher horacio ribeiro - Estácio 2012

boa prova a todos

Page 65: Reqsist REV1

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Contactos e material complementar e exercícios

www.espacodoprofessor.com

Professor: Horacio ribeiro

Modulo Estácio 2012.1

Senha 222222