O documento apresenta os principais tópicos sobre requisitos e qualidade de software. Aborda a definição de requisitos funcionais e não funcionais, as boas práticas para elicitação de requisitos, os desafios nesse processo, a importância da qualidade total e do alinhamento com os requisitos para o sucesso de um projeto.

1. RequisitosRequisitos

2. Apresentação
Wanderlei Silva do Carmo
− Wander.silva@gmail.com
− Twitter: @w3ae
− Youtube: youtube.com/w3ae

Analista e desenvolvedor de sistemas

Formado pelo Universidade Estácio de Sá – RJ

Pós-graduando em Engenharia e Arquitetura de
Software

Especialista Linux

Atuando na área desde 1999 como instrutor em
centros de treinamentos

3. Agenda
● Definição
● Tipos
● Requisitos Funcionais
● Requisitos Não Funcionais
● Elicitação de Requisitos
● Dificuldades na Elicitação de Requisitos
● Produto de Qualidade?
● Garantia de Qualidade
● Ponto Fundamentais
● Qualidade Total
● Métricas
● Tripé da Qualidade
● Conclusão

4. Definição
Uma condição ou uma capacidade com a qual o sistema deve
estar de acordo.

5. Tipos
Funcionais
Não funcionais

6. Requisitos funcionais:
Os requisitos funcionais descrevem a funcionalidade ou os serviços que se
espera que o sistema realize em benefício dos usuários (PAULA FILHO, 2000).
Eles variam de acordo com o tipo de software em desenvolvimento, com
usuários e com o tipo de sistema que está sendo desenvolvido.
(SOMMERVILLE, 2008).
Requisitos Funcionais

7. Requisitos não funcionais:
Os requisitos não funcionais são aqueles que não dizem respeito diretamente às
funcionalidades fornecidas pelo sistema. Podem estar relacionados a
propriedades de sistemas emergentes, como confiabilidade, tempo de resposta,
espaço em disco, desempenho e outros atributos de qualidade do produto
(PAULA FILHO, 2000). Às vezes podem dizer respeito ao sistema como um
todo. Isso significa que na maioria das vezes eles são mais importantes que os
requisitos funcionais individuais. Se uma falha em cumprir um requisito funcional
pode comprometer parte do sistema, uma falha em cumprir um requisito não
funcional pode tornar todo o sistema inútil (SOMMERVILLE, 2008).
Requisitos não Funcionais

8. Preparação: Prepare-se previamente e de forma adequada para as atividades planejadas, as quais são
geralmente realizadas através de entrevistas, questionários, brainstorms e workshops.
Stakeholders: Mapeie (com antecedência) quem serão os participantes do processo, quais os seus papéis
no projeto e na organização e quais são os seus níveis de conhecimento e influência. É imprescindível
que as pessoas corretas sejam envolvidas o quanto antes.
Postura: Busque sempre a efetividade nas comunicações, assim como procure demonstrar ponderação
durante as situações de conflito.
Entendimento: Procure focar no entendimento do problema e evitar conclusões precipitadas. Nesse
primeiro momento o mais importante é saber escutar.
Experiências passadas: Utilize de forma positiva as experiências vividas anteriormente para ajudar a
melhor compreender o problema. Evite considerar que o problema atual é igual a algum outro que tenha
sido resolvido em um cliente ou projeto passado.
Documentação: descreva o problema de forma clara e objetiva. Em caso de dúvidas, consulte o cliente e
evite inferências. Procure usar exemplos citados pelos stakeholders. A adoção de diagramas e figuras
sempre ajuda na documentação e entendimento dos requisitos. A criação de protótipos também contribui
para o entendimento comum da solução proposta.
Validação: Faça com que os stakeholders validem a documentação, verificando o entendimento do
problema e as melhorias desejadas e eventualmente façam solicitações de mudanças.
(https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas_para_a_elicitacao_de_requisitos)
Elicitação de requisitos

9. Ao final do processo deverá ser possível demonstrar de maneira documental o
entendimento do problema, as necessidades do cliente e as oportunidades de
melhorias. Isso delimitará o escopo do projeto e deverá nortear o desenho da solução,
assim como o planejamento do projeto.
A mensuração do tamanho, complexidade e riscos de um projeto dependerá da
qualidade e coerência dos requisitos. É crucial que essa atividade seja executada de
forma criteriosa e detalhada, pois qualquer falha nesse momento poderá gerar projetos
mal sucedidos, perdas financeiras e clientes insatisfeitos.
Elicitação de requisitos
(https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/boas_praticas_para_a_elicitacao_de_requisitos)
Livro: Requirements Engineering 2nd Edition - Ken Jackson

10. Dificuldades na coleta de requisitos
● Nem sempre os requisitos são óbvios e podem vir de várias fontes.
● Nem sempre é fácil expressar os requisitos claramente em palavras.
● Existem diversos tipos de requisitos em diferentes níveis de detalhe.
● O número de requisitos poderá impossibilitar a gerência se não for controlado.
● Os requisitos estão relacionados uns com os outros, e também com o produto
liberado do processo de engenharia do software.
● Os requisitos têm propriedades exclusivas ou valores de propriedade. Por exemplo,
eles não são igualmente importantes nem igualmente fáceis de cumprir.
● Há várias partes interessadas, o que significa que os requisitos precisam ser
gerenciados por grupos de pessoas de diferentes funções.
● Os requisitos são alterados.
Livro: Requirements Engineering 2nd Edition - Ken Jackson

11. Produto de Qualidade?
Um produto somente será considerado de qualidade se estiver em conformidade com os
requisitos. Para isso, os requisitos devem ser bem especificados e agregar valor ao
produto e atender às necessidades do usuário/cliente.
A qualidade de software é o resultado de um bom gerenciamento do projeto alinhado a
uma prática consistente de engenharia de software, onde todos os processos são
devidamente controlados para assegurar qualidade no produto final.

12. Garantia de Qualidade
Para garantia de qualidade total deve-se adotar padrões tanto de processos quanto de
produto.
Padrões de processo
Ex.: especificar documentações em cada fase do desenvolvimento;
Padrões de produto
Ex.: está relacionado ao código-fonte do produto de software;

13. Pontos Fundamentais
● Podemos destacar aqui, três pontos importantes e fundamentais:
– Gestão da qualidade efetiva que tem como objetivo dar suporte e evitar o caos
no projeto;
– Um produto útil que fornece conteúdo, funções e recursos que o usuário deseja,
oferecendo confiabilidade;
– Agregar valor tanto para o fabricante quanto para o usuário, pois um software de
alta qualidade gera benefícios para ambos.

14. Qualidade Total
A qualidade deve estar presente desde a concepção do software, processo de
desenvolvimento, e até o final de seu ciclo.

15. Métricas
A “comprovação” da qualidade pode ser obtida usando métricas bem definidas, validadas
e amplamente aceitas, permitindo-nos utilização de estimativas com base na
produtividade do time envolvido no desenvolvimento do produto, recursos necessários
utilizados e tempo.
Esta medição pode ser feita direta ou indireta:
● Direta: Linhas de código, número de erros, velocidade de execução, etc..
● Indireta: confiabilidade, segurança, (algo relacionado aos requisitos não
funcionais.).

16. Tripé Qualidade

17. Conclusão
Software sem qualidade gera maior CUSTO;
- Nada adiante um software de qualidade mas que não atende as necessidades do
usuário.