The Community Blog for Business Analysts

Dan Tasker
Dan Tasker

Requirements In Context Part 2: The Functional View From 10,000 Feet

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.(1) 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. Itoo 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 shownAnd some organisations have multiple lines of business. For example Walt Disney - Film production would be one, theme parks anotherIn 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 SAPThe 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 startingThe 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 FunctionsA 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: 

The system shall support keeping a record of offers made to selected candidates. 

I have used a variety of functional modelling techniques from dataflow diagrams to business process modelling notation (BPMN). Regardless of the terminology used in any particular method, I have found the definitions of the three functional levels presented above to be excellent guideposts for both functional modelling and drafting requirements. 

Next Time  Project Scope as a Context for High-Level Requirements 

Gathering of requirements is typically managed within a project, and part of managing a project is establishing its scope. Requirements are expected to address the things within this scope. Next time we will look at scope and how high-level requirements can be derived directly from it, and actually as part of the scoping effort. 

(1) The enterprise-wide planning methodology utilized by the company described was called Strategic System Planning (SSP) developed by Robert Holland. 

This entry was published on Apr 28, 2019 / Dan Tasker. Posted in Enterprise Analysis (BABOK KA), Requirements Analysis (BABOK KA) , Systems Analysis, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  35 members liked this article


Karl Wiegers posted on Saturday, May 4, 2019 11:00 AM
I suggest avoiding the use of the word "support" in requirements statements of any kind. It's too vague. What exactly does "support" mean in a statement like "The system shall support keeping a record of offers made to selected candidates"? If the system will simply keep a record of such offers (i.e., "support" = "provide a function to"), then just say so. But "support" can also mean "assist with," in which case it's not clear exactly what portions of keeping a record of offers the system will -- and will not -- perform. "Support" is highly ambiguous; I try not even to use it in daily conversation.

Whenever you're tempted to use the word "support" in a requirement, ask yourself just what kind of capability you're describing, and see if you can provide a more specific statement of that capability instead of leaving it to the reader to try to figure out exactly what is meant by "support" in that case.

I also suggest avoiding words like "including" in a requirement statement, as that leaves unclear whether there are other capabilities that are not stated. It's better to explicitly itemize the expected capabilities so the reader does not have to wonder how much larger the iceberg is.
Karl Wiegers
Dan Tasker posted on Monday, May 6, 2019 7:28 PM
Karl - thanks for your comments and suggestions. I typically use the term 'support' in relation to business processes that involve people performing one or more of the activities/steps of the process. Some form of user interface will be required to 'support' a user interacting with the system. If the requirement is identifying a process, then the detail of the activities within that process are to follow. If the requirement is about one or more activities being supported, presumably each activity will require interaction with the system (e.g. one or more screens).

With regards to the word 'including', I use that to add clarity to the subject of the requirement. It's not intended to be all inclusive, until the next stage (e.g. detail requirements). But any item named as being included is expected to be part of that final list.

I hope that helps you see where I'm coming from, and that subsequent parts of this series makes it clear that the end product is expected to be clear and concise.
Dan Tasker
Karl Wiegers posted on Monday, May 6, 2019 8:09 PM
Dan, my concern with writing requirements is not with what the author means by certain words, but with how the readers will interpret those words. Will every reader interpret the word "support" in the way you have described? That's not a definition I've seen before, so it's possible that readers would come to different understandings of exactly what the author means by "support." Same with "including": some readers might think that is the complete list of capabilities, others might wonder what else is supposed to be there, particularly if the word "including" is still present in the final requirement.

I believe requirements should be written in a way that maximizes clarity of communication and lack of ambiguity in the readers' eyes, and I fear that words like "support" and "including" do not achieve this objective.

If there's more information to come in a draft requirement, I like to use "TBD" instead to make it clear that some information is yet to be determined. You can scan a set of requirements for TBDs to find the holes.
Karl Wiegers
Dan Tasker posted on Monday, May 6, 2019 10:10 PM
Karl - I also believe that requirements should be written in a way that maximizes clarity of communication. This series is about taking into consideration different contexts which, I believe, contribute to clarity. I expect/hope to hear from you again in a subsequent article where I defend using the terms 'manage' and 'maintain'.
Dan Tasker
Duane Banks posted on Friday, July 12, 2019 4:57 PM
Dan, it might be more useful to refer to your LOB and Support functions as business capabilities, which can be each be decomposed level 2 and 3 (and beyond) capabilities.

The article seems to only speak to processes within a particular level 1 capability. A typical process would not be created from a top (level1) capability, but from the sub-capabilities that span multiple level 1 capabilities.
Duane Banks
Duane Banks posted on Friday, July 12, 2019 5:02 PM
“The system shall support Accounting processes integrated between themselves and with processes of other functions.”

Dan, I don't regard this a as requirement, since it provides developers very little guidance. It’s a useful scope item though.
Duane Banks
Dan Tasker posted on Saturday, July 13, 2019 1:48 PM
Duane - Thanks for your two comments. I like the term 'capabilities', and agree that the LOB and support functions I presented are very high level. I believe it's just a matter of terminology - i.e. what a given organization chooses to call different levels of functional composition. In part 4 I speak of 'automated functions', using the term function to mean something very low level. Part of my 'context is everything' view is that a given term takes on a different meaning in different contexts.

Regarding my example requirement, the article does identify this as a high-level requirement. I would not expect developers to get guidance from an HLR. To me the only context that this is a valid [high-level] requirement would be one where the organization is looking to acquire an ERP system, and it is stating (as you mention), which sub-systems within the ERP they are looking to acquire.

I hope this helps put these things in perspective, and that parts 3 and 4 of the series, now available for reading, clarify where I was headed with the article's 'functional view from 10,000 feet.'
Dan Tasker
RHarvey posted on Thursday, October 17, 2019 11:13 AM
Karl, I have enjoyed these articles on elicitation. However, I looked for but have not found your concluding article, parts 3 and 4...
Karl Wiegers posted on Thursday, October 17, 2019 11:20 AM
RHarvey, just to be clear, this series of articles on "Requirements in Context" were written by Dan Tasker, not by me (Karl Wiegers). :-)
Karl Wiegers
Dan Tasker posted on Thursday, October 17, 2019 3:19 PM
RHarvey - I'm glad you are enjoying the articles. Starting with #3 they have been promoted to articles rather than blogs. See Parts 4 and 5 are also currently available. Let me know if you're not able to find them.
Dan Tasker
Neetu posted on Thursday, March 26, 2020 9:15 AM
Its a nice article
Alisa John posted on Wednesday, July 29, 2020 3:08 AM
This blog was a priceless gift for me, especially. It gives such authentic information which will be very helpful for me and other readers as well. Thanks for writing up this. You are amazing in writing blogs; we readers need more real-life articles from you in future as well. It was really readable, and I am looking towards more articles like that.
Alisa John
Dan Tasker posted on Wednesday, July 29, 2020 4:01 AM
Alisa - I'm very glad you found this article helpful. The overall series of 8 articles has now been completed. You can see a list of links to the series at
Dan Tasker
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC