engsw aula apresentacaoswebok&requisitos

8/6/2019 ENGSW Aula ApresentacaoSWEBOK&Requisitos

1/43

SWEBOKGuide to the Soft w are Engineering Body O f Knowledge

1

Teresa [email protected]

DEINFO/UFRPE


2/43

2

Iniciativa do IEEE (Institute of Electrical and ElectronicsEngineers) Computer Society. (www.ieee.org)

Propsito de criar um consenso sobre as reas deconhecimento da Engenharia de Softw are e seu escopo.


3/43

Objetivos

3

Promover uma viso consistentePromover uma viso consistenteda Engenharia de Software noda Engenharia de Software nomundo;mundo;

Caracterizar o contedo daCaracterizar o contedo dadisciplina de Engenharia dedisciplina de Engenharia deSoftware;Software;

Classificar em tpicos a rea deClassificar em tpicos a rea deconhecimento da Engenhariaconhecimento da Engenhariade Software;de Software;

Prover uma fundao para oProver uma fundao para odesenvolvimento do currculo,desenvolvimento do currculo,para certificao individual epara certificao individual epara licenciamento de material.para licenciamento de material.


4/43

PblicoAlvo

4

Organizaes pblicas eOrganizaes pblicas eprivadas;privadas;

Instituies de ensino daInstituies de ensino daengenharia de software;engenharia de software;

Instituies certificadoras;Instituies certificadoras;

Engenheiros de Software;Engenheiros de Software;

Estudantes de Engenharia deEstudantes de Engenharia deSoftware;Software;

Educadores e Instrutores.Educadores e Instrutores.


5/43

5

reas de Conhecimento

SWEBOK

Requisitos de SoftwareDesign (Projeto) de Software

Construo de SoftwareTeste de SoftwareManuteno de Software

Gerncia da Configurao de SoftwareGerncia do Desenvolvimento de Software

Processo de SoftwareMtodos e Ferramentas de Engenharia de Software

Garantia da Qualidade de Software


6/43

6

reas de Conhecimento SWEBOK

Requisitos de Softw areDesign (Projeto) de Software

Construo de SoftwareTeste de Softw areManuteno de Software

Gerncia da Configurao de Softw areGerncia do Desenvolvimento de Software

Processo de Softw areMtodos e Ferramentas de Engenharia de Software

Garantia da Qualidade de Softw are


7/43

7

RequisitosRequisitosde Softw arede Softw are


8/43

8

Caractersticas que o produto de software dever

apresentar para atender s necessidades e expectativasdo cliente .

Requisito de Softw areRequisito de Softw are


9/43

9

Podem ser categorizados em funcionaisfuncionais

(relacionados a funcionalidades a seremimplementadas);

ou nono--funcionaisfuncionais (relativos a caractersticas

de segurana, desempenho e outros aspectos

no inerentes funes do software).

Requisito de Softw areRequisito de Softw are


10/43

Descrevem o que osistema deve fazer

"o software deve possibilitar armazenar os pedidos deoramento ""o software deve possibilitar aconsulta de alunos em umadisciplina

Descrevem as restries ecaractersticas na

implementao dosrequisitos funcionais

"o sistema deve permitir armazenar pelo menos 500pedidos de oramento por

ano "

"o sistema operacionala ser adotado deve ser linux

FuncionaisFuncionais NoNo--FuncionaisFuncionais


11/43

Requisitos NoRequisitos No- -FuncionaisFuncionaisDesempenho

Confiabilidade

ManutenibilidadeUsabilidade

Portabilidade


12/43

S takeholdersS takeholdersStakeholder uma pessoa que ter alguma

influncia direta ou indireta sobre os

requisitos do sistema.


13/43

Engenharia de Requisitos de

SoftwareDescobrir;

Obter;Analisar;Especificar;

Documentar;Verificar;

Gerenciar.


14/43

ElicitarElicitarrequisitosrequisitos

ElicitarElicitarrequisitosrequisitos

AnalisarAnalisarrequisitosrequisitosAnalisarAnalisar

requisitosrequisitosEspecificarEspecificarrequisitosrequisitosEspecificarEspecificarrequisitosrequisitos

ValidarValidarrequisitosrequisitos

ValidarValidarrequisitosrequisitos

Gerenciar mudanasGerenciar mudanas

Processo Bsico de Requisitos


15/43

15

Elicitar Requisitos

Descobrir, tornar explcito e assimilar

todo conhecimento possvel sobre o

requisito em questo, com base nas

necessidades do cliente.


16/43

Elicitar Requisitos

Domnio daDomnio da Aplicao Aplicao

NecessidadesNecessidadese restriese restries

ProblemaProblema

Contexto deContexto de

NegcioNegcio


17/43

Escopo da ElicitaoEntendimento do domnio da aplicao, conhecimento

geral onde o sistema ser aplicado.

Entendimento do problema , detalhes dos problemasespecficos do problema do cliente onde o software ser

aplicado deve ser entendido.

Entendimento do negcio , como os sistemas interagem econtribuem de forma geral com os objetivos de negcio.

Entendimento das necessidades e limitaes dosstakeholders do software, necessidades especficas das

pessoas que requerem suporte do sistema no seu trabalho.


18/43

Definir objetivos

Os objetivos organizacionais devem ser estabelecidos incluindo objetivos geraisdo negcio, um descrio geral do problema a ser resolvidos porque o sistema

necessrio e as limitaes do sistema.

Adquirir conhecimento do contextoAssimilar a organizao onde o sistema ser instalado, o domnio de aplicao

do sistema e sistemas relacionados existentes.

Levantar os requisitos dos stakeholder s

Informaes sobre os requisitos que faro parte do software.

Atividades de Elicitao


19/43

Negociao de Requisitos


20/43

Priorizao de Requisitos

Os requisitos devem ser rankeado s em termos de

valor agregado ao negcio.

O cliente prioriza os requisitos mais relevantes e

estes so os candidatos a serem desenvolvidos

primeiro.


21/43


22/43

E ntrevistas

Leitura de documentos

Questionrios

Participao ativa dos usurios

Cenrios

Observaes

Reuso de requisitos

Prottipos

Tcnicas de Elicitao


23/43

Entendimento dos requisitos atravs de discusses com

usurios.

Vantagens: contato direto com o usurio e validao

Imediata.

Desvantagens: conhecimento tcito e diferenas de

Cultura.

Entrevista


24/43

Abstraes

Vocabulrio da aplicao

Documentao

Vantagens: facilidade de acesso e volume de informaes

Desvantagens: disperso das informaes e volume de

trabalho

Leitura de Documentos


25/43

Adequado quando existe conhecimento sobre o problema e grandenmero de clientes

Do idia definida sobre como certos aspectos universo de

informao/software so percebidos

Possibilitam anlises estatsticas

Vantagens: padronizao das perguntas e tratamento

estatstico das respostasDesvantagens: limitao do universo de respostas e pouca iterao

Questionrios


26/43

Adequado quando existe conhecimento sobre o problema e grandenmero de clientes

Do idia definida sobre como certos aspectos universo de

informao/software so percebidos

Possibilitam anlises estatsticas

Vantagens: padronizao das perguntas e tratamento

estatstico das respostasDesvantagens: limitao do universo de respostas e pouca iterao

Participao Ativa do Usurio


27/43

Incorporao dos usurios ao time de desenvolvimento.

Vantagens: envolvimento dos clientes e usurios

Desvantagens: possvel indisponibilidade do usurio.

Participao do Usurio


28/43

Etnografia uma tcnica das cincias sociais que se mostrou til no

entendimento das processos reais realizados nos trabalhos.

Os processo reais de trabalho geralmente diferem daqueles processos

formais descritos.

Um etngrafo passa algum tempo observando as pessoas

no trabalho e constri uma imagem de como o trabalho

realizado.

Participao do Usurio


29/43

Reuso envolve considerar requisitos que foram desenvolvidos para um

sistema e us-los em sistemas diferentes.

O reuso de requisitos economiza tempo e esforo, pois

requisitos reutilizados j foram analisados e validados em outros sistemas.

Atualmente o reuso de requisitos um processo informal.

Contudo, um reuso mais sistemtico economizaria muito esforo.

Reuso de Requisitos


30/43

Um prottipo uma verso inicial de um sistema que

poder ser usado para experimentao.

Atravs deles, os usurios podero experimentar com o software ir

interagir e identificar pontes fortes e fracos.

O desenvolvimento rpido dos prottipos essencial para

que eles fiquem disponveis logo para o processo de

elicitao .

Prottipos


31/43

Est de acordo com os objetivos de negcio

O requisito consistente com os objetivos de negcio definidos na

introduo do documento de requisitos?

Ambigidade de requisitos

O requisito ambguo, isto poder ser lido de forma diferente por pessoas

diferentes? Quais so as possibilidades de interpretao dos requisitos?

Teste dos requisitos

Podemos testar os requisitos, ou seja, eles foram escritos de tal forma

que um engenheiro de teste poder derivar o teste que mostrar se

o sistema satisfaz os requisitos?

Anlise de Requisitos


32/43

O objetivo da anlise descobrir problemas,

incompletude e inconsistncia nos requisitos elicitados.

A anlise intercalada com elicitao pois problemas so

descobertos quando os requisitos so elicitados



33/43

Cenrios

Casos de UsoEstrias de Usurios



34/43

User S tory

Tcnica para identificao e especificao

de requisitos.

Uma ou duas frases, escrita pelo usurio na

sua linguagem, sobre algo que a aplicao

deve fazer.


35/43

Normalmente um cliente escreve as histrias e as

apresenta na reunio de planejamento inicial e

posteriormente sero detalhados.Em uma segunda reunio de planejamento detalhados

os desenvolvedores fazem perguntas para o cliente

para entender melhor do que cada estria se trata.Ao longo do desenvolvimento os desenvolvedores

devem voltar ao cliente e pedir mais detalhes de

qualquer dvida que tenham.

User S tory


36/43

As estrias de usurios podem guiar tambm os testes de

aceitao, j que seu objetivo ajudar o cliente a

validar se o trabalho desenvolvido est de acordo com

o que havia sido pedido.

Para o cliente no interessa se a comunicao com o

banco de dados est correta ou se a integrao entre

duas classes foi bem sucedida, o que importa

confirmar que a aplicao sendo desenvolvida est de

acordo com o que ele espera ter em produo no

futuro.

User S tory


37/43

As estrias de usurios podem guiar tambm os testes de

aceitao, j que seu objetivo ajudar o cliente a

validar se o trabalho desenvolvido est de acordo com oque havia sido pedido.

Para o cliente no interessa se a comunicao com o

banco de dados est correta ou se a integrao entreduas classes foi bem sucedida, o que importa confirmar

que a aplicao sendo desenvolvida est de acordo

com o que ele espera ter em produo no futuro.

User S tory


38/43

A idia usar papel e caneta, as ferramentas mais

simples possveis, para se gerenciar as estrias.

As estrias estarem em cartes tem vrias vantagens.Primeiro, o espao para escrever limitado e

ningum vai tentar colocar detalhes em excesso

nela.

User S tory


39/43

Cartes

Aps serem preenchidos com as estrias, os cartes ficam

pregados em quadros e so movidos de acordo com

seu status no iniciado, em andamento e pronto,

por exemplo.

Olhar para o quadro uma maneira intuitiva e eficiente

de se saber como anda um projeto, fcil perceber em

que categoria os cartes esto se acumulando.


40/43

Aps serem preenchidos com as estrias, os cartes ficam

pregados em quadros e so movidos de acordo com seu

status no iniciado, em andamento e pronto, por

exemplo.

Olhar para o quadro uma maneira intuitiva e eficiente de se

saber como anda um projeto, fcil perceber em que

categoria os cartes esto se acumulando.

Cartes


41/43

Caractersticas de uma Boa User Story

IndependenteNegocivel

Valiosa para o cliente ou usurioEstimvel

Curta

Testvel


42/43

Especificando Requisitos comUser Stories

Prtica


43/43

Software Enginnering Body of Knowledge SWEBOK, IEEE.Engenharia de Software, Roger Pressman.Engenharia de Requisitos, Ian Sommerville.User Stories Applied: For Agile SoftwareDevelopment, Mike Cohn.

Bibliografia de Apoio

engsw aula apresentacaoswebok&requisitos

Documents