The Community Blog for Business Analysts

In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts will be explored. And in keeping with this principle it set business information systems as the context of the requirements to be addressed. 

Classic Business Functions 

My very first position as a business analyst 30 years ago was with a company that had just completed an enterprise-wide planning effort.⁽¹⁾ They had gone so far as to remodel one of their conference rooms for the specific purpose of displaying the results on multi-layered whiteboards. The most prominent board displayed a functional model of the business. It was said to be a view of the company from 10,000 feet up. The functions were organised into three categories: Management, Support and Line of Business.The following diagram is a slightly simplified version of that model: 

In my first article I presented the classic “Swings” cartoon. It is a classic because it has remained relevant all these years. I consider the high-level functional model presented above to be a classic. It too has stood the test of time. Throughout my years as a business analyst, working in a wide variety of industry segments and government agencies in three countries, this model has proved to be both relevant and useful.  

Not all organisations utilise every one of the functions shown. And some organisations have multiple lines of business. For example Walt Disney - Film production would be one, theme parks another. In this style of model, each would have its own ‘Line of Business’ functions to provide contexts for dealing with very different products. Regardless of the numbers of lines of business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning 

Thirty years ago using a model like this to plan an organisation’s business information systems was leading edge. Database management systems had been around just a few years. Their use typically involved one-for-one replacement of application-specific files. A batch processing inventory management system would be upgraded to an online inventory management system supported by an inventory database. A batch processing sales management system would be upgraded to an online sales management system supported by a sales database. And on and on. 

High-level functional models like this were used to demonstrate to the organization that a shared set of data could and should be used to support multiple functions across the business. The idea was to stop developing application-specific information systems and start developing an enterprise-wide one. Fast forward to today and this vision has become business as usual for many organisations.  

It is common today for an organisation to have a relational database that holds data utilised by multiple business functions. Some of these systems have been developed in-house. Others utilise one of the commercially available Enterprise Resource Planning (ERP) systems. Probably the original and best known of these is SAP. The following is a list of integrated SAP modules that an organisation to pick and choose from:  

• Human Resource Management  

• Production Planning  

• Material Management  

• Financial Supply Chain Management  

• Sales and Distribution  

• Project System  

• Financial Accounting and Controlling  

• Plant Maintenance  

• Quality Management  
   

Quite a striking correlation between these modules and the high-level functions from that 30 year old model. 

High-level Requirements From High-level Functions? 

This series of articles is about requirements in context. The Functional context is where we are starting. The functions from the 10,000 foot level are the most general functional context I can imagine. Could these be used to draft requirements? I can think of one scenario where they could - an organization interested in acquiring an ERP system. Here is an example of one such high-level requirement: 

 The system shall support Accounting processes integrated between themselves and with processes of other functions.  

Each ERP function the organisation is interested in should have its own requirement naming a high-level function it wants within its integrated system. Each would be assigned its own priority. Some would likely be must haves while others might only be nice to haves. (Who am I kidding? – we all know that to business users every requirement is a ‘must have.’) 

Processes within Functions 

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP system we need business functions closer to earth. Fortunately the majority of functional modelling techniques include the concept of functional decomposition. That technique used to produce the model above offered a simple three-level decomposition scheme. The things at the top level were called Functions. A level below functions were things called Processes. The third and lowest level things were called Activities.  

Functions were considered to be ‘ongoing’ activities. A person working in Accounting or HR does their job year round, year in and year out. Processes in the context of this model were defined to be things that have a start and an end point. A given Function typically would decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks down into 12 processes: 

• Organizational Management 

• Personnel Administration 

• Recruitment 

• Payroll 

• Travel Management 

• Personnel Management 

• Time Management 

• Compensation Management 

• Training and Event management 

• Wages 

• Personnel Development 

• Workforce Administration

It’s easy to envision most, if not all of the above processes having start and end points. For example, while it could be argued that Recruitment goes on continuously, in reality filling a specific position starts with some form of notification of the opening and ends ideally with a successful candidate coming on board. Here is an example of a high-level requirement utilising a Process context: 

The system shall support the recruitment process including keeping records of published notifications, candidates, interviews and proof of fairness during the selection process. 

Activities within Processes 

The term Activity can be defined as the individual steps in a process. Visualise a workflow diagram. The boxes in the diagram that don’t themselves require further decomposition would be considered activities. The basic idea is that an Activity is that it should be simple enough that an individual is able to complete it in a single ‘sitting.’ No need to hand the work off to anyone else mid-activity or to have to wait for some other activity to complete. An example of an activity within the Recruitment process would be one called “Make Offer to Candidate.” An example of a high-level requirement ustilising an Activity as a context would be: