Uma descrição resumida do produto com a qual todos os investidores concordem é fundamental para o sucesso do projeto. A descrição do produto deve definir, em alguns parágrafos, o que será o produto, que problemas ele solucionará e por que ele é necessário. A descrição não deve se aprofundar nos itens específicos do problema, mas deve criar um argumento convincente a favor da necessidade do produto. Ela deve ser breve, no entanto, para que seja facilmente compreendida e lembrada por todos os membros da equipe.

O contexto do negócio ajudará os investidores no projeto a entender e concordar com o mercado pretendido para o produto. O mesmo conjunto de requisitos, interpretado por diversos clientes, pode estar relacionado a sistemas distintos.

O contexto do negócio define o mercado pretendido para o produto, inclusive o domínio no qual o sistema será operado (por exemplo, telecomunicações, transações bancárias, comércio na Web, etc.) . Se o domínio for bem compreendido, uma descrição resumida será suficiente. Contudo, para alguns mercados, pode ser necessária uma descrição mais completa do espaço de problemas. A definição do mercado deve incluir produtos semelhantes e identificar empresas ou soluções concorrentes.

Se o produto está sendo desenvolvido para atender a um contrato, os termos do contrato devem ser observados. Se importantes marcos precisam ser passados, deve ser observado o cumprimento dos termos do contrato.

Se o produto for o aprimoramento de um produto já existente, este deverá ser descrito.

A Cadeia de Resultadospode fornecer informação valiosa para a compreensão do contexto, tais como as premissas do negócio.

Informe os objetivos para o desenvolvimento do produto - os motivos de sua importância. Fazem parte desse processo um esboço e uma avaliação dos riscos da programação. Objetivos claramente definidos e expressos garantem uma base sólida para a formulação de marcos e o gerenciamento de riscos, isto é, a manutenção do projeto sob controle e a garantia de seu sucesso.

Consulte a Cadeia de Resultados da qual o projeto faz parte para extrair dela informações sobre a contribuição do produto para a organização.

Para um produto de software comercial, o Caso de Negócio deve incluir um conjunto de suposições sobre o projeto e a ordem de importância do ROI (retorno do investimento) se essas suposições forem verdadeiras. Por exemplo, o retorno do investimento terá importância cinco, se concluído em um ano, dois, se concluído em dois anos, e um número negativo, após esse tempo. Essas suposições são verificadas no fim da fase de elaboração, quando o escopo e o plano já estão melhor conhecidos. O retorno baseia-se na estimativa de custo e nas estimativas de possíveis lucros.

No caso de projetos de software internos, o retorno será calculado em termos do 'Valor Líquido Presente' do projeto ou em termos de uma taxa interna de retorno. Com o valor líquido presente, o futuro stream de fluxos de caixa acumulados no projeto serão calculados (inclusive os fluxos de caixa negativos relacionados ao desenvolvimento e suporte do projeto) e, em seguida, descontados com base em uma taxa de retorno determinada pela organização de acordo com o risco do projeto. Um valor líquido presente superior a zero indica que o projeto representa um benefício economicamente positivo para a empresa.

No caso da taxa interna de cálculo para o retorno, pressupõe

Expressar as restrições para o desenvolvimento do projeto. Essas restrições envolvem riscos e custos. Elas podem ser algo como interfaces externas com as quais o sistema deve ser compatível, padrões, certificações ou abordagens técnicas empregadas por questões estratégicas, como a utilização de uma certa tecnologia de banco de dados ou de mecanismos de distribuição.

Descrever as opções para o produto - recursos e características opcionais e os custos e benefícios a eles associados - e as opções para a abordagem do projeto. As opções do projeto devem incluir diversas bases contratuais, diversos ciclos de vida do projeto, diversas combinações de 'fazer' e 'adquirir', e assim por diante. Em cada caso, o efeito da opção sobre a previsão financeira e as restrições (o risco de impacto) deve ser descrito. O objetivo é oferecer aos gerenciadores com autoridade para financiar o projeto alguma amplitude para a tomada de decisões em termos de capacidade, custo, ROI, benefícios intangíveis e aproveitamento de oportunidades de negócios, programação, base para contrato, ciclo de vida de desenvolvimento, restrições técnicas e outros itens.

Em um contexto de análise de caso de negócio baseado em valor, cada fase do ciclo de vida apresenta diversos trade-offs de negócios, determinando opções de abordagem do projeto.

Durante a fase de Iniciação:

• Analisar, a partir dos objetivos iniciais do projeto, trade-offs de custo, cronograma e funcionalidade, usando técnicas de análise de ...
• Determinar o preço do produto de software (ou outra atividade do projeto que gere receita) usando análise de tendências para prever o voluma de vendas necessário.
• Requisitar orçamentos usando análise de custo/benefício para justificar as despesas necessárias.

Durante a fase de Elaboração:

• Conduzir análise entre "fazer" e "adquirir" (make-or-buy), para determinar como preencher melhor a arquitetura usando técnicas de análise de retorno e de oportunidade de investimento.
• Desenvolver orçamentos para o custo do software e cronograma usando modelos como o COCOMO II (BOE2000) para estimar o esforço e a duração necessária.
• Priorizar riscos (positivos e negativos) através de uma avaliação quantitativa dos impactos dos itens de risco.

Durante a fase de Construção:

• Decidir quanto ao lançamento ou não de uma versão ou incremento do produto baseando-se em análise de tendências (por exemplo, olhando para defeitos e níveis de qualidade associados).
• Desenvolver estimativas de custo e cronograma de conclusão, usando modelos para determinar se é possível ou não entregar como prometido, dependendo da taxa de progresso atual.

Durante a fase de Transição:

• Conduzir trade-offs entre "consertar" ou "substituir" (replace/repair) usando técnicas como análise de Pareto, para determinar quais módulos do software estão mais sujeitos a defeitos.
• Desenvolver estimativas quanto à manutenção, usando modelos de custo para prever esforço e duração baseado em projeções estatísticas de mudanças.