The first question: why?

ArgonDigital - enterprise automation experts

Share This Post

Software has come a long way. Today’s products would amaze the developers of antiquity (only a matter of decades in computational history), just as the applications of the future will break through the present boundaries we now face. These advances won’t necessarily originate from people involved with software development. As people seek ways to solve the problems of their field, they often look to the software industry to develop the tools they need. However, concisely communicating the goal of the software usually isn’t as simple as it seems.

While the later phase of development is characterized by requirements that are complete, traceable, and consistent, getting to requirements of those qualities is a challenging process. Modeling stakeholder goals in the early stage pays dividends in the later stage due to the analysis of the ways in which the system addresses or compromises stakeholder interests.

Sometimes, it’s difficult to know where to start. An analyst recognizes that there are problems to be conquered, but without a visual aid, the software feels ambiguous. A good model with which to begin is i* (pronounced “i star”). The name comes from the notion of intentional strategic actor relationships. It gets an analyst to ask why an actor performs a task to gain a deeper understanding about a process.

Consider the example of scheduling a meeting without the aid of a computer program. Modeling the strategic dependencies is a strong component of i* which illustrates who depends upon whom.

Surely there is some software that can optimize this process. But why would we want it to change? Posing this question to the meeting initiator would reveal that the whole process of scheduling a meeting is time consuming. We would then try to build a system that still allowed the meeting initiator to achieve his goal of having the meeting participant achieve the meeting. This involves minimizing the dependencies between actors.

With the aid of a scheduler, we can see how the software will fit in terms of satisfying the meeting initiator’s goal of getting the meeting participants to attend the meeting. The scheduler will take care of three of the dependencies, sparing the initiator the details and saving him time.
The strategic dependency model puts the software into visual form and makes moving forward a bit more comfortable. Although it may seem trivial, getting everybody acquainted with why the software should exist is an important first step in actually developing it.
Are you a business analyst or a product development manager? Do you have feedback  about the development lifecycle? Do you want more on requirements models? Be sure to check out our other posts.

More To Explore