At the IPA (Information-technology Promotion Agency, Japan) forum held in 2011, the term “ultra-upstream process” was introduced as a new term in requirements engineering. Explaining the process and application techniques of ultra-upstream process in a lecture entitled “Ultra-upstream process to determine software quality (for correct understanding and specification of stakeholder requirements),” the IPA’s Software Engineering Center said that “in order to develop high-quality, safe and secure software, it is important to analyze stakeholder requirements without omissions, understand them correctly and describe them accurately as specifications.”
In the ultra-upstream process as defined by the IPA, a business unit should sufficiently examine the business before the system requirements definition process, and then a system unit should define the requirements after determining whether such examination is sufficient to formulate a systemization plan. In a sense, the system unit confronted the business unit with the demand to conduct sufficient business analysis prior to system development since many of the rework due to changes in requirements in the latter half of the project are caused by inadequate analysis in the initial stage of system development.
If a business unit starts system development project with abstract business goals, such as ”improving sales efficiency” and “optimizing inventory,” important business questions, such as “What exactly is the state of ‘high sales efficiency’?” and “How do we determine the optimal amount of inventory for the products we handle?” are left unanswered. While the system unit recognizes the ambiguity of such business requirements, it nevertheless starts to develop the existing CRM system or PSI system, embellished with “frontline” requirements. In many projects, Excel tables of requirements with mixed levels of abstraction are used as a tool to manage the requirements from the business side; critical business issues are moved to the “background” page of the project plan without being defined as requirements to be handled because of their high level of abstraction. Then, just as the system is beginning to take shape, the business unit recognizes the ambiguity of the requirements for the system. In the worst-case scenario, the frontline realizes that the new system will even reduce sales efficiency and require ever more complexity in managing inventory levels.
There is an initiative called Business Process Re-engineering (BPR) to remove this problem of ambiguity in business requirements. It is an approach that not only draws out system requirements from business units, but also defines business goals and designs business processes that can achieve business goals.
In order to realize BPR, it is necessary to redesign the business; and to do so, it is necessary to draw and analyze the current business processes by finding the problems of the processes based on business goals and redesign the processes to solve them. If we proceed with BPR without a clear definition of business goals and insufficient analysis and design of business processes, we will end up with a mere implementation of an existing ERP/ERP package. To resolve this problem, we have defined a process for BPR implementation called the “Inverse V Model.”
We propose the “Inverse V Model” as a process for executing BPR in the ultra-upstream process. The first half of the process is reverse engineering of the current business process, and the second half is designing of the business process based on the redefined business goals. The Inverse V Model is a business-level design layer to be added to the V Model of development. The PReP model is a method to design the business-level layer.