engenharia de software - campus universitário do...

Engenharia de Software

Engenharia de Software 2012/3Aula 4 – Engenharia de Requisitos

Thiago P. da [email protected]

02/05/13 2

Agenda

● Engenharia de Requisitos

● Níveis de Descrição dos Requisitos

● Tipos de Requisitos

– Requisitos Funcionais

– Requisitos Não Funcionais● Documento de Requisitos de Software (ERS)

● Processos de Engenharia de Requisitos

● Gerenciamento de Requisitos

02/05/13 3

Objetivos da Aula

● Compreender os conceitos de requisitos de usuário e de sistema;

● Compreender a diferença entre requisitos de software funcionais e não funcionais;

● Entender a organização dos requisitos em um documento de requisitos de software (ERS)

● Compreender as principais atividades de elicitação, análise e validação da engenharia de requisitos;

● Entender a importância do gerenciamento de requisitos.

02/05/13 4

Requisitos de Software

● Requisitos de um sistema são declarações do que o sistema deve fazer, os serviços e as restrições a seu funcionamento

– Refletem a necessidade dos clientes● Existem níveis de descrição e detalhamento dos requisitos

– Comunicam informações sobre o sistema para diferentes tipos de leitor

– Os clientes não sabem detalhes técnicos, mas os desenvolvedores necessitam destes detalhes

● Requisitos devem definir as necessidades do sistema de uma forma abstrata de tal forma que não deixe a solução pré-definida

● Podem ser parte do contrato

02/05/13 5

Engenharia de Requisitos

● Engenharia de Requisitos

– É o processo de descobrir, analisar, documentar e verificar os serviços e restrições do sistema

– Faz parte do processo de especificação do sistema, comum a qualquer processo de software

– Nos processo de software tradicionais existem uma fase da engenharia de requisitos claramente identificável antes de se iniciar a implementação do sistema

– Nas abordagens ágeis, simultaneamente são elicitados os requisitos enquanto a sistema é desenvolvido

● Raramente são utilizados para grandes sistemas

02/05/13 6

Níveis de Detalhamento dos Requisitos

● Requisitos de Usuário

– Expressam os requisitos abstratos de alto nível

– Usam linguagem natural com diagramas, de quais serviços o sistema deverá fornecer e as suas restrições

● Requisitos de Sistema

– Declarações mais detalhadas do que o sistema deve fazer, serviços e restrições operacionais

– Deve definir exatamente o que deve ser implementado

02/05/13 7

Níveis de Detalhamento dos Requisitos

● Requisitos de Usuário não se importam como será implementado. Interessados com as Funcionalidades

● Requisitos de Sistema ditam como será implementado. Interessados com os Detalhamentos

02/05/13 8

Requisitos Funcionais

● Descrevem o que o sistema deve fazer

● Quando expressos como requisitos de usuário, são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema

● Requisitos de sistema funcionais descrevem em detalhes as funções do sistema, suas entradas e saídas

● A especificação dos requisitos funcionais de um sistema deve ser completa e consistente

– Todos os serviços requeridos pelo cliente devem ser definidos

– Os requisitos não devem ter definições contraditórias● A imprecisão na especificação dos requisitos é a causa de muitos

problemas na engenharia de software

02/05/13 9

Tipos de Requisitos

● Requisitos Funcionais

– Declarações de serviços que o sistema de fornecer, de como deve reagir a entradas específicas e se comportar em determinadas situações

– Podem também explicitar o que o sistema não deve fazer● Requisitos Não Funcionais

– Restrições aos serviços ou funções oferecidas pelo sistema

– As vezes atingem todo o sistema. Exemplo: segurança● A distinção entre os tipos de requisitos não é tão clara

– Exemplo: Um requisito de usuário relacionado a proteção pode gerar outros requisitos, claramente funcionais, como a necessidade de incluir recursos de autenticação de usuário

● Requisitos não são independentes

– Podem gerar outros requisitos ou até mesmo restringir outros requisitos

02/05/13 10


● Descrevem o que o sistema deve fazer

● Quando expressos como requisitos de usuário, são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema

● Requisitos de sistema funcionais descrevem em detalhes as funções do sistema, suas entradas e saídas

● A especificação dos requisitos funcionais de um sistema deve ser completa e consistente (é possível?)

– Todos os serviços requeridos pelo cliente devem ser definidos

– Os requisitos não devem ter definições contraditórias● A imprecisão na especificação dos requisitos é a causa de muitos

problemas na engenharia de software

02/05/13 11


● Exemplos de Requisitos Funcionais:

– Todos os usuários do sistema devem ser identificados apenas pelo seu número de CPF

– O sistema deve gerar relatórios diários sobre a quantidade de acessos à porta 2222

– O sistema deve importar dados do calendário no formato CVS

02/05/13 12

Requisitos Não Funcionais

● São requisitos que não estão diretamente relacionados com os serviços específicos oferecidos pelo sistema e seus usuários

● Atributos de qualidade do sistema

● Propriedades emergentes do sistema (Surgem quanto os subsistemas ou componentes estiverem integrados)

– Confiabilidade

– Tempo de resposta

– Usabilidade● Restrições sobre a implementação do sistema

– Tipo de IDE

– Tipos de dispositivos

– Linguagem de programação/Arquitetura

– Tipos de dados

– Processo de Software

02/05/13 13


● São mais críticos que os requisitos funcionais, pois se não forem atendidos talvez o sistema seja inútil

– Exemplos● Sistema de aeronaves não cumpre requisito de

confiabilidade. Logo não será homologado● Sistema do freio ABS não cumpre requisito de

desempenho. Poderá provocar acidentes.● Tipicamente é difícil relacionar os componentes do

sistema com os requisitos não funcionais

– Requisitos Não Funcionais podem afetar toda arquitetura

– Um único requisito funcional pode gerar uma série de requisitos funcionais relacionados

02/05/13 14


● Surgem de Necessidades dos usuário:

– Devido a restrições de orçamento

– Políticas organizacionais

– Necessidade de interoperabilidade com outros sistemas ou hardware

– Fatores externos● Reguladores de segurança● Legislação de privacidade

02/05/13 15


Classificação de Requisitos Não Funcionais

02/05/13 16



02/05/13 17



– Requisitos de Produto● Especificam e restringem o comportamento do software

– portabilidade, confiança, disponibilidade, eficiência, proteção, etc

● Exemplos:– O sistema terá disponibilidade de 98%– O sistema processará 23 transações por segundo.– O sistema deve ser implementado usando as tecnologias

JavaEE– O sistema será instalado no servidor de aplicação JBoss

02/05/13 18



02/05/13 19


Classificação de Requisitos Não Funcionais(continuação)

– Requisitos Organizacionais● Derivados de políticas e procedimentos da

organização do cliente e do desenvolvedor– padrões, ISOS, ambientais (S.O.) e infraestrutura

● Exemplos:– O processo de desenvolvimento deve ser ágil– A ferramenta Eclipse de ser usada para apoiar o

processo de desenvolvimento– O processo de desenvolvimento deve ser definido

conforme o padrão ISO 9000

02/05/13 20



02/05/13 21


Classificação de Requisitos Não Funcionais(continuação)

– Requisitos Externos● Fatores externos ao sistema e seu processo de

desenvolvimento– requisitos de interoperabilidade, legislação, direitos

autorais e localização geográfica (País)● Exemplos:

– O layout do sistema deve seguir a política de marcas da empresa

– Os relatórios gerados pelo sistema devem estar em conformidade com o padrão XYZ

– Conformidade com as resoluções da UFMT

02/05/13 22


● Requisitos Não Funcionais devem ser testáveis e precisos

– Evitar usar metas gerais como nos requisitos não funcionais, por exemplo:

● O sistema deve ser de fácil uso pelo cliente– Devem ser escritos quantitativamente, para que

possam ser testados● Métricas podem ser usadas para especificar as

propriedades não funcionais do sistema

02/05/13 23


Métricas para especificar requisitos não funcionais

Propriedade MétricaDesempenho • transações processadas por segundo

• tempo de resposta para entrada do usuárioConfiança • taxa de ocorrência de falha

• tempo médio de falhaDisponibilidade • probabilidade de falha na demandaTamanho • kbytesUsabilidade • tempo necessário para aprender 80% das

facilidades• número de erros cometidos pelo usuário

num dado período de tempoRobustez • tempo para reiniciar após uma falha no

sistemaPortabilidade • número de sistemas alvo

02/05/13 24


Problemas na especificação dos requisitos não funcionais

– Compreensão, Clareza e Ambiguidade● Podem ser expressos com linguagem do domínio da

aplicação● Não necessariamente os engenheiros de software e

desenvolvedores entenderão● Língua portuguese é ambígua

– Conhecimento Implícito● Talvez o especialista do domínio se esqueça de deixar

claro alguns conceitos e requisitos de domínio

02/05/13 25

Documento de Requisitos de Software

Especificação de Requisitos de Software (ERS)

● É uma declaração oficial de que os desenvolvedores do sistema devem implementar.

● Inclui os requisitos de usuário e de sistema.

● Não é um documento de projeto/design.

● Diz o que será o software

● Tem um conjunto diversificado de usuários:

– Desenvolvedores

– Clientes

– Administradores

02/05/13 26


Usuários do ERS

02/05/13 27


Usuários do ERS

● Clientes do Sistema

– Especificam os requisitos e os leem para checar se eles satisfazem suas necessidades

● Gerentes de Projeto

– Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema

02/05/13 28


Usuários do ERS

● Engenheiros de Sistema

– Usam os requisitos para entenderem o sistema em construção

● Engenheiros de Teste

– Usam os requisitos para desenvolverem testes de validação do sistema

● Engenheiros de Manutenção de Sistema

– Usam os requisitos para entenderem o sistema e o relacionamento entre suas partes

02/05/13 29


● Para a maioria dos métodos ágeis, produzir documento de requisitos é perca de tempo

– Eles alegam que os Requisitos mudam constantemente

– O documento sempre estará desatualizado● XP utiliza engenharia de requisitos incremental

– Expressa os requisitos como “Estórias de usuário”

– A cada iteração um subconjunto de requisitos é elicitado● Mas para alguns tipos de sistemas como, por exemplo,

sistemas críticos, torna-se necessário ter elicitados todos os requisitos antes do desenvolvimento

02/05/13 30


● 40% dos erros do sistema, deve-se as especificação mal feita [2]

02/05/13 31


Organização de um documento de requisitos

● Padrão IEEE/ANSI 830-1993 apresenta uma estrutura para o documento de requisitos

– Introdução● 1.1 Propósito do documento de Requisitos● 1.2 Escopo do produto● 1.3 Definições, acrônimos e abreviações● 1.4 Referencias● 1.5 Resumo do resto do documento

– 2. Descrição Geral● 2.1 Perspectiva do produto● 2.2 Funções do produto● 2.3 Características do usuário● 2.4 Limitações gerais● 2.5 Suposições e dependências

– 3. Requisitos específicos● Cobrem requisitos funcionais, não-funcionais e Interface

– 4. Apêndices

– Índice

02/05/13 32


Organização de um documento de requisitos

● Padrão IEEE/ANSI 830-1993 é genérico

– Certas partes talvez não são necessárias para o documento de requisitos

● Qualquer pessoa/empresa pode criar o seu modelo

● Tipos diferentes de sistemas requerem níveis de detalhamento em suas especificações diferentes

● Pode-se usar a linguagem natural para especificação de requisitos ou templates, que representam os requisitos como formulários estruturados

– Poema, verso, cartões de papel, etc.

02/05/13 33


● Prática

– Leitura da IEEE/ANSI 830-1993

02/05/13 34

Processos de Engenharia de Requisitos

● Os processos de Engenharia de Requisitos possuem quatro atividades genéricas:

– Avaliar se o sistema é útil (estudo de viabilidade)

– Descobrir requisitos (elicitação e análise de requisitos)

– Converter os requisitos em uma forma padrão (especificação de requisitos)

– Verificar se os requisitos definem o sistema (validação de requisitos)

● Gerenciamento de Requisitos também é necessário!

– Inevitavelmente os requisitos mudam

– Mas será que todas as empresas gerenciam os requisitos?

02/05/13 35


Modelo Conceitual (Esta é uma visão tradicional)

– Não necessariamente é assim!!!

– Na prática a engenharia de requisitos é um processo iterativo em que as atividades são intercalados (não sequenciais)

Estudode Viabilidade

Elicitação e Análisede Requisitos Especificação

de requisitosValidação

de requisitos

Relatório deViabilidade

Modelosde Sistema

Requisitos deUsuário e Sistema

ERS

02/05/13 36


Visão em Espiral dos processos de engenharia de requisitos

02/05/13 37



– No início do processo (anéis internos) deve-se compreender:● os requisitos de negócio● requisitos não funcionais em alto nível● requisitos de usuário (conhecimento do domínio)

– Depois (anéis externos)● elicitar e compreender os requisitos de sistema em detalhes

– O número de iterações em torno da espiral varia de acordo:● nível de detalhamento desejado● tipo de software● Modelo de Processo de software adotado

02/05/13 38



02/05/13 39


Elicitação e Análise de requisitos

– Após um estudo inicial de viabilidade

– Obtenção de informações sobre o domínio da aplicação, os serviços, desempenho, restrições de hardware, etc.

– As fontes destas informações são diversas● stakeholders● Manuais, especificações e normas● Sistemas semelhantes

– É um processo contínuo, com feedback contínuo de cada atividade para outras atividades

02/05/13 40


Problemas inerentes da elicitação de requisitos

– Stakeholders não sabem realmente o que querem

– Stakeholders expressam requisitos com seus termos (linguagem)

– Diferentes Stakeholders terão requisitos conflitantes

– Fatores organizacionais e políticos podem influenciar os requisitos do sistema

– Os requisitos mudam durante o processo de análise

02/05/13 41


Modelo para processo de Elicitação e Análise de Requisitos

02/05/13 42


Modelo para processo de Elicitação e Análise de Requisitos

– 1 - Descoberta de requisitos – Elicitar requisitos, reunir informações sobre o sistema. Existem várias fontes e técnicas para descoberta de requisitos.

– 2 - Classificação e Organização de requisitos – Agrupamento de requisitos relacionados.

– 3 - Priorização e negociação de requisitos – priorizar requisitos e resolver conflitos.

– 4 - Especificação de requisitos – Documentos formais.

02/05/13 43


Descobrir os Requisitos

– Obtenção de informações sobre o domínio da aplicação, os serviços e restrições do sistema

– As fontes de informação incluem:● Documentação● Stakeholders● especificações de sistemas similares● Protótipos também podem ser usados tanto para descobrir quanto para

validar requisitos– Como obter tais informações?

● Entrevistas● Cenários (formato de texto, tabelas e/ou diagramas)● Casos de Uso● Etnografia (observação)

02/05/13 44


Exemplo de stakeholders para supermercado

– Cliente do supermercado

– Representantes comerciais de produtos

– Dono do estabelecimento

– Caixas do supermercado

– Empacotadores

– Administradores

– Departamento de marketing, vendas, etc

– Fiscais

– Distribuidores

– Etc

02/05/13 45


Como Descobrir os Requisitos

EntrevistasEntrevistas● Formais ou informais● Entrevistas fechadas com uma lista predeterminada de questões● Entrevistas abertas onde várias questões são exploradas

– As perguntas estão relacionadas ao sistema atual em uso e o sistema a ser desenvolvido

– Normalmente se usa uma mistura de entrevista fechada e aberta

– Entrevistas são boas para obtenção de um entendimento geral do que os stakeholders fazem e como eles podem interagir com o sistema

02/05/13 46



EntrevistasEntrevistas– Entretanto, não são boas para elicitar o conhecimento do domínio

● Os engenheiros de requisitos podem não entender a terminologia específica de domínio

● Alguns conhecimentos de domínio são tão especificos que as pessoas acham difícil explicar ou pensam que não vale a pena mencioná-los

– Também não são uma técnica eficaz para elicitação do conhecimento sobre requisitos e restrições organizacionais

● Relações de poder● Estrutura organizacional não corresponde á realidade

02/05/13 47



EntrevistasEntrevistas– Características dos entrevistadores eficazes

● Abertura a novas ideias● Estimular o entrevistado a participar de discussões

– As entrevistas podem deixar escapar informações essenciais● Desta forma necessitam ser usadas juntamente com

outras técnicas

02/05/13 48



CenáriosCenários– São exemplos do mundo real de como o sistema pode ser usado

– Devem incluir:● Uma descrição do que o sistema e usuário esperam quando o cenário iniciar● Descrição do fluxo normal de eventos e como é tratado● Descrição do fluxo excepcional (quando ocorre erro)● Informações sobre atividades concorrentes● Uma descrição do estado do sistema quando o cenário acaba

– Podem ser escritos como texto, suplementados por diagramas e telas

– Estórias usadas no Extreme Programming são exemplos de cenário de requisitos

– Podem ser usado protótipos de GUI para sistemas interativos

02/05/13 49



CenáriosCenários● Exemplo no material impresso!

02/05/13 50



Casos de UsoCasos de Uso– São cenários baseados na UML que identificam as

interações no sistema

– Um conjunto de casos de uso podem descrever todas as interações com o sistema

– Cenários e casos de uso não são eficazes para elicitar restrições ou requisitos de negócio e não funcionais ou para descobrir requisitos de domínio

02/05/13 51



Casos de UsoCasos de Uso● Exemplo no material impresso!

02/05/13 52



EtnografiaEtnografia– Técnica de observação para compreender os

processos operacionais (funcionamento da empresa) e extrair os requisitos que apoiam esse processos

– Observação do trabalho do dia a dia e anotações sobre as tarefas reais em que os participantes estão envolvidos

– O observador é inserido na organização e as pessoas não precisam explicar seu trabalho

– Fatores sociais e organizacionais de importância podem ser observados

02/05/13 53



EtnografiaEtnografia– São requisitos originados a partir do modo como as

pessoas realmente trabalham● Maneira como realmente as pessoas trabalham e

não como as definições dos processos dizem.● Cooperação e conhecimento das atividades de

outras pessoas– Não é boa para descobrir novos requisitos

02/05/13 54



02/05/13 55


Especificação de Requisitos

– Escrever os requisitos de usuário e de sistema em um documento

– Os requisitos de usuário devem descrever os requisitos funcionais e não funcionais de modo que sejam compreensíveis para usuários que não tenham conhecimento técnico detalhado

– Os requisitos de sistema são mais detalhados e incluem mais informações técnicas

– Os requisitos podem ser parte do contrato de desenvolvimento do sistema

● Idealmente o documento de requisitos não deve possuir detalhes da arquitetura ou projeto do sistema

● Evitar usar jargões de software

02/05/13 56



– Os requisitos devem estabelecer o que o sistema deve fazer e o projeto/design descrevo como fazer

– Na prática, requisitos e projeto são inseparáveis● A arquitetura do sistema é projetada para suportar os

requisitos● O sistema deve interoperar com outros sistemas

que podem gerar requisitos de projeto (não funcionais)● O uso de uma arquitetura específica para satisfazer

requisitos não funcionais pode ser necessário

02/05/13 57



– Especificação em linguagem naturalEspecificação em linguagem natural● Texto com apoio de diagramas e tabelas● Expressivo, intuitivo e universal● Pode ser entendido pelo cliente e desenvolvedores

facilmente● Entretanto:

– Precisão é difícil– Difícil organização– Diferentes requisitos podem ser expressos em uma

única sentença

02/05/13 58



– Especificação em linguagem natural (Exemplo)Especificação em linguagem natural (Exemplo)● Req 1 – O sistema deve medir o açúcar no sangue e

fornecer insulina, se necessário, a cada dez minutos.● Req 2 – O sistema, deve a cada dez minutos, realizar

a rotina de autoteste com as condições a serem testadas e as ações associadas definidas na Tabela 5.2.

02/05/13 59



– Especificação estruturadaEspecificação estruturada● A liberdade do escritor é limitada e os requisitos são

escritos de uma forma padronizada● Garante certa uniformidade sobre a especificação● Faz uso de templates para representar os requisitos

como formulários estruturados

02/05/13 60



– Especificação estruturadaEspecificação estruturada● Estrutura de um formulários

– Descrição da funcionalidade– Entradas e de onde vieram– Saídas e para onde irão– Informação necessário para o processamento– Descrição da ação a ser tomada– Pré e pós condições (se aplicável)– Efeitos colaterais da função (se aplicável)

02/05/13 61



– Especificação estruturadaEspecificação estruturada (Exemplo) (Exemplo)

02/05/13 62



– Especificação estruturadaEspecificação estruturada (Exemplo) (Exemplo)

02/05/13 63



02/05/13 64


Validação de Requisitos

– Verifica se os requisitos definem o sistema que o cliente realmente quer

– Os custos de requisitos errados são altos● Arrumar um requisito errôneo depois da liberação do

sistema pode custar 100 vezes o preço de se arrumar um erro de implementação.

– Diferentes tipos de verificação devem ser efetuados com os requisitos

02/05/13 65



– Tipos de Verificação● Verificação de Validade – O sistema provê as

funcionalidades que melhor atendem a necessidade dos clientes?

● Verificação de Consistência – Existem requisitos conflitantes?

● Verificação de Completude – Todas as funções requeridas pelo cliente estão inclusas?

● Verificação de Realismo – Os requisitos podem ser implementados de acordo com a tecnologia atual?

● Verificabilidade – Os requisitos podem ser conferidos?

02/05/13 66



– Técnicas de Verificação● Revisões de Requisitos – Os requisitos são

analisados de forma manual e sistemática● Prototipação – Uso de versões funcionais do sistema

para verificar os requisitos● Geração de Caso de Testes – Desenvolver testes

para os requisitos. Se os testes falharem, então provavelmente os requisitos estão errados

02/05/13 67

Gerenciamento de Requisitos

● É um processo para compreender e controlar as mudanças de requisitos

● Requisitos são, inevitavelmente, incompletos e inconsistentes

– Novos requisitos surgem durante o processo inteiro

– Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios

● Diferentes stakeholders atribuem diferentes prioridades para os mesmos requisitos

● Os ambientes técnico e de negócio do sistema mudam durante seu desenvolvimento

– Novos requisitos surgem

02/05/13 68


● É necessário manter a rastreabilidade dos requisitos

● Associar via links os requisitos dependentes

● O gerenciamento de requisitos necessita de apoio automatizado

02/05/13 69


Estabelecer decisões de gerenciamento

– Identificar os requisitos - unicamente

– Definir processo de gerenciamento de de mudanças – avaliar o impacto e custos da mudança

– Política de Rastreabilidade - relacionamento entre cada requisito

– Ferramenta de Apoio● Armazenar os requisitos● Gerenciar mudanças● Gerenciar rastreabilidade

02/05/13 70


Gerenciamento de Mudança de Requisitos (decidir se aceita ou não uma mudança)

– Deve ser aplicado a todas as mudanças propostas aos requisitos

– Estágios principais:● Análise de problema - discutir problemas e mudanças

de requisitos● Análise de mudança e estimativa de custo - avaliar

os efeitos das mudanças sobre outros requisitos● Implementação de mudança - Modificar vários

artefatos para refletir as mudanças

02/05/13 71

Referências

engenharia de software - campus universitário do...

Documents