Engenharia de Requisitos: Por quê?

(1)

Engenharia de Requisitos:

Por quê?

Julio Cesar Sampaio do Prado Leite

(2)

Software

É

Um Produto

(3)

(4)

Por quê?

● artificial, aberto, abstrato

● “facilidade” de re-escrita

● o mundo muda

● o hardware é “difícil de mudar”

● permite “rápida” diferenciação

● muda o “mundo”

(5)

Estratégias Para Lidar Com a Mutabilidade

● Olhar para o futuro

● Construir orientado para mudar

○ Generalizar ○ Simplificar ○ Modularizar

● Tratar o re-trabalho a cada passo

● Engenharia Concorrente

(6)

O que é Engenharia de Requisitos?

A Engenharia de Requisitos, uma sub-área da

Engenharia de Software, estuda o processo de

definição dos requisitos que o software deverá

atender. A área surgiu em 1993 com a realização do I

International Symposium on Requirements

Engineering. O processo de definição de requisitos é

uma interface entre os desejos e necessidades dos

clientes e a posterior implementação desses

(7)

Por quê?

Por que os requisitos são

importantes? São várias as razões,

mas: a mais evidente é:

porque não se pode construir nada,

sem que antes saiba-se o que se quer

(8)

Requisitos

● Sempre Existem

● Podem ter graus de transparência (explícitos,

implícitos)

● Para explicitá-los, torná-los transparentes, há a

necessidade da Engenharia de Requisitos.

● Requisitos são construídos

● Requisitos mudam

● Confusão

de

necessidades/conhecimento

contextual

(9)

Requisitos (Engenharia)

Entender as necessidades e atender os desejos dos clientes sempre foi colocado como um dos maiores desafios da Engenharia de Software. A postura da Engenharia de Requisitos é a de prover ao Engenheiro de Software, métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o software deve atender. Diferentemente de outras sub-áreas da engenharia de software, a área de requisitos tem que lidar com

conhecimento interdisciplinar envolvendo,muitas vezes,

aspectos de ciências sociais e ciência cognitiva.

(10)

Definições

Universo de Fatos (Universe of Discourse)

É o contexto no qual o software deverá ser

desenvolvido e operado. O UdI inclui todas as fontes de fatos e todos os atores relacionadas ao software. O UdF é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software.

(11)

Definições

A engenharia de requisitos estabelece o processo de

definição de requisitos como um processo no qual o que

deve ser feito deve ser elicitado,

modelado

,

analisado

e

gerenciado

. Este processo deve lidar com

diferentes

pontos de vista,

e usar uma combinação de métodos,

ferramentas e pessoal. O produto desse processo são

modelos, dos quais um documento chamado requisitos é

produzido. Este processo é perene e acontece num

contexto previamente definido a que chamamos de

Universo de Fatos.

E

M

A

(12)

Engenharia

Concorrente

(13)

(14)

A Ponte entre Dois Mundos

Mundo dos clientes e usuários

Mundo dos de-senvolvedores Solicitações (quem, quando, prioridade,…) Requisitos (qual, atende a, quando, por quem, …) Operações Desenvolvimento Mudanças (qual, atende a, porque, …) Gerência de Configuração

(15)

Requisitos (Contexto)

2014

● A ilusão da página em branco

● A ilusão da completeza

● A definição de um sistema é função do desenho/implementação do

macrosistema

● A distância entre solicitações de clientes e requisitos de software

● A constante evolução das solicitações (pressão do mercado)

(16)

Atores

2014

● Usuários (Operadores, Clientes)

● Clientes ( Investidor, Dono, Especialista,

Parceiro)

● Desenvolvedores (Controle de Qualidade,

Engenheiros de Software, Escritores Técnicos,

Fornecedores)

● Sociedade (Governo (Leis, Normas), Código de

(17)

Construir Requisitos

● Requisitos são construídos, por isso: Engenharia de Requisitos

● Requisitos podem ser inventados, mas geralmente refletem

desejo/necessidades/obrigações de um contexto social

● Requisitos é uma classe de artefatos imprescindível para produção de

software de qualidade

(18)

Modelar

/ Artefatos

Requisitos Nome Sintaxe Semântic a Tamanho Criar Apagar Editar Recuperar … Fontes de Informação Sentenças de Requisitos Grafo de Metas Flexíveis Casos de Uso i* LAL _MER

(19)

É fácil?

● Falácia da Completeza

● Conhecimento Tácito

● Falácia da Página em Branco

● Essencial vs Acidental (“…building software will always be hard. There is

inherently no silver bullet.” Fred Brooks)

(20)

Elicitar

● Identificar Fontes

• Leitura de Documentos (Mineração de Textos)

• Observação

• Entrevistas

• Questionários

• Análise de Protocolos

• Participação Ativa dos Atores (Clientes)

• Enfoque Antropológico

• Reuniões

• Reutilização

(21)

Problema Básico

● Existe um problema básico na filosofia de

construção de software.

● Esse problema está relacionado com a divisão de

trabalho na construção de software

○ Quem constrói, pouco conhece o que deve ser construído

○ Para quem se constrói tinha pouco conhecimento do que poderia ser construído

(22)

Consequências

● Métodos foram criados para tratar do “pouco

conhecimento”, ou seja para responder ao “O que

é”, ao que faz.

● O “pouco conhecimento” sobre as possibilidades do

produto

levam

a

pouca expectativa

de suas

qualidades.

● Sendo um produto cameleão,

o importante era

saber o que o software deveria fazer, ao contrário

de outros produtos mais tradicionais onde o

importante é saber que qualidades irá ter.

(23)

Resultado

● A maioria de métodos de construção dão prioridade

a perspectiva funcional

● Requisitos

de

software

são

ancorados

em

funcionalidade

● A representação se torna plana, apenas uma

dimensão.

● Isso acarreta o que foi percebido por Gregor

Kiczales, entre outros, na proposta de Programação

Orientada à Aspectos.

(24)

Do que Estamos Falando?

Suponha o seguinte:

Uma loja, especializada em idosos,

deseja cadastrar seus clientes

…

(25)

novocliente Cliente Cadastrar clientecadastrado

…

Cadastrar

Artefatos

DFD

Caso de Uso

(26)

Artefato

(27)

Qualidade de Software – A Taxonomia de Peter Freeman

basic quality

○

functionality

,

○

reliability,

○

ease of use,

○

economy and

○

safety

extra quality

○

flexibility,

○

reparability,

○

adaptability,

○

understandability,

○

documentation and

(28)

Qualidade em Primeiro Lugar (Quality is Job One)

● Vários depoimentos sobre problemas de software apontam para a falta de

atenção em lidar com aspectos de qualidade.

● O estudo do Caso da Ambulância de Londres é típico. Vários problemas

podem ser rastreados para a falta de consideração com qualidade em

tempo de planejamento.

(29)

Fato

Requisitos de qualidade podem ser entendidos como

metas a serem alcançadas, mas que são satisfeitas a

(30)

Fato

(31)

Fato

Requisitos de qualidade, quando implementados

tornam-se características transversais

(32)

Por que Requisitos Não Funcionais?

● Qualidade é o que diferencia

● Qualidade é o determinante para decisões de desenho

● Qualidades são tácitas

● Qualidades são tanto do/no produto como dos artefatos do processo de

produção

(33)

Qualidade é o determinante para decisões de desenho

(Variabilidade)

(34)

Qualidade dos Artefatos

● Os requisitos devem ser fáceis de entender (entendimento)

● Os requisitos devem ser verdadeiros (confiança)

● Os requisitos devem ser rastreáveis (rastreabilidade)

● O desenho deve ser modular (modularidade)

● O código deve ser padronizado (padronização)

(35)

O humano como

tomador de decisão.

O humano pode ser

um mecanismo da

verificação

(36)

Verificação

através da

Inspeção de

(37)

Gerenciar

● Atividades (Organizar, Planejar, Dirigir, Controlar)

● PDCA

● Retroalimentação

entrada saída

retroalimentação Sistema

(38)

Gerência Técnica vs Gerência Tradicional

● Técnica

○ Triângulo do Conhecimento aplicado a aconselhamento ○ Indicação de melhores caminhos

○ Discutir prós e contras das decisões de desenho

● Tradicional

○ quando ○ quem ○ onde

(39)

Exemplo: Uma Equipe de Requisitos

Req. Engineer Req. Building Team Builder member is part of Auditor Team Auditor Req. Elicitor Req.