Por que é tão difícil?

Definir Análise de Objetivos é fácil.
Aplicar Análise de Objetivos é difícil.

A complexidade do que é necessário fazer deve funcionar como um desestimulante na indústria para se aplicar a análise de objetivos, mesmo que muitos já tenham percebido a sua importância. A academia ainda precisa encontrar uma maturidade e uma usabilidade nos métodos e ferramentas que permitam a popularização dessa atividade que oferece benefícios à Engenharia de Requisitos, e por consequência à Engenharia de Software, cujo produto é o próprio software.

Algumas dificuldades/problemas que podem ser apontados:

• Há uma quantidade significativa de métodos e ferramentas. E ainda por cima eles não são integrados;
• Não há padrões claramente estabelecidos;
• A comunicação com os stakeholders é complicada - elicitar objetivo é difícil, pois as pessoas podem fazer algo sem saber dizer exatamente porque faz aquilo, entre outras considerações;
• Sendo a análise de objetivos um processo de refinamento - até quando refinar? Qual é o ponto de parada ideal?
• O reconhecimento do que deve ser identificado como goal e do que deve ser requirement;
• O reconhecimento do que deve ser identificado como hard goal e do que deve ser soft goal;
• O reconhecimento do que deve ser identificado como goal e do que deve ser task;
• O estabelecimento de relacionamentos entre goals, entre agentes, entre goals e agentes;
• Qual é o tipo correto de relacionamento (dependência? delegação?);
• Se existir, qual(is) é(são) a(s) alternativa(s) de um objetivo?
• Se existir, qual(is) é(são) a(s) contribuição(ões) de um objetivo?
• ... (melhor parar com a lista, por enquanto).

Essas dificuldades/problemas precisam ser superadas. Algumas serão sanadas a medida que a área ganhar maturidade. Outras, deixam a impressão de que essa atividade continuará sendo uma atividade essencialmente complexa e que deve ser executada por um profissional de larga experiência.

Enterprise Architecture

Uma nova sigla que se juntou a verdadeira "sopa de letrinhas" que os profissionais da computação estão acostumados a lidar é EA (Enterprise Architecture). Tal área surge como uma estratégia de união entre a tecnologia da informação e o meio empresarial.
Para que as organizações possam retirar o máximo de vantagens das tecnologias de informação disponíveis é preciso que tais tecnologias estejam adaptadas às necessidades das organizações. A primeira palavra que vem à mente nessa união certamente passa pela informatização de Processos.

E no que isso está relacionado com a Análise de Objetivos?
Processos existem para satisfazer Objetivos. Para melhor compreender um processo é necessário ter em mente o(s) objetivo(s) que ele atende. Dessa forma, ao invés de simplesmente informatizar o processo que existe naquele momento é possível entender a sua motivação, o motivo de sua existência,  e mesmo conferir se o processo é adequado, é o melhor para atender ao objetivo ao qual está relacionado. E ao se perceber tal situação, além da visão de processos, começou-se a trabalhar também com a modelagem de objetivos, inicialmente em um caráter bastante informal, mas caminhando em direção a um formato mais adequado para beneficar a EA.

Requirements x Goals

A Análise de Objetivos é desenvolvida com o propósito de oferecer benefícios à Engenharia de Requisitos (ER), e pode desempenhar um papel fundamental para o sucesso desta etapa da Engenharia de Software em um projeto.
No entanto a Análise de Objetivos ainda precisa atingir um estágio de maturidade, de estabilidade, para que possa conquistar o mercado. Atualmente há, por exemplo, muitos métodos com focos diferentes. Não há algum método, hoje, contemplando todas as atividades associadas a análise de objetivos. De uma certa forma, lembra a situação que os métodos e notações da Orientação a Objetos enfrentavam antes que a UML fosse lançada.

Como será a "UML" da Análise de Objetivos? Quando será que ela vai surgir? Será da Academia ou do Mercado, ou de uma parceria entre ambos?

Outra questão interessante, e que é difícil de efetivamente entender e aplicar é a própria diferenciação entre o que é um requisito (requirement) e o que é um objetivo (goal). Um objetivo é definido como algo que o sistema quer atingir, enquanto um requerimento é uma característica que o sistema deve/precisa ter. São conceitos parecidos e complementares. Um requisito pode ser encarado como um refinamento de um objetivo. É dito que um requisito tem um critério de corte preciso quando comparado ao objetivo. Tratando objetivos e requisitos como complementos, em diferentes níveis de abstração, poderíamos encará-los como uma estrutura de árvore, na qual se começa com objetivos de mais alto nível de abstração que vão sendo sucessivamente refinados, aumentando os níveis da árvore até um nível de abstração menor. Os nós-folha de tal árvore são justamente os requisitos.

Mas até onde detalhar? Como reconhecer que uma característica é efetivamente um objetivo ou um goal? Parece ser uma distinção sutil, mais subjetiva, que pode variar de analista para analista, dependendo de uma série de considerações, e principalmente da experiência do analista.