ENGENHARIA DE SOFTWARE

Kele Teixeira Belloze

kelebelloze@gmail.com

Engenharia de Requisitos

Tipos de requisitos de software

Técnicas de elicitação e análise de requisitos

Validação e gerenciamento de requisitos

TUDO COMEÇA COM A DEFINIÇÃO DOS REQUISITOS

The IEEE Standard Glossary of Software Engineering

Terminology [IEEE97] define requisito como uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo (...).

Desta definição pode-se aferir que os requisitos de

software são derivados de necessidades que usuários têm em resolver algum problema. Situa-se, então, o domínio do problema.

ENGENHARIA DE REQUISITOS

• A engenharia de requisitos é a disciplina que procura

sistematizar o processo de definição de requisitos. Aborda um ponto fundamental do desenvolvimento de software: a definição do que produzir.

• A engenharia de requisitos tem sido identificada como uma fase crucial por tratar de conhecimentos

não apenas técnicos, mas também gerenciais, organizacionais, econômicos e sociais, e estar intimamente associada a qualidade do software.

4

DIFICULDADE DE COMUNICAÇÃO

Dificuldade

de

comunicação

realmente

existe? Vamos averiguar?

5

6

NECESSIDADE DO CLIENTE

? Requisitos

Solicitação do Cliente:

Uma cadeira com quatro

pernas, um assento,

encosto para as costas e

braços.

Desejo do Cliente

COM A ESPECIFICAÇÃO DADA, COMO SABER QUAL CADEIRA O CLIENTE DESEJA?

DOMÍNIOS DA ENGENHARIA DE REQUISITOS

9

Domínio

do Problema

Domínio

da Solução

Universo

de Informações

Universo da Informações

A especificação de requisitos deve incluir não somente as

especificações do domínio do problema, mas também qualquer tipo de informação que descreva o contexto do sistema.

Esse contexto é conhecido como universo de informações, que é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software, e inclui todas as fontes de informação e todos os stakeholders.

Domínio do Problema

• O domínio do problema é o domínio de atuação do

software e inclui todos os elementos que interagem com ele. Neste ambiente principiam as atividades da engenharia de software, a definição das necessidades do software.

• É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem dos usuários, e definir um sistema que atenda às suas necessidades.

Domínio da Solução

• No domínio da solução é enfocada a definição da solução

aos problemas dos usuários.

• Os desenvolvedores do software aplicam seus conhecimentos em busca da especificação do sistema a ser desenvolvido.

• Envolve as características da solução e os requisitos do sistema.

• Uma vez estabelecido o conjunto de características com a concordância dos stakeholders, deve-se definir os requisitos mais específicos que serão necessários impor a solução.

CLASSIFICAÇÃO DOS REQUISITOS

CLASSIFICAÇÃO DOS REQUISITOS (1/4)

• Funcionais: representam os comportamentos que um programa ou sistema deve apresentar diante de certas ações de seus usuários.

• Não-funcionais: quantificam determinados aspectos do comportamento. (Ex: tempo de resposta, tempo médio entre falhas, etc.).

CLASSIFICAÇÃO DOS REQUISITOS (2/4)

Segundo Summerville (2007)

Requisitos de Usuário: descrevem os requisitos funcionais e não-funcionais de modo que eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado.

Requisitos de Sistema: são versões expandidas dos requisitos do usuário.

Requisitos de Domínio: são derivados do domínio da aplicação do sistema, em vez das necessidades dos usuários do sistema.

Segundo Eduardo Bezerra (2007)

Requisitos Normativos: restrições impostas sobre o desenvolvimento do sistema. Exemplo: restrições de custo, prazos e também as regras de negócio.

The Businness Rules Group

Regras de Negócio: é toda norma ou tudo aquilo que a lei ou uso comum determina a respeito de qualquer transação que envolve uma determinada organização. Por tanto, regra de negócio é uma diretriz destinada a regulamentar o comportamento do negócio.

CLASSIFICAÇÃO DOS REQUISITOS (3/4)

EXEMPLOS:

Requisitos Normativos - Regras de Negócio

“Uma conta não pode ter saldo negativo”.

“Um time não pode ter mais que 11 jogadores em campo”.

“Se uma conta tiver saldo maior que 5.000, enviar folheto sobre

investimentos”.

“Saldo é igual a crédito menos débito”

“Uma conta é “Ouro Especial” se seu saldo atual é superior a 30.000 e

seu saldo médio é superior a 20.000.”

Requisitos de Usuário: O LIBSYS deve fornecer um sistema de

contabilidade financeira que mantenha registros de todos os pagamentos

realizados pelos usuários do sistema. Os gerentes podem configurar este

sistema de modo que os usuários frequentes possam receber descontos.

Requisitos de Domínio: A desaceleração do trem deve ser calculada como:

Dtrem = Dcontrole + Dgradiente

CLASSIFICAÇÃO DOS REQUISITOS (4/4)

EXEMPLOS:

Requisitos de Sistema

Bomba de insulina/Software de controle/SRS/3.3.2

Função Calcular dose de insulina: nível seguro de açúcar

Descrição Calcula a dose de insulina a ser liberada quando o nível medido de açúcar atual está na zona segura

entre 3 e 7 unidades

Entradas Leitura atual de açúcar (r2), as duas leituras anteriores (r0 e r1)

Origem Leitura atual de açúcar do sensor. Outras leituras de memória

Saídas CompDose – a dose de insulina a ser liberada

Destino Loop de controle principal

Ação: CompDose será zero se o nível de açúcar estiver estável ou em queda, ou se o nível estiver aumentando, mas a taxa

de aumento estiver diminuindo. [...] então CompDose será definido como a dose mínima que pode ser liberada.

Requer Duas leituras anteriores de modo que a taxa de mudança do nível de açúcar possa ser calculada.

Precondição O reservatório de insulina conter, pelo menos, o máximo de dose única permitida de insulina.

Pós-condição R0 é substituído por r1, portanto r1 é substituído por r2.

Efeitos colaterais Nenhum.

REQUISITOS FUNCIONAIS

Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas.

Exemplo:

Identificação Nome Sumário Ator

RF01 Manter

mercadoria

O Gerente de Compras atualiza o cadastro (inclusão,

alteração, exclusão e consulta) das mercadorias.

Gerente de

Compras

RF02 Registrar pedido

de compra

O Caixa registra o pedido de compra do cliente

informando, para cada produto, a sua quantidade.

Caixa

RF03 Cancelar pedido

de compra

O Supervisor cancela um pedido de compra que ainda não

foi entregue, informando o motivo do cancelamento.

Supervisor

RF04 Abrir caixa O Caixa dá início às operações do seu trabalho. Caixa

RF05 Fechar caixa O Caixa encerra as operações do seu trabalho. Caixa

REQUISITOS NÃO-FUNCIONAIS (1/4)

Requisitos

Não

Funcionais

Requisitos

do produto

Requisitos

organizacionais

Requisitos

externos

Requisitos

éticos Requisitos de

interoperabilidade

Requisitos

legais

Requisitos

de segurança Requisitos

de privacidade

Requisitos

de

implementação

Requisitos

de espaço

Requisitos

de

desempenho

Requisitos

de eficiência

Requisitos

de facilidade

de uso

Requisitos

de

confiabilidade

Requisitos

de

portabilidade

Requisitos

de entrega

Requisitos

de padrões

Os requisitos não funcionais

podem ser classificados

segundo a seguinte estrutura

hierárquica

REQUISITOS NÃO-FUNCIONAIS (2/4)

REQUISITOS DO PRODUTO: são os requisitos que especificam o comportamento do produto. Requisitos de facilidades de uso: estabelece o esforço para utilizar,

aprender o produto.

Exemplo: A função de digitação de notas fiscais deve minimizar o uso do mouse a fim de aumentar a produtividade.

Requisitos de espaço: quanto de memória o sistema requer.

Exemplo: O software deve ocupar no máximo “x” de memória para que possa ser executado em tablets.

Requisitos de desempenho: com que rapidez o sistema deve operar.

Exemplo: A consulta ao histórico de pagamentos de um cliente não deve ser superior a 5 segundos.

Requisitos de confiabilidade: estabelecem a taxa aceitável de falhas.

Exemplo: O software deve possuir uma disponibilidade 24x7.

Requisitos de portabilidade: capacidade do produto ser transferido para outros ambientes.

Exemplo: O software deve utilizar linguagem SQL padrão ANSI-92.

REQUISITOS NÃO-FUNCIONAIS (3/4)

REQUISITOS ORGANIZACIONAIS: são procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor.

Requisitos de entrega: especificam quando o produto e seus

documentos devem ser entregues.

Exemplo: O software deve estar em produção até abril de 2016.

Requisitos de implementação: especificam restrições para a implementação.

Exemplo: O software deve ser construído na plataforma J2EE.

Requisitos de padrões: especificam os padrões e métodos que devem ser seguidos para o desenvolvimento do sistema.

Exemplo: Para o desenvolvimento do sistema deve-se utilizar a metodologia SCRUM.

REQUISITOS NÃO-FUNCIONAIS (4/4)

REQUISITOS EXTERNOS: abrange todos os requisitos procedentes de

fatores externos ao sistema e a seu processo de desenvolvimento.

Requisitos de interoperabilidade: definem como o sistema interage com sistemas em outras organizações.

Exemplo: O sistema deve ser capaz de gerar os dados das notas fiscais para exportação para a base de dados do SINTEGRA.*

Requisitos de privacidade: especialização dos requisitos legais.

Exemplo: Os gerentes não podem visualizar a movimentação bancária de clientes VIP que não estejam sob sua responsabilidade.

Requisitos de segurança: especialização dos requisitos legais, que são requisitos que devem ser seguidos para assegurar que o sistema funciona de acordo com a lei.

Exemplo: O acesso aos módulos do software deve ser restrito por grupo de usuários.

Requisitos éticos: definidos para garantir que este será aceitável para seus usuários e o público geral.

Exemplo: O histórico clínico do paciente só deve estar disponível para o médico.

*Sistema Integrado de Informações sobre Operações Interestaduais com Mercadorias e Serviços

http://www.sintegra.gov.br/

ATIVIDADES DA ENGENHARIA DE REQUISITOS

ATIVIDADES DA ENGENHARIA DE REQUISITOS (1/6)

Fonte: CPRE-FL Quick Guide - 2011

ELICITAÇÃO (2/6)

Fontes Principais Stakeholders

Clientes

Usuários

Desenvolvedores

Documentos

Livros

Sistemas de software (específico da organização ou software comercial)

ELICITAÇÃO (3/6)

Métodos de Coleta de Requisitos

Algumas técnicas das ciências sociais, como psicologia e sociologia, têm sido estudadas e utilizadas nesta atividade, que envolve fatores comportamentais e de relacionamento humano.

Entre os métodos mais comuns estão:

• análise de documentos;

• entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas);

• reuniões (Participatory Design, Joint Application Design e Brainstorming);

• observação e etnografia;

• prototipação;

• questionários.

DOCUMENTAÇÃO – ESPECIFICAÇÃO DE REQUISITOS (4/6)

A especificação de requisitos visa descrever de

maneira sistemática quais propriedades o

software terá que ter para resolver o problema do

domínio.

A especificação é também a forma de

comunicação sistemática entre analistas e

projetistas do software.

O documento de especificação de requisitos além

de conter uma parte textual, costuma conter

diagramas que representem determinados

aspectos do sistema de software.

Exemplo de especificação de requisitos: arquivo “Template para especificação de

requisitos - Merci_10_ERSw” Referência: Engenharia de Requisitos, Profª Carmen Asp –

CEFET/RJ

VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS (5/6)

Verificação (definição IEEE)

Confirmar por testes e com provas objetivas que os requisitos especificados foram cumpridos.

Garante que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase ou seja o produto foi construído corretamente.

Validação (definição IEEE)

Confirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridos.

Prova que o software implementa cada um dos requisitos corretamente e completamente ou seja, o produto correto foi construído.

Como obter Verificação e Validação com provas objetivas? TESTES

GERENCIAMENTO DE REQUISITOS (6/6)

O gerenciamento de requisitos é um processo para

compreender e controlar as mudanças dos requisitos.

Durante o processo de desenvolvimento, o

entendimento dos stakeholders sobre o problema muda constantemente.

Após o desenvolvimento do produto, muito

provavelmente, surgirão novos requisitos.

GERENCIAMENTO DE REQUISITOS (6/6)

Rastreabilidade de Requisitos

Existem vários relacionamentos entre os requisitos e entre os

requisitos e o projeto do sistema. Existem também ligações entre requisitos e motivos básicos do por que esses requisitos foram propostos.

Quando as mudanças são propostas, você deve rastrear seu impacto em outros requisitos e no projeto do sistema.

A rastreabilidade é a propriedade de uma especificação de requisitos que reflete a facilidade de encontrar os requisitos relacionados.

A rastreabilidade permite um maior controle sobre os artefatos gerados ao longo do desenvolvimento facilitando sua manutenção e análise de impacto a partir de solicitações de

alteração.

TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS - Levantamento de requisitos orientado a pontos de vista

- Cenários

LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA ()

Para qualquer sistema, normalmente, há diferentes tipos

de usuário final. Por esse motivo, existem muitos pontos de vista diferentes que devem ser considerados.

Os diferentes pontos de vista a respeito de um problema ‘vêem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas

em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns.

As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem esses diferentes

pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os próprios requisitos.

LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA ()

O método VORD (viewpoint-oriented requirements

definition – definição de requisitos orientada a ponto de vista) foi projetado como um framework orientado a serviço para o levantamento e análise de requisitos.

Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.

Envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior.

A etapa de documentação do ponto de vista tem por objetivo refinar a descrição dos pontos de vista e serviços identificados.

Envolve identificar objetos em um projeto orientado a objetos, utilizando as informações de serviço que estão encapsuladas nos pontos de vista.

LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA ()

Exemplo de hierarquia de ponto de vista:

Todos os pontos de vista

Cliente Pessoal do banco

Caixa Gerente Engenheiro

Não-titular da conta

Titular da conta

Serviços Consultar saldo Retirar dinheiro

Serviços Pedir cheques Enviar mensagem Executar transação da lista Pedir extrato Transferir fundos

CENÁRIOS

Cenários são estórias que explicam como um sistema poderá ser usado.

Cada cenário aborda um ou um pequeno número de possíveis interações.

O cenário geralmente começa com um esboço da interação e, durante o levantamento de requisitos, são acrescentados detalhes para criar uma distribuição completa dessa interação.

O cenário pode incluir: uma descrição de estado do sistema no início do cenário; uma descrição do fluxo normal de eventos no cenário; uma distribuição do que pode sair errado e de como lidar

com isso; informações sobre outras atividades que possam estar em

andamento ao mesmo tempo; uma descrição do estado do sistema no final do cenário.

ANÁLISE DE DOCUMENTOS

• A análise de documentos é uma técnica usualmente

aplicada na qual explora-se o conhecimento escrito encontrado no universo de informações.

• A análise dos documentos permite um contato com o

vocabulário utilizado no domínio do problema e auxilia na construção do glossário de termos especializados,

que tem por objetivo definir os objetos e equalizar o conhecimento dos stakeholders.

ENTREVISTAS

Entrevistas tutoriais: o entrevistado fica no comando, praticamente lecionando sobre um determinado assunto.

Entrevistas informais (não estruturadas): o entrevistador age espontaneamente, perguntando ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação.

Entrevistas estruturadas: são preparadas pelo entrevistador, que define previamente o andamento do procedimento de aquisição de conhecimento.

Entrevistas semi-estruturadas: são entrevistas que misturam as características das entrevistas estruturadas e das entrevistas não estruturadas.

Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas, que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material produzido deve ser organizado e serve como base para a preparação da próxima entrevista.

PIECES – TÉCNICA PARA EXTRAÇÃO DE REQUISITOS

P - Desempenho (ou performance): quantidade de tarefas executadas em um intervalo de tempo. Exemplo: Quantos atendimentos são efetuados por dia? Quantos usuários utilizam o sistema por turno? Quantos pedidos são efetuados em uma hora?

I - Informação e Dados: as informações a serem acessadas pelos usuários devem ser exatamente as que eles necessitam. Exemplo: A relação de funcionários da empresa é fornecida em que intervalo de tempo? Todos os dados de cada item do pedido devem constar da nota fiscal?

E - Economia: o nível de serviço e a capacidade de lidar com alta demanda. Exemplo: Você recebe um maior número de pedidos em determinada época do mês ou do ano? Existe um horário em que o registro de reclamações aumenta?

C - Controle: o software é desenvolvido para funcionar de maneira prevista. Exemplo: Todos os usuários têm acesso irrestrito à base de dados do sistema? Aos usuários deverá ser requisitada autorização de acesso?

E - Eficiência: redução da perda de recursos. Exemplo: Todas as funções se utilizarão deste dado? Você vai entrar com esse valor uma única vez?

S - Serviços: um software é desenvolvido para prestar serviços ao usuário ou a outro software. Definir quais são esses serviços. Exemplo: O software emite ordem de serviço ? O software controla o estoque em tempo real?

PARTICIPATORY DESIGN

É uma abordagem que concentra-se mais fortemente no envolvimento dos usuários, em relação ao Joint Application Design,

por facilitar o processo de aprendizado entre desenvolvedores e usuários através de experiências conjuntas em situações de trabalho simuladas.

Em linhas gerais, os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com os usuários em suas

tarefas. Ocorre um aprendizado mútuo que vem a contribuir no processo de definição dos requisitos.

BRAINSTORMING

A filosofia básica do brainstorming é procurar deixar que venham a tona todas as idéias possíveis, sem que estas sofram quaisquer

críticas durante o processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio não-

lógico que estava bloqueado e, quando bem aplicado, seja um poderoso instrumento de trabalho.

Nesta reunião, a característica principal é a total ausência de

crítica e o julgamento adiado. As ideias que surgirem serão anotadas, por mais loucas que possam parecer, e nunca sofrerão críticas na hora em que forem formuladas.

FAST (FACILITATED APPLICATION SPECIFICATION TECHNIQUES)

Estimula a criação de uma equipe conjunta de clientes e desenvolvedores e tem algumas diretrizes:

Encontros em locais neutros

Regras para participação

Agenda formal para cobrir os pontos importantes e informal

para encorajar o fluxo de ideias

Um moderador

Mecanismos de definição

Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas mini especificações.

JAD - JOINT APPLICATION DESIGN

Baseia-se em sessões estruturadas e disciplinadas, onde os envolvidos (representantes de todas as áreas relacionadas com os assuntos em discussão) reúnem-se para desenvolver juntos o sistema de software.

O produto final é um documento que contém definições do produto/software.

É uma abordagem popular da técnica FAST.

JAD - JOINT APPLICATION DESIGN

As regras da sessão:

• Todos os participantes são iguais.

• Apenas uma pessoa fala de cada vez.

• Todas as opiniões são válidas.

• Hora para começar, interromper e terminar.

• Celular desligado.

• Recursos visuais.

PROTOTIPAÇÃO

A prototipação é uma técnica valiosa para se obter

rapidamente informações específicas sobre requisitos de informação do usuário.

Protótipo é um produto que...

– não tem tempo de vida definido;

– pode servir a múltiplos propósitos;

– deve ser construído rapidamente e com baixo custo;

– é parte integrante de um design centrado no usuário, para avaliação e modificação.

Avaliar protótipo

- Usuário -

Definir objetivos e requisitos de informação

Construir/Revisar protótipo

PROTOTIPAÇÃO

A prototipação permite capturar os seguintes tipos de

informação:

Reações iniciais do usuário: como o usuário se sente em

relação ao sistema em desenvolvimento?

Obs.: Reações ao protótipo podem ser obtidas através da observação, entrevistas, questionário ou relatório de avaliação.

Sugestões do usuário para refinar ou alterar o protótipo: guiam na direção de melhor atender as necessidades dos usuários.

Inovações: novas capacidades, não imaginadas antes da interação com o protótipo.

Informações para revisão de planos: estabelecer prioridades e

redirecionar planos.

QUESTIONÁRIO

Deve ser preparado antecipadamente com questões objetivas (múltipla escolha).

A desvantagem deste modelo em relação a Entrevista é a comunicação restrita com o usuário.

A preparação do questionário exige tempo e atenção. Perguntas mal feitas podem levar a resultados não desejados.

Utilização conjunta de Questionários e Entrevistas

Refinar respostas não claras de um questionário em uma entrevista;

Projetar um questionário com base no que foi levantado em uma entrevista.

TÉCNICA DE OBSERVAÇÃO

Observação é uma técnica na qual o engenheiro de requisitos procura ter uma posição sobre o domínio do problema, observando seus elementos e comportamentos.

As observações consistem em observar alguém no momento da realização de suas tarefas rotineiras no ambiente real.

O observador procura familiarizar-se com o domínio do problema e elicitar as informações necessárias para o seu entendimento.

A aquisição desse conhecimento pode ocorrer com interrupção ou não das atividades do observador.

ETNOGRAFIA

Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos observados, por uma impregnação duradoura e contínua e um processo que se realiza por aproximações sucessivas.

É originária da antropologia, em observações de práticas das sociedades.

No contexto da engenharia de requisitos, é uma técnica de observação que busca revelar informações sobre a estrutura, organização e práticas do domínio do problema.

A etnografia pode levar a obtenção de requisitos fechados à prática corrente, o conhecimento tácito.

REFERÊNCIA

Carmen Asp de Queiroz. Engenharia de Requisitos. CEFET-RJ. 2016.

SOMMERVILLE, Ian, Engenharia de Software, 9a edição, São Paulo: Pearson Education – Addison-Wesley, 2011.