Aula 05 - Eng Software

Prévia do material em texto

Engenharia e Processos de Software
Prof. Esp. Sergio Fernandes Lima
Gerência de Requisitos
O que é um requisito?
O requisito do sistema pode ser apenas uma declaração
abstrata em alto nível de um serviço que o sistema deve
oferecer ou uma restrição a um sistema, ou pode ser uma
definição detalhada e formal de uma função do sistema.
O que é um requisito?
Desenvolvedor de 
Software Cliente
O que? Um sistema sob encomenda.
Para que? Para automatizar o agendamento de consultas e 
exames.
Por que?
Porque queremos que o próprio paciente escolha 
o melhor horário, sem necessitar ocupar nossa 
secretária.
Como? Por meio de uma ferramenta online.
Tipos de Requisitos
Requisitos de usuário
São declarações, em uma linguagem natural com
diagramas, de quais serviços o sistema deverá fornecer a
seus usuários e as restrições com as quais este deve
operar.
Tipos de Requisitos
Requisitos de sistema
São descrições mais detalhadas das funções, serviços e
restrições operacionais do sistema de software. O
documento de requisitos do sistema (às vezes, chamado
especificação funcional) deve definir exatamente o que
deve ser implementado. Pode ser parte do contrato entre
o comprador do sistema e os desenvolvedores de
software.
Tipos de Requisitos
Requisitos Funcionais
São declarações de serviços que o sistema deve fornecer,
de como o sistema deve reagir a entradas específicas e de
como o sistema deve se comportar em determinadas
situações. Em alguns casos, os requisitos funcionais
também podem explicitar o que o sistema não deve fazer
(SOMMERVILLE, 2011).
Requisitos Funcionais
Requisitos Funcionais
Cada requisito deixa sua contribuição
para a construção de uma parte do
sistema.
Requisitos Não Funcionais
São restrições aos serviços ou funções oferecidos pelo
sistema. Incluem restrições de timing, restrições no
processo de desenvolvimento e restrições impostas pelas
normas. Ao contrário das características individuais ou
serviços do sistema, os requisitos não funcionais, muitas
vezes, aplicam-se ao sistema como um todo
(SOMMERVILLE, 2011).
Tipos de Requisitos Não Funcionais
Requisitos Não Funcionais: Produtos
Os requisitos de produto especificam o comportamento
do produto.
Requisitos Não Funcionais: Organizacionais
Os requisitos organizacionais são derivados das políticas
organizacionais do cliente e do desenvolvedor.
Requisitos Não Funcionais: Externos
Os requisitos externos são procedentes de fatores
externos ao sistema e ao seu processo de
desenvolvimento.
Atores do Processo de Requisitos
(STAKEHOLDERS)
Usuários: grupo que irá usar o software.
Clientes: grupo que encomendou o software ou que
representa o público alvo do mesmo.
Analistas de mercado: para casos de produtos que
precisam da análise de mercado.
Atores do Processo de Requisitos
(STAKEHOLDERS)
Autoridades de regulamentação: para aplicações com
regulamentações próprias.
Desenvolvedor/Engenheiro de Software.
Outros engenheiros de software: em casos como reuso de
componentes.
Atores do Processo de Requisitos
(STAKEHOLDERS)
O contato inicial normalmente indica pessoas com quem
se deve falar, seus papéis e seus interesses.
Stakeholders incluem usuários diretos do sistema e
interessados indiretos também.
Stakeholders podem sugerir outras pessoas que devem
ser consultadas.
Desafios na Elicitação dos Requisitos
Para que o processo de desenvolvimento de software seja bem
sucedido é fundamental que haja uma compreensão completa
dos requisitos de software. Tanto o desenvolvedor como o
cliente desempenham um papel ativo na análise e especificação
dos requisitos.
Desafios na Elicitação dos Requisitos
Desafios na Elicitação dos Requisitos
Desafios na Elicitação dos Requisitos
• Falta de conhecimento do usuário das suas reais necessidades.
• Falta de conhecimento do desenvolvedor do domínio do
problema.
• Domínio do processo de elicitação de requisitos pelos
desenvolvedores.
• Comunicação inadequada entre os desenvolvedores e
usuários.
Desafios na Elicitação dos Requisitos
• Dificuldade do usuário tomar decisões.
• Problemas de comportamento.
• Questões técnicas.
Possíveis Fonte de Requisitos
Analisando as Fontes para os Requisitos
Funcionalidades
O que o sistema realizará?
Quando o sistema o fará?
Existem diversos modos de operação?
Interfaces
Os dados de entrada provêm de outros sistemas?
Os dados de saída são encaminhados para outros sistemas?
Analisando as Fontes para os Requisitos
Documentação
Que documentação é necessária?
Esta documentação deve ser on-line, em manual impresso ou ambos?
A que público se destina cada tipo de documentação?
Dados
Qual deverá ser o formato dos dados de entrada e de saída?
Quão precisos esses dados devem ser?
Qual o fluxo de dados no sistema?
Analisando as Fontes para os Requisitos
Recursos
Que habilidades os desenvolvedores devem ter?
Qual o espaço físico necessário ao sistema?
Qual o limite de investimento nesse sistema?
Segurança
Como o acesso ao sistema ou às suas informações devem ser
controladas?
Qual a política de backup a ser adotada para o sistema?
Analisando as Fontes para os Requisitos
Garantia da Qualidade
O sistema deve detectar falhas/erros?
Qual o tempo esperado entre falhas?
Como o sistema pode incorporar mudanças ao seu projeto?
A manutenção será apenas corretiva ou incluirá também manutenção
adaptativa/perfectiva?
Técnicas de Elicitação de Requisitos
• Entrevistas
• Brainstorming
• Questionários
• Workshop de Requisitos
• Etnografia
• Prototipação
• Casos de Uso e Cenários
Entrevistas
A entrevista é uma das técnicas tradicionais mais simples
de utilizar e que produz bons resultados na fase inicial de
obtenção de dados. Convém que o entrevistador dê
espaço ao entrevistado para esclarecer as suas
necessidades. É uma discussão do projeto desejado com
diferentes grupos de pessoas.
Entrevistas
• Entrevistas formais ou informais com os stakeholders do
sistema são parte da maioria dos processos de engenharia de
requisitos.
• Nessas entrevistas, a equipe de engenharia de requisitos
questiona os stakeholders sobre o sistema que usam no
momento e sobre o sistema que será desenvolvido.
• Requisitos surgem a partir das respostas a essas perguntas.
Brainstorming
Brainstorming é uma técnica para geração de ideias. Ela
consiste em uma ou várias reuniões que permitem que as
pessoas sugiram e explorem ideias.
Brainstorming
As principais etapas necessárias para conduzir uma sessão
e brainstorming são:
– Seleção dos participantes;
– Explicar a técnica e as regras a serem seguidas;
– Produzir uma boa quantidade de ideias.
Questionários
Diferente da entrevista, essa técnica é interessante
quando temos uma quantidade grande de pessoas para
extrair as mesmas informações. As questões são dirigidas
por escrito aos participantes com o objetivo de ter
conhecimento sobre opiniões das mesmas questões. São
autoaplicáveis pois o próprio informante responde.
Questionários
O uso de questionário é indicado, por exemplo, quando há
diversos grupos de usuários que podem estar em diversos locais
diferentes do país.
Utilizar questões de forma simples, clara e concisa, de forma a
minimizar o tempo gasto em sua resposta.
Tipos de questionários: múltipla escolha, lista de verificação e
questões com espaços em branco.
Workshop de Requisitos
Trata-se de uma técnica de elicitação em grupo usada em
uma reunião estruturada. Devem fazer parte do grupo
uma equipe de analistas e uma seleção dos stakeholders
que melhor representam a organização e o contexto em
que o sistema será usado, obtendo assim um conjunto de
requisitos bem definidos.
Workshop de Requisitos
• Há um facilitador neutro cujo papel é conduzir o
workshop e promover a discussão entre os vários
mediadores.
• Uma técnica utilizada em workshops é o brainstorming.
• Após os workshops serão produzidas documentações
que refletem os requisitos e decisões tomadas sobre o
sistema a ser desenvolvido.
Etnografia
Etnografia é uma técnica de observação que podeser
usada para compreender os processos operacionais e
ajudar a extrair os requisitos de apoio para esses
processos. Um analista faz uma imersão no ambiente de
trabalho em que o sistema será usado. 0 trabalho do dia a
dia é observado e são feitas anotações sobre as tarefas
reais em que os participantes estão envolvidos
(SOMMERVILLE, 2011).
Etnografia
Os sistemas de software não existem isoladamente. Eles são
usados em um contexto social e organizacional, e requisitos de
software do sistema podem ser derivados ou restringidos desse
contexto.
Uma razão pela qual muitos sistemas de software são entregues,
mas nunca são usados, é que seus requisitos não levam
devidamente em conta a forma como o contexto social e
organizacional afeta o funcionamento prático do sistema.
Etnografia
A etnografia é particularmente eficaz para descobrir dois tipos de
requisitos:
• Requisitos derivados da maneira como as pessoas realmente
trabalham, e não da forma como as definições dos processos
dizem que deveriam trabalhar.
• Requisitos derivados da cooperação e conhecimento das
atividades de outras pessoas.
Prototipação
Utilizado no estágio inicial do projeto. Ajuda aos stakeholders a
desenvolver uma forte noção sobre a aplicação a qual ainda não
foi implementada, que através da visualização da mesma eles
podem identificar os reais requisitos e fluxos de trabalho do
sistema. É muito utilizado quando os stakeholders são incapazes
de expressar os seus requisitos ou se os mesmos não têm
nenhuma experiência com o sistema.
Prototipação
• Um protótipo é uma versão inicial de um sistema que poderá
ser usado para experimentação.
• Protótipos são úteis para elicitação de requisitos porque os
usuários poderão experimentar o “sistema” e mostrar os
pontes fortes e fracos. Eles terão algo concreto para criticar.
• O desenvolvimento rápido dos protótipos é essencial para que
eles fiquem disponíveis logo para o processo de elicitação.
Cenários
• Os cenários são estórias que explicam como um sistema
poderá ser usado e podem ser particularmente úteis para
adicionar detalhes a uma descrição geral de requisitos.
• Trata-se de descrições de exemplos de sessões de interação,
onde cada cenário geralmente cobre um pequeno número de
interações possíveis.
• Diferentes cenários são desenvolvidos e oferecem diversos
tipos de informação em variados níveis de detalhamento sobre
o sistema.
Casos de Uso
• Os casos de uso são uma técnica de descoberta de requisitos
introduzida inicialmente no método Objectory (JACOBSON et
al., 1993).
• Eles já se tornaram uma característica fundamental da
linguagem de modelagem unificada (UML).
• Em sua forma mais simples, um caso de uso identifica os atores
envolvidos em uma interação e dá nome ao tipo de interação.
Casos de Uso
Os casos de uso são documentados por um diagrama de casos de
uso de alto nível. O conjunto de casos de uso representa todas as
possíveis interações que serão descritas nos requisitos de
sistema.
• Atores (pessoas ou outros sistemas).
• Classe de interação (elipse).
• Linhas fazem a ligação entre os atores e a interação.
• Pontas de flechas (opcional).
Casos de Uso
Cenários e casos de uso são técnicas eficazes para elicitar
requisitos dos stakeholders que vão interagir diretamente com o
sistema.