Reqsist aula4

REQUISITOS DE SISTEMAS

REQUISITOS DE SISTEMAS PROF. Horacio Ribeiro

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

NOME DA DISCIPLINA

Conteúdo Programático desta aula

•Conhecer o conceito de stakeholders.

•Identificar características dos stakeholders.

•Conhecer técnicas de levantamento de requisitos •Relacionar cenários distintos e as melhores técnicas de levantamento de requisitos a serem aplicadas

NOME DA AULA – AULA1

Aula passada: ciclo de vida do processo estudo de viabilidade -> documento de analise do projeto elicitação e análise de requisitos -> documento que mostra cada forma de registrar ações, telas,... especificação de requisitos -> especificação padronizada de cada requisito validação de requisitos) - > validação nos aspectos de completude e consistência.

Estudo de viabilidade Todo projeto de software, em sua fase inicial, deve ser submetido a uma rápida análise nos seus diversos aspectos. . É o estudo de viabilidade estudar pontos críticos do projeto apresentar diferentes alternativas de soluções para o problema Verificar opçoes de custo e prazo .... E decide-se se o projeto será levado adiante ou não.

Deve tratar aspectos técnicos\ financeiros

Estudo de viabilidade Documento: - Breve descrição sobre a organização, - Descrição do problema em questão, fontes e referências que proporcionam conhecimento do problema (questionários, bibliografia, etc) - Apresentação de mais de uma solução para o problema.

Cada uma, acompanhada de uma breve análise com prós e contras.

- conclusao a partir da análise de cada uma das soluções propostas, indica qual a mais adequada, levando em consideração fatores como custo, tempo de desenvolvimento, satisfação dos anseios do cliente. .

conceito de stakeholders. e suas caracterĂ­sticas

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

relacionados

direta

ou

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

São denominamos stakeholders.

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

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

Após identificar os objetivos desejados vamos identificar e detalhar as pessoas que usam e/ou são afetados pelo sistema Independente de tecnologia um projeto que atua na área da engenharia de software contempla a participação direta ou indireta, ativa ou passiva, de pessoas.

Um tipo de ator (indivíduo) que em algum momento tem algum tipo de interesse, participação, etc., sobre um determinado software ´é é chamado de stakeholder. um entendimento mais amplo do que é um stakeholder, Em todo em qualquer sistema (computacional ou não), sempre teremos agentes diretos ou indiretos, que irão compor ou sofrer com as suas características.

A

palavra vem de da seguinte composição:

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

•Holder: aquele que possui.

Portanto, todos aqueles que de alguma maneira é afetado pelo software, é um stakeholder . É correto afirmar que toda a preocupação para o correto desenvolvimento de um sistema e demais recursos de infra-estrutura tem como objetivo de facilitar o atendimento das responsabilidades dos stakeholders.

Ao usarmos a sintaxe de premissa (visto na segunda aula) <temporal> <agente><ação no sistema> os agentes são pessoas que irão usar o software

Segundo Summerville (2009), podemos definir da seguinte forma: “Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquitetura.”

Podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de sofware:: Gerente de Projeto – Responsável em organizar e conduzir as equipes em suas responsabilidades.

Como gestor, precisa manter harmonia no desenvolvimento do projeto, supervisionando a execução das tarefas, observar os processos, sustentar e fomentar o equilíbrio entre os stakeholders, etc.

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

Para isso, busca analisar as especificidades inerentes ao determinado software.

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

Podemos então relacionar os seguintes exemplos e atribuições de stakeholders no desenvolvimento de um projeto de sofware:: (continuação) Patrocinador – Popularmente é quem “paga a conta”. É aquele que libera os recursos, custeia a produção do projeto. Ele será o responsável por prover financeiramente a arquitetura necessária para o desenvolvimento de software.

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

Além dos citados tem se muitos outros stakeholders – que não são tão elementares, mas possuem algum tipo de interesse.

Por exemplo: •Poder público •A comunidade •Concorrentes •Fornecedores •Investidores e acionistas •As famílias da equipe de projeto

São outras características dos stakeholders: •São específicos para cada projeto; •Possuem anseios e objetivos distintos em um projeto; •São atores fundamentais para detalhamento do que deve ser desenvolvido.

O envolvimento é fundamental para o êxito de um projeto de software. um dos riscos projeto é a levantamento dos stakeholders.

ocorrência de uma falha no

O gerente de projeto deve avaliar as necessidades de todos os envolvidos; A conseqüência pode ser: - um software que não atende aquilo que o cliente esperava, e de que deverá ser revisto e ajustado posteriormente.

-desgastes de recursos, além da insatisfação daquele que encomendou o sistema.

Primeiros cuidados: - o gerente de projeto deve observar bem seus objetivos -e não procurar stakeholders por todos lados, o que culminará em um cenário difícil de gerenciar.

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

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

Aรงoes com stakeholders

Com influencia politica

Sem influencia politica

INI MIG OS

S O D A ALI

CO LAB

OR AD

OR E

Com interesse No sistema

S

OS OP

ES R O IT

Sem interesse No sistema

TĂŠcnicas para levantamento de Requisitos

escrever linhas de códigos não deve ser o foco de atenção para o projeto de software, o inicio do projeto de desenvolvimento de software deve ser o

levantamento de requisitos.

E tratar esta atividade como engenharia Para um navio que não tem rumo qualquer porto serve’

levantamento inicial: A fonte das informações inerentes as atividades está com que pratica as atividades atualmente de forma manual ou automática.

Problema: -o cliente não estabelece claramente todas as regras relativas ao negócio; - quem está sendo contratado desconhece as especificidades referente ao processo que atualmente está em execução.

Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as seguintes atividades: •Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação; •Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa atividade; •Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;

Sommerville (2009) propõe um processo genérico de levantamento e análise que contém as seguintes atividades: •Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos; •Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a definição dos requisitos mais importantes; •Verificação de requisitos: Os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.

o problema de não saber especificar corretamente o que o sistema deverá fazer é muito rotineiro: (a) de um usuário principal do sistema não saber o que quer que o sistema faça ou sabe e não consegue/quer transmitir para o analista; (b) requisitos identificados, mas que não exprimem a realidade; (c) não estão em concordância com os requisitos informados por pessoas diferentes, são constantes na elaboração dos requisitos.

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

No levantamento dos requisitos, dois fatores contribuem para o baixo grau de satisfação dos usuários: •Não utilizar uma técnica adequada para extrair os requisitos do sistema; •Descrever os requisitos do sistema de modo pouco claro, com ambigüidades, sem consistência com todos os aspectos significativos do sistema proposto.

Algumas tĂŠcnicas de levantamento de requisitos, detalhando seu conceito e suas respectivas vantagens e desvantagens:

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

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

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

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

Etnografia ações consideradas importantes que devem ser executados antes, durante e depois do estudo de observação: •Antes, é necessário identificar as áreas de usuário a serem observadas; obter a aprovação das gerências apropriadas para executar as observações; obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação; e explicar a finalidade do estudo; •Durante, é necessário familiarizar-se com o local de trabalho que está sendo observado. é preciso observar os agrupamentos organizacionais; facilidades manuais e automatizadas; coletar amostras de documentos e procedimentos usados em cada processo que está sendo observado; e acumular informações estatísticas a respeito das tarefas, como: freqüência que ocorrem, estimativas de volumes, tempo de duração para cada pessoa. Observar as as exceções;

Etnografia ações consideradas importantes que devem ser executados antes, durante e depois do estudo de observação: •Depois, é necessário documentar as descobertas resultantes das observações feitas. Consolidar o resultado e rever os resultados com as pessoas observadas e/ou com seus superiores.

desvantagens . Consumir bastante tempo, além da possibilidade do analista ser induzido a erros em suas observações, mediante anomalia no comportamento dos stakeholders. . Perda de foco na observação. . Perpetuar erros no processo (atividades)

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

São integrantes do grupo que participaram do workshop: •Equipe de analistas.

•Seleção dos stakeholders mais envolvidos no contexto em que o sistema atuará.

principal estratégia acionar o trabalho em equipe. Há um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários mediadores.

As tomadas de decisão são baseadas em processos bem definidos e com o objetivo de obter um processo de negociação, mediado pelo facilitador.

Workshops É dos e com o objetivo de obter um processo de negociação promovido mediado pelo facilitador.

Uma vez encerrado é gerada uma documentação que reflete os requisitos e decisões tomadas sobre o sistema.

Fatores de sucesso são: •A postura do condutor do seminário - mediador e observador; •Deve possuir dia, hora, local, horário de início e de término; destacando o assunto a ser debatido e sua documentação.

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

Organizar a entrevista: - Os membros da equipe devem ter funçoes : redator, condutor, revisor....

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

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

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

Entrevistas boas práticas de entrevistas: •Desenvolver um plano geral de entrevistas; •Certificar-se da autorização para falar com os usuários; •Planejar a entrevista para fazer uso eficiente do tempo.

Previamente o analista que fará a entrevista deve procurar está bem contextualizado, sendo mais assertivo e produtivo O entrevistador deve coletar e estudar todos os dados pertinentes, como formulários, relatórios, documentos e outros. . No término, é necessário validar se o que foi documentado está de acordo com a necessidade do usuário, que o usuário não mudou de opinião e que o usuário entende a notação ou representação gráfica de suas informações.

Entrevistas -termino

exemplos de como aferir a veracidade das informações levantadas na entrevista: 1 -Faça uma explanação sobre o relacionamento entre o que está em discussão e as demais partes do sistema; •Informe do ponto de vista de outros usuários em relação ao item que foi discutido; •Descreva informalmente a narrativa do item em que o analista deseja obter informações; •O analista deve dizer ao usuário o que acha que ouviu ele dizer. e solicitar ao entrevistado confirmação do que foi dito.

Questionários Existem vários tipos de questionários : • múltipla escolha, •lista de verificação •questões com espaços em branco. quando há diversos grupos de usuários que podem estar em diversos locais diferentes do país elaboramse pesquisas específicas de acompanhamento com usuários selecionados, que a contribuição em potencial pareça mais importante, pois não seria prático entrevistar todas as pessoas em todos os locais.

Questionários Etapas .preparo (fazer um protótipo) •Identifique todos os destinatários que o receberão.

•Realize a distribuição junto com instruções detalhadas sobre seu preenchimento.

•Defina e informe o prazo para devolução do questionário.

•Documente o resultado da análise e consolidação das respostas dos participantes.

•Envie uma cópia com as informações levantadas para o participante, como sendo uma forma de agradecimento e consideração pelo tempo dedicado a pesquisa.

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

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

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

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

Brainstorming AS etapas necessárias para conduzir uma sessão de brainstorming são: •Seleção dos participantes ou grupo de trabalho: É aconselhável sempre a presença de pessoas que estejam sempre bem informadas, sejam de diferentes grupos; •Prepara a sessão: Duração e local do encontro, bem como o que será tratado.

•Explicar a técnica e as regras a serem seguidas: Definir as regras a serem seguidas durante a sessão; •Gerar ou produzir uma boa quantidade de idéias: Os participantes são convidados, um por vez, a dar uma única idéia.

Se alguém tiver problema, passa a vez e espera a próxima rodada.

•Analisar as idéias: Revisar a produção de idéias, destacando as mais valiosas definidas pelo grupo e classificando-as com prioridades.

Prototipagem Fazer um protótipo para explorar requisitos vinculados a um produto que possua aspectos críticos.

Implementando de maneira mais rápida um pequeno subconjunto de funcionalidades deste produto.

requisitos

desenvolver

validar

acertar fim

protótipo é aconselhado para: 1.Estudar as alternativas de interface do usuário; 2.Problemas de comunicação com outros produtos; 3.A viabilidade de atendimento dos requisitos de desempenho. principais benefícios : reduções dos riscos na construção do sistema, Validaçoes de especificaçoes . elementos para o sucesso na elaboração dos protótipos: 1.Seleção do ambiente de prototipagem; 2.Compreender os objetivos do protótipo por parte de todos os interessados no projeto; 3.Focar em áreas que estejam com maior dificuldade na compreensão; 4.Rapidez na construção.

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

A idéia é criar uma visão compartilhada do produto de software .

Ela ajuda os usuários e desenvolvedores a formular problemas e explorar soluções, no escopo do projeto a ser desenvolvido.

JAD (Joint Application Design).

Possui quatro princípios básicos: •Dinâmica de grupo: são realizadas reuniões com um líder experiente, analista, usuários e gerentes, para despertar a força e criatividade dos participantes. O resultado final será a determinação dos objetivos e requisitos do sistema; •Uso de técnicas visuais: para aumentar a comunicação e o entendimento; •Manutenção do processo organizado e racional: o JAD emprega a análise top down e atividades bem definidas.

•Utilização de documentação padrão: preenchida e assinada por todos os participantes. Este documento garante a qualidade esperada do projeto e promove a confiança dos participantes.

JAD -participantes – •Líder da sessão: É um facilitador dos encontros. Deve ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderança.

•Engenheiro de requisitos: É um participante experiente nas questões técnicas, diretamente responsável pela produção dos documentos de saída das sessões JAD. •Executor: É o responsável pelo produto sendo construído.

•Representantes dos usuários: São pessoas na empresa que terão incumbência de utilizar o produto de software.

•Representantes de produtos de software: São pessoas que estão familiarizadas com as capacidades dos produtos de software, capazes de mediar os usuários na compreensão entre o que é possível e razoável no sistema.

•Especialista: é a pessoa que pode fornecer informações detalhadas sobre um tópico específico.

Outras técnicas: -simuladores -mapas mentais - Determinação de cenários -oficinas de requisitos - Casos de uso

Na próxima aula: você estudará sobre os assuntos seguintes: - Documento de Requisitos de Software.

- Composição do Documento de Requisitos de Software.

- Utilidade e validade do Documento de Requisitos de Software.

NOME DA DISCIPLINA

Contactos e material complementar e exercícios www.espacodoprofessor.com Professor: Horacio ribeiro Modulo Estácio 2012.1 Senha 222222

NOME DA AULA – AULA1