Desenhando e Desenvolvendo Aplicações em .NET Framework - Parte I

Requerimentos e Desenho de uma Aplicação

É importante entender a visão para uma determinada aplicação. A visão é normalmente definida pelo patrocinador e administrador do projeto. Eles possuem o orçamento; é o problema do negócio deles que você tentará resolver. Seu trabalho é traduzir a visão deles em software tangível. Isto não é nenhuma tarefa fácil.

São pedidos frequentemente para os arquitetos e desenvolvedores de aplicação que ajudem ao analistas de negócio a construir um consenso na visão e definição de metas, como também numa lista de requerimentos para a aplicação.

Uma vez que você tenha esses itens em mãos, você pode começar o processo de avaliar, recomendar e refinar o desenho para aplicação.

Avaliando Requerimentos e Propondo um Desenho

Obter um entendimento comum entre o negócio, usuários e os desenvolvedores é a meta principal dos requerimentos de uma aplicação. Quase todas aplicações empresariais construídas por profissionais, definem e documentam requerimentos. Como esses requerimentos são documentados, aceitos, e gerenciados frequentemente diferem de um projeto para outro.

Uma boa lista de requerimentos incluem requerimentos que são definidos vindos de múltiplas perspectivas. Isso faz muito sentido. Todos projetos têm múltiplas influências. O Negócio (ou patrocinadores) possuem uma lista de objetivos e metas para aplicação. Usuários definem tarefas específicas que eles necessitam realizar. Desenvolvedores e Testadores necessitam saber que características específicas serão requeridas para tornar essa aplicação um sucesso. Existem requerimentos necessários à suporte e manutenção da aplicação, performance e escalabilidade, e mais.

A meta é definir o suficiente esses requerimentos para assegurar o sucesso do projeto.

Requerimentos de Negócio

Um requerimento de negócio define o que o negócio acredita ser importante para o sucesso do projeto. O negócio normalmente inclui a administração ou patricinadores, que são os fundadores do projeto. Eles frequentemente definem requerimentos em termos de visão e metas para aplicação. Porém, estas metas precisam ser transformadas em realidade, requerimentos tangíveis.

Por exemplo, considere um requerimento de negócio que declara, "A nova versão deverá nos permitir vender a aplicação para novos mercados." Esta é uma grande meta para o sistema. Isto ajuda a justificar a despesa de desenvolvimento dentro do qual irá abrir novos canais de vendas e mercados e, consequentemente, aumento de rendas e lucros. Porém, esta meta precisa ser transformada em um requerimento de negócio real. Na realidade os requerimento de negócio de alto-nível que derivam desta meta poderiam ser visto como o seguinte:

1) O Sistema precisa incluir metadata para suportar todos os conceitos conhecidos. Isto permitirá que empresas em diferentes mercados utilizem estes conceitos baseados em sua própria tecnologia.

2) O Sistema precisa implementar um padrão aberto para troca de informações de dados de vendas. Isto permitirá que todos os mercados interoperem com a aplicação.

3) O Sistema precisa suportar a definição de pacotes característicos para mercados específicos.

Você pode ver que estes são requerimentos tangíveis amarrados a uma meta para suportar múltiplos mercados. Também é importante notar que estes são requerimentos de alto-nível - que são requerimentos sem especificações detalhadas. Os requerimentos podem ser mantidos e localizados a um nível alto. Um arquiteto de aplicação terá que traduzir requerimentos em especificações e desenho. As especificações e desenho não devem, porém, incluir, alterar ou excluir requerimentos.

Requerimentos de Usuários

Requerimentos de usuários são tarefas que os usuários devem poder realizar para satisfazer os objetivos de seus trabalhos. A maioria dos desenvolvedores estão acustumados a receber ou documentar requerimentos de usuários. Isto tipicamente envolve sentar e discutir com os usuários o que exatamente o desenvolvedor terá que fazer para ajudá-los. Abaixo, os requerimentos de usuários de alto-nível.

1) Um representante de atendimento ao consumidor deve poder fazer um pedido para um cliente.

2) Um usuário de poder consultar o estoque disponível e determinar o número de unidades de um determinado produto em estoque.

3) O usuário deve poder ver o histórico do pedido dentro de uma lista. Deve ser capaz de selecionar a ordem da lista e ver seus detalhes.

Estes são todos os requerimentos de usuários de alto-nível. Eles carecem de definição de casos de usos e especificações.

A primeira pergunta que um analista de negócio poderia fazer, por exemplo é "Como?" Como um representante de atendimento coloca um pedido para um cliente? O usuário detalhará então os passos que são envolvidos neste processo. Estes passos representam o caso de uso para o representante colocar um pedido para o cliente. Este caso de uso ajuda a tornar claro o requerimento. Além disso, um arquiteto deveria definir as especificações para o determinado requerimento. Desenvolvedores precisam saber o que constitui um pedido, que campos são requeridos, que regras são processadas, e assim por diante.

Requerimentos Funcionais

Requerimentos funcionais ou especificações funcionais, são caracteríticas que os desenvolvedores precisam construir para satisfazer outros requerimentos. Estes requerimentos são tipicamente definidos em grandes detalhes para ajudar aos desenvolvedores entender exatamente o que precisam desenvolver. Os requerimentos funcionais são tipicamente feitos por um lider técnico ou arquiteto. Eles não são requerimentos de usuários ou de negócio.

Um requerimento funcional, por exemplo, poderia ser a criação de uma Web page em ASP.NET, para administrar o perfil de um cliente. A especificação funcional deveria incluir o nome da página, os controles usados na página, as regras de validação de entradas (input), as regras de segurança para a página, as classes que deverá ser chamada para suportar as funcionalidades da página, e assim por diante.

Como você pode ver, as especificações funcionais podem ser muito detalhadas. Frequentemente é melhor fazer o desenho funcional em lugar de escrever requerimentos funcionais. Isto permite você tirar vantagem da modelagem da aplicação com ferramentas como Visual Studio e algum código para definir a funcionalidade do sistema. Desenvolvedores frequentemente entendem melhor estes itens. Além disso, ganha-se tempo em documentar estes itens em dois lugares diferentes (modelos de documentos e códigos).

Requerimentos de Qualidade de Serviços

Um requerimento de qualidade de serviço define o contratual ou requerimentos não funcionais para o sistema. Requerimentos de qualidade de serviço tipicamente não representam problemas de usuários específicos, ao contrário, elas definem os requerimentos ao redor das coisas como, desempenho, escalabilidade e padrões.

Estes requerimentos não deveriam ser negligenciados. Eles precisam ser definidos e considerados durante a arquitetura e desenvolvimento da aplicação. Abaixo, alguns exemplos de requerimentos de qualidade de serviço:

1) Todas as requisições de páginas do site deveriam retornar ao usuário em cinco segundos em conexão banda larga.

2) O sistema deveria escalar, dentro de um cenário de servidor único (olhar especificação do servidor) para 25 usuários simultâneo e 400 usuários ativos com standard think times.

3) O sistema deveria usar o Microsoft Windows integrated security, para segurança das páginas e identificação dos usuários.

Você pode ver que os requerimentos de qualidade de serviço são muito importantes. Eles avançam definindo o que a aplicação precisa suportar vindo de uma perspectiva não funcional. Você precisa chegar a estas informações no inicio do projeto para tomar decisões sábias sobre como recomendar e implementar tecnologias para um determinado problema de negócio.