SaaS – Cenário Fictício – Levantamento de Cenários e Requisitos

Boa tarde a todos !

Continuando a nossa série “Cenários Fictícios” vamos a mais um capítulo.

Veja os outros capítulos:
Capítulo 1 : SaaS – Série - Cenário Fictício – Considerações iniciais
Capítulo 2 : SaaS – Série - Cenário Fictício – Visão do Projeto

Capítulo 3 – Necessidades de negócios (Deseja X Necessidade)

No capítulo anterior da série “Cenários Fictícios”, falamos sobre a visão do projeto e as forças que estão presentes nele. Em várias conversar com profissionais de TI, uma importante discussão é sobre o entendimento do cenário de negócio onde o projeto está situado. Além do conhecimento de patterns, tecnologias, tendências, roadmap, como Arquiteto, conhecer o negócio e as motivações do mesmo são atributos imprescindíveis para desenhar uma arquitetura adequada.

Requisitos (Requeriments)

Uma maneira de auxiliar o entendimento do cenário de negócio é identificar os requisitos do projeto. O requisito (requeriment) pode ser entendido uma capacidade esperada pela aplicação. De uma maneira didática podemos dividir os requisitos em:

Requisitos de negócios (Business Requeriments)
Os Requisitos de Negócios são aqueles que a empresa acredita que são importantes para o sucesso do projeto. Eles mostram a visão e os objetivos da aplicação. É claro que estes requisitos precisam ser transformados itens reais e tangíveis afim de serem contabilizados no projeto. Podemos citar os exemplos abaixo:

• A aplicação deve fornecer uma API aberta para ser consumida por outras aplicações, através de protocolos abertos
• A aplicação deve fornecer um conjunto de Widgets para que outros sites possam compor mesh-ups.

Note que podemos entender “novos mercados” como a capacidade da aplicação em se integrar com outros serviços Web 2.0, através de uma realidade mais tangível (APIs, mesh-ups).

Os Requisitos de Negócios são muitas vezes chamados de high-level requeriments, eles representam as visõessem detalhamento técnico.

Requisitos de usuário (User Requeriments)
Os Requisitos de Usuários são as tarefas que eles devem executar para atingir os seus objetivos. Por exemplo:

• O usuário de internet deve ser capaz de publicar uma reclamação através da Internet
• O usuário de internet deve ser capaz de visualizar o status das suas reclamações
• O Gerente deve ter um relatório para acompanhamento da evolução das reclamações via internet

Tipicamente os Requisitos dos Usuários são modelados através de casos de usos. Os casos de usos são ferramentas lúdicas que permite uma interpretação visual de “como” o usuário deve executar as suas tarefas. Por ser de fácil desenho e utilização, é muito comum o emprego de casos de usos nos diversos projetos atuais.

Requisitos funcionais (Functional Requeriments)
Os Requisitos Funcionais ou especificações funcionais representam o que os desenvolvedores devem construir para atingir os outros requisitos (Requisitos de Negócios). Estes requisitos são detalhados, normalmente escritos por um líder técnico ou arquiteto.

Os Requisitos Funcionais podem incluir protótipos de telas, pseudo code, diagramas. Quanto mais detalhado melhor para o desenvolvimento do projeto. Os Requisitos Funcionais são chamados de low-level requeriments.

Requisitos de Qualidade de Serviço (Quality of Services)
Os Requisitos de Qualidade de Serviço (Quality of Service) são os requisitos que definem de maneira contratual o comportamento da aplicação. Eles são normalmente categorizados em requisitos de desempenho, escalabilidade, segurança e padrões. Podemos dar alguns exemplos:

• Quando o usuário de internet for salvar uma reclamação, o tempo esperado é de menos de 3 segundos para salvar e retornar uma resposta.
• A aplicação deve suportar 1.500 usuários de internet simultaneamente
• A aplicação utilizará um mecanismo próprio de autenticação
• O tempo esperado de downtime (SLA) é de 99% por mês corrido

Note que os Requisitos de Qualidade de Serviço influenciam na escolha das tecnologias, plataformas, ferramentas de desenvolvimento e de produção.

Levantamento de requisitos

Identificar requisitos dentro de um projeto é um trabalho intensivo. Técnicas de entrevistas, JAD, Brainstorm, UML, Casos de Usos são algumas ferramentas para auxiliar a equipe de construção em entender, refinar, classificar e montar um requisito.

Em vários cursos e palestras que já fiz, sempre falo de que entender um requisito é separar o Desejo da Necessidade.  Aprendi que todo o projeto de desenvolvimento de software tem esta raiz comum. Para completar este raciocínio, compartilho aqui um conceito que é chamado de Hierarquia das Necessidades de Maslow. Simplificando a teoria dele, as necessidades são os guias da motivação humana, se uma determinada necessidade não for satisfeita, ela gera comportamentos negativos (por exemplo: agressivade, falta fé, pessimismo, medos) no indíviduo. Estas necessidades estão organizadas e dispostas em níveis, numa hierarquia de importância e de influência, numa pirâmide, em cuja base estão as necessidades mais baixas (necessidades fisiológicas) e no topo, as necessidades mais elevadas (as necessidades de auto realização).

De acordo com Maslow, as necessidades fisiológicas constituem a sobrevivência do indivíduo e a preservação da espécie: alimentação, sono, repouso, abrigo, etc. As necessidades de segurança constituem a busca de proteção contra a ameaça ou privação, a fuga e o perigo. As necessidades sociais incluem a necessidade de associação, de participação, de aceitação por parte dos companheiros, de troca de amizade, de afeto e amor. A necessidade de estima envolvem a auto-apreciação, a autoconfiança, a necessidade de aprovação social e de respeito, de status, prestígio e consideração, além de desejo de força e de adequação, de confiança perante o mundo, independência e autonomia. A necessidade de auto-realização são as mais elevadas, onde cada pessoa é elevada a realizar próprio potencial e o desenvolvimento contínuo.

Usando Maslow, então podemos observar que os desejos são na realidade, ferramentas que materializam-se em objetos (serviços dependendo do caso) para satisfazer as nossas necessidades. Por exemplo, porque um alguém compra uma Ferrari e não um fusca? Tecnicamente, o propósito de qualquer automóvel é locomover, ou seja, levar do ponto A para o ponto B. Mas o que leva alguém a comprar uma ferrari ao invés de um fusca? Isto pode ser explicado por Maslow, o consumidor em potencial de uma ferrari não está buscando uma ferramenta de deslocamento, mas sim uma que satisfaça a necessidade status.

O conflito de necessidades e desejos persegue todo projeto, você pode sentir isto naquele momento que o cliente já diz assim "Olha, quero um sistema que faça x, y e funciona na web". Isto é o tipo de discurso que o cliente está apresentando o desejo dele, mas não foi analisado a necessidade para aquela aplicação, como por exemplo: A plataforma web é mais recomendada para o tipo de problema? Será que as funcionalidades apresentadas conseguirão atender e resolver o problema atual?.

Neste ponto, que exige do interlocutor do projeto, a capacidade de mostrar que aquele desejo pode não resolver a necessidade latente, e junto com a equipe mostrar qual é o caminho a seguir. Fácil né? Bem, no IRL (In real life ou na vida real) não é tão fácil, pois a partir do momento que o cliente escuta "não", a coisa muda de figura e começa os jogos de poder.

Controlar as necessidades e os desejos, exige muito trabalho, precisará aguentar uma pressão, desconfiança, os conflitos. Mas se sobreviver a este momento, todos começaram a concordar e confiar. As dicas que dou para viver neste momento são:

1. Procure ouvir mais do que discutir. 
2. Procure prototipar a idéia. As pessoas discutem e pensam melhor, a partir do momento que possuem material paupável. Seja como a televisão, conquiste pelo coração.
3. Procure ver a rotina de quem usará. Bem, observando a rotina de trabalho do usuário, poderá entender porque talvez ele precise daquela solução.
4. Aprenda a dizer não. Lembre-se, doi falar não, mas doi mais ainda é dizer sim e depois não entregar o projeto.
5. Use o príncipio SMART do Microsoft Solutions Framework (Specific, Measurable, Achievable, Results-oriented, Time-bound) para entender e classificar os requisitos.

Nos próximos posts vamos continuar com esta discussão. E para quem não leu, segue os capítulos anteriores:

Capítulo 1: https://blogs.msdn.com/conde/archive/2009/05/12/saas-s-rie-cen-rio-fict-cio-considera-es-iniciais.aspx

Capítulo 2: https://blogs.msdn.com/conde/archive/2009/06/01/saas-s-rie-cen-rio-fict-cio-vis-o-do-projeto.aspx

abs e T+
Condé

versão 1.0