Você está na página 1de 14

Fundamentos de Requisitos de Software

Magno A. Cavalcante
(Engenheiro de Software)

Introduo
Definir com preciso os requisitos permite direcionamento claro:
dos recursos da empresa; da energia da equipe de desenvolvimento.

Sem essa definio:


Perde-se tempo; Mais erros so cometidos; A qualidade do produto de software ser incerta.

Porque Gerenciar Requisitos?


Quanto mais tarde um erro detectado, maior o custo de corrigi-lo. Muitos erros nos requisitos podem ser detectados mais cedo no ciclo de desenvolvimento de software. Erros tpicos incluem falta de compreenso da viso de negcios, fatos incorretos, omisses, inconsistncias, e ambiguidade.

Porque Precisamos Declarar Requisitos?


1. Cliente procura a empresa precisando de um software. 2. Analista de sistemas entrevista o cliente e colhe dados
E acrescenta um toque pessoal, para cobrir lacunas. E o gerente decide fazer algumas modificaes para cumprir o prazo. E ento adapta o design com base em suas prprias experincias. E o desenvolvedor efetua ajustes para a reutilizar o cdigo-fonte. Pode ser esquecido ou entendido de diversas maneiras.

3. Analista expe suas anotaes equipe de projeto 4. Analista percebe que algumas mudanas foram prejudiciais

5. Design entregue ao desenvolvedor de software 6. Considerando que esse fluxo seja passado de forma oral

Dilogo entre Cliente e Desenvolvedor


Dificuldades de comunicao merecem ateno especial dos desenvolvedores. Um dos problemas a negociao de requisitos entre clientes e desenvolvedores:
O cliente no sabe o que quer
difcil explicar algo antes dele existir.

No pedi porque bvio


Usurios ignoram o fato de que os desenvolvedores no conhecem seu trabalho.

Basta incluir dois campos a mais no formulrio


Clientes acham que fcil fazer modificaes no produto.

Funcionava mais rpido na fase de testes


Cliente no entende a mudana de ambiente.

Do qu o cliente realmente precisa?

Requisitos de Software
Descries sobre comportamento, funes e operaes que deve realizar;
Levantamento, anlise, especificao, rastreamento e validao

Principais causas de falhas em projetos:


Dificuldade em entender o que o usurio quer; Descries incompletas; Mudanas no controladas.

Forma que as operaes so realizadas;


Viso do cliente e viso do programador

Requisitos de Software
Num software operaes e dados esto relacionados. Durante o ciclo de vida do software os requisitos sofrem influncia de diferentes pessoas:
Stakeholders: pessoas que tem controle sobre a especificao Operadores Gerentes Compradores Leis e regulamentos Analistas Programadores

Alm de pessoas, podem influir:


Natureza da aplicao; Tecnologia disponvel; Restries de controle de projetos.
8

Lidando com o Desconhecido


Deve haver ateno com requisitos no especificados, mas que fazem parte do produto;
Automveis devem ter janelas, softwares interfaces inteligveis.

Diagrama de visibilidade dos requisitos; Requisitos bvios;


Ausncia de bugs, facilidade de operar.

Cliente a fonte de informaes sobre seu negcio;


Podem ser extremamente prticos ao descrever; Ou no conseguem (no querem).

Requisitos documentados: explcitos; Requisitos no especificados, mas necessrios: implcitos.


9

Origem dos Requisitos de Software

Fonte: Koscianski & Soares, 2007

10

Tipos de Requisitos
Requisitos Funcionais Requisitos No Funcionais Requisitos Inversos

11

Requisitos Funcionais
So requisitos diretamente ligados a funcionalidade do software. So funcionalidades que se espera que o software tenha. Deve ser completa e consistente:
Todas as funes requeridas pelo usurio devem estar definidas; No devem ser contraditrias.

Para softwares grandes quase impossvel:


Existem diferentes pontos de vista.

Devem ser desvinculados o mximo possvel da tecnologia.

12

Requisitos No Funcionais
So requisitos que expressam restries que o software deve atender ou qualidades especficas que o software deve ter. Restries ao software de forma geral:
Ex: confiabilidade de um sistema de controle de vo.

difcil verific-los:
Ex: capacidade de deteco, facilidade de uso, rapidez de resposta.
Esto abertos interpretao

Idealmente devem ser expressos quantitativamente:


Usar mtricas; Transaes processadas por segundo, tamanho em bytes do sistema, memria necessria.

Podem entrar em conflito e interagem com requisitos funcionais.


Ex: desempenho, verificao, portabilidade, recursos, interface, eficincia, qualidade, segurana, interoperabilidade, robustez, confiabilidade, manutenibilidade.

13

Requisitos No Funcionais
Classificao dos principais requisitos no funcionais.

Fonte: Kontoya e Sommerville (em citao por Koscianski & Soares, 2007)

14

Taxonomia para Requisitos No Funcionais

Fonte: Sommerville, 2005

15

Requisitos Inversos
Estabelecem condies que nunca podero ocorrer e que no sero contempladas no desenvolvimento do software. Representam funcionalidades que esto FORA DO ESCOPO da soluo de software.

16

Documento de Requisitos
Escrever de forma correta e concisa fundamental para sua compreenso
No basta apenas saber programar para ser bom profissional.

Basta uma pequena inconsistncia para levar a problemas. Boas prticas:


Alocar tempo: no ter pressa ao escrever o documento. Consistncia: requisitos devem ser entendidos de uma s forma por todos que o leiam (evitar sinnimos). Conciso: frases e pargrafos curtos, evitando adjetivos.
17

Documento de Requisitos
Deve conter:
Servios e funcionalidades que o software deve ter; Restries de negcios; Restries de tecnologias; Restries de operao; Propriedades gerais do software; Definio de quais outros softwares devem ser integrados; Requisitos de hardware.

18

Documento de Requisitos
Padro IEEE-Std-830-1998
Introduo; Propsito do documento; Escopo do produto; Definies e abreviaes; Referncias; Viso geral do documento; Descrio geral; Perspectiva do produto; Funes do produto; Caractersticas do usurio; Restries gerais, suposies e tendncias; Requisitos adiveis; Requisitos especficos; Apndices; ndice.
19

Tcnicas de Levantamento de Requisitos


No existe um processo ideal. Muitos acham que necessrio comear a programao o mais rpido possvel.
Boa especificao de requisitos custa tempo e dinheiro; No entanto, sua ausncia pode custar ainda mais dinheiro;

Possveis problemas:
Stakeholders podem no estar de total acordo; Ocorrem decises unilaterais; Gerentes podem impor requisitos que no sejam ideais.

Processo cooperativo:
Desenvolvedores, analistas, contratantes, operadores, etc.

20

10

Tcnicas de Levantamento de Requisitos


Entrevistas
Tcnica mais comum; Analista deve querer ouvir; Comear com questes pontuais simples e evoluir para mais complexas; Tipos de perguntas:
Abertas: perguntas subjetivas sobre funcionamento de algo; Fechadas: perguntas objetivas onde so apresentados valores quantitativos; Continuidade: prope que o entrevistado esclarea sobre um assunto no muito claro.

21

Tcnicas de Levantamento de Requisitos


Questionrios:
Sequncia lgica de questes a fim de extrair necessidades reais; So mais eficazes com stakeholders que se expressam melhor por escrito que oralmente; O analista deve ter experincia para montar o questionrio; Pode ser combinado com a entrevista

Etnografia:
Observao do trabalho dirio; Prticas de trabalho so ricas, complexas e dinmicas; Diferena entre o trabalho suposto e o real.
22

11

Tcnicas de Levantamento de Requisitos


Cenrios:
Descrio de situaes reais de trabalho atravs de exemplos; Permite lembrar de detalhes que no podem ser revelados em questionrios; Podem ser descritos de diversas formas UML ou histrias de usurio Analistas podem simular a execuo dos cenrios.

23

Qualidade de Requisitos
A especificao de requisitos deve satisfazer
Correo: todo requisito presente um requisito do software Preciso: todo requisito presente possui nica interpretao Completude: reflete todas as decises de especificaes tomadas Consistncia: no h conflitos entre subconjuntos de requisitos Priorizao: explcita de acordo com a importncia e estabilidade Verificabilidade: atestar a conformidade do produto final com os requisitos Modificabilidade: sua estrutura e estilo permitem mudana de forma fcil, completa e consistente Rastreabilidade: permite a fcil identificao dos antecedentes e consequncias dos requisitos

24

12

Perspective-Based Reading
Leitura: tcnica chave para verificao e validao de documentos
Planos de teste, cdigos, especificao de requisitos.

PBR: leitura de requisitos escritos em linguagem natural


Analisa o documento em busca de certas caractersticas que sinalizam problemas; Leitura segundo determinado ponto de vista (desenvolvedor de software); Ex: ambiguidade nmero x cdigo; Atribui a cada revisor uma perspectiva: Cada revisor recebe um script de aplicao.

25

Rastreabilidade
Usada para prover relacionamento entre requisitos, design e implementao final do software; uma caracterstica de sistemas nos quais os requisitos so claramente ligados s suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do software; Quais requisitos ESTO implementados nesta release do software? Quais requisitos NO ESTO implementados nesta release do software?
26

13

Referncias
IEEE Computer Society - www.computer.org Software Engineering Body of Knowledge (SWEBOK) www.computer.org/portal/web/swebok Software Engineering Institute - www.sei.cmu.edu Rational Unified Process - www.wthreex.com/rup/portugues/index.htm Kotonya, G. & Sommerville, I. "Requirements engineering: processes and techniques". Chichester: Wiley, 1998 Sommerville, I. "Software engineering". (4th Ed.), Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1993 Koscianski, A. & Soares, M. S. Qualidade de Software. (2. Ed.), NOVATEC, So Paulo, 2007

27

FIM

28

14