Engenharia de Requisitos V2

8/8/2019 Engenharia de Requisitos V2

http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 1/338

X25 Treinamento e Consultoria

Treinamentos e Soluções em Tecnologia eEngenharia de Requisitos de Software



Fátima Saldanha [email protected]

[email protected]• 30 anos na área de TI• Especialista em APF

• CFPS -> re certificação• Consultora de TI CAIXA - Qualidade• Instrutora Métricas/Gerência de Requisitos

“ A essência da gestão é que não se pode gerenciar aquilo que nãose pode medir “ (Scott Sink & Thomas Tuttle)

mailto:[email protected]

mailto:[email protected]



André Barbosa [email protected]

• Gerente de Programas• Mestre em Informática

• Certificado PMP, Scrum Master e Product Owner• Professor de Pós-graduações em Engenharia de

Software e Gerência de Projetos



Agenda• Introdução e Contextualização

– Modelos de Desenvolvimento• Definição de Requisitos• Modelagem de Negócio• Engenharia de Requisitos

– Elicitação– Análise– Especificação– Validação– Gerência de Requisitos– Métricas

• Processo Unificado

• Modelando com Diagrama de Caso de Uso• Gerência de Requisitos• Rastreabilidade



Introdução eContextualização



Objetivos

• Descrever as principais atividades daengenharia de requisitos• Introduzir técnicas para a elicitação e

análise de requisitos

• Descrever validação de requisitos• Discutir a influência do gerenciamento

de requisitos sobre as outras atividadesda engenharia de requisitos



Engenharia de Software

• É a aplicação de uma abordagem sistemática,disciplinada e quantificável no desenvolvimento ,operação e manutenção de software.

Sistemática – Existe um processo

Disciplinada - Processo deve ser seguido

Quantificável – Podemos medir o que estamos fazendo



Objetivos Engenharia Software

• Qualidade

• Produtividade

• Controle de Custos e Prazos

www.swebok.org - Software Engineering Body of Knowledge

http://www.swebok.org/

http://www.swebok.org/



Conceito da Engenharia deRequisitos

Para Summerville (2003):

O processo de descobrir, analisar,

documentar e verificar as funções erestrições do sistema.



Alvo da Engenharia de Requisitos

• Clientes Satisfeitos

• Eles Estão Satisfeitos

Quando Você:– Atende às expectativas– Entrega no prazo

– Entrega no orçamentoO Sucesso começacoma Gerência de

Requisitos



A Grande Armadilha• 85% erros são causados por defeitos inseridos na

fase de análise de requisitos.% custo dedesenvolvimento

% defeitosintroduzidos

% defeitosencontrados

Custorelativo dacorreção

Análise deRequisitos 5 55 18 1Projeto 25 30 10 1-1.5Codificação eteste deunidade

50

Teste 10 10 50 1-5Validação edocumentação

10

Manutenção 5 22 10-100



Cenário Atual

• Erros mais caros são aqueles encontradosno processo de requisitos e descobertospelo usuário.

• Standish Group 350 Cia e 8.000 projetos desoftware.

• 31% cancelados e somente 16% dentro do prazo e

orçamentos em grandes 9%



O problema

Fatores Críticos dos Projetos%Resp

Requisitos Incompletos13,1%

Falta de envolvimento do usuário 12.4%

Falta de Recursos10.6%

Expectativas Irreais9.9%

Falta de apoio Executivo9.3%

Mudança de Requisito eEspecificação

8.7%

Falta de Planejamento8.1 %



Sintomas dos Problemas doDesenvolvimento de Software

Necessidades de Negócio e Usuário não atendem. Muitas mudanças de requisitos. Módulos não integram. Difícil de manter. Descoberta tardia das falhas. Baixa qualidade e iteratividade com o usuário. Baixa performance sob condições normais. Esforço não coordenado da equipe.

Problemas de build-e-release (construção elançamento de versão).



Questões:

• Por que leva tanto tempo para darmos umsoftware como terminado ?

• Por que os custos com desenvolvimento desoftware são tão altos ?

• Por que não conseguimos encontrar todos oserros antes de entregarmos o software para ocliente ?

• Por que ainda continuamos a ter dificuldadesem medir o progresso de como um softwareestá sendo desenvolvido ?

Analisar o Problema do Projeto



Analisar o Problema do ProjetoRespostas:

• 1. O software é desenvolvido/projetado, ao invés demanufaturado no sentido clássico.

• 2. Software não se desgasta com o uso: não existempeças de reposição.

• 3. Custo derivado do esforço intelectual.

• 4. Software não pode ser visto ou tocado: para analisar oprogresso de um projeto de software é preciso recorrer à suadocumentação.

• 5. Toda falha de software indica um erro no projeto ou noprocesso de desenvolvimento. Logo a manutenção desoftware é mais complexa do que a de hardware.

• 6. A maioria dos softwares é feita sob medida (porencomenda), ao invés de ser montada a partir decomponentes existentes.



Analisar o Problema do ProjetoProblemáticas:

• Dedica-se pouco tempo à coleta de dados (requisitos dosclientes):

• Normalmente apenas um subconjunto das necessidades docliente são levadas em conta.

• Os profissionais estão sempre com muita pressa para

começar a programar ...

• A qualidade geralmente é suspeita ...

• Testes sistemáticos e tecnicamente completos raramentesão feitos;

• A flexibilidade da maioria dos softwares também é bastantelimitada;

• A concorrência com software barato mas sem qualidade,feito por pessoas sem qualificação adequada é grande.




Mito:

Já temos um manual repleto de padrões eprocedimentos para a construção desoftware. Isso não oferecerá ao meu pessoaltudo que eles precisam saber ?

Realidade: Os padrões….O manual de padrões pode muito bem existir,mas será que ele é usado? Os profissionais desoftware têm conhecimento de suaexistência? Ele reflete a moderna prática de

desenvolvimento de software? É completo?Em muitos casos, a resposta a todas estasperguntas é "não".




Mito:

Se nós estamos atrasados nos prazospodemos adicionar mais programadores e tiraro atraso (chamado conceito de horda dosmongóis).

Realidade:O desenvolvimento de software não é um

processo mecânico igual à manufatura. Brooksdisse:"...acrescentar pessoas em um projeto desoftware atrasado torna-o ainda mais atrasado".

Quando novas pessoas são acrescentadas, aspessoas que estavam trabalhando devemgastar tempo educando os recém chegados, oque reduz o tempo despendido num esforço dedesenvolvimento produtivo.




Mito:

Uma declaração geral dos objetivos ésuficiente para começar a escrever programas –podemos preencher os detalhes mais tarde.

Realidade:

Uma definição inicial ruim é a principalcausa de fracasso dos esforços dedesenvolvimento de software. Uma descriçãoformal e detalhada do domínio da informação,função, desempenho, interfaces, restrições de

projeto e critérios de validação é fundamental.Essas características podem ser determinadassomente depois de cuidados comunicação entreo cliente e o desenvolvedor.



Analisar o Problema do ProjetoMito:

Os requisitos de projeto modificam-se

continuamente, mas as mudanças podem serfacilmente acomodadas, porque o software éflexível.

Realidade:

É verdade que os requisitos de software semodificam, mas o impacto da mudança variade acordo com o tempo em que ela éintroduzida. Se uma séria atenção for dada àdefinição inicial, os primeiros pedidos demudança podem ser acomodados facilmente.

• Definição . . . . . . . . . . . . . . . . . x• Desenvolvimento . . . . . . . . . . 1.5x a 1.6x• Manutenção . . . . . . . . . . . . . . 60x a 100x




Mito:

Assim que escrevermos o programa e ocolocarmos em funcionamento nosso trabalhoestará completo.

Realidade:

Alguém disse certa vez que "quanto maiscedo se começa a 'escrever o código', maistempo demora para que se consiga terminá-lo".Os dados da indústria indicam que entre 50 e70% de todo esforço gasto num programa serão

despendidos depois que ele for entregue pelaprimeira vez ao cliente.




Mito:

A única coisa a ser entregue em umprojeto bem sucedido é o programafuncionando.

Realidade:

Um programa funcionando é somenteuma parte de uma configuração de softwareque inclui: plano, especificação de requisitos,projeto, estrutura de dados, listagem,especificação de teste, programa funcionando.




Mito:

Enquanto não tiver o programa"funcionando", eu não terei realmente nenhumamaneira de avaliar sua qualidade.

Realidade: ex RTPUm dos mecanismos mais efetivos de

garantia da qualidade de software pode seraplicado desde o começo de um projeto - arevisão técnica formal. As revisões de softwaresão um "filtro da qualidade" que têm sido

consideradas mais eficientes do que arealização de testes para a descoberta decertas classes de defeitos de software.



Principais Fatores deFalha dos Projetos

Requisitos e Especificações IncompletosRequisitos e Especificações Incompletos

Objetivos Não Estavam ClarosObjetivos Não Estavam Claros

Requisitos e Especificações InstáveisRequisitos e Especificações Instáveis(Mudanças)(Mudanças)

Falta de “Input” do UsuárioFalta de “Input” do Usuário

Falta de Suporte do NívelFalta de Suporte do NívelExecutivoExecutivo



Um caso comum !!

O sistema que queremos deve fazer isto,isto, ..., e nesse caso também isto...;

- Sim, Sim, estou anotando...

- Conversei com os usuários ebasicamente este é o sistema queteremos que desenvolver;

- Sim chefe;

- Ótimo, começaremos a especificar osrequisitos imediatamente.



Motivação

Quatro meses depois ...- Senhores usuários, após o emprego dasmais modernas técnicas de especificação,produzimos este documento que descreve

minuciosamente o Sistema;- Ótimo! Bom! Hum! ... É um documentocom 300 páginas e todos estes gráficos,tabelas. Enfim, vamos analisá-los evoltamos a falar;



Motivação

Mais um mês e meio ...- Sr. Analista, nosso pessoal analisou com

cuidado o documento. Tivemos muitasdificuldades em entendê-lo. Mas o que

percebemos é que NÃO FOMOSCORRETAMENTE ENTENDIDOS!!!- Como não? Tudo que está aí foi fruto de

nosso entendimento pessoal.

REALMENTE VOCÊS NÃO SABEM O QUEQUEREM!!!



Motivação



• Comprometimento da Alta Administração

• Treinamento e Educação

• O uso adequado das técnicas, métodos, eferramentas.

• Utilização dos Modelos e padrões de

Qualidade deSoftware

• Documentação do Sistema

A Crise de Software:existe solução?



Modelos

Vi ã G l



Visão Geral



Modelos de Desenvolvimento

Descrições abstratas do processo de

desenvolvimento de software, mostrando asatividades e dados usados no ciclo de vida dosoftware.Os principais modelos existentes são:

- Modelo clássico (ou em cascata ouSequencial);- Prototipagem (ou Prototipação);- Incremental (iterativo)

- Modelo espiral (ou baseado em riscos);- Transformação formal (ou refinamento);




Modelo Clássico em Cascata

Requisitos

Análise

Design

Construção

Teste

Manutenção

Vantagens?•Oferece uma maneira de tornaro processo mais visível.•Facilita o planejamento.•Fixa pontos específicos para aescrita de relatórios.•Indicado para quando os

requisitos do sistema são muitobem entendidos.esvantagens?

Projetos reais raramente seguem o fluxoeqüencial proposto por este modelo: na maioriaos casos existe interação e superposição.Raramente os clientes (usuários) declaram todass exigências de uma vez, no início do projeto.Boa parte dos programas não estará disponível atém ponto adiantado no cronograma do projeto: éeralmente difícil convencer o usuário de que éreciso paciência




Modelo Incremental/Interativo




Modelo Incremental/Iterativo

Vantagens?•Indicado para os projetos onde já se tem uma compreensão dassuas características essenciais e tem-se um deadline rígido paraimplantá-lo.

•Desenvolvimento da primeira versão do sistema o mais rápidopossível;

•Modificações sucessivas até que o sistema seja consideradoadequado;

•A primeira versão pode ser implementada por poucas pessoas ecom a aceitação do produto pode-se adicionar mais pessoas paraacelerar odesenvolvimento.

•O primeiro incremento (versão) é o núcleo do software. Nesta

d l d l i




Modelo Incremental/Iterativo

Vantagens?•As características suplementares (algumas já conhecidas eoutras não) são entregadas apenas nas versões posteriores.

Desvantagens?•Visibilidade Fraca•Estrutura Desorganizada•Habilidades Especiais são requeridas

M d l d D l i




Prototipação

Especificação

Desenvolvimento

Validation

Versão Inicial

Vesão InicialVesão InicialVersõesIntermediárias

Versão Final

Descrição Alto Nível

M d l d D l i




Prototipação

Vantagens?•Protótipos contribuem para melhorar a qualidade daespecificação dos futuros programas, o que leva à diminuição dosgastos com manutenção.

•Em alguns casos, o treinamento dos usuários pode até ser feitoantes do produto ficar pronto.

•Algumas partes do protótipo podem vir a ser usadasnodesenvolvimento do sistema final.

Obs.: comum em métodos ágeis!

M d l d D l i t




Prototipação

Desvantagens?•Em geral o grande argumento contra a construção de protótiposé o custo.

•A construção do protótipo atrasa o início daimplementação do sistema final.

• Atrasos são um dos maiores problemas dos projetos desoftware.• Construir um protótipo pode não ser tão mais rápido doque construir o sistema final.

• Se os ambientes utilizados forem diferentes este custoserá um custo extra.

F G é i d Q i



Fases Genéricas de QuaisquerModelos

Independente do modelo, as fases a seguir sempre

precisam existir, mesmo que não seja trivial identificá-lasno projeto.

Definição - O QUÊ.•Análise dos Requisitos•Planejamento

•Análise do Sistema

Desenvolvimento - COMO.•Projeto•Codificação• Testes

Manutenção - MUDANÇAS•Correção•Adaptação•Melhoramento

Foco da Gestãode Requisitos

F G é i d Q i



Fases Genéricas de QuaisquerModelos

Independente do modelo, as fases a seguir sempre

precisam existir, mesmo que não seja trivial identificá-lasno projeto.

Definição - O QUÊ.•Análise dos Requisitos•Planejamento

•Análise do Sistema

Desenvolvimento - COMO.•Projeto•Codificação• Testes

Manutenção - MUDANÇAS•Correção•Adaptação•Melhoramento

Foco da Gestãode Requisitos

M d l d M t id d CMMI



CENÁRIO ATUAL

•Globalização da Economia•Mudanças Tecnológicas Velozes

•Crescimento da Complexidade Sistemas

•Escassez de Recursos Humanos

•Clientes mais Exigentes

QUALIDADE E PRODUTIVIDADE

Modelo de Maturidade CMMI

GERÊNCIA DE REQUISITOS E CMMI SE/SW



GERÊNCIA DE REQUISITOS E CMMI-SE/SW

• CMMI (CMM Integration): framework/suíte queintegrou os seguintes modelos:– CMM for Software– Systems Engineering CM (SECM)– The Integrated Product Development CMM (IPD-CMM)

• As organizações podem usar o CMMI para ajudar:

– definir objetivos e prioridades da melhoria do processo;

– melhorar processos;

– prover um guia para assegurar processos estáveis,capacitados e maturos;

– servir com um guia para a melhoria dos processoorganizacionais.




•Qualidade do Processo de Software

•Qualidade do Produto

•Processo Controlado

Indicadores





Melhor Gerênciada Terceirização

Aumento da Produtividade

Melhora da Qualidade

Redução doCustoda ManutençãoReduçãodo

Retrabalho

Gerência de Riscos

Garantia daSatisfação

do Cliente





Métricas, Modelos,Medições e Análises

Foco noCliente

Melhoriado Processo

Lado Humano

da Qualidade

Total Quality Management

Melhoria Contínua





•Modelos de referência de práticas de engenharia desoftware, como o CMM (Capability Maturity Model) e,mais recentemente, o CMMI, consideram ogerenciamento de requisitos como sendo uma dasprimeiras etapas para alcançar a maturidade

organizacional.• Para haver o gerenciamento é preciso que o

processo de gerenciamento de requisitos estejaimplantado na empresa.

• A seguir, será visto o gerenciamento de requisitos naperspectiva do CMMI-SE/SW.



Qualidade Total

OTIMIZAÇÃO5

DEFINIDO3

REPETÍVEL2

INICIAL1

NÍVEIS DENÍVEIS DEMATURIDADEMATURIDADE

GERENCIADO4

ControleGerencial

Básico

Definiçãodo Processo

Mediçãodo Processo

Controledo Processo

MODEL

O CMMI

MODELO CMM



MODELO CMM

1 - INICIAL O desenvolvedor é ogrande artista.

2 - REPETITIVO •Gerência deConfiguração de Software•Garantia de Qualidadede Software

•Gerência de Contrato desoftware•Superv.Acomp.deProj.Software•Planejamento do Projetode Software

•Gerência de RequisitosMétrica



3 - Definido •Revisão por parceiros•Coordenação Grupos•Engenharia Produtosoftware•Gerência de SoftwareIntegrada•Treinamento•Definição ProcessoOrganização

•Foco no Processo daOrganização

4 - Gerenciado Gerência de QualidadeGerência Quantitativa-Processosde Medidas

Gerência da Evolução doProcessoEvolução de TecnologiaPrevenção de defeitos

5 -

Otimizado




CMMI – Breve Histórico– Capability Maturity Model (CMM) para Software

• Ainda não era o CMMI...– Desenvolvido inicialmente pelo SEI (Software Engineering

Institute) da Carnegie-Mellon, no início dos anos 90– Um modelo de referência de práticas maduras em uma

disciplina específica, usado para avaliar uma capacidade deum grupo para executar aquela disciplina

– Feito para ser genérico– Disponível publicamente, documentado, repetível e ‘vivo’– Usado como balizador para melhoria de processos de

software, recursos humanos e engenharia de sistemas.– Segundo o modelo CMMI, quanto maior o controle sobre o

processo de desenvolvimento, mais madura é a organização.





Software

CMM

V1.1

SECAM

EIA/IS 731

SECM

SE-CMM

Time 1993 2002

Software

CMM

V2.0c

Timeline not to scaleIPD-CMM

v0.98

SA-CMM

v1.01

CMMI

V1.1xCMMI

V1.0x




Por estágios:

cinco níveis dematuridade

cada nível dematuridade definido por (Key) Process Areas

(KPAs/PAs) provê um guia para aimplementação

Contínua:

cinco ou seis níveis decapacidade

cada nível de capacidadedefinido por PAs e Práticas Gerais

provê flexibilidade máxima por focar em áreas de processo

específicas de acordo com asmetas e os objetivos do negócio

O CMMI possui duas representações:

por estágios (staged )

contínua




A organização recebe uma classificação dematuridadeA maturidade do processo é classificada emníveis (1 a 5) – cada nível é definido poragrupamento de áreas de processo (PAs) Todas as áreas de processo dentro de cadanível devem ser satisfeitas para atingir umaclassificação específica .

Ê




http://www.borland.com/resources/cmmi/staged/static/CMMI%20Staged%20MainPage.html

Ê




5Optimizing

Process change management

Technology change managementDefect prevention

4Managed

3Defined

2Repeatable

1

Initial

Software quality management

Quantitative process management

Peer Reviews

Intergroup coordination

Software product engineering

Integrated software managementTraining program

Organization process definition

Organization process focus

Software configuration management

Software quality assurance

Software subcontract management

Software project tracking and oversight

Software project planningRequirements management

Process improvement

is institutionalized

Product and process

are quantitatively

controlled

Technical practices are

integrated with

management practicesand institutionalized

Project management

practices are

institutionalized

Process is informal and

ad -hoc

Key Process AreaLevel Focus Results

Risk

Key Process Area

Quality

From Software Engineering Institute (SEI)





Área de Processo “Gerenciamento de Requisitos”

segundo o CMMI:

• Propósito– Gerenciar os requisitos dos produtos do projeto e de seus

componentes e identificar inconsistências entre estesrequisitos e aqueles que foram identificados nos planos deprojeto e nos artefatos.[1]

• Verificado:

– No Nível 2 quando se usa a Representação por Estágios– Na Categoria Engenharia na Representação Contínua

[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 82 (stagedrepresentation)




[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 83 (stagedrepresentation)

• Meta

– Os requisitos são gerenciados e as inconsistências entreos planos de projeto e os artefatos são identificadas [1]

Manter a coleção de requisitos aprovados (baseline) e‘rastrear’ as mudanças nesses requisitos.

Manter os relacionamentos entre requisitos, os planosde projeto e outros artefatos.

Identificar inconsistências entre os requisitos, o plano deprojeto e outros artefatos.

Tomar medidas corretivas, quando necessário.

Isso significa:





• Práticas e Artefatos– Obter um entendimento dos requisitos:

• Lista de critérios para distinguir os ‘provedores’ de requisitos apropriados;• Critérios para avaliação e aceitação de requisitos;• Resultados da análise por meio dos critérios.

– Obter um comprometimento em relação aos requisitos:• Verificação de impactos nos requisitos• Aceites documentados em relação aos requisitos e às mudanças nos

requisitos– Gerenciar mudanças nos requisitos

• Status dos requisitos• Repositórios de requisitos

– Manter rastreabilidade bidirecional• Matriz de Rastreabilidade de Requisitos• Sistema de Acompanhamento de Requisitos

– Identificar inconsistências entre requisitos e demais artefatos• Documentação de Inconsistências, incluindo fontes, condições e rationale• Ações corretivas

[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 82 (staged





Relações entre o Gerenciamento de Requisitos e as outras Áreas deProcesso

GERÊNCIA DE REQUISITOS X GERÊNCIA POR



GERÊNCIA DE REQUISITOS X GERÊNCIA PORREQUISITOS

•Importância da Gerência de Requisitos

Segundo o CMMI, a Gerência por Requisitos (ou Gerência de Requisitos)trata de um aspecto fundamental e crítico em qualquer processo desoftware: estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo software.

• Aspectos fundamentais na Gerência de Requisitos:– Estabilidade– Rastreabilidade



Requisito - Definição

O que é um requisito?



O que é um requisito?• Uma condição ou capacidade necessitada por um

usuário para resolver um problema ou atingir umobjetivo.

• Uma condição ou capacidade que deve ser

atendida ou contemplada por um sistema oucomponente de sistema para satisfazer umcontrato, padrão, especificação ou outrodocumento formalmente imposto.

• Uma representação documentada de umacondição ou capacidade conforme ilustradas nositens anteriores.



Regras de Negócio

• Políticas Corporativas• Regulamentos governamentais• Práticas contábeis• Padrões do negócio• Algoritmos , Cálculos do negócio

É possível rastrear a origem de certas

funcionalidades que são derivadasatravés de certas regras de negócio

Regras de Negócio



Regras de Negócio

• As Regras de Negócio são todos oscálculos, consistências, validações, processamentos e eventos de um sistema.

• Estas Regras são especificadas em

linguagem natural, normalmente sem padronização.• Depois de especificadas, estas Regras são

enviadas para a programadores, que vãotransformar a especificação em código

fonte em alguma linguagem de programação.

Fronteira



Fronteira

•É uma interface conceitual entre a aplicação e o mundo externo.

•Define o que é externo à aplicação.•É definida pela visão de negócio do usuário e não por considerações

tecnológicas.• Age como uma membrana por onde passam dados processados pelas

transações, entrando ou saindo do sistema.

•Quando o escopo da contagem envolver mais de uma aplicação, asfronteiras entre as aplicações devem ser determinadas.

Escopo



Escopo

Define as funcionalidades que serão

incluídas em um Sistema.

Novo sistema inclui todas as funcionalidades .

O escopo define um conjunto (ou subconjunto)

das funcionalidades do software.

Pode incluir mais de uma aplicação

Engenharia de



gRequisitos

Elicitação

Requisitosdesenvolvimento

Requisitosdesenvolvimento

GerenciamentoRequisitos

Análise Especificação Validação

clarear

Reavaliar

Reescrever

Corrigir e encerrar aslacunas



Processo

Entidade

Fronteira

A menor Unidade Lógica

M d l F i iM d l F i i



Modelos FuncionaisModelos Funcionais

O que é uma funcionalidade ?• Uma Função• Uma necessidade do negócio, do usuário.

• Uma Capacidade necessitada por um usuário

para resolverum problema ou atingir um objetivo

Algo Visto, Tangível, com sentido tanto parausuários quanto para desenvolvedores que

trabalhando em conjunto produzem umdeterminado resultado

Nota : Funcionais,Qualidade (ISO 9126) e

Técnicos.





• Tanto pode ser uma declaraçãoabstrata de alto nível de um serviçoou restrição do sistema quantouma especificação funcionalmatemática detalhada




O que é um requisito?(Sommerville and Sawyer 1997)

1. Requisitos são....a especificação do que pode serimplementado.

2. Eles são a descrição de como o sistema poderá se comportar,ou uma propriedade ou atributo do sistema.

3. Eles podem ser também uma restrição no processo dedesenvolvimento do sistema

4. Atributos descrevem não o que o sistema faz mas como tãobem ele faz

Exemplos de softwares que satisfazem os requisitosfuncionais mas não satisfazem a expectativa do usuário emqualidade.

5. Outros tipos de requisitos podem impor restrições que os

desenvolvedores devem tratar que limitam em função datecnolo ia um bom desem enho do software.



Tipos de Requisitos



Tipos de Requisitos

Os nomes mais utilizados são:• Requisitos do Sistema• Requisitos funcionais• Requisitos de Software

• Requisitos do Produto• Requisitos Técnicos• Restrições• Artefatos

• Requisitos• Requisitos do Negócio• Requisitos do Usuário

Níveis de Requisitos



Níveis de Requisitos

1. Requisitos do Negócio

1. Requisitos do Usuário

1. Requisitos Funcionais

1. Requisitos do Sistema

1. Requisitos Não Funcionais

Hierarquia de Requisitos



Hierarquia de Requisitos

Requisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário =df

Tipos de Requisitos



pos de equ s os

• Requisitos do Usuário– Declarações em linguagem natural com

diagramas de serviços que o sistema deveoferecer e suas restrições operacionais.Escrito para os clientes

• Requisitos do Sistema– Documento estruturado com descriçõesdetalhadas sobre os serviços do sistema.Contrato entre cliente e fornecedor

• Especificação do Software– Descrição detalhada do software que servecomo base para projeto ou implementação.Escrito para desenvolvedores

Requisitos Funcionais e Não-



qFuncionais

• Requisitos Funcionais– Declarações sobre o que o sistema deveoferecer, como o sistema deve reagir adeterminadas entradas e como o sistema devecomportar-se em situações especiais

• Requisitos Não-Funcionais– Restrições sobre funções ou serviços oferecidas

pelo sistema (tempo, processo dedesenvolvimento, padrões, etc)

• Requisitos de Domínio– Requisitos vindos do domínio da aplicação do

sistema e que refletem características dessedomínio (funcionais/não-funcionais)



Requisitos Funcionais



q(Exemplos)

• O usuário poderá pesquisar todo oconjunto inicial de banco de dados ouselecionar um sub-conjunto dele

• O sistema deve oferecer visualizadores

apropriados para o usuário lerdocumentos armazenados

• A todo pedido deve ser associado umidentificador único (PID), o qual o usuário

pode copiar para a área dearmazenamento permanente da conta

Requisitos Não-Funcionais



q

• Definem propriedades e restrições dosistema (tempo, espaço, etc)• Requisitos de processo também podem

especificar o uso de determinadas

linguagens de programação, método dedesenvolvimento

• Requisitos não-funcionais podem sermais críticos que requisitos funcionais.Não satisfaz, sistema inútil.



Medidas de Requisitos



q(Não-Funcionais)

ropriedade Medidaelocidade Transações processadas/seg

Tempo de resposta do usuário/eventomanho K bytes

No de chips de RAMcilidade de uso Tempo de treinamento

No de quadros de ajudaonfiabilidade Tempo médio de falhas

Probabilidade de indisponibilidade Taxa de ocorrência de falhas

obustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha

rtabilidade Percentual de declarações dependentes do destiNo de sistemas destino

Requisitos Não-Funcionais



q(Exemplos)

• Requisitos do Produto– Toda consulta ao banco de dados baseada

em código de barras não deve exceder 5 s

• Requisitos Organizacionais– Todos os documentos entregues devem

seguir o padrão de relatórios XYZ-00

• Requisitos Externos– O sistema não deve usar informações

pessoais do usuário com os operadores dosistema

Requisitos de Domínio



q

• Derivados do domínio da aplicaçãoe descrevem características dosistema e qualidades que refletemo domínio

• Podem ser requisitos funcionaisnovos, restrições sobre requisitosexistentes ou computações

específicas• Se requisitos de domínio não forem

satisfeitos, o sistema pode tornar-

se não prático




q(Problemas)

• Entendimento– Requisitos são descritos na linguagem

do domínio da aplicação

– Não é entendido pelos engenheiros desoftware que vão desenvolver aaplicação

• Implicitude

– Especialistas no domínio entendem aárea tão bem que não tornam todos osrequisitos de domínio explícitos




q(Exemplo 1)

• A desaceleração do trem deve sercomputada através da fórmula

Dtrem

=Dcontrole

+Dgradienteonde ...

Outra Classificação



• Requisitos Mutáveis– Mudanças do ambiente da organização

Ex:financiamento do tratamento dospacientes,diferentes informações sejam

coletadas

• Requisitos Emergentes– Aparecem pela maior compreensão durante

o desenvolvimento do sistema.




• Requisitos conseqüentes– Requisitos que resultam da modificação dosprocessos da organização e criação de novosmeios de trabalho, que geram novosrequisitos.

• Requisitos de compatibilidade.– Requisitos que dependem de outros sistemas

ou processos do negócio. A medida que elesse modificam ,os requisitos de

compatibilidade podem ter que evoluir.




• Requisitos Permanentes

- Relativamente estáveis derivados daatividade principal da empresa ex: Um

hospital terá sempre requisitos relativosaos pacientes, aos médicos, àsenfermeiras e aos tratamentos w Podemser derivados dos modelos de domínio.




• Requisitos Voláteis

- Provavelmente vão se modificardurante o desenvolvimento do sistema

ou depois que o sistema já estiver emoperação. ex:políticas governamentaissobre assistência médica.

Priorização



• Requisitos podem ser vistos em trêsclasses distintas– Essenciais– Importantes

– Desejáveis

• Em princípio, sistema deve resolvertodos os requisitos de essenciais paradesejáveis

Regras de Negócio



Regras de Negócio

• Políticas Corporativas• Regulamentos governamentais• Práticas contábeis• Padrões do negócio

• Algoritmos , Cálculos do negócio

É possível rastrear a origem de

certas funcionalidades que sãoderivadas através de certas regras denegócio

Regras de Negócio



g g

• As Regras de Negócio são todos oscálculos, consistências, validações,processamentos e eventos de um sistema.

• Estas Regras são especificadas emlinguagem natural, normalmente sempadronização.

• Depois de especificadas, estas Regras sãoenviadas para a programadores, que vãotransformar a especificação em códigofonte em alguma linguagem deprogramação.

Qualidades de um requisito de



software

• Verificabilidade• Ranqueamento por importância ou

estabilidade• Modificabilidade

• Rastreabilidade• Inteligibilidade• Corretude• Completude• Consistência• Não-ambiguidade

Qualidades de um requisito:



verificabilidade

• Um requisito é verificável quando:– Existe um processo finito e de custo efetivo no qualuma pessoa ou máquina pode checar se o produtoatende aos requisitos

O sistema suporta 1000 usuários simultâneos

O sistema consegue responder a uma consulta arbritária em500mseg. A cor apresenta um tom agradável de verde O sistema é capaz de ficar disponível 24 horas por dia 7 dias na

semana O sistema consegue exportar dados em formato separado por

vírgula Esses requisitos são verificáveis?

Caso contrário, qual seria a melhor forma de definí-los?




rastreabilidade

Solicitações dos envolvidos

Características

Casos de uso Especificações

suplementares




não-ambiguidade• Um requisito é não-ambíguo quando:

– Só tem uma interpretação possível

Requisito A

“A deve fazerB para C”

“A deve fazerB para C”

“A deve fazer

B para C”

Explorando a ambiguidade: uma



observação

Fonte: Rational University

O que um requisito nãol



contempla

• Design – como atingir os requisitos– O modelo de design especifica componentes de umsistema e/ou interfaces com outros subcomponentes

• Verificação – como saber se os requisitos foram

alcançados– O modelo de teste especifica casos e procedimentos deteste

• Dados do projeto – quando os requisitos serãoalcançados– O plano de desenvolvimento de software especifica

calendários, planos de verificação e validação, e planosde gerenciamento de configuração

Desafios



• Compreensão do domínio doProblema

•Achar o verdadeiro usuário• Evolução contínua dos Requisitos(Scope Screep)

• Definição de domínio Sistemas ou áreasfuncionais dentro dos sistemas que exibemfuncionalidades similares

Verdades e Requisitos



1. Se você não captura direito os requisitos, nãoimporta como você fará bem o resto doprojeto.

2. Desenvolvimento de requisitos é um processode invenção e descoberta, não simplesmenteum processo.

3. Mudanças acontecem.4. O interesse de todos os envolvidos influencia

no processo.

5. Envolvimento do cliente é a maiorcontribuição crítica para a qualidade dosoftware

6. O cliente não está sempre certo , maissempre tem algo importante.

Antes dos Requisitos



Antes dos Requisitos

Modelagem de Negócios




Com a crescente complexidade dossistemas corporativos enecessidade de integração entreeles, veio a necessidade de ser criar

modelos de mais alto nível deabstração e estes modelos foram seintegrando às disciplinas dedesenvolvimento de software.




Requisitos do Negócio

• Nível superior , declarações dasmetas, objetivos e necessidades daempresa.

• São desenvolvidos e definidosatravés de análise da empresa• Descrevem as razões pelas quais

um projeto foi iniciado, o objetivosque o projeto vai alcançar, e asmétricas que serão usadas paramedir seu sucesso




Requisitos do Negócio

• Descrevem as necessidades daorganização como um todo, e nãogrupos ou partes interessadas nele.

Modelagem de Negóciosi i d á i



Requisitos do Usuário(Stakeholder)

• Necessidades que um ator tem ecomo as partes interessadas irãointeragir com a solução .

• servem como uma ponte entre asnecessidades empresariais e asdiversas classes de requisitos da

solução• São desenvolvidos e definidosatravés da análise de requisitos

Modelagem de NegóciosR i i d S l ã



Requisitos da Solução

• descrevem as características deuma solução que atendam aosrequisitos de negócio e aosrequisitos dos Usuário interessadas.

• Eles são desenvolvidos e definidosatravés de análise de requisitos

Modelagem de NegóciosR i it d S l ã



Requisitos da Solução

• Divididos em sub-categorias paradescrever a solução de software

– Requisitos Funcionais ▷ ▷

descrevem o comportamento e asinformações que a solução vai gerir. Acapacidade que o sistema será capazde realizar em termos de

comportamentos ou Operações .

Modelagem de NegóciosR i it d S l ã



Requisitos da Solução– Requisitos Não Funcionais▷ ▷– condições que descrevem as

condições ambientais em que asolução deve permanecer .

– Qualidades que os sistemas devemter.– São conhecidos como os requisitos de

qualidade : Capacidade, Velocidade,

Segurança, Disponibilidade ,Arquitetura da informação eUsabilidade




Negócio

Necessidades

Objetivo: mapear e documentar os processos da cadeia devalor da organização para melhor atingir sua missão,estratégia, metas e objetivos.

Permite identificar mais facilmente quais atividadesautomatizar através de software para obter melhordesempenho.

Software




Como modelar?RUP oferece casos de uso de negócio.O mercado tem adotado o BPMN.

O BPMN fornece uma notação necessária para

expressar os processos de negócio em um único diagramade processo de negócio (Business Process Diagram – BPD)

– Fornece uma notação que compreensível por todos osutilizadores, analistas e técnicos do negócio.

– Garante que linguagens projetadas para a automação eexecução de processos de negócio, tais como o BPEL4WS e o

BPML, sejam visualmente expressos com uma notaçãocomum.




Abordagem BPMN




Artefatos

Objeto Descrição Figura

Objetos de dados O objeto de dado é um mecanismopara mostrar como os dados sãorequeridos ou produzidos poratividades. São conectados àsatividades com as associações.

Grupo Um grupo é representado por umretângulo e pode ser usado parafinalidades de documentação ou deanálise.

Anotações As anotações são mecanismos

para fornecer informaçõesadicionais para o leitor de umdiagrama BPMN.




Objeto Descrição FiguraEvento É algo que acontece durante um processo

do negócio. Estes eventos afetam o fluxodo processo e têm geralmente uma causa(trigger) ou um impacto (result). Há trêstipos de eventos, baseados sobre quandoafetam o fluxo: Start, Intermediate, e End.

Atividade É um termo genérico para um trabalhoexecutado. Os tipos de atividades são:

Tarefas e sub-processos. O sub-processo édistinguido por uma pequena cruz nocentro inferior da figura.

Gateway É usado para controlar a divergência e aconvergência da seqüência de um fluxo.Assim, determinará decisões tradicionais,como juntar ou dividir trajetos.

Objetos de Fluxo




Objeto Descrição Figura

Fluxo deseqüência

É usado para mostrar a ordem(seqüência) com que as atividadesserão executadas em um processo.

Fluxo de

mensagem

É usado mostrar o fluxo das

mensagens entre dois participantesdiferentes que os emitem e recebem.

Associação É usada para associar dados, texto, eoutros artefatos com os objetos defluxo. As associações são usadas para

mostrar as entradas e as saídas dasatividades.

Objetos de Conexão




Objeto Descrição FiguraPool Um pool representa um

participante em um processo.Ele atua como um containergráfico para dividir umconjunto de atividades de

outros pools, geralmente nocontexto de situações de B2B.

Lane Uma lane é uma subdivisãodentro de um pool usado paraorganizar e categorizar as

atividades.

Swimlanes e Pools




Exemplo BPMN: marcação de consulta médica.




Exemplo BPMN: subprocesso de consulta médica.

Modelagem de NegóciosExemplo: RUP: casos de uso de negócio abordagem estrutural



Exemplo: RUP: casos de uso de negócio, abordagem estrutural.



Engenharia de Requisitos




Definição Genérica:

- Estabelecer o que o cliente requer de um sistemade software

Definição da IEEE Institute of Electrical and

Electronics Engineers :-Processo de aquisição, refinamento e verificaçãodas necessidades do cliente, com o objetivo deobter uma especificação correta e completa dosrequisitos.


http://en.wikipedia.org/wiki/Institute_of_Electrical_and_Electronics_Engineers














Definição de Boehm:

Disciplina para desenvolver uma especificação completa,consistente e não ambígua do software;Um acordo entre as partes descrevendo o que o produto desoftware irá fazer.

Definição de B. Meyer:Especificar o documento de requisitos de um software édefinir de uma forma completa e não ambígua:- as características externas do softwareoferecidas aos usuários;- a forma pela qual o software é integrado ao

sistema.




Definição de A. Davis:

- Durante a fase de requisitos, é necessárioanalisar, e portanto entender o problema a serresolvido.- A análise do problema é a atividade que inclui o

entendimento das necessidades do usuário bemcomo as limitações impostas na solução.

O Processo da Engenharia deRequisitos



Requisitos

Modelagem deNegócio

Elicitação derequisitos

Modelagem de

Requisitos

Análisede requisitos

Especificaçãode requisitos

Documento de

requisitos

Validaçãode requisitos


Gerenciamento deRequisitos



Requisitos• Gerenciar as mudanças das evoluções

dos requisitos que já foram instalados egeraram um release.

• Gerenciar requisitos também incluirastrear o status de um requisitoindividual.

• Gerenciar requisitos possibilita rastrearos requisitos da sua origem atéelementos de design, módulos de código

e testes



Elicitação de Requisitos

(O quê?)

Análise de ProblemasIdentifique stakeholders para o



Elicitar

Requisitos

Expandir a lista desoluções do

stakeholder

Escolher as melhoressoluções para alcançar os

objetivos.Melhor solução

identificada

Problema validado/ajustado

Problema de NegócioDefinido

Problema Atualidentificado e definido

Identifique stakeholders para o problema.

Análise da Causa-Raiz.

Reavaliar qual é a melhor idéia de solução.

Entendimento dosProblemas no

Contexto dosObjetivos de Negócio.

Problemade

Negócio

Idéia deSolução ou

Oportunidade




• ELICITAR: descobrir, tornar explícito,obter o máximo de informações para oconhecimento do objeto em questão;

• Identificar os fatos que compõem osrequisitos do sistema a fim de prover omais correto e mais completoentendimento do que é demandado

daquele software.

• Entender o processo como um todo.




• Envolvimento com o ambiente detrabalho do cliente, ou seja, se misturarcom os funcionários,observar, aprender,e questionar, de forma a superar a

ignorância do domínio do problema;• É preciso entender a razão porque as

coisas são feitas da forma que são.

Elicitação de requisitos:dificuldades



dificuldades

• Usuários podem não ter uma idéia precisado sistema por eles requerido;• Usuários têm dificuldades para

descreverem seu conhecimento sobre odomínio do problema;

• Usuários e analistas têm diferentes pontosde vista do problema (por teremformações diferentes)

• Usuários podem antipatizar com o novo

sistema e se negar a participar daelicitação (ou mesmo fornecerinformações errôneas).

Elicitação de requisitos



• É uma atividade de negociação ecomunicação entre especialistas e nãoespecialistas;

• A qualidade da comunicação entre as

partesenvolvidas depende:– de um bom entendimento;– de uma análise rigorosa.

• Resultado: Uma declaração em linguagemnatural dos serviços que o sistema deveráprover e suas limitações operacionais.

Atividades da Elicitação



Entendimento do domínio da aplicação• O conhecimento do domínio da aplicação é o

conhecimento geral onde o sistema seráaplicado

Entendimento do problema

• Os detalhes específicos do problema do clienteonde o sistema será aplicado deve serentendido

Entendimento do negócio• Você deve entender como os sistemas

interagem e contribuem de forma geral com osobjetivos do negócio

Entendimento das necessidades e limitações dosstakeholders sistema

Produtos da Elicitação• Lista dos usuários do sistema



• Lista dos usuários do sistema

• Entendimento do fluxo de trabalho dosusuários

• O papel de cada departamento/setorque iráutilizar o sistema

• O que atrapalha o andamento doprocesso dousuário e o que pode ser feito paramelhorar.

Técnicas de Elicitação



• Técnicas especiais que podem ser usadaspara coletar conhecimento sobre osrequisitos dos usuários

• Este conhecimento deve ser estruturado

• Problemas da elicitação– Tempo– Engenheiros de software

– stakeholders

Técnicas de Elicitação• Entrevistas



• Entrevistas• Leitura de documentos• Questionários• Análise de protocolos ETNOGRAFIA• Participação ativa dos usuários

• Cenários• Observações e análise sociais• Prototipação

Técnicas continuação)



• Levantamento orientado a pontos devista

• Workshops• Prototipagem

• JAD ( Joint Application Design)• Brainstorming

Escolhendo a técnica



• Deve-se selecionar as técnicas a seremutilizadas e estabelecer a maneira comoelas serão integradas

• A escolha das técnicas e seu esquema de

integração dependerá do problema e daequipe participante• É interessante conhecê-las e saber

identificar onde uma técnica se aplica

melhor que outra

Técnicas específicas deelicitação



elicitação

Entrevistas



• O Engenheiro de requisitos ou analistadiscute o sistema com diferentesstakeholders e obtêm um entendimentodos requisitos

• Vantagens: contato direto com o usuárioe validação imediata• Desvantagens: conhecimento tácito e

diferenças de cultura

Entrevistas - tipos



• Entrevistas fechadas: o analista buscarespostas a um conjunto de questõespré-definidas

• Entrevistas abertas: Não há uma agenda

pré-definida e o engenheiro de requisitosdiscute de forma aberta, o que ostakeholder quer do sistema

• Tutorial: o cliente dá uma aulaexplicando seu trabalho

Entrevistas - dicas



• Identificar candidatos• Preparação da entrevista : agendar

e preparar questionário (se for ocaso)

• O analista não deve ir para aentrevistas com noções pré-concebidas

Entrevistas - condução



• Informar aos stakeholders o ponto inicial

da discussão. Isto pode ser uma questão,uma proposta de requisitos ou umsistema existente

• Esperar por respostas incompletas

• Repetir frases do entrevistado com suaspróprias palavras• Entrevistadores devem estar cientes da

política organizacional - muitos requisitosreais podem não ser discutidos devido aimplicações políticas

Entrevistas - finalização



• Tempo para rever respostas de todas asperguntas - consolidar informações

• Agradecimentos

• Gerar documento que deve ser assinadopelo entrevistado

Leitura de Documentos



• Abstrações• Vocabulário da aplicação

• Vantagens: facilidade de acesso evolume de informações• Desvantagens: dispersão das

informações e volume de trabalho

Questionários



• Quando existe conhecimento sobre o

problema e grande número de clientes• Quando dados estatísticos são

importantes

• Dão idéia definida sobre como certosaspectos do universo de informação sãopercebidos

• Vantagens: padronização das perguntas

e tratamento estatístico das respostas• Desvantagens: limitação do universo de

respostas e pouca iteração

Cenários



• Cenários são partes inerentes de alguns

métodos de desenvolvimento OO• São estórias que explicam como um

sistema poderá ser utilizado. Devem

incluir:– descrição do estado do sistema antes decomeçar o cenário

– o fluxo normal de eventos do cenário

– exceções ao fluxo normal de eventos– informações sobre atividades concorrentes– uma descrição do estado do sistema no final

do cenário

Cenários



• Cenários são exemplos de interação quedescrevem como o usuário interage como sistema

• A descoberta de cenários expõe

interações possíveis do sistema e revelaas facilidades que o sistema podeprecisar

Análise de protocolosETNOGRAFIA



• Analisar o trabalho de determinada

pessoa através da verbalização• Objetivo: estabelecer a racionalidade

utilizada na execução de tarefas

• Vantagens: possibilidade de elicitarfatos não facilmente observáveis epermitir melhor entendimento dos fatos

• Desvantagens: desempenho doentrevistado e “o que se diz é diferentesdo que se faz”

Participação ativa dosusuários



• Incorporação dos usuários ao grupo de

ER• Os usuários precisam aprender a

linguagem de modelagem utilizadas paraler as descrições e criticá-las

• Integração dos usuários na modelagemdo sistema

• Vantagens: envolvimento dos

clientes/usuários• Desvantagens: Tempo em treinamento

dos usuários e falsas expectativas no

usuário

JAD Joint Application Design)• Técnica para promover cooperação,



entendimento e trabalho em grupo entre os

usuários desenvolvedores.• O JAD facilita a criação de uma visão

compartilhada do que o produto de

software deve ser• Através da sua utilização osdesenvolvedores ajudam os usuários aformular problemas e explorar soluções.

Dessa forma, os usuários ganham umsentimento de envolvimento, posse eresponsabilidade com o sucesso doproduto.

• Brainstorming• Brainstorming é uma técnica para



Brainstorming é uma técnica para

geração de idéias. Ela consiste emuma ou várias reuniões quepermitem que as pessoas sugiram eexplorem idéias.

• as idéias são encorajadas, pois elasfrequentemente estimulam osparticipantes, o que pode levar a

soluções criativas para o problema.

Brainstorming• Produza o maior número de idéias



possíveis.Regras do Brainstorming

Esclareça o objetivo da sessão. Gere o maior número de idéiaspossíveis. Deixe a imaginação voar. Não permita críticas ou

debates. Mescle idéias.

Brainstorming: Vantagense Desvantagens



e Desvantagens

• Vantagens–Usado a qualquer tempo, em qualquer

lugar.–

Bom para grupos.–Bom para coisas de alto-nível epressuposições.

–Bom para algum nível de automação.

• Desvantagens–Se aplica mais a processos em grupo.–Não sistemática na forma “clássica”.

Redução de Idéias: Podar eorganizar



organizar

Afine Diagramas

Redução de Idéias: PriorizeIdéias• Priorize idéias restantes.



Priorize idéias restantes.

–Vote• Votos cumulativos– Compre idéias

• Voto único

–Aplique avaliações– Critério

• Não ponderado

• Ponderado

Rational University “bucks”



Análise de Requisitos

(Como?)

Análise de Requisitos• Análise - Derivar maiores detalhes dos

R i it d Alt Ní l



Requisitos de Alto Nível.

• Processo iterativo que envolve a compreensãodo domínio, coleta, classificação, estruturação,priorização, validação dos requisitos.

Criar múltiplas visões dos requisitos tais comoprotótipos.

Modelos gráficos de análise e testes.Negociar prioridades.Procurar as funcionalidades escondidas.Fazer avaliações técnicas.

Avaliar riscosDescobrir quais as formas de um fracasso.

Análise de Requisitos -Objetivo• Consiste em organizar os requisitos em



Consiste em organizar os requisitos em

categorias relacionadas.• Examinar o relacionamento e adependênciaentre os requisitos.

• Analisar a consistência, omissões,ambiguidades dos requisitos fornecidospelo cliente.

• Estabelecer uma ordem de prioridadedosrequisitos.

• Reconher a origem e a necessidade decadarequisito.

Análise de Requisitos -Processo



Entendimentodo domínio

Coleta derequisitos

Classificação

Resoluçãode conflito

Atrib. PrioridadeEntrada doprocesso

Análise de Requisitos -Checklist• Cada requisito está consistente com o



Cada requisito está consistente com oobjetivogeral do sistema ?

• Os requisitos foram descritos num nívelapropriado de abstração?

• Todos os requisitos são realmentenecessários ?• Quais requisitos podem ser testados e

implementados ?

• Quem solicitou cada requisito ?• Os requisitos foram classificados?• Os requisitos foram priorizados?



Análise de Requisitos -Dificuldades

• Stakeholders em geral não sabem o que



Stakeholders em geral não sabem o que

querem• Stakeholders expressam requisitos emsua terminologia

• Stakeholders diferentes podem gerar

requisitos conflitantes• Fatores políticos e organizacionais

podem influenciar os requisitos dosistema

• Requisitos mudam durante o processode análise. Stakeholders novos podemsurgir e o ambiente de trabalho muda

Atividades de Análise



1. Reconhecimento do Problema2. Avaliação do problema e síntese

da solução (Modelagem)

3. Especificação dos requisitos dosoftware

4. Revisão

Atividade 1Reconhecimento do



Problema• A meta é o reconhecimento dos elementosbásicos do problema, conforme percebidos pelocliente.

clientes

Administrador do projeto

analista desenvolvedores

Plano de projetode software

protótipo

Atividade 2Avaliação do Problema e Síntese da

Solução



Solução

• Avaliar os problemas na situação atual• Principal Foco para o novo sistema: O

QUE e não COMO:- qual o fluxo e o conteúdo de informação- quais as funções do sistema- quais dados que o sistema produz e consome

- qual o comportamento do sistema

- qual as características de interface- quais são as restrições do projeto


Solução



Solução

• Sintetizar uma ou mais soluções (dentrodo alcance delineado no Plano de Projeto doSoftware)

• O processo de avaliação e síntese continua atéque o analista e o cliente concordem que osoftware pode ser adequadamenteespecificado.

É a maior área de esforço


Solução



Solução

• Durante a atividade de avaliação e síntesedevem ser criados modelos do sistema para secompreender melhor o fluxo de dados e decontrole, o processamento funcional e aoperação comportamental, além do conteúdoda informação.

• O modelo serve como fundamento para oprojeto de software e como base para a criação

de sua especificação



Atividade 4Revisões



•Devem ser efetuadas revisões técnicas erevisões no Plano de Projeto de Software

as revisões são conduzidas pelo Cliente epelo Analista

a base para a revisão são os documentosproduzidos na Especificação dos Requisitos• O Plano de Projeto do Software deve ser revisto

devido ao conhecimento adquirido durante aanálise.


O i t t ti



• Os revisores tentam garantir que a

especificação seja completa, consistentee precisa.

• Respondem a Questões como:

– Metas e objetivos do software permanecemconsistentes com metas e objetivos dosistema?

– O fluxo e a estrutura de informação sãoadequadamente definidas para o domínio da

informação?– Os diagramas são claros?


• As funções importantes permanecem dentro do escopo e



As funções importantes permanecem dentro do escopo ecada uma foi adequadamente descrita?

• As restrições de projeto são realísticas? Qual é o riscotecnológico desenvolvimento? Requisitos de softwarealternativos foram considerados?

• Critérios de Validação foram declarados detalhadamente?Eles são adequados para descrever um sistema bemsucedido?

• Existem inconsistências, omissões ou redundâncias?

• O usuário revisou o Manual Preliminar ou o protótipo?

• Como as estimativas do Plano de projeto de Softwareforam afetadas?

Revisar as Especificaçõesdo Cliente



• Identificar Requisitos.–Reconhecer e rotular:

• Comportamentos da Aplicação

• Atributos comportamentais• Questões e Suposições

• Perguntar ao cliente.

Revisão dosRequisitos



Especificação de Requisitos

(Escrever)

Princípios de uma boaespecificação

1 Separe funcionalidade de implementação



1. Separe funcionalidade de implementação

2. A especificação deve abranger o sistema doqual o software é um componente3. Uma especificação deve abranger o ambiente

no qual o sistema opera4. Uma especificação de sistema deve ser um

modelo cognitivo5. Uma especificação deve ser operacional6. A especificação do sistema deve ser tolerante

com não ser completa e ser expansível7. Uma especificação deve ser localizada e

fracamente acoplada.

Especificação

D t f li



• Documentar e formalizar osresultados da elicitação e daanálise.

• Usar templates específicos dedocumentos para cada tipo derequisito.

d ifi ã d i i

Princípios de uma boaEspecificação



• Formato da Especificação de Requisitos1. Introdução - declara as metas e os objetivos do

software, descrevendo-os no contexto dosistema baseado em computador

2. Descrição da Informação - descrição detalhadado problema que o software deve resolver

3. Descrição Funcional

4. Descrição Comportamental

5. Critérios de Validação6. Bibliografia

7. Apêndice

Especificação• Registrar os vários tipos de informações



g p ç

dos requisitos para facilitar acomunicação entre os stakeholders doProjeto.

Documentações em linguagem natural.

Modelos gráficos de análiseArmazenar as informações dos requisitosFerramentas de gerenciamento comercial Utilizando documentos padrões

Documento de Requisitos• Introdução



ç

• Definição dos Requisitos do Usuário• Especificação dos Requisitos do

Sistema

• Modelo do Sistema• Arquitetura do Sistema• Glossário• Apêndices

Importância daEspecificação Correta

• Uma compreensão completa dos Requisitos do



• Uma compreensão completa dos Requisitos do

Software é fundamental para obter umsoftware e um processo de desenvolvimentocom alta qualidade

• Não importa quão bem projetado ou codificadoestá um programa, se ele for mal analisado eespecificado desapontará o usuário e traráaborrecimentos ao desenvolvedor

• Reduz o custo e o retrabalho

• Referência para Validação Final• Base de Concordância Cliente e Fornecedor

Documento por Tipo deRequisito

Funcional Não-funcional



Requisitos de

negócio

Requisitos deusuário

Regras denegócio

Atributos de

qualidade

Interfacesexternas

RestriçõesRequisitosfuncionais

Requisitos desistema

Documento de visão eescopo

Documento de casode uso

Especificação dosrequisitos de software

Quais artefatos são usadosOnde o problema é definido?Onde os stakeholders e usuários são listados?Onde os ambientes e plataformas são

Visão



Onde os ambientes e plataformas são

identificadas?

Onde os casos de uso são

mantidos?

Onde o vocabulário comum está descrito?

Especificações

de Caso de uso

Glossário

EspecificaçãoSuplementar

Onde os requisitos não funcionaisestão localizados?

Onde as Necessidades eRequisiçõesdos stakeholders são capturadas?

Requisições do

Stakeholder

Descrever Stakeholders no Documento deVisãoStakeholder

Digitador

Representante Kelly Hansen

Descrição Usuário



Tipo O digitador é tipicamente um técnico com conhecimentos em

informática. O digitador é treinado e experiente no uso do atualsistema batch de registro.

Responsabilidades O digitador é responsável por administrar o cadastro de cursos paracada per íodo letivo. Isto inclui a supervisão administrativa e de permissão de acesso aos dados.

Critério de Sucesso Conseguir manter o banco de dados de estudantes e professores, eabrir/fechar cursos para matr ícula.

Envolvimento A responsabilidade primária dos digitadores ser á manter o bancode dados de estudantes e professores, e abrir/fechar cursos paramatr ícula.

Também ser á requerido da área de matr ículas….

Entregas Gestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matr ículas.

Comentários/Preocupações

Nenhum

Descrever o problema no Documento de Visão



Especificações deManual doUsuário

Especificações deDesign

Requisiçõe

s doStakeholder

Documento deVisão

Especificação

Suplementar

Modelo de

Caso de Uso

Definição doProblema

Documento de Visão

• As mesmas informações para gerência,



As mesmas informações para gerência,

marketing, e equipe de projeto.• Fornece o feedback inicial do cliente.• Promove uma compreensão única do

produto.• Define escopo e prioridade em alto-nível das requisições do stakeholder esuas características.

• Um documento de sistema quedescreve o “que” e “porquê” doproduto.

Visão

Estrutura do Documento deVisão1. Introdução



ç

2. Posicionamento3. Descrições do Stakeholder e Usuário4. Visão Geral do Produto5. Características do Produto

6. Restrições7. Faixas de Qualidade8. Precedência e Prioridade9. Outros Requisitos do Produto10. Requisitos de Documentação11. Anexo 1 – Atributos das Características

Obtendo o Entendimento doProblema



Descrição do Problema

Visão

O problema de (descreva o problema)

afeta (os stakeholders afetados peloproblema)

O impactodisto é que

(qual o impacto do problema)

Uma solução desucesso seria

(listar vários benefícios-chave denegócio para uma solução de sucesso)



Definir a fronteira da solução desistema

Outros



ã

Comunicações Relatórios

Novo Sistema

Outros

sistemas

UsuáriosSistemasLegados

Atores ajudam a definir afronteira do sistema

Fronteira do



PC

Fronteira do

sistema?

ServidorPC

PC

PC

Quem é o ator? Os módulos dosistema ou o usuário?

Servidor

PC

Capturando o Vocabulário comumdo sistema



• Definir os termos usados no projeto.

• Ajudar a previnir mal-entendidos.

Glossário

Capturar o Vocabulário Comum

•Começar o mais cedo

possível.•Continua durante todo o

projeto.

Conceitos de Modelagem deCasos de Uso



• Um ator representa uma pessoa ououtro sistema que se comunicacom o sistema

• Um caso de uso define umaseqüência de ações que o sistemarealiza para entregar algo de valor

ao atorActor Use Case



Um usuário pode agir comovários atores



Charlie comoGerente

CharlieEngenheiro

Gerente

Engenheiro

Charlie

Caso de Uso

Use Case



• Especifica um diálogo entre ator esistema

• O caso de uso é iniciado por um ator

que invoca uma funcionalidade dosistema

• Um caso de uso é completo e com

um conjunto de fluxos entendível• Todos juntos, os casos de usorepresentam as diversas formas deutilizar o sistema

Use Case

Cenário – Um passo pelo caso deuso



• Um caso de uso pode ter várias instâncias• Um cenário é descrito como uma instância

de caso de uso: uma seqüência específica de

ações que ilustra o comportamento dosistema

Matrícula emCurso

Estudante Funcionário



O que é um modelo de Casode Uso

• Atores e suas descrições



• Diagramas de casos de uso e seusrelacionamentos

• Para cada caso de uso:

– Nome e descrição breve– Da especificação textual:• Fluxo de eventos• Pré e pós condições

• Requisitos especiais• Outros diagramas (estado, seqüência, atividades,

classes e etc)



O que é modelagem de casosde uso?• Associe necessidades a requisitos de



Associe necessidades a requisitos de

software.• Defina claramente as fronteiras do

sistema.• Capture e comunique o comportamento

que é desejado do sistema.• Identifique quem ou o que interage

com o sistema.

• Valide/Verifique requisitos.• É um instrumento de

Planejamento.EspecificaçãoCaso de Uso 2

Ator 2

Use case 1

Modelo

Use case 2

Use case 3

Use case 1

Modelo de Caso de Uso

V lt l M d l d CSU



Use case 2

Use case 3

Volta pelo Modelo de CSU- Navegue pelos textos- Liste todos os atores- Liste todos os casos de uso

Especif. CSU 2- Descrição Breve- Fluxo de eventos

Espec. CSU 3- Descrição breve- Fluxo de eventos

Ator 1Ator

Ator 3

Especificação CSU 1- Descrição breve- Fluxo de eventos



O que é um Caso de Uso?



Define a seqüência de ações

Realizado pelo sistema

Que produz um resultado de valorPara um ator.

Um Casode Uso

Nome do Caso de Uso

O Caso de Uso contém osRequisitos de Software



• Cada caso de uso– Descreve ações no sistema que entrega algo

de valor para um ator.– Apresenta a funcionalidade do sistema

usada pelo ator– Modela o diálogo entre sistema e ator.– É um fluxo de eventos completo e

significativo dos eventos da perspectiva deum ator em particular



Ciclo de Vida de Casos de Uso

DescobertFechar Matrículas



o

Rabiscado

Descrevabrevement

e

Descrição Breve: Este caso de uso permite aoDigitador fechar o processo de matrículas. Ofertas decurso que não possuírem alunos serão canceladas. Osistema de Cobrança é notificado com todos os dados dematrícula para assim efetuar as devidas cobranças.

Resumo do Fechar Matrículas-Fluxo de Eventos

-Passo-a-Passo

Fechar Matrículas Especificação de Caso deUso- Fluxo de Eventos detalhadoRequisitos Especiais-Condições Pré/Pós

Totalmente Descrito

Definir Atores: Foco nos papéis• Um ator representa

um papel que um



um papel que um

humano, hardware,ou outro sistemadesempenha emrelação ao sistema.

• Os nomes de atordevem representarclaramente seupapel.

?

Atores e Papéis



Charlie e Jodie agemcomo estudantes.

Charlie também agecomo Professor.

Estudante

Professor

Matricularem Curso

Submeter grades

Charlie: Está empregado comoprofessor de matemática e é

aluno de Economia.

Jodie: É um aluno deCiências.



Convenções das setas e linhas



Supervisor Sensor ativo

Sensor passivo

Sensorhíbrido

Supervisor

Monitorar

Alarmes

Sensor passivo

Sensor

Sensor ativo

Monitorar

Alarmes



Exemplo: Sistema de Matrículas



Sistema de Registrode Cursos

Estudante

Sistema de Matrículas

Ator XAtor Y

Matricular em Curso

Outro caso de uso

Caso de Uso 3



Passos para criar o Modelo deCasos de Uso



1. Procurar atores e casos de uso.

– Identifique e descreva brevemente os atores.

– Identifique e descreva brevemente casos de usos.

1. Escreva os casos de uso.

– Desenhe todos os casos de uso.

– Priorize os fluxos de casos de uso.

– Detalhe os fluxos por ordem de prioridade.



Identifique atores

• Quem/o que usa o sistema?



• Quem/o que obtêm informação dosistema?• Quem/o que fornece informação

para o cliente?• Onde na empresa o sistema éusado?

• Quem/o que suporta ou mantêm osistema?

• Quais outros sistemas usam osistema?



Identificar Casos de Uso



Ator

Objetivo 1

Objetivo 2

Quais objetivosdesejo alcançarutilizando o

sistema?

Identifique os Casos de Uso

• Quais são os objetivos de cada



ator?–Porque o ator quer utilizar o sistema?–O ator irá criar, guardar, mudar,

remover, ou ler dados no sistema? Sesim, porque?–O ator precisa informar ao sistema

sobre mudanças ou eventos externos?

–O ator precisará ser informado sobrecertas circunstâncias do sistema?

• O sistema atende ao negócio com



Decomposição funcional• É a quebra do problema em partes

menores, isoladas.



–As partes juntas fornecem afuncionalidade do sistema.•Muitas vezes não fazem sentido se isoladas.

• Casos de uso:–Não há decomposição funcional.–Mantêm a funcionalidade junta para

descrever o uso completo do sistema.–Fornecer o contexto.



Como represento as exceções ?

Cenários Alternativos

Cenário Principal e oCenário Alternativo



Alternativa: Problemas na leitura do cartãomagnético

1ª) Se o sistema não conseguir ler o dados do cartão , tentarnova lleitura por no máximo duas vezes. Caso persista o

problemas encerrar o caso de uso.

Alternativa: Senha inválida

3ª) Se a senha digitada não for igual à igual a senhacadastrada , informar e solicitar nova digitação .Esteprocedimento pode ser repetido no máximo 3 tentativas. Apósa terceira tentativa a conta do usuário deve ser bloqueada e ocaso de uso encerrado. Include Bloquear conta



Associação (Association)

Relacionamento entreCasos de Uso e Atores



Interação do ator com o caso de uso por meio do envio erecebimento de mensagens.

binárias -> envolvem apenas dois elementos.

Por exemplo: O ator Correntista envia e recebe mensagensdo Caso de Uso Calcular Empréstimo Pessoal, por um

relacionamento de associação.

Generalização (Generalization)




Ocorre entre Casos de uso OU entre atores

Dois elementos semelhantes, mas com um deles realizando

algo mais.

Por exemplo:podemos criar um ator genérico

Aluno e especializá-lo nos atores Aluno Matriculado eAluno Ouvinte



Atendimento ao cliente

Mostrar Mapa do

salão

Reserva de

Restaurante

Cadastrar Cliente

Reserva

«extends»

include«uses»



Modelando casos de uso como auxílio de pacotes



• Impossível representar vários casos de uso em umúnico diagrama é uma tarefa impossível

• Podemos agrupar casos de uso considerando uma

mesma abordagem conceitual, podemos trabalharcom pacotes • Agrupamento de qualquer elemento de modelo, como

casos de uso, classe, estados, outros pacotes etc..

Nomenclatura <nome do pacote>seguido de :: e

<nome do elemento> pacote::elemento Exemplo: Controle Acadêmico::Cadastrar Aluno

Protótipos



• Armas importantes no processo dedesenvolvimento

• Interface gráfica – RAD(Rapid Application

Development)• Validação do usuário• Pedir padrões gráficos distintos• Levantar detalhes que não foram vistos

Evoluir o Caso de Uso

E t d t

Sistema de

M t í l C

Matricularem Curso



Especificação de Caso deUso

do Matricular para Curso+ Fluxo de Eventos detalhado

• Passo a Passo+ Requisitos Especiais+ Condições Pré/Pós

Matricular Online em Curso+ Fluxo de eventos rabiscado

• Passos de alto nível

Estudante Matrícula em Curso+ Descrição Breve



Validação• É o processo de verificar os requisitos

quanto a sua validade, consistência,

l li f ilid d



completeza, realismo e sua facilidadede verificação.

• Se os requisitos demonstram o quecliente realmente quer.

Verificações• Validade.

– O sistema fornece as melhores funções

t d id d d li t ?



para atender as necessidades de cliente?Soluções conciliatórias com os usuáriosfunções adicionais ou diferentes que sãoexigidas.

• Consistência.– Existem requisitos em conflito ? Descrições

diferentes para uma mesma função do

sistema ou restrições contraditórias.

Verificações• Completeza.

– Todas as funções solicitadas e exigidas

l li t tã i l íd ?



pelo cliente estão incluídas?

• Realismo.– Os requisitos implementados estão dentro

do orçamento, prazo e da tecnologiaexistente?

• Facilidade de Verificação.– Os requisitos podem ser verificados?

Como é o Processo

Cliente

Requisitos Ad-hoc vindos de um cliente Membrodo Projeto



Aprovado pelo Cliente

Especificação corrigida

Rejeitada Novamente

Especificação corrigida

Rejeitado pelo cliente

Especificação de RequisitosCliente

Técnicas de Validação• Revisões de Requisitos

– Requisitos analisados sistemáticamente por

i d i



uma equipe de revisores.

• Prototipação– Um modelo executável do sistema é

mostrado aos usuários finais e clientes.Podem experimentar o modelo para verificarse ele atende às suas necessidades.

Técnicas de Validação• Geração de Casos de Teste

– Como modelo ideal os requisitos deveriam

t tá i S t t i it



ser testáveis.Se os testes para os requisitossão criados como parte do processo devalidação isso muitas vezes revelaproblemas nos requisitos.

• Análise Automatizada da consistência.– Se os requisitos são expressos como modelo

de sistema em uma notação formal ou

estruturada então pode-se utilizar umaferramenta CASE para verificar aconsistência do sistema.

Revisão dos Requisitos• Revisões regulares devem ser feitas

regularmente enquanto os requisitos estão

d f l d



sendo formulados.

• Ambos, cliente e a equipe do contratantedevem ser envolvidos nas revisões.

• As revisões podem ser formais (com adocumentação concluída) ou informais. Boacomunicação entre colaboradores, clientes

e usuários podem resolver problemas emum estágio bem inicial.

Revisores check• Verificabilidade. da forma como foi definido pode ser

testado?



• Facilidade de Compreensão. O requisito pode seradequadamente compreendido pelo compradores ou usuáriosfinais ?

• Facilidade de Rastreamento. A origem do requisito éclaramente definida ?

• Adaptabilidade. Ele pode ser modificado, sem que isso

provoque efeitos em grande escala em outros requisitos dosistema. Muito impacto?

Dificuldades de Validação• Conflitos, contradições, erros e omissões

devem ser destacados durante a revisão.



• Devem ser formalmente registrados.

• Fica por conta dos usuários, compradores

e dos desenvolvedores do sistemanegociar a solução para esses problemasidentificados.



Processo Unificado

Visão Geral dos Conceitos



Uma abordagem iterativaEm uma

iteração,

você passat d



Disciplinasagrupam

atividadeslogicamente.

você passapor todas as

disciplinas.

Conteúdo do RUP - Fases• O conteúdo do RUP é organizado em

disciplinas

• Uma disciplina é um conjunto de tarefasrelacionadas a uma área de interesse



• Uma disciplina é um conjunto de tarefasrelacionadas a uma área de interesse• Disciplinas do RUP:

– Requisitos– Modelagem de Negócio– Gerência de Configuração & Mudanças– Ambiente– Gerência de Projetos– Análise & Design

– Implementação– Teste– Implantação

Disciplinas

RUP temdi i li



RUP temdisciplinas.

Artefatos são desenvolvidos em

cada disciplina através de um

processo iterativo.

Disciplinas produzem e compartilhammodelos

Várias disciplinasproduzem modelos

Análise & DesignRequisitosModelagemNegócio Implementação



produzem modelos… DesignNegócio ção

Implementado

por

Modelo deImplementação

Modelo deDesign

Modelo de

Caso de Uso

Modelo de

Negócio

BusinessAnalysis Model

RealizadoPor

Automatizado por

Realizado por

Teste

Verificado por Validado por

BBB

B

…cada modelo éaveriguado.

E n t r e g a

Entrada para

Papéis e artefatos



Fonte: IBM Rational Unified Process

Quem deve usar o RUP?

• O RUP pode te ajudar a entregar edesenvolver software críticos para



desenvolver software críticos parao sucesso de sua empresa

• O RUP foi pensado primariamente

para dois grupos de usuário:– Participantes de uma equipe de

desenvolvimento de software,inclusive os stakeholders

– Engenheiros de Processo,principalmente de software eGerentes de Software

Por que eu devo utilizar oRUP?

• RUP lhe fornece um processo de software

baseado em padrões customizável e



baseado em padrões, customizável econfigurável– Permite publicar um processo customizável e

acessível para qualquer um

– Permite customizar o processo para cada Projeto– Fornece uma visão filtrada para cada tipo de

função (Visão para Analistas, Gerentes e etc)

• O RUP é formado por boas práticas deEngenharia de Software melhoradocontinuamente para refletir as mudanças daIndústria de Software

Por que devo utilizar o RUP(cont.)

• Para stakeholders:

– Fornece um glossário de termos e umai l édi d h i t lh j d



– Fornece um glossário de termos e umaenciclopédia de conhecimentos que lhe ajudam acomunicar suas necessidades à equipe dedesenvolvimento

• Para integrantes da equipe– O RUP apresenta uma função central e comum

de definição de processo que os membros podemcompartilhar para melhorar a comunicação.

• Para gerentes e gerentes de projeto–

Fornece um meio de comunicação efetivo com aequipe, ajudando da gerência, planejamento econtrole

• Para Engenheiros de Processo– Fornece uma base de conhecimento, conteúdo e

Quando usar o RUP?O RUP pode ser usado desde o início até as fases de manutenção doprojeto. O RUP pode ser customizado para suas necessidades, masseguindo as considerações abaixo:



• Ciclo de Vida do Software(nº de iterações, tamanho dasfases e do projeto)

• Objetivos de negócio doprojeto, visão, escopo e risco

• Tamanho e complexidadedo esforço de

desenvolvimento

Sintomas e Causas-Raiz

• Quais os sintomas



• Quais os sintomasde problemas nodesenvolvimentodos softwares?

• Quais as causas-raiz de cada

sintoma?

Sintomas dos Problemas deDesenvolvimento de Software• Necessidades dos

usuários não atendidas



usuários não atendidas• Confusão de Requisitos• Módulos não integram• Difícil de Manter

• Descoberta tardia defalhas

• Qualidade e iteratividadebaixa

• Performance baixa• Equipe não coordenada• Problemas de build e

Relação Problema-Causa

Não atende Requisitos

Sintoma Causas Raiz Princípio-Chave

Adaptar o Processo



necessid.

ConfusãoRequisitos

Modules don’t fit

Difícil Manter

Descoberta tardia

Qualidade baixa

Performancebaixa

Time colide

Build-e-release

qinsuficientes

Comunicação ambígua

Conflitos arquiteturais

Alta complexidade

Inconsistênciasescondidas

Pouco teste

Avaliação subjetiva

DesenvolvimentoCascata

Mudanças nãocontroladas

Automação

ComunicaçãoAmbígua

Inconsistênciasescondidas

Módulos nãointegram

Adaptar o Processo

Balancear requisiçõesdos Stakeholders

Demonstrar ValorIterativamente

Elevar Abstração

Colaboração no time

Focar qualidadecontinuamente

Princípios-Chave para oDesenvolvimento Orientado a

NegóciosA Adapt The Process



Negócios

F

E D

C

B

A Adapt The ProcessBalance Competing StakeholderPriorities

Collaborate Across TeamsDemonstrate Value IterativelyElevate Level Of AbstractionFocus Continuously On Quality

Principio: Adaptar oProcessoA

É adaptar o processo ao tamanho do projeto. A quantidade decerimônia, precisão e controle apresentada pelo projeto deve serde acordo com o tamanho da equipe, se estão locais ou remotas,

fase do projeto e quantidade de restrições do mesmo.



• Benefícios– Eficiência de Ciclo de Vida– Comunicação honesta e aberta dos riscos

• Padrão– Tamanho certo do processo para o processo

– Adaptar a cerimônia do processo a fase do ciclode vida e permitir a cerimônia as circunstânciasdo projeto

– Melhorar o processo continuamente– Balancear lanos e estimativas ao nível de

p j q ç

Tamanho certo do processoas necessidades do projeto

• Mais processo não é necessariamente



• Mais processo não é necessariamentemelhor

• Para projetos menores com o time todos

juntos localmente e tecnologia conhecida,o processo deve ser menor• A medida que o projeto cresce, é

necessário um processo mais disciplinado

Fatores que afetam o tamanho doprocesso

• Vários fatores afetam o tamanho doprocesso:

Tamanho do projeto



– Tamanho do projeto– Distribuição geográfica da equipe– Complexidade tecnológica

– Número de stakeholders– A fase do projeto

Princípio: Balancear Prioridadesconcorrentes do Stakeholder

• É importante balancear porque:F t t há flit d ó i d

B



É importante balancear porque:– Frequentemente há conflitos de negócio e denecessidades

– Questão de desenvolvimento customizado Xpacotes prontos

• Benefícios– Alinhar a aplicação com o negócio e

necessidades– Reduzir desenvolvimento customizado

– Otimizar o valor do negócio• Padrões– Definir, entender e priorizar o negócio e

necessidades– Priorizar ro etos e re uisitos e relacionar

B

Balancear necessidade de negócio ede usuário

• Gerenciar Requisitos efetivamente–

Capturar processos de negócioPriorizar projetos e capacidades do sistema para



Capturar processos de negócio– Priorizar projetos e capacidades do sistema parasuportar necessidades de negócio

• Atualizar prioridades quando o

entendimento do projeto cresce– Envolve o usuário para garantir o entendimento

das necessidades, usando:• Desenvolvimento orientado a casos de uso

• Design centrado no usuário• Use soluções de pacote e itens existentes

para entregar mais rápido e com customenor

Entender quais itensabsolver

• Entender quais itens estão



Entender quais itens estãodisponíveis e balancear reuso deitens com necessidades

• Exemplos de itens:– Aplicações Legadas– Serviços– Componentes Reutilizáveis

– Padrões

Princípio: Colaborar pelotime

C Prioriza comunicação otimizada no projeto. Alcançado comorganização do time e ambientes colaborativos



• Benefícios– Produtividade do time– Melhor relacionamento entre necessidades do negócio e o

desenvolvimento e operação de sistemas de software• Padrões– Motivar pessoas para realizar o seu melhor– Criar times auto gerenciáveis– Encorajar colaboração pelas funções (analistas, gerentes,

etc)– Fornecer ambiente colaborativos– Gerenciar o desenvolvimento de artefatos e tarefas para

melhorar a colaboração– Integrar negócio, software e atividades do time

Princípio: Demonstrar valoriterativamente

B fí i

DO processo iterativo possibilita acomodar mudanças, obterfeedback e reduzir riscos cedo



• Benefícios– Cedo de riscos cedo– Previsibilidade alta no projeto

– Confiança junto aos stakeholders• Padrões

– Possibilita feedback ao entregar valor

iterativamente– Adaptar seus planos usando o processo iterativo– Abraçar e gerenciar as mudanças– Atacar os maiores riscos técnicos, negociais e

Habilitar feedback Entregandovalor iterativamente

• Divida o projeto em iterações



Divida o projeto em iterações– Cada iteração realizará vários requisitos,

design, implementação, teste daaplicação, produzindo um executávelpara o usuário

• Obter feedback dos stakeholderspara:

– Ver se estamos movendo na direçãocerta?– Stakeholders satisfeitos?– Precisamos alterar características á

Adaptar seus Planos ao ProcessoIterativo

• Desenvolvimento iterativo fornece um

bom entendimento de:



bom entendimento de:– Onde estamos?– Em qual velocidade o time está?

– Precisamos fazer correções no curso paracompletar o projeto com sucesso

• Podemos usar esta informação para:

– Atualizar o plano para o projeto– Desenvolver planos detalhados para a

próxima iteração

Abraçe e Gerencie a Mudança

• As aplicações são muito complexasi it d i



As aplicações são muito complexaspara que requisitos, design,implementação e teste funcionem

na primeira vez• Processos efetivos abraçam asmudanças

• O processo iterativo nos fornece aoportunidade de implementarmudanças incrementalmente

Ataque riscos cedo

• A necessidade de atacarriscos cedo não pode ser



A necessidade de atacarriscos cedo não pode sersubestimado. Isto inclui:– Riscos técnicos

– Riscos negociais– Riscos de programação

• Isto é feito avaliandoriscos continuamente,

atacando os maioresriscos nas primeirasiterações.

Perfil dos Riscos



Princípio: Elevar o nível deabstração

• Benefícios

E Reduz a complexidade e diminui a quantidade de documentaçãogerada. É alcançado com reuso, uso de modelagem visual earquitetura estabilizada



Benefícios– Produtividade– Complexidade reduzida

• Padrões– Reuso de itens– Use ferramentas de alto-nível e linguagens para

reduzir quantidade de documentação– Foco na arquitetura primeiro– Arquitetura para requisitos não funcionais:

qualidade, flexibilidade e controle dacomplexidade

Reuso de itens existentes• Reduz complexidade de maior impactona produtividade

• Trabalhando com alto nível deabstração reduz se a complexidade e



Trabalhando com alto nível deabstração reduz-se a complexidade efacilita-se a comunicação

• Reduzir complexidade reutilizando:– Componentes reutilizáveis– Sistemas legados– Processos existentes de negócio

– Padrões– Software open-source

Princípio: Foco contínuo naQualidade

F Enfatiza o alcance da qualidade. Um processo iterativo é adaptado

para alcançar qualidade por que oferece várias métricas eoportunidades de correção



• Benefícios

– Alta qualidade– Alcance rápido do progresso e qualidade

• Padrões– Garantir a responsabilidade da equipe na

qualidade do produto– Testar cedo e continuamente com integraçãodas capacidades demonstráveis

– Teste incremental e build contínuo

p ç

Disciplinas de Requisito -Propósitos

• Estabelecer e manter um acordo com osusuários e outros stakeholders sobre o



que o sistema deve fazer• Fornece à equipe um melhor

entendimento dos requisitos do sistema

• Define as fronteiras do sistema (escopo)• Fornece a base para o planejamento das

iterações• Fornece uma base para estimar custo e

tempo• Define a interface visual do sistema

baseado nas necessidades levantadas

Tipos de Requisito

• Características: escopo do projeto– Documentado no Documento de Visão



• Requisitos Funcionais: especificainterações com o usuário

– Documentado nos Casos de Uso• Requisitos Suplementares: especifica

requisitos não funcionais

(performance, segurança e etc), alémde requisitos gerais do sistema, nãoespecíficos de um caso de uso– Especificação Suplementar

Papéis e Artefatos



Análise do Problema:Atividades e Artefatos



Gerenciamento de

Requisitos

Gerenciamento de Requisitos• Gerenciamento de requisitos é o

processo de controlar as mudanças dosrequisitos durante o processo daengenharia de requisitos



q pengenharia de requisitos.

• Requisitos são inevitavelmenteincompletos e inconsistentes– Requisitos novos surgem durante o processo

de acordo com mudanças nas necessidadesdo negócio e um entendimento melhor dosistema é desenvolvido.

– Diferentes pontos de vista têm diferentesrequisitos e esses geralmente sãocontraditórios.

Gerenciamento de Requisitos• Requisitos são por natureza voláteis. Diversos

fatores contribuem para sua instabilidade ao longodo tempo. Mudanças externas no ambiente(mudanças de legislação, mudanças no mercado,

d i i é i d



mudança no posicionamento estratégico daempresa), erros incorridos no processo derequisitos, entre outros. Todos esses fatores fazem

com que seja necessário alterar os requisitos. Taisalterações precisam ser conduzidas de formaordenada para que não se perca controle sobre oprazo e o custo do desenvolvimento.

Gerenciamento de RequisitosOs benefícios desta atividade são percebidos nomédio prazo, sendo que são necessáriosinvestimentos no curto prazo.

Assim, a atividade é, muitas vezes, tida como um



fardo desnecessário à condução do processo.

Contudo, sua não implementação faz com que aseconomias de curto prazo sejam logo suplantadaspelas despesas no longo prazo, verificadas comsuperação de custo e prazo nos projetosconduzidos.

• .

Mudanças nos Requisitos• A prioridade dos Requisitos nosdiferentes pontos de vista mudamdurante o processo de desenvolvimento.



• Os donos, clientes do sistema podemespecificar os requisitos em uma

perspectiva do negócio que é diferentedos requisitos do usuário final.

• O negócio e o ambiente técnico dosistema mudam durante o seudesenvolvimento.

Controle de Mudanças

• Checar validade da solicitação de mudança;

• Identificar os requisitos diretamente afetados



com a mudança;• Identificar dependências entre requisitos para

buscar os requisitos afetados indiretamente• Assegurar com solicitante a mudança a serrealizada;

• Estimar custos da mudança;• ·

Controle de Mudanças

• Obter acordo com usuário sobre ocusto da mudança



custo da mudança.• Após a realização desta análise,

podemos aceitar ou rejeitar amudança, conforme os impactos ecustos que ela pode ter no sistema

Controle de Mudanças• O ponto de entrada de qualquer mudança deve

ser a elicitação.

Eli it ã d

Mudança



Elicitação derequisitos

Modelagem deRequisitos

Análisede requisitos

Especificaçãode requisitos

Documento derequisitos

Validaçãode requisitos


Análise deImpacto

Matriz deRastreabilidade

• A matriz de

rastreabilidade fornece oinsumo daanálise deimpacto.

• Toda adocumentação deve ser

revisada.

GERENCIAMENTO DECONFIGURAÇÕES

• O objetivo do Gerenciamento de Configurações(Configuration Management) é estabelecer e



manter a integridade dos produtos de trabalho,utilizando a identificação da configuração,controle da configuração, comunicação do

status da configuração e auditorias deconfigurações. [PA159]

GERENCIAMENTO DE CONFIGURAÇÕESA área de processo de Gerenciamento de Configuraçõesenvolve:

• Identificar a configuração de produtos de trabalhoselecionados que compõem as baselines emd i d



determinados momentos no tempo• Controlar as mudanças nos itens de configuração• Construir ou fornecer especificações para construir

produtos de trabalho a partir do sistema degerenciamento de configurações

• Manter a integridade das baselines•

Fornecer um status preciso e os dados atuais deconfigurações para desenvolvedores, usuários finais eclientes

Plano de gerência de configuração

• estabelecer normas, ferramentas e templates quepermitam gerenciar de maneira satisfatória os

itens de configuração de um sistema,d fi id d d



• definidos por Pressman como: “cada um doselementos de informação que são criados durante odesenvolvimento de um produto de software, ou

que para este desenvolvimento sejam necessários,que são identificados de maneira única e cuja

evolução é passível de rastreamento”.

Baseline• Em cada fase do processo de

desenvolvimento, um conjunto bem definido

de itens de configuração deve serestabelecido



estabelecido.• A este conjunto é dado o nome de

baselines.

• Estas baselines servem como marco noprocesso de desenvolvimento

• ao final de cada fase é estabelecida umanova baseline e, portanto, todos os itens deconfiguração estão sob total controle deseus desenvolvedores

BaselineÉ guardada “uma foto” dos artefatos criadosaté aquele momento:

•· tornando mais fácil realizarmodificações nos artefatos de maneira



modificações nos artefatos de maneiracontrolada;•· possibilitando ter um controlesistemático sobre todos os itens deconfiguração abordados em cada fase do ciclode vida do software

•· tornando possível que sejamrealizadas, mais facilmente, avaliações sobreseu grau de evolução.•.



Baseline



• O versionamento da documentação é a base para ocontrole através de baselines. Todo artefato deve ter uma

lista de revisões.

Baseline VerticalDocumento de

Requisitos Projeto Teste

Documento

de Usuário

Baseline 1 V1.3 V2.4 V1.0 V2.1

Baseline 2 V1.4 V2.5 V1.5 V2.3

Baselines

X Artefatos

Req1



• Conjunto de artefatos de requisitos e projeto que formauma baseline de entrega ao cliente.

... ... ... ... ... ...

Baseline Horizontal

Baseline X



Baseline X

Versão• As entregas ao cliente devem ser controladas por baselines,para menhor controle de versionamento.

Rastreabilidade• No centro da atividade de gerenciamento

de requisitos está a rastreabilidade.

• Esta é definida como a habilidade de se



• Esta é definida como a habilidade de seacompanhar a vida de um requisito emambas as direções (por exemplo:

partindo de requisitos e chegando aprojeto ou, partindo de projeto echegando a requisitos) do processo desoftware e durante todo o seu ciclo de

vida.

Rastreabilidade• Responsável por dependências entre

requisitos, suas origens e projeto do

sistema



• É base do gerenciamento de requisitos edo processo de controle de mudanças

Rastreabilidade• A dificuldade envolvida com a

rastreabilidade está no grande volume de

informações gerado.• As informações do processo de requisitos



As informações do processo de requisitosdevem ser catalogadas e associadas aosoutros elementos de forma que possam

ser referenciadas através dos diversositens de informação registrados.• É um trabalho extenso que, sem o auxílio

de ferramentas adequadas, muito

provavelmente não poderá ser feito

Rastreabilidade• Para implementar a rastreabilidade,

usualmente é confeccionado em conjuntocom a especificação de requisitos um

t f t h d t i d



artefato chamado matriz derastreabilidade, que tem como objetivo

mapear os rastros dos requisitos descritosna especificação.

RastreabilidadeOs rastros dos requisitos podem ser de dois

tipos:• Pré-rastreabilidade: os rastros



(artefatos: plano de negocio, atas de reuniãocom o usuário) que fundamentaram a

criação do requisito.• Pós-rastreabilidade: os rastros

(artefatos: código, documentos) que seformaram a partir do requisito criado.

Rastreabilidade

• Rastreamento de Origem

– Associação entre requisitos e stakeholders que propuseram tais requisitos



q p p q

• Rastreamento de Requisitos– Associação entre requisitos dependentes

• Rastreamento de Projeto– Associação dos requisitos com o projeto

• Usar hipertexto ou referência cruzada– Ou matriz de rastreamento

1. Rastrear requisitos dousuário nos do sistema2. Rastrear requisitos noprojeto

Req A

1

RequisitosProduto

(Caracter.)

Rastreabilidade Vertical



projeto3. Rastrear requisitos nosprocedimentos de teste4. Rastrear requisitos dousuário no plano

Projeto

Modelos Suítes Teste

Teste

2 3

1

Requisitos

Detalhados(Casos de Uso)

Req B

Plano

Doc. Usuário

4

Req A antes“if return value > $5” “if return value > $2”

Req A depois

Rastreabilidade: Análise deImpacto



Links dos requisitos devem ser marcados como

“suspeitos” Links suspeitos devem ser resolvidos

if return value $5

Req B

Req C

$

Req C

Req B

Rastreabilidade HorizontalRequisitos

X

Requisitos Req1 Req2 Req3 Req4 Req5

Req1



Req2

Req3

Req4

Req5

Organização dos requisitos

• Estruturar para que possam ser

abordados nos ciclos dedesenvolvimento



desenvolvimento

• Acomodados em processos denegócio conhecidos como casos deuso

• Priorizar os mais críticos deixandoara o final os mais elementares.

Planejamento dodesenvolvimento• Acomodar os diferentes casos de

uso, cadastros e consultas nos ciclos

P d ã d i l



• Prever a duração dos ciclos

• Determinar tamanho da equipe

• Produto final cronogramafinanceiro e de atividades para o

desenvolvimento do projeto

Gerenciar requisitos não é fácilporque...• Os requisitos:

– nem sempre são óbvios– podem surgir de várias fontes



– pode nem sempre ser facilmente expressadoem palavras

– se relacionam uns com os outros e com outrosprodutos no processo de engenharia desoftware

– tem propriedades únicas– mudam

• Um número grande de requisitos não égerenciável se não é controlado.

Chaves para gerenciarrequisitos efetivamente• Manter uma declaração clara dos requisitos por

meio de:– requisitos de alta qualidade

t ib t li á i d ti d i it



– atributos aplicáveis para cada tipo de requisito– rastreabilidade com outros requisitos e outros

artefatos de projeto

A meta é entregar produtos de qualidade no tempo e orçamento que atendam àsreais necessidades do cliente.

Como os projetos podem serbem sucedidos• Análise do problema

– Entender o problema– Obter a aceitação do cliente• Levantamento de requisitos



• Levantamento de requisitos– Identificar quem usará o sistema (atores)– Levantar como o sistema será usado (casos de

uso)• Gerenciamento de requisitos

– Especificar os requisitos completamente– Gerenciar expectativas, mudanças e erros

– Controlar a mudança de escopo– Envolver os membros da equipe

Envolver toda a equipe com osrequisitos• Desenvolvedores, testadores, documentadores

– Ajudam a desenvolver práticas de gerenciamentode requisitos

– Monitoram a aderência às práticas



Monitoram a aderência às práticas– Verificam o levantamento do processo– Documentam requisitos– Participam das revisões de requisitos– Participam do comitê de controle de mudanças– Revisam as entradas por meio da rastreabilidade– Verificam a qualidade, testabilidade e

completude

Disciplina de Configuração eMudançasPropósito: controlar mudanças e manter a integridade entre osartefatos do projeto



Gerência de Configuração

• As ferramentas de gerência deconfiguração suportam:



– Realizar baseline de versõesconcorrentes

– Identificação da configuração egerência

– Monitorar e apresentar as mudanças e

status de configuração– Seleção de Versão– Métricas dos itens sob controle

Gerência de Qualidade deRequisitos (IEEE830)• Correção: um documento de requisitos é

considerado correto se todos os requisitos representamalgo que deve estar presente no sistema que está



algo que deve estar presente no sistema que estásendo desenvolvido, ou seja, os requisitos reais dousuário devem coincidir com os requisitos identificados.

Esta não é uma tarefa trivial e parte de seu sucessoestá associada a uma boa atividade de validação dosrequisitos.

• ·

Gerência de Qualidade deRequisitos (IEEE830)• Não ambigüidade: um conjunto de requisitos é

não ambíguo quando somente pode ser interpretadopor todos os envolvidos em um projeto de uma única



por todos os envolvidos em um projeto de uma única

maneira.

• ·Completude: um conjunto de requisitos é ditocompleto quando descreve todas as demandas deinteresse dos usuários. Estas demandas incluemrequisitos funcionais, de desempenho, restrições,

atributos e interfaces externas.• ·

Gerência de Qualidade deRequisitos (IEEE830)• Consistência: um conjunto de requisitos é dito

consistente se nenhum subconjunto destes requisitosentra em conflito com os demais requisitos do sistema



entra em conflito com os demais requisitos do sistema.• · Verificabilidade: um requisito é verificável se

existe uma forma efetiva, em termos de tempo e custo,para que pessoas ou ferramentas indiquem se umsistema cumpre o requisito (IEEE). Em quase todas assituações, é difícil provar de forma conclusiva que umrequisito é cumprido por um software

• ·

Gerência de Qualidade deRequisitos (IEEE830)• Modificabilidade: um conjunto de requisitos é

modificável quando seu estilo e estrutura é tal que asalterações podem ser realizadas de forma simples e



alterações podem ser realizadas de forma simples econsistente com os demais requisitos.

A gerência, neste cenário, é responsável por manteruma infra-estrutura necessária para atividades deverificação que tornem possível investigarmos aqualidade dos requisitos que estamos definindo

Bibliografia

• Pressman, R. Engenharia deSoftaware



• Sommerville, I. Software

Engenharia de Requisitos V2

Documents

Transcript of Engenharia de Requisitos V2