Docente: Umbelina T.

João de Menezes (Msc) 1

Requisitos de Software
Características Especiais de um Requisito – SMART.
O que são as Metas Smart?
As metas SMART são uma ferramenta que auxilia na
definição de metas – independentemente se estas metas
servirão para uma determinada pessoa ou para uma empresa.
O importante é entender que essa é uma importante ferramenta
de Coaching que auxilia de maneira poderosa e objetiva a
estabelecer suas metas.
▪ É importante ressaltar que ao definir metas as pessoas
precisam entender que elas devem ser extremamente
diretas e objetivas. Isso é importante para que não haja
espaço para suposições ou dúvidas.

2
O que são as Metas de um
requisito Smart?
Os requisitos, para serem considerados bem
formados, devem possuir 5 características
principais.

 Especifico;
 Mensurável;
 Achievable; Implementável
 Realisable; Relevante ou realizavel
 Traceable. Time based, ou temporal

3
Requisitos de Software
▪ S – Específico: Concreto, Claro, Simples, Consistente,
Detalhado.
▪ Corresponde ao termo specific, ou seja, uma meta deve ser
específica naquilo que quer. Se o objetivo é aumentar
vendas, o gestor deve ser prático e objetivo para definir que
quer aumentar as vendas em 20, 30 ou 40% em um período
de 10 meses, por exemplo. O importante é ser
extremamente direto.

4
 exemplos

1 – Uma pessoa que estabelece como meta:

“ano que vem vou cuidar mais da minha
saúde”
2 – Uma pessoa que estabelece como meta:
“semestre que vem vou implementar novas
ideias nos estudos”.

5
Percebe-se o quanto tudo isso é vago, não há
objetividade tão pouco prazos para o cumprimento
das metas. Para que as metas mencionadas consigam
ser aplicadas como metas SMART, é fundamental que
sejam reformuladas a fim de se tornarem mais
precisas e diretas, pois da forma que estão elas podem
ser consideradas como metas utópicas( quase
impossivel de se realizar) e dificilmente serão
cumpridas.

6
SMART
 o que eu quero alcançar com essa meta? Aumentar
as vendas em 10%
 quem será ou quem serão os responsáveis por ela? A
equipa de marketing
 onde ela será realizada? Online
 como ela será conquistada? Com divulgação de
conteúdos relevantes
 por que ela deve ser seguida? Queremos aumentar a
participação online

7
SMART
M – Mensurável: Possível de verificar a sua concretização no
sistema.

Como criar uma meta se ela não pode ser medida? Isso
não faria nenhum sentido

8
 Para uma meta ser mensurável, ela deve
responder as questões:
 Quais requisitos devem ser verificados antes
deste?
 Quais os casos de testes necessários para
verificação?
 Pode ser testado isoladamente?
 Quais as condições técnicas para a sua
execução?
 O que se deve testar? Como testar e porque
testar?
9
Para uma meta ser mensurável, ela deve
responder as questões:

 Qual é o resultado esperado?

 Quanto tempo será necessário para a equipa
alcançar a meta?
 Trabalhando em nosso caso, teremos:
 Qual é o resultado esperado? Aumento de 10% nas
vendas online
 Quanto tempo será necessário para a equipa
alcançar a meta? 4 meses
 Mas imagine que, com essa meta, nossa equipa
conquistou o objetivo facilmente em 1 mês. Então,
para incentivar ainda mais a equipa, aumentamos a
meta para 70% de aumento. Será que é atingível?
10
 Revisão Sobre Requisitos
de Software
▪ A – Implementável: Deverá ser possível, por parte do sistema,
exibir funcionalmente ou tecnicamente a implementação do
mesmo nas condições definidas. Responde as seguintes
questões:

 Existe uma solução teórica para o problema?

 Existe uma restrição de substituição que proíbe a
implementação do requisito?
 Existe alguma restrição tecnológica para a implementação do
mesmo?

11
 R – Realizável: Possível de alcançar, caso seja possível de
implementar dentro de todos constrangimentos em que é
desenvolvido o sistema e o processo de desenvolvimento.
Responde as seguintes questões:

 Existem recursos suficientes para sua implementação?

 Skills da equipa, hardware, softwares disponíveis para
desenvolvimento e testes.
 Existe tempo e dinheiro suficiente para implementar?

12
 Revisão Sobre Requisitos de Software

Quando se cria uma meta e designa responsáveis,

devem ser elaboradas estratégias para que os resultados
sejam alcançados. Porém, quanto mais relevante for a meta,
mais motivados estarão os envolvidos.
Uma meta que não gera efeito sobre o negócio
fatalmente não será tratada como prioridade. Para criar uma
meta relevante é importante olhar os principais números da
empresa, como o faturamento, qualidade, número de clientes e
lucro. Assim, uma meta relevante terá impacto direto
nesses indicadores.

13
T – Time based, ou temporal
O último ponto das metas SMART é extremamente
importante. Qualquer meta traçada deve ter prazo. Quando
se cria uma meta e não se estabelece um tempo para a
sua realização, ele pode ser alcançado em 1 dia, 1 mês, 1
ano.

14
▪ T – Time based, ou temporal
▪ Capacidade que um requisito tem de ser seguido (de frente
para trás e vice-versa) a partir da sua concepção através da
especificação passando pelo seu desenho, implementação,
até aos testes. Esta é uma propriedade muito importante
pelas seguintes razões:

▫ Conhecer e entender a razão pela qual cada requisito foi

incluído no sistema:
▫ Verificar se e como cada requisito foi implemendado;
▫ Facilitar modificações consistentes e completas.

15
 Requisitos de Software
▪ Em função dos desafios da construção de um software e dos impactos
que os requisitos passaram a ter na Qualidade dos Softwares
desenvolvidos, a área de Requisitos passou a ser uma sub-disciplina
independente da Engenharia de Software. Surgiu assim a
Engenharia de Requisitos, que é definida como sendo a área da ES
que estuda os processos cooperativos, interactivos e incremental que
garantem que:
 Todos os requisitos relevantes são explicitamente conhecidos e
entendidos no nível de detalhe exigido.
 Existe um entendimento suficiente entre todas as partes envolvidas sobre
os Requisitos do Sistema a ser desenvolvido.
 Todos os requisitos são especificados e documentos em conformidade
com os padrões, formatos e regras estabelecidades.

16
 Conceitos de Qualidade
de Software
▪ A Qualidade de Software é área da Engenharia de
Software que se dedica ao estudo de processos, técnicas e
ferramentas que visam garantir que um produto de
software atende as características e propriedades definidas
nos requisitos.
▪ A Qualidade de Software como atributo, é definida como
sendo a propriedade que os softwares possuem em
satisfazer os requisitos implícitos e explícitos definidos sob
condições específicas. – ISO/EIC 9126-1 e ISO/IEC 25010.

17
 Conceitos de Qualidade
de Software
▪ A teoria sobre Qualidade de Software parece simples, porém, na
prática existem alguns aspectos problemáticos específicos da
Qualidade de Software, nomeadamente:

▫ Tensão entre requisitos para qualidade na perspectiva do

cliente (eficiência, confiabilidade, etc) e requisitos para
qualidade na perspectiva do desenvolvedor de software
(manutenibilidade, reusabilidade, etc.).
▫ Alguns requisitos são difíceis de especificar de forma
inequívoca.(evidente)
▫ As especificações de software são geralmente incompletas e
algumas vezes inconsistentes.

18
 Qualidade do Software vs Qualidade do Processo de
Desenvolvimento de Software

A premissa básica dos estudos e investimentos na

qualidade de software é que a Qualidade do Software
depende e está directamente ligada à Qualidade do
Processo de Desenvolvimento do mesmo.

Sendo assim, torna-se comum afirmar que a procura

por um software de maior qualidade passe necessariamente
e, na maior parte da vezes, primeiramente por uma melhoria
no processo de desenvolvimento do mesmo.

19
 Qualidade do Software vs Qualidade do Processo de
Desenvolvimento de Software

▪ Um bom processo de desenvolvimento não garante que os

softwares desenvolvidos dentro do mesmo sejam de boa
qualidade, mas é um indicativo de que o fornecedor/equipa
de desenvolvimento é capaz de desenvolver bons
softwares, ao passo que a qualidade do software
especifica que o software para além de ser bem
desenvolvido atende a todas as necessidades básicas do
utilizador.

20
Qualidade do Software vs Qualidade do Processo de
Desenvolvimento de Software

As principais razões para a procura pela qualidade do

processo de desenvolvimento são:

 Aumento da qualidade do software produzido;

 Diminuição/eliminação de trabalho;
 Maior produtividade;
 Redução do time to market;
 Maior competitividade;
 Maior precisão nas estimativas das entregas.

21
Qualidade do Software vs Qualidade do Processo de
Desenvolvimento de Software

▪ Para que um processo de desenvolvimento seja

considerado de qualidade, deve ser e estar documentado,
compreendido e seguido por todos envolvidos no referido
processo.

22
Revisão Sobre Processos de Desenvolvimento de
Software

▪ Sendo assim, entende-se como Processo de

Desenvolvimento de Software, o conjunto de
actividades, parcialmente ordenadas, executadas com a
finalidade de obter um produto de software.
▪ É estudado dentro da área de Engenharia de Software,
sendo considerado um dos principais mecanismos para se
obter software de qualidade e cumprir correctamente com
os compromissos e contratos acordados entre fornecedor
e cliente.

23
 Revisão Sobre Processos de Desenvolvimento de
Software

▪ Um processo que se pretende que seja de qualidade deve

ter os seguintes aspectos muito bem estabelecidos:
▫ Actividades a serem realizadas, sua estrutura e
organização (decomposição e precedência);
▫ Artefactos necessários produzidos e para cada
actividade do processo;
▫ Procedimentos (métodos, técnicas, padrões e
roteiros);
▫ Recursos necessários (humanos, hardware e
software) para a realização das actividades.

24
Revisão Sobre Processos de Desenvolvimento de
Software
▪ Existem vários modelos para aplicação de processos de
desenvolvimento de software, entretanto, todos incidem
sobre as mesmas fases:

 Análise e Especificação de Requisitos;

 Arquitectura e Desenho;
 Implementação/Codificação;
 Testes;
 Documentação;
 Instalação*, Suporte*, Treinamento*, Manutenção*
(Preventiva, Correctiva e Evolutiva).

25
Revisão Sobre Processos de Desenvolvimento de
Software

▪ Não obstante o processo de desenvolvimento ter as suas

características, propriedades e actividades claramente
definidas, a concretização das mesmas num cenário real
deve ser considerado caso a caso, levando-se em conta
as características específicas do projecto em questão,
nomeadamente:
 Equipa do Projecto;
 Domínio do Software;
 Tipo de Software;
 Tecnologias a serem adoptadas, restrições de negócio
e do projecto (cronograma, custo, qualidade), etc.

26
FIM
27