Documento de visão

O documento de visão captura restrições de design e requisitos de alto nível para que o cliente possa compreender o sistema que será desenvolvido. Seu objetivo é fornecer uma visão ampla do produto que se pretende desenvolver, sem se aprofundar em detalhes. É um dos artefatos da Análise Estruturada para projetos de sistemas informáticos. Ele facilita uma análise preambular deste, sendo de grande relevância durante as primeiras fases, permitindo a captura de todas as perspectivas que o sistema pode abranger. Pretende-se que sirva como ferramenta de auxílio, a evitar alguns dos problemas mais custosos com que as pessoas envolvidas no projeto poderão ter que se confrontar. Esta ajuda é proporcionada através da divulgação do conteúdo deste a todos aqueles que estejam integrados no sistema.

Todos os stakeholders e engenheiros deverão partilhar uma visão comum das necessidades e desafios que vão encarar, de forma que todos trabalhem com o propósito de atingir um mesmo fim. Ao mesmo tempo que assegura a viabilidade do projeto, uma vez que vai proporcionar ao cliente ter uma visão mais estruturada do porquê da necessidade da sua implementação, e também através da credibilidade que é adquirida, pois o cliente pode dar-se conta do valor acrescentado que o levantamento traz, proporcionando uma visão mais tangível do que o produto final virá a ser.

Dependendo do âmbito do projeto e do objetivo deste, a estrutura do documento pode abranger motes distintos, sendo que alguns deles serão comuns a todas as estruturas.

Identificação do problema

Uma das principais partes do documento é a identificação do problema, que deve envolver todas as partes envolvidas. Primeiramente devem ser detalhadas as bases do projeto. É apresentado um resumo do problema para o qual se pretende encontrar uma solução viável, disponibilizando uma breve explicação das situações que levaram à decisão para avançar com o projecto, definindo as razões da origem do problema, o historial que envolve a organização e a descrição de eventuais soluções que tenham sido aplicadas no passado para a resolução da situação.

Em seguida são identificados todos os stakeholders envolvidos no sistema, sendo estes reconhecidos por um nome, um título ou uma regra. Para cada um, deverão ser avaliadas as necessidades e quais os problemas do sistema atual, sendo ainda assimiladas quais as alternativas que estes identificam. Estes são os intervenientes do sistema, e a quem se destina o sistema.

Deverá também ser definida uma lista dos utilizadores, sendo estes identificados por um nome, um código ou uma outra regra qualquer, sendo que, se o seu número for muito grande, pode tornar-se ineficiente a sua identificação, podendo ser agrupados em grupos menores coerentes entre si. As necessidades de cada um deles deverão ser descritas com algum detalhe.

A seguir, devem também ser ilustrados os factores que poderão evidenciar-se como eventuais ameaças para o sucesso do nosso projecto. Estes deverão ser identificados numa sessão de brainstorming com todos os elementos da equipa. Pode identificar factores externos que possam causar qualquer tipo de impacto negativo, ou problemas que possam causar atrasos na entrega final.

Por fim deve ser elaborada uma lista das previsões que os stakeholders, os utilizadores ou os elementos da equipes fizeram. Ilustra todas as situações que se estão a prever ter de enfrentar e para as quais se vai procurar encontrar soluções.

Visão da solução

A visão da solução fornece informações sobre um possível caminho para solucionar o problema já identificado. Primeiramente define-se uma indicação, que visa descrever o que a solução do projeto virá a fornecer. Ela deve explicar qual o propósito do projeto e esclarecer a razão pela qual se vai despender tempo, dinheiro e recursos para o seu desenvolvimento. Esta secção deverá ser escrita depois de se ter falado com todos os utilizadores e stakeholders, e de se ter consciência de quais as suas necessidades. Por esta altura já se deve ter uma ideia mais ao menos concreta de como o projeto deverá vir a ser elaborado. Esta visão deve ser acompanhada pelo levantamento de domínio em que se insere a solução, através de uma analise de domínio.

A seguir é criada uma lista de características, sendo que, cada característica identifica uma área do software que tem como função, fornecer um conjunto de serviços que venham a prover a solução para um dos requisitos. O número de características identificadas num projeto estará dependente do nível de detalhe com que se pretende efectuar a análise e do número de características estão combinadas numa só. Convém que o número de características não seja demasiado grande, pois pode conduzir a que se torne demasiado maçudo para quem o vai ler. Demasiadas características trazem para o projeto um grau de complexidade muito grande, podendo inclusive tornar a sua estimativa irreal, uma vez que cada uma destas implica tempo e esforço para o seu desenvolvimento. Cada uma deverá ser descrita num parágrafo, identificada com um nome, seguida de uma breve descrição que deverá indicar qual a funcionalidade que vai facultar. Se existir alguma informação que um utilizador ou um stakeholder julgue crucial, esta deverá ser incluída, detalhando a implicação que tem no sistema.

Uma fase intermediária opcional é a criação de níveis. No caso do projeto vir a ser efetuado em várias fases, ou de ser constituído por vários lançamentos, deve-se detalhar quais as tarefas a serem efetuadas na fase atual.

Por fim são definidas as capacidades que foram identificadas, como mais valias na implementação, mas que por alguma razão não vão ser implementadas nesta entrega do produto.

Estrutura do documento

Abaixo é detalhada uma possível estrutura de um documento de visão. Note que ela pode variar de acordo com as necessidades do projeto.

Introdução Deverá proporcionar uma abordagem inicial ao documento de visão e qual o propósito deste.
Sub-seção	Motivação
Propósito do documento de visão	Ponto onde se deverá detalhar o desígnio deste documento, analisando e definindo as necessidades e desafios que o projecto em questão levanta.
Breve descrição do Produto	Identificar qual o propósito da aplicação, se existem versões, qual é aquela em que se encontra, quais as características associadas e funcionalidades mais importantes.
Referências	Provém um conjunto de referências para documentação que é referida ao longo de todo o documento. Nesta parte podemos incluir livros, páginas web, artigos científicos, estudos de mercado, etc.
Descrição dos utilizadores	Breve descrição da perspectiva dos utilizadores do sistema. Aqui devem estar incluídos todos os elementos que vão interagir com o sistema.
Mercado	Indica quais as razões do mercado que levaram à decisão da implementação do novo produto. Pode ser apresentada uma análise de domínio. Deve ser dada especial atenção ao porquê de surgir este produto.
Perfis do Utilizadores	Descrever em perspectiva cada um dos intervenientes no sistema. Deve ser dada atenção ao seu papel dentro do sistema e ter bem delineado o seu raio de acção.
Ambiente de trabalho	Descrever qual o ambiente de trabalho de cada um dos utilizadores, indicando qual as ferramentas e ambientes utilizados, especificando modelos de uso. Deve realçar o ambiente actual existente, bem como as aplicações utilizadas.
Necessidades	Abordar quais as necessidades ou problemas apontados pelos utilizadores do sistema. Deve ser detalhado o que levou à detecção de que o produto actual não é satisfatório ou a motivação subjacente ao desenvolvimento de um novo produto.
Alternativas	Identificar as alternativas apontadas pelos utilizadores.
Visão do Produto Visão geral do produto a desenvolver.
Sub-seção	Motivação
Perspectiva do produto	Dar a ideia do produto através da sua interacção com componentes já existentes. Se possível mostrar um diagrama de blocos do produto ou do sistema e as interfaces com os elementos externos.
Indicações da posição do produto	Fornecer uma indicação genérica que sintetize qual a posição do mercado que o produto pretende alcançar. Se possível indicar quais as lacunas que o produto vai preencher.
Sumário das capacidades	Fazer um resumo de quais os benefícios e características que o produto vai proporcionar. Devem ser detalhadas as características mais importantes do produto e o seu resultado final, podemos recorrer a casos de uso para ilustrar estas características.
Suposições e dependências	Pressupostos de como deverão ser implementados algumas das características da aplicação e pontos em que o seu funcionamento esteja dependente de elementos externos. Apesar de ter algum nível de detalhe neste ponto não devemos detalhar nenhuma arquitectura, para não condicionarmos o levantamento de requisitos e o desenvolvimento.
Custo e Preço	Descreve os elementos que vão justificar o custo do produto e antecipa o preço deste. Pode ser ilustrado através de uma tabela custo e benefício, dando ênfase à parte dos benefícios que vamos obter depois do sistema implementado.
Características do produto / Atributos das características Deve listar as características que estão associadas ao produto. Descreve os atributos que vão ser utilizados para avaliar, controlar, tornar prioritárias ou identificar cada uma das características. Pode ser utilizada uma lista de prioridades (com uma escala quantitativa ou qualitativa), de forma escalonar e realçar as características mais importantes.
Casos de Uso Descreve através da utilização de casos de uso (que ajudem os utilizadores a compreender melhor como o sistema tende a ser implementado) e como é pretendido que este venha a ser utilizado. Estes casos de uso não devem ser demasiado detalhados, para poderem ser entendidos por todos os intervenientes.
Outros requisitos do produto
Sub-seção	Motivação
Padrões aplicáveis	Deve detalhar todos os padrões que o produto pretende satisfazer. Pode ser útil no futuro de forma a validar a conformidade com os padrões propostos.
Requisitos do sistema	Define quais os requisitos necessários para que a aplicação funcione correctamente. Aqui podemos ter a especificação do sistema operativo, a capacidade da rede, as características de hardware entre outros.
Licenças, segurança e instalação	Indica quais as questões relacionadas com licenças, com a segurança ou com a instalação, para que a aplicação possa funcionar de acordo com o que foi definido inicialmente. Pode conter a referência a outros produtos.
Requisitos de performance	Identificar os requisitos necessários para tirar o melhor partido da aplicação. Deve ser estabelecido o mínimo desejável, bem como o nível de performance normal.
Requisitos da documentação Descreve a documentação necessária que deverá vir a ser elaborada para servir de suporte ao produto. Pode detalhar qual a documentação que poderá vir a ser fornecida com o produto.
Sub-seção	Motivação
Manual do utilizador	Descreve o propósito e conteúdos que a aplicação faculta. De uma forma pouco detalhada, deve conter as características base da aplicação e como as utilizar, podendo no entanto ser muito mais detalhado. No entanto, num documento de visão, ainda não conhecemos todos os detalhes do produto, para podermos elaborar uma manual demasiado detalhado.
Ajuda Online	Lista um conjunto de tópicos de ajuda mais comuns, para uma rápida pesquisa de soluções para situações anómalas detectadas.
Guias de instalação, configuração e ficheiros Leia-me	Conjunto de documentação que sirva de ajuda na instalação e parametrização da aplicação. Serve de apoio ao arranque da aplicação e pode ser sobre a forma de um guia rápido, de um sistema passo a passo, ou outro.
Glossário	Nesta secção são apresentados os termos técnicos utilizados ao longo do documento.

Benefícios

Todos os projectos informáticos durante o seu desenrolar passam por situações mais ou menos complicadas. Através da utilização de um documento de visão inicial do sistema, podemos contribuir largamente para ultrapassar essas situações.

Os clientes poderão aperceber-se do valor que se está a acrescentar ao projecto ao se efectuar a captura dos requisitos. Estes poderão ter uma percepção mais realista do produto final após efectuada esta captura. Esta captura deve ser antecedida de uma análise de domínio onde se insere este produto, conferindo-lhe uma maior credibilidade.

É essencial que todas as partes envolvidas no desenrolar do projecto tenham a convicção de que o resultado final será bem sucedido. A preparação deste documento vai contribuir em grande medida para assegurar o sucesso final, servindo de vínculo entre todas as partes envolvidas no projecto desde a primeira hora.

O documento de visão vai ajudar a que os clientes tenham uma percepção mais detalhada daquilo que existe, e como funciona todo o processo, antes da implementação, e qual os resultados que se vão obter após o produto estar concluído. Ajuda a que estes tenham a noção mais clara de todos os benefícios que vão alcançar.

Ver também

• Sistemas de informação
• Engenharia de software
• Engenharia de requisitos
• Análise de domínio
• Workshop de requisitos
• Brainstorming
• Casos de uso

Referências

Alberto