RequisitosRequisitos

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

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

Definição

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

Tipos

FuncionaisNão funcionais

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

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

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

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

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

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.

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;

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.

Qualidade Total

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

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.).

Tripé Qualidade

Conclusão

Software sem qualidade gera maior CUSTO;

- Nada adiante um software de qualidade mas que não atende as necessidades do usuário.