ES1 04 Requisitos de Software

Engenharia de Software 1

04 - Requisitos de software

Alexandre de Andrade Barbosa

[email protected]

Objetivos

Objetivos

Apresentar os conceitos de requisitos de usu´

ario e de sistema

Descrever requisitos funcionais e n˜

ao funcionais

Compreender as principais atividades da engenharia de requisitos

Conhecer algumas t´

ecnicas para elicita¸

c˜

ao e especifica¸

c˜

ao de requisitos

Compreender a necessidade e importˆ

ancia da valida¸

c˜

ao e gerenciamento de requisitos

Explicar como os requisitos de software podem ser organizados em um documento

de requisitos

Aquilo que vocˆe desejava

“ontem” ´e o mesmo que vocˆe

Introdu¸c˜

ao

A compreeens˜

ao e a especifica¸

c˜

ao de requisitos ´

e um dos

principais problemas da ES

Os requisitos s˜

ao influenciados:

por preferˆ

encias, recusas e preconceitos dos usu´

arios;

por quest˜

oes pol´ıticas e organizacionais.

Engenharia de requisitos. Processo de estabelecer os servi¸

cos que

o cliente requer a partir de um sistema e as restri¸

c˜

oes sob as

quais ele opera e ´

e desenvolvido

O que ´

e um requisito?

Pode variar entre:

uma declara¸

c˜

ao abstrata de alto n´ıvel de um servi¸

co ou de uma

restri¸

c˜

ao de sistema

uma especifica¸

c˜

ao matem´

atica funcional

De maneira simples...

Os requisitos correspondem a descri¸

c˜

ao daquilo que o cliente

espera para o software

Requisitos de usu´

ario

Declara¸

c˜

oes em linguagem natural, diagramas dos servi¸

cos que o

sistema fornece e suas restri¸

c˜

oes operacionais

S˜

ao escritos para os clientes

Requisitos de sistema

descri¸

c˜

oes detalhadas das fun¸

c˜

oes, servi¸

cos e restri¸

c˜

oes

operacionais do sistema

define o que ser´

a implementado

Requisitos funcionais e n˜

ao funcionais

Requisitos funcionais

servi¸

cos que o sistema deve fornecer

como o sistema deve reagir a entradas espec´ıficas

como o sistema deve se comportar em determinadas situa¸

c˜

oes

Requisitos n˜

ao funcionais

restri¸

c˜

oes sobre servi¸

cos ou fun¸

c˜

oes oferecidos pelo sistema

Requisitos de dom´ınio

relacionados ao dom´ınio de aplica¸

c˜

ao do sistema e que refletem as

caracter´ısticas desse dom´ınio

Exerc´ıcio

Forne¸

ca um exemplo para cada um dos tipos de requisito identificando o sistema ao

qual este requisito pertence.

Requisitos funcionais

Requisitos n˜

ao

funcio-nais

Exerc´ıcio

Forne¸

ca um exemplo para cada um dos tipos de requisito identificando o sistema ao

qual este requisito pertence.

Requisitos funcionais

Requisitos n˜

ao

funcio-nais

Requisitos de dom´ınio

Realizar matricula

Linguagem C++

M´

edia = (AB1+AB2)/2

Inserir nota

Respostas r´

apidas

Descrevem as funcionalidades ou servi¸cos de sistema

Dependem de alguns elementos:

tipo de software;

usu´

arios esperados;

ambiente onde o software ´

e usado.

Requisitos funcionais do usu´

ario podem ser declara¸

c˜

oes de alto

n´ıvel

Requisitos funcionais do sistema devem descrever os servi¸

cos do

Requisitos funcionais: Imprecis˜

ao

Problemas surgem quando os requisitos n˜

ao s˜

ao precisamente

definidos

Requisitos amb´ıguos podem ser interpretados de maneiras

diferentes pelos desenvolvedores e usu´

arios

Exemplo: O sistema deve fornecer

telas apropriadas

para o

usu´

ario ler os documentos no reposit´

orio de documentos

Usu´

ario: tela de especial para cada tipo de documento

Desenvolvedor: tela de texto que exiba todo o conte´

udo do

documento

Requisitos imprecisos geram mudan¸

cas, as quais levam a atrasos

Especifica¸c˜

ao de requisitos deve ser completa e consistente

completa: todos os servi¸

cos desejados devem ser definidos

consistente: requisitos n˜

ao devem ser contradit´

orios

Requisitos funcionais

Requisitos completos e consistentes s˜

ao uma utopia no mundo

real

Quanto maior e mais complexo o sistema mais dif´ıcil ´

e obter

completude

Clientes (usu´

arios) diferentes podem ter necessidades diferentes,

o que favorece descri¸

c˜

oes contradit´

orias

Definem propriedades e restri¸

c˜

oes de sistema (ex. confiabilidade,

tempo de resposta, requisitos de armazenamento, ...)

Requisitos de processo podem tamb´

em ser especificados (ex.

restri¸c˜

oes quanto ao uso de ferramentas ou linguagens)

Requisitos n˜

ao funcionais est˜

ao relacionados:

`

as necessidades do usu´

ario;

`

as restri¸

c˜

oes de or¸

camento;

`

as pol´ıticas organizacionais;

outros

Requisitos n˜

ao funcionais

Problemas relacionados com os requisitos n˜

ao funcionais podem

ser mais cr´ıticos do que aqueles relacionados aos requisitos

funcionais

O que ´

e pior?

O sistema n˜

ao responder em um per´ıodo adequado

N˜

ao realizar uma atividade da maneira como se imaginava

Requisitos n˜

ao funcionais

Requisitos de produto

especificam que o produto entregue deve se comportar de uma

maneira particular (ex. velocidade de execu¸

c˜

ao, confiabilidade, ...)

Requisitos de organizacionais

s˜

ao conseq¨

uˆ

encia de pol´ıticas e procedimentos da organiza¸

c˜

ao (ex.

padr˜

oes de processo usados, requisitos de implementa¸

c˜

ao, ...)

Requisitos de externos

surgem a partir de fatores externos ao sistema e seu processo de

desenvolvimento (ex. requisitos de interoperabilidade, requisitos

legais, ...)

S˜

ao muito dif´ıceis de definir precisamente e requisitos imprecisos

podem ser dif´ıceis de verificar

Clientes definem estes requisitos utilizando metas gerais

Desenvolvedores podem interpretar de maneira inadequada

Meta

Inten¸

c˜

ao geral do usu´

ario (ex. facilidade de uso)

Requisito n˜

ao funcional verific´

avel

Declara¸

c˜

ao usando alguma medida que pode ser objetivamente

testada

Sempre que poss´ıvel deve-se expressar requisitos n˜

ao funcionais

quantitativamente

Exerc´ıcio

Expresse os requisitos n˜

ao funcionais descritos no exerc´ıcio anterior de forma

quantitativa

Meta

Requisito verific´

avel

Linguagem C++

Respostas r´

apidas

Exerc´ıcio

Expresse os requisitos n˜

ao funcionais descritos no exerc´ıcio anterior de forma

quantitativa

Meta

Requisito verific´

avel

Linguagem C++

n˜

ao ´

e poss´ıvel/necess´

ario

Respostas r´

apidas

Ao solicitar algum processamento a

resposta a esta solicita¸

c˜

ao deve ser

fornecida no m´

aximo em cinco

se-gundos

Requisitos n˜

ao funcionais: Conflitos

Conflitos entre os diferentes requisitos n˜

ao funcionais s˜

ao comuns

em sistemas complexos

Exemplo: Sistema para uma aeronave

RNF 1: Minimizar o peso.

Implica¸

c˜

ao: n´

umero de chips separados no sistema deve ser

minimizado

RNF 2: Minimizar consumo de energia

Implica¸

c˜

ao: chips de baixa potˆ

encia devem ser usados

Conflito: Uso de chips de baixa potˆ

encia pode significar que mais

chips devem ser usados

Descrevem caracter´ısticas de sistema que refletem o dom´ınio de

aplica¸c˜

ao

Podem restringir os requisitos funcionais existentes ou

estabelecer como c´

alculos espec´ıficos devem ser realizados

Se os requisitos de dom´ınio n˜

ao forem satisfeitos, o sistema

Os requisitos de usu´

ario devem descrever os requisitos funcionais

e n˜

ao funcionais de modo compreens´ıvel para aqueles que n˜

ao

possuem conhecimento t´

ecnico

Estes requisitos devem:

especificar somente comportamento externo;

evitar caracter´ısticas de projeto do sistema;

evitar uso de termos t´

ecnicos.

´

E aconselh´

avel utilizar linguagem simples, tabelas e diagramas

Requisitos de usu´

ario

Problemas com linguagem natural

Falta de clareza. ´

E dif´ıcil atingir uma precis˜

ao sem tornar o

documento dif´ıcil de ler

Confus˜

ao de requisitos. Requisitos funcionais e n˜

ao funcionais

tendem a estar misturados

Fus˜

ao de requisitos. V´

arios requisitos diferentes podem ser

expressos juntos

´

E adequado separar os requisitos de usu´

ario dos requisitos de

sistema

Os usu´

arios podem ser sobrecarregados com informa¸

c˜

oes t´

ecnicas

incompreens´ıveis para eles

O requisito de grade mistura trˆ

es tipos diferentes de requisitos:

Requisito funcional conceitual (a necessidade de uma grade);

Requisito n˜

ao funcional (unidades de grade);

Diretrizes para escrever requisitos:

Inventar um formato padr˜

ao e us´

a-lo para todos os requisitos

Usar a linguagem de uma forma consistente

Use ‘deve’ para requisitos obrigat´

orios, e ‘deveria’ para requisitos

desej´

aveis

Real¸

ce o texto para identificar as partes principais do requisito

Evitar o uso de jarg˜

oes de computa¸

c˜

ao

Requisitos de sistema

S˜

ao vers˜

oes mais detalhadas dos requisitos de usu´

ario

S˜

ao utilizados pelos desenvolvedores como ponto de partida para

o projeto do sistema

Eles podem ser incorporados no contrato de sistema

Requisitos de sistema podem ser definidos ou ilustrados usando

modelos de sistema

Em princ´ıpio, requisitos devem definir o que o sistema deve fazer

e o projeto deve descrever como ele faz isto

Exerc´ıcio

1

Identifique como Req. Funcional (RF), Req. N˜

ao Funcional (RNF) ou Req. de

Dom´ınio (RD)

(

)

E necess´

´

ario manter um log de todas as a¸

c˜

oes do usu´

ario

(

)

emiss˜

ao de relat´

orios gerenciais

(

)

o IMC do atleta deve ter precis˜

ao de 3 casas decimais

(

)

cadastro de dados pessoais dos clientes

O objetivo da engenharia de requisitos ´

e criar e manter um

documento de requisitos

Engenharia de requisitos:

estudo de viabilidade;

elicita¸

c˜

ao e an´

alise de requisitos;

especifica¸

c˜

ao de requisitos;

valida¸

c˜

ao de requisitos.

Em geral, os requisitos de sistema mudam

maior compreens˜

ao do que desejam do software;

mudan¸

cas na organiza¸c˜

ao que compra o produto;

altera¸

c˜

oes de hardware;

outros.

Estudo de viabilidade

Um estudo de viabilidade deve iniciar o processo de engenharia

de requisitos

Com base em um conjunto de entradas deve-se determinar se ´

e

recomend´

avel ou n˜

ao prosseguir com o desenvolvimento

... ´

e poss´ıvel criar o produto?

... ´

e poss´ıvel obter benef´ıcio com a cria¸

c˜

ao do produto?

Envolve avalia¸

c˜

ao de informa¸

c˜

oes, coleta e elabora¸

c˜

ao de um

relat´

orio

Tipos de viabilidade

Tipos de viabilidade:

viabilidade operacional - adequa¸

c˜

ao do produto ao contexto de uso

viabilidade t´

ecnica - possibilidade t´

ecnica para desenvolvimento da

solu¸

c˜

ao

viabilidade de cronograma - consistˆ

encia entre o tempo existente e

o tempo necess´

ario

viabilidade econˆ

omica - rela¸

c˜

ao entre custo e benef´ıcio obtido com

o produto

Estudo de viabilidade

Tipos de viabilidade

Viabilidade operacional

O sistema funcionar´

a? performance, eficiˆ

encia, ...

Os usu´

arios ir˜

ao utilizar? mudan¸

cas em rela¸

c˜

ao ao trabalho atual,

...

A gerˆ

encia apoia o desenvolvimento? aprendizado inicial,

disponibilidade para atender a equipe de desenvolvimento, ...

Tipos de viabilidade

Viabilidade t´

ecnica

O conhecimento sobre o dom´ınio do neg´

ocio ´

e acess´ıvel?

Existem as tecnologias necess´

arias para o desenvolvimento?

O conhecimento t´

ecnico dispon´ıvel ´

e suficiente?

Estudo de viabilidade

Tipos de viabilidade

Viabilidade de cronograma

Dado o escopo, ´

e poss´ıvel desenvolver dentro do prazo dispon´ıvel?

´

E poss´ıvel ‘quebrar’ em entregas menores?

Tipos de viabilidade

Viabilidade econˆ

omica

Quais os ganhos econˆ

omicos com a cxria¸

c˜

ao do sistema?

´

E melhor continuiar com a solu¸c˜

ao atual?

Custos envolvidos

custos de desenvolvimento ou aquisi¸

c˜

ao do sistema

custos operacionais (ex. hardware e pessoas)

custos fixos (ex. aluguel, licen¸

ca de software, ...)

custos vari´

aveis (ex. suprimentos, energia, telefone, ...)

Elicita¸c˜

ao e an´

alise de requisitos

Stakeholders devem descrever o que se espera da aplica¸

c˜

ao:

servi¸cos, desempenho, restri¸c˜

oes, etc

A elicita¸c˜

ao de requisitos ´

e uma atividade complexa, alguns dos

motivos s˜

ao:

os stakeholders possuem, em geral, somente uma vaga no¸

c˜

ao do

que esperam do sistema;

diferentes stakeholders possuem diferentes formas de expressar os

requisitos;

fatores ambientais e econˆ

omicos da empresa podem influenciar

nos requisitos do sistema

Elicita¸c˜

ao e an´

alise de requisitos

Obten¸c˜

ao de requisitos. Intera¸

c˜

ao com stakeholders para coletar

os requisitos

Classifica¸c˜

ao e organiza¸

c˜

ao de requisitos. Os requisitos s˜

ao

agrupados em conjuntos coerentes

Prioriza¸c˜

ao e negocia¸

c˜

ao de requisitos. Resolu¸

c˜

ao de conflitos

entre stakeholders e prioriza¸

c˜

ao dos requisitos

Documenta¸

c˜

ao de requisitos. Os requisitos s˜

ao documentados e

As descri¸c˜

oes anteriores s˜

ao um modelo gen´

erico de elicita¸

c˜

ao e

an´

alise de requisitos

Diferentes organiza¸

c˜

oes possuem diferentes meios para realizar

tais atividades

Elicita¸c˜

ao e an´

alise de requisitos

Obten¸

c˜

ao de requisitos

A obten¸c˜

ao de requisitos consiste na coleta de informa¸

c˜

oes

relacionadas ao sistema proposto

Diferentes abordagens podem ser utilizadas na obten¸

c˜

ao de

requisitos:

observa¸

c˜

ao de documentos;

entrevistas;

T´

ecnicas ´

uteis (para elicitar/ especificar):

Entrevista

Question´

arios

Pontos de vista

Casos de Uso e Diagramas de Caso de Uso

Cen´

arios

M´

etodos formais

...

Elicita¸c˜

ao e an´

alise de requisitos

Obten¸

c˜

ao de requisitos - Entrevista

Entrevistas formais ou informais s˜

ao op¸

c˜

oes bastante utilizadas

nos processos de engenharia de requisitos

Entrevistas podem ser de dois tipos:

Entrevistas fechadas - quest˜

oes predefinidas;

Entrevistas abertas - n˜

ao existe um roteiro de quest˜

oes

Na pr´

atica ambos os tipos de entrevista s˜

ao utilizados em

conjunto

Obten¸

c˜

ao de requisitos - Entrevista

O entrevistador deve:

possuir mente aberta, sem preconceber ideias sobre os requisitos

induzir os entrevistados com uma proposta, n˜

ao se deve esperar

que eles respondam a quest˜

oes “o que vocˆ

e quer?”

Alguns problemas com entrevistas:

especialistas de dom´ınio podem utilizar muitos termos t´

ecnicos;

alguns conceitos de dom´ınio podem ser considerados t˜

ao

familiares que s˜

ao dif´ıceis de explicar ou nem s˜

ao mencionados

Especifica¸c˜

ao de requisitos

Os requisitos elicitados anteriormente devem ser representados

A linguagem natural tamb´

em pode ser utilizada para especificar

requisitos de sistema

Contudo, diversos problemas podem existir:

Ambig¨

uidade;

Flexibilidade excessiva;

Falta de modulariza¸

c˜

ao.

Os requisitos podem ser representados de maneira mais

especializada

Especifica¸c˜

ao de requisitos

Sommerville descreve t´

ecnicas para especifica¸

c˜

ao de requisitos

Cen´

arios

Casos de uso

Cen´

arios

Cen´

arios s˜

ao exemplos reais de como um sistema pode ser usado

´

E mais simples relatar o comportamento esperado do sistema

Cada cen´

ario corresponde a uma ou mais intera¸

c˜

oes com o

sistema

Elicita¸

c˜

ao de requisitos com base em cen´

arios ´

e uma t´

ecnica

Especifica¸c˜

ao de requisitos

Cen´

arios

Uma descri¸

c˜

ao de cen´

ario deve conter:

Uma descri¸

c˜

ao da situa¸

c˜

ao inicial;

Uma descri¸

c˜

ao do fluxo normal de eventos;

Uma descri¸

c˜

ao do que pode dar errado;

Informa¸

c˜

ao sobre outras atividades concorrentes;

Uma descri¸

c˜

ao do estado quando o cen´

ario termina.

Casos de uso

Casos de uso s˜

ao uma t´

ecnica baseada em cen´

arios para

elicita¸c˜

ao de requisitos

Um caso de uso identifica o tipo da intera¸

c˜

ao e os agentes

envolvidos

Especifica¸c˜

ao de requisitos

Casos de uso

Casos de uso ser˜

ao descritos de maneira detalhada em aulas

A valida¸c˜

ao de requisitos dedica-se a mostrar que os requisitos

definem o sistema que o cliente realmente deseja

Custos de erros de requisitos s˜

ao altos e, desse modo, a valida¸

c˜

ao

´

Valida¸c˜

ao de requisitos

Algumas verifica¸c˜

oes no documento de requisitos devem ser

realizadas:

Verifica¸

c˜

ao de validade. O sistema fornece as fun¸

c˜

oes que melhor

ap´

oiam as necessidades do cliente?

Verifica¸

c˜

ao de consistˆ

encia. Existe algum tipo de conflito de

requisitos?

Verifica¸

c˜

ao de completeza. Todas as fun¸

c˜

oes requisitadas pelo

cliente foram inclu´ıdas?

Verifica¸

c˜

ao de realismo. Os requisitos podem ser implementados

com o or¸

camento e a tecnologia dispon´ıveis?

Algumas t´

ecnicas de valida¸c˜

ao:

Revis˜

oes de requisitos. An´

alise manual sistem´

atica dos requisitos.

Prototipa¸

c˜

ao. Uso de um modelo execut´

avel do sistema para

verificar requisitos.

Gera¸

c˜

ao de casos de teste. Desenvolvimento de testes para

requisitos a fim de verificar a testabilidade

O documento de requisitos de software

O documento de requisitos ´

e a declara¸c˜

ao oficial do que ´

e

requisitado para os desenvolvedores do sistema

Deve incluir requisitos do usu´

ario e requisitos do sistema

N˜

AO ´

e um documento de projeto. Logo que poss´ıvel, ser´

a

preciso definir “o que” o sistema deve fazer ao inv´

es de “como”

Padr˜

ao de requisitos do IEEE

Introdu¸

c˜

ao

Descri¸

c˜

ao geral

Requisitos espec´ıficos

Apˆ

endices

´Indice

O documento de requisitos de software

Descri¸c˜

ao estendida proposta por Sommerville

Pref´

acio

Introdu¸

c˜

ao

Gloss´

ario

Defini¸

c˜

ao de requisitos de usu´

ario

Arquitetura de sistema

Especifica¸

c˜

ao de requisitos de sistema

Modelos de sistema

Evolu¸

c˜

ao de sistema

Apˆ

endices

Exerc´ıcio

Utilizando o projeto de um sistema academico como estudo de caso, identifique

requisitos funcionais e requisitos n˜

ao funcionais

Forne¸

ca uma descri¸

c˜

ao de um dos requisitos anteriores como “requisitos de usu´

ario”

e “requisito de sistema”

Ilustre o processo de elicita¸

c˜

ao de requisitos para o sistema academico

Como os requisitos poderiam se especificados?

Resumo

Resumo

Os requisitos estabelecem o que sistema deve fazer e definem as restri¸

c˜

oes sobre

suas opera¸

c˜

oes e sua implementa¸

c˜

ao

Requisitos funcionais definem os servi¸

cos que o sistema deve fornecer

Requisitos n˜

ao funcionais restringem o sistema que est´

a sendo desenvolvido ou o

processo de desenvolvimento

Requisitos de usu´

ario s˜

ao declara¸

c˜

oes de alto n´ıvel

Requisitos de sistema s˜

ao descri¸

c˜

oes detalhadas das fun¸

c˜

oes que o sistema deve

fornecer

Um documento de requisitos de software ´

e uma declara¸

c˜

ao oficial dos requisitos do

sistema

Resumo

Usu´

arios + Clientes + Desenvolvedores = Stakeholders

Usu´

arios podem n˜

ao compreender as ‘necessidades’

O desenvolviemnto do produto deve ser investigado para que se indique se ele ´

e

vi´

avel ou n˜

ao

Leituras recomendadas

Ian Sommerville.

Engenharia de Software, 8

a

ed., 2007.

Cap´ıtulo 6: Requisitos de software

Cap´ıtulo 7: Processos de engenharia de requisitos

Roger S. Pressman.

Engenharia de Software, McGraw-Hill, 6

a

ed., 2006.

Cap´ıtulo 10 - Engenharia de sistemas

Perguntas?

Alexandre de Andrade Barbosa

[email protected]