Tpicos Especiais

Aula 6 Analisando Requisitos para Documentar

Corretamente.

Walter Travassos Sarinho

walter.travassos@unipe.br ou travassoswalter@gmail.com

https://goo.gl/eztp2P

O que j sabemos?
Elicitao
Escolher o melhor instrumento para levantar os requisitos de um software;
Escrever corretamente requisitos em linguagem natural;

Documentao
Identificar requisitos incompletos e errados;
Sabemos propor algumas melhorias.

Aula de Hoje...
Analisar para Documentar
Anlise e Documentao Correta de Requisitos:

Funcionais [RF]
No Funcionais [NF]
de Domnio [RD]
de Sustentabilidade [RS]

O que fazer aps a coleta de requisitos?

Logo aps a etapa de elicitao de requisitos (captura em
linguagem natural) necessrio documentar os requisitos
corretamente;
Uma viso geral do projeto pode ser alcanada utilizando vrios
diagramas da linguagem UML (caso de uso, componentes, por
exemplo);
Entre os diagramas disponveis, o mais utilizado (num primeiro
momento) o Diagrama de Caso de Uso por ser uma viso
intermediria entre a linguagem natural e o projeto do software.

Requisitos do Usurio x Requisitos do Sistema

Uma viso geral do projeto pode ser alcanada utilizando os

requisitos descritos em linguagem natural (requisitos do usurio) e
um diagrama de caso de uso;
De posse dessa viso, hora de identificar e documentar os
requisitos do sistema;
De 1 Requisito do Usurio surgem 1 ou mais requisitos do Sistema.

Os Requisitos do Sistema podem ser:

Funcionais
No-funcionais
de Domnio
de Sustentabilidade

Funcionais e No-Funcionais
Requisitos Funcionais: descrevem as funcionalidades que se espera
que o sistema disponibilize, de uma forma completa e consistente.
aquilo que o utilizador espera que o sistema oferea, atendendo
aos propsitos para qual o sistema ser desenvolvido.
Requisitos no-funcionais: referem-se a aspectos no-funcionais do
sistema, como restries nas quais o sistema deve operar ou
aspectos desejados no sistema. Costumam ser divididos em
Requisitos no-funcionais de: Utilidade, Confiana, Desempenho,
Suporte e Escalabilidade.

Requisitos No-Funcionais

Requisitos de Domnio
Derivados do domnio da aplicao;
Descrevem caractersticas e recursos do sistema que refletem o
domnio;
Podem ser novos requisitos funcionais, restries nos requisitos
existentes ou definies de novas Computaes;
Se os requisitos de domnio no forem satisfeitos, o sistema pode
no ser trabalhvel.

Requisitos de Domnio

Os Requisitos de Domnio originam-se do domnio da aplicao do

sistema, refletindo as caractersticas deste domnio
(SOMMERVILLE, 2003). Podem ser funcionais ou no funcionais
(PRESSMAN, 2001).

Temos que nos preocupar com a

natureza
E no que isso tem relao com o desenvolvimento de software?

Requisitos de Sustentabilidade
O que sustentabilidade?

I. Sustentabilidade a capacidade de suportar;

II. o desenvolvimento sustentvel que atende s necessidades do presente
sem comprometer a capacidade das geraes futuras de satisfazerem as
suas prprias necessidades.

Mas... Como isso se aplica na Engenharia de Requisitos?

Requisitos de Sustentabilidade

Existem trs pilares que concorrem para a definio de software

sustentvel:

1. Long Lasting Software capacidade de lidar com a mudana sem

demandar um hardware mais robusto;
2. Lean Software impacto energtico, lixo eletrnico;
3. Software for Sustainable Humans promove comportamento sustentvel.

J est no Unip Virtual a aula sobre requisitos de sustentabilidade!

Requisitos de Sustentabilidade
Analisar "o que" e "como" a Engenharia de Requisitos pode
contribuir para a melhoria da sustentabilidade ambiental das
Empresas que consomem TI;
O objetivo criar um contedo guias para especificar requisitos de
sustentabilidade e informaes relacionadas;
Ento... Voc poderia mencionar um requisito de sustentabilidade
para o desenvolvimento de software?

Finalizei a descrio dos requisitos em

categorias. E agora?

Documentando Requisitos Corretamente

Por conveno, a referncia a requisitos feita atravs do nome da
subseo onde eles esto descritos (Requisito Funcional, por
exemplo), seguidos do identificador do requisito (um nmero), de
acordo com a especificao a seguir:
[nome da subseo. identificador do requisito]
Confiabilidade.
[RF001] [NF002]
Recuperao de Dados.
ManterFuncionrio.

[RD003]

Por exemplo...
O requisito funcional [Recuperao de dados.RF016] deve estar
descrito em uma subseo chamada Recuperao de dados, em
um bloco identificado pelo nmero [RF016];
J o requisito no-funcional [Confiabilidade.NF008] deve estar
descrito na seo de requisitos no-funcionais de Confiabilidade,
em um bloco identificado por [NF008];
Os requisitos devem ser identificados com um identificador nico.
A numerao inicia com o identificador [RF001] ou [NF001] e
prossegue sendo incrementada medida que forem surgindo novos
requisitos.

Guia para Elaborao de Requisitos

Definir um formato padro e us-lo para todos os Requisitos;
Utilize o idioma de forma consistente. Use deve para requisitos
obrigatrios, deveria para requisitos desejveis;
Usar texto destacado para identificar as partes principais do requisito;
Evitar o uso do jargo de computao startar, refreshar, bugou,
legando (muito lag), resetar, mockar, comitar, upar, dropar...
J est (tambm) no Unip Virtual alguns exemplos de Documentos de
Requisitos.

Requisitos Funcionais devem possuir:

1. Descrio do caso de uso Em linguagem natural;

2. Prioridade Essencial (ou obrigatria, alta, mxima), importante
(mdia) ou Desejvel (baixa, mnima);
3. Entradas e pr-condies necessrias ao requisito;
4. Sadas e ps-condies aps a execuo do requisito.

Exemplo de RF

Requisitos No Funcionais devem possuir:

A Descrio do requisito logo abaixo do ttulo do requisito;

E tambm...

A sua Prioridade
Cada requisito deve
receber uma prioridade;
As prioridades podem ser:
essencial, importante
e desejvel;
Por exemplo:

Mas o que realmente significa cada

uma das prioridades?

Prioridade Mxima, Obrigatria, Alta...

o requisito sem o qual o sistema no entra em funcionamento;

So requisitos imprescindveis, que tm que ser implementados
impreterivelmente;
Por exemplo: manter usurio; autenticar;

Prioridade Importante, Mdia..

o requisito sem o qual o sistema entra em funcionamento, mas de

forma no satisfatria;
Requisitos importantes devem ser implementados, mas, se no
forem, o sistema poder ser implantado e usado mesmo assim;
Por exemplo: validar os dados; criptografar a senha usando MD5;

Prioridade Desejvel, Baixa, Mnima...

o requisito que no compromete as funcionalidades bsicas do
sistema, isto , o sistema pode funcionar de forma satisfatria sem
ele;
Estes requisitos podem ser deixados para verses posteriores do
sistema, caso no haja tempo hbil para implement-los na verso
que est sendo especificada;
Por exemplo: Recuperar senha;

Sabendo da prioridade dos requisitos, por

onde devo comear a implementao?
Como garantir a qualidade do produto para
alcanar a satisfao do cliente?

Qualidade do Produto x Prioridade de

Requisitos
Na sua opinio, a satisfao total do cliente est ligada a qual dos trs requisitos?

Definio de Qualidade (Garvin, 1988)

Transcendental

Baseada no
produto

Baseada no
usurio

Baseada na
produo

Baseada no
valor

PMBok

Qualidade o grau at o qual um conjunto de caractersticas

inerentes satisfaz as necessidades;
Um projeto com qualidade aquele concludo em conformidade
com os requisitos, especificaes e adequao ao uso

Identificando as Necessidades dos Stakeholders

VoC (Voice of Customer)

Entrevistas, simulao da situao de consumo e pesquisa de mercado;

necessrio converter a Voz do Consumidor em caractersticas crticas do
projeto (CtQ - Critical to Quality), estabelecendo metas que nortearo os passos
do projeto.

Kano et al., (1984) afirmam que a Voz do Consumidor pode ser dividida
em:
Itens Bsicos: qualidade mnima esperada (causam insatisfao se no estiverem
presentes no produto;
Itens de Desempenho: tem impacto na satisfao do cliente, so requisitos
declarados;
Itens de Encantamento: tem importncia exponencial na satisfao dos
consumidores.

Qualidade x Prioridade de Requisitos

Para o produto ter qualidade ele deve atender todos os requisitos

apresentados pelos stakeholders... e ir alm! preciso surpreender!

Prxima aula...

Do Project Model Canvas at a elaborao do Termo de Abertura

de Projeto;
Apresentao do tema do projeto e definio de equipes!!

Avaliao da 2 Unidade - Projeto

Entrega de 2 artefatos (impressos). Data de entrega: 21/04/2016.
1 Artefato (0,00 a 2,00 pts): Termo de Abertura de Projeto de Software;
2 Artefato (0,00 a 2,00 pts): Diagrama de caso de uso do projeto (Apenas
o diagrama, no precisa da descrio);
3 Artefato (0,00 a 6,00 pts) Documento de Especificao de Requisitos de
Software contendo:

Requisitos Funcionais (no mnimo 4)

Requisitos No-Funcionais (no mnimo 3)
Requisitos de Domnio (no mnimo 2)
Requisitos de Sustentabilidade (no mnimo 1)

Tpicos Especiais
Aula 6 Analisando Requisitos para Documentar
Corretamente.

Walter Travassos Sarinho

walter.travassos@unipe.br ou travassoswalter@gmail.com

https://goo.gl/eztp2P