202201_ES_S6_aulas

Prévia do material em texto

Engenharia de Software
Semana 6 – Engenharia de Requisitos.
Gustavo Scalabrini Sampaio
Universidade Presbiteriana Mackenzie
Faculdade de Computação e Informática
Universidade Presbiteriana Mackenzie
2
Engenharia de requisitos
Princípios da comunicação
Antes que os requisitos dos clientes sejam analisados, modelados ou especificados, eles devem ser coletados por meio da atividade de comunicação. 
A comunicação efetiva (entre parceiros técnicos, com o cliente, com outros parceiros envolvidos e com gerentes de projetos) constitui uma das atividades mais desafiadoras. Nesse contexto, discutem-se princípios aplicados na comunicação com o cliente. Entretanto, muitos desses princípios são aplicados a todas as formas de comunicação.
Antes de se comunicar, assegure-se de compreender o ponto de vista alheio e suas necessidades. Saiba ouvir.
Princípio 1 - Ouça: Concentre-se mais em ouvir do que em se preocupar com respostas. Peça esclarecimento, se necessário, e evite interrupções constantes. Nunca se mostre contestador, tanto em palavras quanto em ações (por exemplo, revirar olhos ou balançar a cabeça) enquanto uma pessoa estiver falando.
Universidade Presbiteriana Mackenzie
3
Engenharia de requisitos
Princípios da comunicação
Princípio 2 - Prepare-se antes de se comunicar: Dedique tempo para compreender o problema antes de se reunir com outras pessoas. Se necessário, faça algumas pesquisas para entender o jargão da área de negócios em questão. Caso seja sua a responsabilidade conduzir uma reunião, prepare uma agenda com antecedência.
Princípio 3 - Alguém deve facilitar a atividade: Toda reunião de comunicação deve ter um líder (um facilitador) para manter a conversa direcionada e produtiva, mediar qualquer conflito que ocorra e garantir que outros princípios sejam seguidos.
Princípio 4 - Comunicar-se pessoalmente é melhor: No entanto, costuma ser mais produtivo quando alguma outra representação da informação relevante está presente. Por exemplo, um participante pode fazer um desenho ou um esboço de documento que servirá como foco para a discussão.
Princípio 5 - Anote e documente as decisões: As coisas tendem a cair no esquecimento. Algum participante desta reunião deve servir como “gravador” e anotar todos os pontos e decisões importantes.
Princípio 6 - Esforce-se para conseguir colaboração: Colaboração e consenso ocorrem quando o conhecimento coletivo dos membros da equipe é usado para descrever funções e características do produto ou sistema. Cada pequena colaboração servirá para estabelecer confiança entre os membros e chegar a um objetivo comum.
Universidade Presbiteriana Mackenzie
4
Engenharia de requisitos
Princípios da comunicação
Princípio 7 - Mantenha o foco; crie módulos para a discussão: Quanto mais pessoas envolvidas, maior a probabilidade de a discussão saltar de um tópico a outro. O facilitador deve manter a conversa modular, abandonando um assunto somente depois de ele ter sido resolvido.
Princípio 8 - Faltando clareza, desenhe: A comunicação verbal flui até certo ponto. Um esboço ou um desenho pode permitir maior clareza quando palavras são insuficientes.
Princípio 9 - (a) Uma vez de acordo, siga em frente. (b) Se não chegar a um acordo, siga em frente. (c) Se uma característica ou função não estiver clara e não puder ser elucidada no momento, siga em frente: A comunicação, assim como qualquer outra atividade da engenharia de software, toma tempo. Em vez de ficar interagindo indefinidamente, os participantes precisam reconhecer que muitos assuntos exigem discussão e que “seguir em frente” é, algumas vezes, a melhor maneira de ser ágil na comunicação.
Princípio 10 - Negociação não é uma competição nem um jogo: Funciona melhor quando as duas partes saem ganhando. Há muitas ocasiões em que é necessário negociar funções e características, prioridades e prazos de entrega. Se a equipe interagiu adequadamente, todas as partes envolvidas têm um objetivo comum. Mesmo assim, a negociação exigirá compromisso de todos.
Universidade Presbiteriana Mackenzie
5
Engenharia de requisitos
Entendendo os requisitos
Antes de iniciar qualquer trabalho técnico é uma boa ideia criar um conjunto de requisitos para todas as tarefas de engenharia.
É importante entender o que o cliente quer antes de começar a projetar.
OBS: A engenharia de requisitos estabelece uma base sólida para o projeto e para a construção. Sem ela, o software resultante tem grande probabilidade de não atender às necessidades do cliente.
O amplo espectro de tarefas e técnicas que levam a um entendimento dos requisitos é chamado de engenharia de requisitos. 
Do ponto de vista do processo de software, a engenharia de requisitos se inicia durante a atividade de comunicação e continua na de modelagem. 
Universidade Presbiteriana Mackenzie
6
Engenharia de requisitos
Entendendo os requisitos
A engenharia de requisitos constrói uma ponte entre o projeto e a construção; e permite que examinemos:
O contexto do trabalho de software a ser realizado; 
As necessidades específicas a que o projeto e a construção devem atender; 
As prioridades que orientam a ordem na qual o trabalho deve ser concluído; 
As informações, funções e comportamentos que terão um impacto profundo no projeto resultante.
A engenharia de requisitos abrange sete tarefas distintas: 
Concepção
Levantamento
Elaboração
Negociação
Especificação
Validação 
Gestão
Algumas delas ocorrem em paralelo e todas são adaptadas às necessidades do projeto.
Universidade Presbiteriana Mackenzie
7
Engenharia de requisitos
Entendendo os requisitos
Concepção: Como um projeto de software é iniciado? Em alguns casos, uma conversa informal basta para precipitar um trabalho de engenharia de software.
A maioria dos projetos começa quando é identificada a necessidade do negócio ou é descoberto um novo serviço ou mercado potencial. 
Envolvidos da comunidade de negócios (por exemplo, gerentes comerciais, pessoal de marketing, gerentes de produto) definem um plano de negócio para a ideia, tentam identificar o tamanho do mercado, fazem uma análise de viabilidade aproximada e identificam uma descrição operacional da abrangência do projeto. 
Na concepção do projeto, estabelecemos um entendimento básico do problema, as pessoas que querem uma solução, a natureza da solução desejada e a eficácia da comunicação e colaboração preliminares entre os demais envolvidos e a equipe de software.
Universidade Presbiteriana Mackenzie
8
Engenharia de requisitos
Entendendo os requisitos
Levantamento: Verificar junto ao cliente, aos usuários e aos demais envolvidos quais são os objetivos para o sistema ou produto, o que deve ser obtido, como o sistema ou produto atende às necessidades da empresa e, por fim, como o sistema ou produto deve ser utilizado no dia a dia. Parece simples, mas é muito difícil.
Uma parte importante do levantamento é estabelecer metas de negócios. 
Uma vez capturadas as metas, deve ser estabelecido um mecanismo de atribuição de prioridades, podendo ser criado um raciocínio lógico para a possível arquitetura do projeto (que atenda às metas dos envolvidos).
Problemas que são encontrados durante o levantamento:
Problemas de escopo: ocorrem quando os limites do sistema são definidos de forma precária.
Problemas de entendimento: são encontrados quando clientes e usuários não estão completamente certos do que precisam ou transmitem de forma inadequado os requisitos; especificam requisitos conflitantes com as necessidades de outros clientes e usuários ou especificam requisitos ambíguos ou impossíveis de serem testados.
Problemas de volatilidade: ocorrem quando os requisitos mudam com o passar do tempo. 
Universidade Presbiteriana Mackenzie
9
Engenharia de requisitos
Entendendo os requisitos
Elaboração: As informações obtidas do cliente durante a concepção e o levantamento são expandidas e refinadas durante a elaboração. 
Essa tarefa concentra-se no desenvolvimento de um modelo de requisitos refinado que identifique os diversos aspectos da função, do comportamentoe das informações do software.
É guiada pela criação e pelo refinamento de cenários que descrevem como o usuário (e outros atores) vão interagir com o sistema.
Cada cenário de usuário é analisado para extrair classes de análise (entidades do domínio de negócio visíveis para o usuário). Os atributos de cada classe de análise são definidos, e os serviços exigidos de cada uma são identificados. As relações e a colaboração entre as classes são identificadas, e uma variedade de diagramas suplementares é produzida.
Universidade Presbiteriana Mackenzie
10
Engenharia de requisitos
Entendendo os requisitos
Negociação: Clientes ou usuários proporem necessidades conflitantes, argumentando que sua versão é “essencial para nossas necessidades especiais”.
É preciso conciliar esses conflitos por meio de um processo de negociação. Devemos solicitar a clientes, usuários e outros envolvidos para que ordenem seus requisitos e discutam sua prioridade. 
Usando uma abordagem iterativa que priorize os requisitos, avalie seus custos e riscos e trate dos conflitos internos, os requisitos são eliminados, combinados e/ou modificados, de modo que cada parte atinja certo nível de satisfação.
OBS: Em uma negociação efetiva não existem ganhadores, nem perdedores. Ambos os lados ganham, pois é consolidado um “acordo” que ambas as partes aceitam.
Universidade Presbiteriana Mackenzie
11
Engenharia de requisitos
Entendendo os requisitos
Especificação: pode ser um documento por escrito, um conjunto de modelos gráficos, um modelo matemático formal, um conjunto de cenários de uso, um protótipo ou qualquer combinação dos fatores citados.
Para sistemas grandes, um documento escrito, combinando descrições em linguagem natural e modelos gráficos, pode ser a melhor abordagem. 
Entretanto, talvez sejam necessários apenas cenários de uso para produtos ou sistemas menores que residam em ambientes técnicos bem compreendidos.
OBS: A formalidade e o formato de uma especificação variam com o tamanho e a complexidade do software a ser construído.
Universidade Presbiteriana Mackenzie
12
Engenharia de requisitos
Entendendo os requisitos
Validação: Os artefatos produzidos pela engenharia de requisitos têm sua qualidade avaliada durante a etapa de validação. 
A validação de requisitos examina a especificação para garantir que todos os requisitos de software tenham sido declarados de forma não ambígua; que as inconsistências, omissões e erros tenham sido detectados e corrigidos; e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto.
O principal mecanismo de validação de requisitos é a revisão técnica.
Gestão de requisitos: A gestão de requisitos é um conjunto de atividades que ajuda a equipe de projeto a identificar, controlar e acompanhar as necessidades e suas mudanças à medida que o projeto prossegue. Muitas dessas atividades são idênticas às técnicas de gerenciamento de configurações de software (SCM, software configuration management)
Universidade Presbiteriana Mackenzie
13
Engenharia de requisitos
Envolvidos
Envolvidos (stakeholder) como “qualquer pessoa que se beneficie de forma direta ou indireta do sistema que está sendo desenvolvido”. 
Envolvidos “de sempre”: 
Gerentes de operações
Gerentes de produto
Pessoal de marketing
Clientes internos e externos
Usuários
Consultores
Engenheiros de produto
Engenheiros de software
Engenheiros de suporte e manutenção
Cada envolvido tem uma visão diferente do sistema, obtém diferentes benefícios quando o sistema é desenvolvido com êxito e está sujeito a diferentes riscos caso o trabalho de desenvolvimento venha a fracassar.
Universidade Presbiteriana Mackenzie
14
Engenharia de requisitos
Envolvidos
OBS: devemos criar uma lista das pessoas que vão contribuir com sugestões à medida que os requisitos forem obtidos. 
Diferença entre clientes e usuários:
Cliente é a pessoa ou grupo que: 
Originalmente requisita o software a ser construído;
Define os objetivos gerais do negócio para o software;
Fornece os requisitos básicos do produto; 
Coordena os recursos financeiros para o projeto. 
Usuário é uma pessoa ou grupo que:
Vai realmente usar o software construído para atingir algum propósito de negócio;
Vai definir os detalhes operacionais do software de modo que o objetivo seja alcançado.
Universidade Presbiteriana Mackenzie
15
Engenharia de requisitos
Reconhecimento de diversos pontos de vista
Como há muitos envolvidos diferentes, os requisitos do sistema serão explorados sob vários pontos de vista. 
Cada uma dessas partes (e outras) contribuirá com informações para o processo de engenharia de requisitos.
À medida que as informações dos diversos pontos de vista são coletadas, requisitos emergentes talvez sejam inconsistentes ou entrem em conflito uns com os outros. 
As informações de todos os envolvidos (inclusive os requisitos inconsistentes e conflitantes) devem ser classificadas, de maneira que permita aos tomadores de decisão escolher um conjunto internamente consistente de requisitos para o sistema.
Universidade Presbiteriana Mackenzie
16
Engenharia de requisitos
Trabalho em busca da colaboração
Se cinco envolvidos estiverem ligados a um projeto de software, talvez tenhamos cinco (ou mais) opiniões diferentes sobre o conjunto de requisitos apropriado. 
Os envolvidos devem colaborar entre si e com os profissionais de engenharia de software, caso se queira obter um sistema bem-sucedido.
O engenheiro de software deve identificar áreas em comum e áreas de conflito ou inconsistência.
Colaboração não significa necessariamente que os requisitos são definidos por um comitê̂. Em muitos casos, os envolvidos colaboram dando suas visões dos requisitos, mas um “defensor dos projetos” forte (por exemplo, um gerente comercial ou um técnico sênior) pode tomar a decisão final sobre quais requisitos serão cortados.
Universidade Presbiteriana Mackenzie
17
Engenharia de requisitos
Questões iniciais
As perguntas feitas na concepção do projeto devem ser “livres de contexto”. O primeiro conjunto de perguntas foca no cliente e outros envolvidos, nos benefícios e nas metas de projeto globais:
Quem está por trás da solicitação deste trabalho?
Quem vai usar a solução?
Qual será o beneficio econômico de uma solução bem-sucedida?
Há outra fonte para a solução de que você̂ precisa?
Essas perguntas ajudam a identificar todos os envolvidos interessados no software, o benefício mensurável de uma implementação bem-sucedida e possíveis alternativas para o desenvolvimento de software personalizado.
Universidade Presbiteriana Mackenzie
18
Engenharia de requisitos
Questões iniciais
O próximo conjunto de perguntas permite entender melhor o problema e permite que o cliente expresse suas percepções sobre uma solução:
Como você̂ caracterizaria uma “boa” saída, que seria gerada por uma solução bem-sucedida?
Qual(is) problema(s) esta solução vai resolver?
Você poderia me indicar (ou descrever) o ambiente de negócios em que a solução será usada?
Aspectos ou restrições de desempenho afetam a maneira com que a solução será abordada?
O conjunto final de perguntas concentra-se na eficiência da atividade de comunicação em si: 
Você é a pessoa correta para responder a estas perguntas? Suas respostas são “oficiais”?
Minhas perguntas são relevantes para o problema que você̂ tem?
Estaria eu fazendo perguntas demais?
Alguma outra pessoa poderia me prestar informações adicionais?
Deveria eu perguntar-lhe algo mais?
Essas (e outras) perguntas ajudarão “quebrar o gelo” e iniciar o processo de comunicação que é essencial para o êxito do levantamento.
Universidade Presbiteriana Mackenzie
19
Engenharia de requisitos
Requisitos não funcionais
Um requisito não funcional (NFR, nonfunctional requirement) pode ser descrito como um atributo de qualidade, de desempenho, de segurança ou como uma restrição geral em um sistema. 
Frequentemente, os envolvidos têm dificuldade de articulá-los. 
A disponibilização da função de qualidade (QFD) tenta traduziras necessidades ou metas não mencionadas do cliente em requisitos do sistema. 
Os requisitos não funcionais frequentemente são listados separadamente em uma especificação de requisitos de software.
Universidade Presbiteriana Mackenzie
20
Engenharia de requisitos
Rastreabilidade
Rastreabilidade é um termo da engenharia de software que se refere a mapeamentos documentados entre os artefatos de engenharia de software (por exemplo, requisitos e casos de teste). 
Uma matriz de rastreabilidade permite a um engenheiro de requisitos representar a relação entre os requisitos e outros artefatos da engenharia de software. 
As linhas da matriz de rastreabilidade são rotuladas com os nomes dos requisitos, e as colunas podem ser rotuladas com o nome de um artefato da engenharia de software (por exemplo, um elemento do projeto ou um caso de teste).
À medida que o número de requisitos e o número de artefatos aumentam, torna-se cada vez mais difícil manter a matriz de rastreabilidade atualizada. 
Contudo, é importante criar algumas maneiras de monitorar o impacto e a evolução dos requisitos do produto.
	ID	Requisito	Necessidade de negócio	Objetivo de projeto	Requisitado por	Departamento	Especificação	Design	Caso de teste
	1	Login	Acesso ao serviço	Criar o sistema mínimo	Gustavo	Conteúdo	Finalizado	Em progresso	1001
Universidade Presbiteriana Mackenzie
21
Engenharia de requisitos
Levantamento de requisitos
O levantamento de requisitos (também chamado elicitação de requisitos) combina elementos de solução de problemas, elaboração, negociação e especificação. 
Para estimular uma abordagem colaborativa e orientada a equipes em relação ao levantamento de requisitos, os envolvidos trabalham juntos para identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução.
Universidade Presbiteriana Mackenzie
22
Engenharia de requisitos
Levantamento de requisitos
Coleta colaborativa de requisitos
Diretrizes básicas:
As reuniões (reais ou virtuais) são conduzidas por e com a participação tanto dos engenheiros de software quanto de outros envolvidos.
São estabelecidas regras para preparação e participação.
É sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes; porém, suficientemente informal para estimular o fluxo livre de ideias.
Um “facilitador” (pode ser um cliente, um desenvolvedor ou uma pessoa de fora) dirige a reunião.
É utilizado um “mecanismo de definições” (planilhas, flip charts, adesivos de parede ou um boletim eletrônico, salas de bate-papo ou fóruns virtuais).
O objetivo é identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução em uma atmosfera que seja propícia para o cumprimento da meta.
Universidade Presbiteriana Mackenzie
23
Engenharia de requisitos
Levantamento de requisitos
Processo
Concepção
Pedido de produto
Local
Hora
Data 
para a reunião de requisitos
Participantes elaboram a lista de requisitos antes da reunião
Participantes
*Escolhido o facilitador
Reunião de requisitos
Lista de requisitos consolidada
Universidade Presbiteriana Mackenzie
24
Engenharia de requisitos
Levantamento de requisitos
Exemplo: Biblioteca da Steam (Recurso da aplicação Steam).
Concepção: Dentro da aplicação Steam um recurso “Biblioteca” deve ser disponibilizado para que os usuários possam gerenciar seus jogos dentro da plataforma.
Requisitos iniciais (Individual):
O usuário pode visualizar a lista dos jogos que ele já adquiriu.
Notícias dos jogos adquiridos como atualizações devem ser exibidas para o usuário.
Uma lista dos últimos jogos adquiridos deve ser exibida em destaque.
O usuário deve ter uma opção de adicionar mais jogos à sua biblioteca (Redirecionar para a loja).
Requisitos consolidados e priorizados (Coletivo):
O usuário pode visualizar a lista dos jogos que ele já adquiriu.
O usuário pode gerenciar os jogos da biblioteca. Jogos podem ser adicionados, removidos ou iniciados.
O usuário pode filtrar a lista de jogos com opções como Gênero; quantidade de jogadores; suporte a hardware específico; etc.
O retorno da busca não pode demorar mais que 1 segundo.
O usuário pode criar uma coleção de jogos personalizada.
Sugestões de jogos de estilos similares já adquiridos pelo usuário devem ser exibidos na seção “Jogue também”.
Notícias dos jogos adquiridos como atualizações devem ser exibidas para o usuário.
O usuário pode configurar a seção de notícias.
Uma lista dos últimos jogos adquiridos deve ser exibida em destaque.
O usuário deve ter uma opção de adicionar mais jogos à sua biblioteca (Redirecionar para a loja).
Por questões de segurança o usuário deve realizar novamente o login ao ser redirecionado para a loja.
OBS: A negociação é um fator importante durante a elaboração e priorização dos requisitos.
Universidade Presbiteriana Mackenzie
25
Engenharia de requisitos
Levantamento de requisitos
Exemplo: Biblioteca da Steam (Recurso da aplicação Steam).
Concepção: Dentro da aplicação Steam um recurso “Biblioteca” deve ser disponibilizado para que os usuários possam gerenciar seus jogos dentro da plataforma.
Requisitos iniciais (Individual):
O usuário pode visualizar a lista dos jogos que ele já adquiriu.
Notícias dos jogos adquiridos como atualizações devem ser exibidas para o usuário.
Uma lista dos últimos jogos adquiridos deve ser exibida em destaque.
O usuário deve ter uma opção de adicionar mais jogos à sua biblioteca (Redirecionar para a loja).
Requisitos consolidados e priorizados (Coletivo):
O usuário pode visualizar a lista dos jogos que ele já adquiriu.
O usuário pode gerenciar os jogos da biblioteca. Jogos podem ser adicionados, removidos ou iniciados.
O usuário pode filtrar a lista de jogos com opções como Gênero; quantidade de jogadores; suporte a hardware específico; etc.
O retorno da busca não pode demorar mais que 1 segundo.
O usuário pode criar uma coleção de jogos personalizada.
Sugestões de jogos de estilos similares já adquiridos pelo usuário devem ser exibidos na seção “Jogue também”.
Notícias dos jogos adquiridos como atualizações devem ser exibidas para o usuário.
O usuário pode configurar a seção de notícias.
Uma lista dos últimos jogos adquiridos deve ser exibida em destaque.
O usuário deve ter uma opção de adicionar mais jogos à sua biblioteca (Redirecionar para a loja).
Por questões de segurança o usuário deve realizar novamente o login ao ser redirecionado para a loja.
Requisitos não funcionais
Universidade Presbiteriana Mackenzie
26
Reflexão em grupo
Levantamento de requisitos
Seu grupo foi designado para desenvolver um sistema de consulta a métricas de redes sociais. Nesse sistema o usuário pode escolher a rede social desejada (Facebook, Twitter, Instagram, etc.) e monitorar diversos aspectos das postagens. Por exemplo: fazer a busca sobre determinado assunto e visualizar tabelas com trending topics; gráficos das regiões do país com mais comentários; usuários mais engajados, etc. (https://www.social-searcher.com/)
Sua equipe deve gerar a lista de requisitos (com separação entre requisitos funcionais e não funcionais) do sistema; que será discutida com todos os envolvidos. 
Para tanto:
1. Elaborar individualmente a lista de requisitos. 
2. Classificar a lista em requisitos funcionais e não funcionais.
3. Com sua equipe, discutir os requisitos e definir uma lista de requisitos consolidada.
4. Priorizar os requisitos.
Universidade Presbiteriana Mackenzie
27
Reflexão em grupo
Levantamento de requisitos
Após a geração da lista de requisitos algumas perguntas devem ser feitas e analisadas:
Podemos construir o sistema?
Esse processo de desenvolvimento nos permitirá superar nossos concorrentes no mercado?
Existem recursos adequados para construir e manter o sistema proposto?
O desempenho do sistema vai atender às necessidades de nossos clientes?
As respostas dessas e de outras perguntas vão evoluir com o passar do tempo.
Universidade PresbiterianaMackenzie
28
Tarefa em grupo
TG2 - Levantamento de requisitos
Atualize a Wiki do projeto com os artefatos gerado a partir da engenharia de requisitos do sistema.
Cada membro do grupo gera uma lista sucinta dos requisitos.
O grupo se reúne para consolidar os requisitos iniciais.
O grupo prioriza a lista de requisitos.
A lista de requisitos deve ter as seguintes colunas:
Número do requisito
Descrição
Classificação (RF: Requisito Funcional; RNF: Requisito Não Funcional)
Dependências (Números de outros requisitos, os quais o requisito é dependente)
Esforço (Para desenvolver: Alto; Médio; Baixo)
Relevância (Para o negócio: Alta; Média; Baixa)
Risco (Para o projeto: Alto; Médio; Baixo)
Ordene a tabela pela prioridade do requisito.
Universidade Presbiteriana Mackenzie
29
Aplicação da qualidade por QFD (Quality Function Deployment)
A disponibilização da função de qualidade (QFD, quality function deployment) é uma técnica de gestão da qualidade que traduz as necessidades do cliente para requisitos técnicos do software. 
Enfatiza o entendimento daquilo que é valioso para o cliente e emprega esses valores ao longo do processo de engenharia.
No contexto da QFD:
Requisitos normais identificam os objetivos e metas declarados para um produto ou sistema durante as reuniões com o cliente. Se esses requisitos estiverem presentes, o cliente ficará satisfeito. 
Requisitos esperados estão implícitos no produto ou sistema e podem ser tão básicos, que o cliente não os declara explicitamente. Sua ausência será causa de grande insatisfação. 
Requisitos fascinantes vão além da expectativa dos clientes e demonstram ser muito satisfatórios quando presentes.
Universidade Presbiteriana Mackenzie
30
Aplicação da qualidade por QFD (Quality Function Deployment)
O QFD usa observação e entrevistas com clientes, pesquisas e exame de dados históricos (por exemplo, relatórios de problemas) como evidências para a atividade de levantamento de requisitos. 
Esses dados são então transformados em uma tabela de requisitos, denominada tabela da voz do cliente, revisada com o cliente e outros envolvidos. 
Uma série de diagramas, matrizes e métodos de avaliação é então usada para extrair os requisitos esperados e para tentar obter os requisitos fascinantes.
OBS: O QFD define necessidades de modo a maximizar a satisfação do cliente.
OBS: Todo mundo quer implementar um monte de requisitos fascinantes; porém, tenha cuidado. É assim que o “surgimento descontrolado de novos requisitos” se estabelece. Por outro lado, requisitos fascinantes levam a um produto revolucionário (ou disruptivo)!
Universidade Presbiteriana Mackenzie
31
Artefatos do levantamento de requisitos
Os artefatos produzidos pelo levantamento de requisitos vão variar dependendo do tamanho do sistema ou produto a ser construído. Para a maioria dos sistemas, entre os artefatos, temos: 
Declaração de necessidade e viabilidade
Declaração da abrangência do sistema ou produto com escopo limitado
Lista de clientes, usuários e outros envolvidos que participaram do levantamento de requisitos
Descrição do ambiente técnico do sistema
Lista dos requisitos (preferivelmente organizada por função) e as restrições do domínio que se aplicam a cada um
Conjunto de cenários de utilização dando uma ideia do uso do sistema ou produto sob diferentes condições operacionais
Quaisquer protótipos desenvolvidos para definir melhor os requisitos
Cada um desses artefatos é revisado por todas as pessoas que participaram do levantamento de requisitos.
Universidade Presbiteriana Mackenzie
32
Cenários de uso
À medida que os requisitos são reunidos, uma visão geral das funções e características começa a se materializar. 
No entanto é difícil passar para atividades mais técnicas da engenharia de software até que se entenda como tais funções e características serão usadas por diferentes classes de usuários. 
Os desenvolvedores e usuários podem criar um conjunto de cenários que identifique um roteiro de uso para o sistema a ser construído. Os cenários, normalmente chamados de casos de uso, fornecem uma descrição de como o sistema será utilizado.
Universidade Presbiteriana Mackenzie
33
Desenvolvimento de casos de uso
Um caso de uso descreve o comportamento do sistema sob várias condições, à medida que o sistema responde a uma solicitação de um de seus envolvidos.
Basicamente, um caso de uso conta uma jornada estilizada sobre como um usuário (desempenhando um de uma série de papéis possíveis) interage com o sistema sob um conjunto de circunstâncias específicas. 
A jornada poderia ser um texto narrativo, uma descrição geral das tarefas ou interações, uma descrição baseada em modelos ou uma representação esquemática. Independentemente de sua forma, um caso de uso representa o software ou o sistema do ponto de vista do usuário.
O primeiro passo ao escrever um caso de uso é definir o conjunto de “atores” envolvidos na história.
Universidade Presbiteriana Mackenzie
34
Desenvolvimento de casos de uso
Atores são as diferentes pessoas (ou dispositivos) que usam o sistema ou produto no contexto da função e do comportamento a ser descrito. 
É importante notar que ator e usuário não são necessariamente a mesma coisa.
O usuário típico poderia desempenhar inúmeros papéis diferentes ao usar um sistema, ao passo que o ator representa uma classe de entidades externas (normalmente, mas não sempre, pessoas) que desempenham apenas um papel no contexto do caso de uso. 
Ex: operador de máquina (um usuário) que interage com o computador de controle de uma célula de fabricação contendo uma série de robôs e máquinas, comandada por controle numérico. O computador de controle exige quatro modos (papéis) diferentes para interação: modo de programação, modo de teste, modo de monitoramento, modo de diagnóstico. 
Portanto, podem ser definidos quatro atores: 
Programador
Testador
Monitorador
Diagnosticador
Em alguns casos, o operador da maquina pode desempenhar todos esses papéis. Em outros, pessoas diferentes poderiam desempenhar o papel de cada ator.
Universidade Presbiteriana Mackenzie
35
Desenvolvimento de casos de uso
Como o levantamento de requisitos é uma atividade evolutiva, nem todos os atores são identificados durante a primeira iteração.
É possível identificar atores primários durante a primeira iteração e atores secundários quando mais fatos são aprendidos sobre o sistema. 
Os primários interagem para atingir a função necessária e obter o benefício desejado do sistema. Eles trabalham com o software direta e frequentemente. Os secundários dão suporte ao sistema para que os primários possam realizar seu trabalho.
Os atores podem ser listados no catálogo de atores:
	Ator	Descrição
	Usuário	Usuário do sistema da Steam
Universidade Presbiteriana Mackenzie
36
Desenvolvimento de casos de uso
Depois de identificados os atores, os casos de uso podem ser desenvolvidos. 
Algumas perguntas que devem ser respondidas por um caso de uso:
Quem é o ator primário e quem é (são) o(s) ator(es) secundário(s)?
Quais são as metas do ator?
Que precondições devem existir antes de uma jornada começar?
Que tarefas ou funções principais são realizadas pelo ator?
Que exceções poderiam ser consideradas à medida que uma jornada é
descrita?
Quais são as variações possíveis na interação do ator?
Que informações de sistema o ator adquire, produz ou modifica?
O ator terá de informar o sistema sobre mudanças no ambiente externo?
Que informações o ator deseja do sistema?
O ator gostaria de ser informado sobre mudanças inesperadas?
Universidade Presbiteriana Mackenzie
37
Diagrama de casos de uso
O diagrama de caso de uso (UML) representa graficamente os atores, casos de uso e relacionamentos entre esses elementos. 
Tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com as funcionalidades do sistema. 
A notação para a ilustração dos elementos desse diagrama são as seguintes:
Ator
Usuário
Adicionar jogo à biblioteca
Caso de Uso
Relacionamento de ComunicaçãoFronteira do Sistema
Atores: figura de um boneco, com o nome do ator definido abaixo da figura. Um ator nem sempre corresponde a seres humanos, como a notação leva a entender. 
Caso de Uso: representado por uma elipse. Seu nome é posicionado abaixo ou dentro dessa elipse. Um ator pode estar associado por meio do relacionamento de comunicação a vários casos de uso.
Relacionamento de comunicação: representado por um segmento de reta ligando ator e caso de uso. 
Fronteira do Sistema: representada por um retângulo no interior do qual são inseridos os casos de uso. Os atores são posicionados do lado de fora do retângulo, para enfatizar a divisão entre o interior e o exterior do sistema. 
Universidade Presbiteriana Mackenzie
38
Especificação do Caso de Uso
A especificação do caso de uso é um complemento textual à representação gráfica dos casos de uso. Na especificação do caso de uso são apresentadas informações sobre os atores, as condições e fluxo de processamento.
A descrição da interação do relacionamento entre atores e casos de uso permite, também, extrair requisitos não percebidos anteriormente, nas fases de concepção e levantamento de requisitos.
Juntamente com o diagrama, a especificação do caso de uso é uma ferramenta importante para o processo de refinamento dos requisitos.
Universidade Presbiteriana Mackenzie
39
Especificação do Caso de Uso
As principais informações presentes na especificação do caso de uso são:
Identificador: Código para a identificação do caso de uso.
Nome: Descreve o nome do caso de uso. Geralmente expressa o objetivo do caso de uso.
Atores: Identifica os atores que possuem relacionamento com o caso de uso.
Sumário/Descrição: Descreve a função e o objetivo do caso de uso.
Pré-condição: Um estado do sistema que deve estar presente antes de um caso de uso ser iniciado.
Pós-condição: Uma lista de estados possíveis para o sistema imediatamente após a conclusão de um caso de uso.
Pontos de Inclusão: Um ponto no fluxo de eventos do caso de uso em que outro caso de uso é referenciado.
Pontos de Extensão: Um ponto no fluxo de eventos do caso de uso em que outro caso de uso é referenciado.
Fluxo Principal: Descreve o fluxo básico do caso de uso.
Fluxos Alternativos: Descreve desvios do fluxo principal.
Fluxos de Exceção: Descreve exceções dos fluxos principal e alternativo.
Exemplo de especificação na planilha “especificação_caso_de_uso.xlsx”
Universidade Presbiteriana Mackenzie
40
Reflexão em grupo
Diagrama de Casos de Uso e Refinamento de Requisitos
Seu grupo foi designado para desenvolver um sistema de consulta a métricas de redes sociais. Nesse sistema o usuário pode escolher a rede social desejada (Facebook, Twitter, Instagram, etc.) e monitorar diversos aspectos das postagens. Por exemplo: fazer a busca sobre determinado assunto e visualizar tabelas com trending topics; gráficos das regiões do país com mais comentários; usuários mais engajados, etc.
Sua equipe gerou uma lista de requisitos inicial do sistema. No entanto, há a preocupação em refinar essa lista analisando os casos de uso do sistema. 
1. Elabore o diagrama de caso de uso do sistema descrito apontando as principais operações que o usuário pode realizar.
2. Escolha 1 caso de uso e elabore sua especificação.
Universidade Presbiteriana Mackenzie
41
Referências
PRESSMAN, R.S.; MAXIM, B.R.; Engenharia de Software, uma abordagem profissional. 8ª ed. Porto Alegre. AMGH, 2016. (Disponível na Biblioteca do Mackenzie, tanto físico como digital)
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2ª ed. Rio de Janeiro: Elsevier Campus. 2007.
Anotações e materiais da Professora Renata Araujo.
Anotações e materiais do Professor Calebe de Paula Bianchini