Business Requirements

In the field of systems development, we distinguish between different kinds of requirements, such as top level requirements, business requirements, user requirements, and system requirements. 

Business requirements refer to the overarching needs and constraints imposed by an organisation's stakeholders on the solutions to a problem. They delineate the range of acceptable solutions to the problem, but without going too much into the solution. User requirements in contrast dictate needs relating to how the solution will be operated, maintained, and used.

Some of the business requirements, in order to be met, will also generate user and system requirements (eg business requirements to meet policies relating to disability).

Business requirements can derive from organisational policies, strategies, business case, and a range of other sources.

Examples of business requirements are:

• The solution must cost no more than $100m
• The technology platform must be AWS (or Azure, or Google) - for example, because organisational policy requires that IT solutions use these platforms.
• The solution must be fielded by 2nd quarter of 2025, to align with the strategy.
• The solution must meet data privacy policies.
• The solution must meet policies supporting users with disabilities.

Systems Engineering Bibliography

Buede, Dennis M. The Engineering Design of Systems: Models and Methods, 3rd Edition. John Wiley & Sons, 2016.

Strong focus on function analysis and decision analysis.  Good introduction to IDEF0.

Chapman, William L., Terry Bahill, and A. Wayne Wymore. Engineering Modeling and Design. Boca Raton, FL: CRC Press, Taylor & Francis Group, 2019.

Forsberg, Kevin, Hal Mooz, and Howard Cotterman. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems. Hoboken, NJ: J. Wiley, 2005.

The rare project management book that gives emphasis on the critical importance of systems engineering.

Gibson, John E., William T. Scherer, William F. Gibson, and Michael C. Smith. How to Do Systems Analysis: Primer and Casebook. Hoboken, NJ: Wiley, 2017.

Teaches systems analysis (systems decision making) rather than systems engineering.  Systems analysis is an essential practice in systems engineering.  Bahill's book on trade-off analysis is another one of few books on the subject.

Hitchins, Derek K. Systems Engineering a 21st Century Systems Methodology. Chichester, West Sussex, England: John Wiley, 2007.

Kossiakoff, Alexander, Steven M. Biemer, Samuel J. Seymour, and David A. Flanigan. Systems Engineering: Principles and Practice. Hoboken, NJ: John Wiley & Sons, Inc., 2020.

James, Martin. N. System Engineering Guide Book. Springer, 1997.

Rechtin, Eberhardt. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, N.J: Prentice Hall, 1991.

Sage, Andrew P., and Andrew P. Sage. Systems Engineering. New York: J. Wiley & Sons, 1992.

Stevens, Richard J. Systems Engineering: Coping with Complexity. London: Pearson/Prentice Hall, 1998.

Walden, David D., Garry J. Roedler, Kevin Forsberg, R. Douglas Hamelin, and Thomas M. Shortell. INCOSE Systems Engineering Handbook: a Guide for System Life Cycle Processes and Activities. Hoboken, NJ: Wiley, 2015.

Wymore, A. Wayne. Model-Based Systems Engineering: an Introduction to the Mathematical Theory of Discrete Systems and the Tricotyledon Theory of System Design. Boca Raton: CRC Press, 1993.

Dude, Where's My System?

What are the user requirements for using an ATM? The most obvious ones are: ability to withdraw cash, ability to check account balance, ability to make deposits.

But how about others: ability to retrieve all the coins and cash in the ATM, ability to unjam the ATM if things get stuck, ability to physically move the ATM?

They are not requirements of the bank's customers, but they all valid user requirements. The user requirements depend on who the users are.

To build a successful systems, it's necessary to identify who the users of the system are. The 'who' does not mean specific persons, but categories (or types) of users.  For an ATM, these can include: the paying stakeholder, bank customers, customers of other banks with whom the ATM's bank has arrangements with, bank personnel who need to manage the ATM, security personnel, network staff who need to ensure the ATM is connected, back office bank staff who need to analyse and report on data about ATM usage, and so on.

It's clear that if we miss one of the categories of users, we will be unlikely to have miraculously provided system functionality that satisfies their needs.

One challenge to identify categories of users occurs when we are building new systems that are not merely upgrade of existing systems. In this case, there are currently no existing users.  The categories of users would need to be identified.  Other sources, such as the concept of operations, or the operating model are sources of an initial set of users. 

Does your system development process include a rigorous identification of the system users?

References:

Stevens, R. J. (1998). Systems engineering: Coping with complexity. London: Pearson/Prentice Hall.

Another Root of Evil

Premature allocation of requirements is the root of many system architecture evils.

(With a hat tip to Donald Knuth, who coined: "Premature optimization is the root of all evil.")

***

The Real FR vs NFR Requirements

Any professional working with requirements is familiar with the abbreviations FR (Functional Requirements) and NFR (Non-Functional Requirements). This categorisation attempts to distinguish one type of requirement from the other. It's an unfortunate exercise to separate them so distinctly because FRs often need to be described with their accompanying NFRs, while NFRs are often met by implementing a set of FRs.

However, we can reuse the FR vs NFR distinction in some other ways. Proposed below is a list of the more important ones:

Fictional vs Non-Fictional Requirements – Fictional requirements are not really requirements. They are designs, solutions, or wishes masquerading as requirements.  Non-fictional requirements are real requirements.

Factional vs Non-Factional Requirements – Factional requirements are those pushed for by only a certain set of stakeholders. Other stakeholders couldn’t care less about these. Non-factional requirements are required by the system and transcend individual factions.

Frictional vs Non-Frictional Requirements – Frictional requirements are contentious, either to some stakeholders or to other requirements. They also cause friction in the system development by causing the majority of the delays. 

Fallacious vs Non-Fallacious – Fallacious requirements are requirements that are properly written (they are Non-Fictional), but aren’t what is needed. Non-Fallacious requirements are requirements that are needed.

Fundamental vs Non-Fundamental – closely related are Fundamental requirements, which are essential to meeting the objectives. Non-Fundamental requirements are 'nice to haves'. Ironically, building only Non-Fundamental requirements does not result in a nice system.

Function vs Non-Function – Function requirements are about what the system needs the user to be able to do (‘The user must be able to cancel a transaction’). The user is replaced if they cannot perform the function. Non-function refers to user attributes and capabilities (‘The user must have the ability to view the most recent transactions' -- perhaps by possessing SQL skills?)

Familiar vs Non-Familiar – requirements that are common to many systems. These include management reports, etc. Non-familiar requirements are those that haven't appeared before in the project's collective experience.

Favourite vs Non-Favourite – Favourite requirements are flashy requirements sponsored by someone. They tend to be given attention. Non-Favourites languish or are implemented and tested perfunctorily. No one notices if they run away.

Falsifiable vs Non-Falsifiable – Falsifiable requirements are those that can be shown to not exist. Non-Falsifiable requirements cannot be proven to have been met. A quintessential example being ‘The system must be user friendly’. 

Fat vs Non-Fat – Fat requirements are a clump of requirements stated as one single requirement, often with multiple adjectives.  They tend to clog the process. Too many can result in a project heart attack. Non-Fat requirements are singular, and are processed through without harmful effect.

Fiscal vs Non-Fiscal – Fiscal requirements relate to cost ( ‘The solution shall not cost more than $X per transaction’)

Filial vs Non-Filial – Filial requirements are those that can be traced to a parent requirement. They show respect, and obedience, and conform to their parents wishes. Non-Filial requirements are either orphans or contradict their parent requirements. They cause family infighting and should be made to either conform, or else be cut off from family tree.

Fecund vs Non-Fecund Requirements - Fecund requirements are prone to keep popping out new requirements -- annoying, smelly, little new requirements that need lots of care and feeding.

Book Review ‘Capability Cases’

Capability Cases: A Solution Envisioning Approach
Irene Polikoff, Robeert Coyne, Ralph Hodgson

Introduces the concept of ‘Capability Cases’ – a concept made up one or more functions that collectively provide a business value.

 

 

 

Titles referenced in the book:

Title	Author	Remarks and link to Amazon
Towards an Architecture Handbook	Bruce Anderson
The Timeless Way of Building	Christopher Alexander
Real Options:Managing Strategic Investment in an Uncertain World	Martha Amram and Nalin Kalatilaka
Creativity – The Magic Synthesis	Silvano Arieti
Information Systems Development	D. E. Avison and G. Fitzgerald
Learnings and Inquiry Based Reuse Adoption	S. Bailing, M. Simos, L. Levine, and R. Creps
Web Services and Service-Oriented Architectures	Douglas K Barry
Extreme Programming Explained	Kent Beck
Designing Hard Software – The Essential Tasks	Dougla Bennett
Multiple Criteria Decision Analysis: An Integrated Approach	Val Belton and Theodoer J. Stewart
Software Configuration Management Patterns: Effective Teamwork, Practical Integration	Stephen Berczuk, Brad Appleton
The Creative Mind: Myths and Mechanisms	Margaret A. Boden
The Mythical Man-Month and Other Essays on Software Engineering	Frederick P. Bookrs
The Social Life of Information	John Seely Brown and Paul Duguild
Web Services, E-Business, and the Semantics Web	C. Bussler, R. Hull, S.A. McIlraith, M.E.Orlowska, B. Pernici, and J. Yang
The Mind Map Book	Tony Buzan
Scenario-Based Design	J.M. Carroll
Enterprise Service Bus	David A. Chappell
To be continued…

The Problem and the Non-Solution

What’s wrong with presentations like the table below?  You’ll find tables like that in many enterprise communications.

Problem	Solution
Customers moving to a competitor’s product.	Increase product information campaign to let customers know the benefits of our product
Employees unhappy about the new salary arrangements.	Provide a channel for employees to voice their concerns.

Let’s ignore the actual problems and solutions as shown – they are just vehicles for this discussion.  The problem with solutions like this is that there is no description of the desired effect that will dissolve (or reduce) the problem.  For problem number 1, what is the intended effect of the solution? Is it to stop the customers from moving to the competitor?

Before a solution to a problem is proposed, we need to first identity the effect we want.  What will the world be like once the (still unknown) solution has been put into effect? For the first problem, perhaps what we want to achieve is a stanching of the flow of customers to the other side.  Next, we ask what is the measure?  How do we measure the effect?  One measure might be the number of customers per month moving to the competitor.  The higher the better. 

By this method, we make it clearer what we want the solution to do.  We make it clear what the mission of the solution is: to stanch the flow of customers to the competitor. 

We can come up with several solutions to this.  For example, we might decide we want to offer additional perks to our products.  Or we might decide to lower our prices.  The next question is: which of these solutions might be the most effective?  That is, which one will more considerably deliver the effect we want?  We can measure solutions by several attributes.  These would include the number of losses it stops, the cost to implement the solution, the length of time required for the solution to be implemented, and so forth.  We decide which solution offers the best bang for buck based on these attributes (using systems analysis).

Only in this way can we show the solid relationship between the problem, the effect desired that dissolves the problem, and the solution that will bring the intended effect.

What are the Different Kinds of Requirements?

ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy.  So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean. 

F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.

Another major classification of requirements is that between business and system requirements.  The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document).  The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.

If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.

One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.

Mission Requirements

At the top of the requirements hierarchy lie the mission requirements.  An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’.  A concept of a solution is developed and mission level requirements are developed.  These requirements specify what is needed from the solution in order that it will meet the business objectives.  The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.

These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.  

Stakeholder Requirements

Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements?  If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need?  These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version). 

Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation.  They also need to be reviewed for completeness.  Stakeholders tend to provide only the most salient requirements prominent in their mind.

Derived Requirements

The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements.  Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language.   Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement.  From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.

System Requirements

System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.

Component Requirements

Component Requirements are Derived Requirements which specify what specific components must meet.  For example, for a web-based system, components might include requirements for web servers and database management systems. 

There are other ways to classify requirements, but they are orthogonal to the above.  For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.

Comparing the BABOK and SEBOK, Part 6

The BABOK Knowledge Area called “Elicitation” shares some overlap with some of the contents of the SEBOK Knowledge Area called “Concept Definition”, which discusses the elicitation of requirements, among other topics related to concept definition. 

How do the BABOK and SEBOK compare in their coverage of requirements elicitation?

The BABOK “Elicitation” Knowledge Area

This Knowledge Area’s topic is the drawing forth of requirements from the various stakeholder, and documenting these requirements.

The first thing that strikes me about the BABOK’s coverage, is that it’s extremely generic and lacking any real depth.  Most of the discussion touches on what the elicitation tasks are, what the most common inputs are, what the most common elicitation techniques are, and what the most common outputs are.  Notice that I prefixed each item in the list with a ‘what’, because that is pretty much all that the BABOK covers. 

It does not address the why’s and the how’s.  It merely mentions nouns with very little fleshing out.   As an example, one of the outputs is a Requirements Management Plan.  There is no discussion about such a plan contains.  The BABOK identifies which tasks produce this plan, and which tasks use it as input, but that’s about it.

SEBOK Elicitation Coverage

The SEBOK does not have a specific Knowledge Area focused solely on Elicitation.  However, elicitation of stakeholder requirements is discussed under “Stakeholder Needs and Requirements”, which is a topic under the ‘Concept Definition’ Knowledge Area.

The SEBOK distinguishes between ‘needs’ and ‘requirements’.  In fact, it speaks of activities necessary to ‘identify and prioritize the needs of stakeholders, as well as transform those needs into requirements’

The SEBOK stresses that the stakeholder needs (which are obtained as a result of the process of elicitation), are to be transformed into stakeholder requirements.  I could not find something similar in the BABOK, which seems to treat the elicited stakeholder needs as requirements, evidenced by a statement like this:

“Requirements [Stated, Confirmed]: Identical to Requirements [Stated] for all practical purposes, including use as an input to other tasks.”

The SEBOK explains that requirements come from needs (i.e., they are more formal and precise expressions of needs).  It also goes into fair detail about the different types of needs:

• Real Needs
• Perceived Needs 
• Expressed Needs 
• Retained Needs
• Specified Needs
• Realized Needs

Comparison of Elicitation Techniques

Both the SEBOK and BABOK give us a list of common techniques used for elicitation.  This table blow shows their lists:

BABOK	SEBOK
Brainstorming	Structured Brainstorming Workshops
Document Analysis	Technical, Operational, and / or Strategy Documentation Review
Focus Group
Interface Analysis
Interviews	Interviews
Observation
Prototyping (including Storyboarding, Navigation Flow, Paper Prototyping, Screen Flows)	Prototyping
Requirements Workshops
Survey / Questionnaire	Questionnaires
	Simulations and Visualisations
	Modelling
	QFD (Quality Function Deployment)
	Use Case Diagrams
	Activity Diagrams
	Functional Flow Block Diagrams

Comparison of Outputs

The BABOK ‘Elicitation’ activities and the SEBOK ‘Stakeholder Needs and Requirements’ activities produce outputs. The table below compares the outputs:

BABOK Outputs	SEBOK Artefacts	Remarks
Elicitation Results	Stakeholder Interview Reports	A record of what was elicited from the stakeholders.  This is subject to further processing and formalisation.
Scheduled Resources		A schedule of when the elicitation activities will take place, when, how, and who will be involved
Stakeholder Concerns [Unconfirmed / Confirmed]		Issues identified by the stakeholders.  These include assumptions, concerns, risks, and constraints.  The Confirmed version has been signed-off by the stakeholder.
Supporting Materials		“Any materials required to help explain the techniques used or perform them” (BABOK).
Requirements [Stated / Confirmed]	Stakeholder Requirements Document	BABOK - Stakeholder needs as stated by the stakeholder. The confirmed version is signed-off by the stakeholder. SEBOK – does not provide an description of ‘Stakeholder Requirements Document’
	Stakeholder Requirements Database
	Stakeholder Requirements Justification Documents	SEBOK – The SEBOK says this is for ‘traceability purposes’

Comparison of Tasks and Processes

The BABOK provides a clear list of key Tasks related to Elicitation and I have listed them in the table below.  Unfortunately, the SEBOK does not gather the activities in such a defined way.  I collect the main activities mentioned throughout the text and list them in the same table below, for ease of comparison.

BABOK Elicitation Tasks	SEBOK Activities	Remarks
Prepare for Elicitation
Conduct Elicitation Activity	Elicitation
Document Elicitation Results
Confirm Elicitation Results

In conclusion, the SEBOK coverage has more depth and meat.  The BABOK coverage could provide more information in upcoming versions.  As it stands, its current coverage is merely a mapping of inputs to outputs with virtually no description of what characteristics a good quality output should have, and no description of the processes that produce the outputs.  I also think it should deliver more distinction between stated needs and the requirements derived from those needs.

Comparing the BABOK and the SEBOK, Part 5

I want to take a second look at the Knowledge Areas identified by the BABOK and those by the SEBOK, specifically where there is an overlap between the two sets. 

I want to do this in preparation for a deeper comparison of their treatments of their Knowledge Areas and Tasks and Activities.

The table below lists the Knowledge Areas for the BABOK, and what to me might be the corresponding Knowledge Area addressed in the SEBOK.  As can be immediately seen, the SEBOK Knowledge Areas cover a lot more topics.

BABOK Knowledge Area	SEBOK Knowledge Area	Remarks
	Systems Fundamentals
	Systems Science
	Representing Systems with Models
	Systems Approach Applied to Engineered Systems
	Life Cycle Models
	System Deployment and Use
	Product and Service Life Management
	Systems Engineering Standard
Business Analysis Planning and Monitoring
Elicitation	Concept Definition	This SEBOK KA contains the following Activities: Mission Analysis Stakeholder Needs and Requirements
Requirements Management and Communication	System Definition Systems Engineering Management	“Requirements Management” is very briefly treated in the SEBOK under the “System Requirements” topic, which is under the System Definition KA. Configuration Management is considered part of the BABOK KA “Requirements Management and Communication”. In the SEBOK, Configuration Management is discussed under the Systems Engineering Management KA
Enterprise Analysis	Concept Definition	This SEBOK KA contains the following Activities: Mission Analysis Stakeholder Needs and Requirements
Requirements Analysis	System Definition	The topic of "System Requirements” addresses assessing the quality of the requirements and their prioritisation. System Requirements is a topic under the KA System System Definition
Solution Assessment and Validation	System Realization	This SEBOK KA contains the following Activities: System Implementation System Integration System Verification System Validation
	Product Systems Engineering
	Service Systems Engineering
	Enterprise Systems Engineering
	System of Systems
	Enabling Businesses and Enterprises
	Enabling Teams
Underlying Competencies	Systems Thinking Enabling Individuals
	Systems Engineering and Software Engineering
	Systems Engineering and Project Management
	Systems Engineering and Industrial Engineering
	Systems Engineering and Procurement / Acquisition
	Systems Engineering and Specialty Engineering

In the next post on this topic, I will start comparing the contents of the matching Knowledge Areas.

Comparing the BABOK and the SEBOK, Part 4

In this post I’ll compare how the two documents structure their presentation of a Knowledge Area (KA).

BABOK Knowledge Area Structure

The BABOK discusses each of its KA in turn.  The discussion starts with a short overview of the KA,  followed by an Input / Output Diagram showing the Tasks under that KA, the Inputs required by the Tasks, and the Outputs generated by the Tasks (and by extension the KA).

The core of the Knowledge Area is its Tasks, and the BABOK structures the presentation of the KA around the Tasks.  Each Tasks is described in turn using the following sections:

1. Purpose of the Task – brief explanation of the focus of the Task.
2. Description – usually more details about the Task.
3. Input – a list of information (typically documents) needed for performing the Task, also describing why each Input is used for.  This section is accompanied by a context diagram showing the Task, the Inputs it requires, the Task Outputs, and downstream Tasks using the Outputs as Inputs.
4. Elements – describes considerations relevant to the Task which need to be addressed for a successful execution of the Task.
5. Techniques – lists the most common techniques used in performing the task.  Techniques are methods or tools such as ‘Interviewing’, or ‘Brainstorming’.  All of the Techniques are described in more detail in Chapter 9, so this section is just a listing.
6. Stakeholders – is a list of organisation titles generally involved or interested in the Task execution.
7. Output – a list of the Outputs of the Task (generally documents).

SEBOK Knowledge Area Structure

As we have seen in the previous post, the SEBOK has many more KA’s than the BABOK.  Not only are there many more, the scope is more extensive.  Whereas the BABOK KA’s are narrow enough that one can expect every practicing BA to be knowledgeable at a professional level in ALL the KA’s (though perhaps not all the Techniques), the SEBOK KA’s are so expansive, it is unlikely that a majority of professional SEs would have high quality proficiency in all the SEBOK KAs.

Each KA is divided into Topics (contrast with ‘Tasks’ for the BABOK), which confusingly is also called ‘Activities’.  The KA itself is described in great detail (far greater than what is done in the BABOK).  After which a list of Reference work is provided.

After providing a detailed discussion of the KA, each of the Activities under that KA are discussed using the following structure:

1. Introduction – brief narrative about the Topic 
2. Purpose and Definition – detailed description of the Topic / Activity
3. Principles and Concepts - key concepts one needs to know about the Topic.  Depending on the topic being discussed, this can be fairly comprehensive.
4. Process Approach / Activities of the Process – description of the subtasks performed for the Activity
5. Artifacts – listing of most common outputs (generally documents) for the Activity
6. Methods and Modeling Techniques – listing and description of key Techniques one can expect to be used to perform this Activity.  (For the most part, the SEBOK uses the single-ell spelling ‘modeling’, but sometimes also uses ‘modelling’)‘
7. Practical Considerations – tips and lessons learned from the trenches.  
8. References – comprehensive list of Works Cited, Primary References, and Additional References relevant to the Activity.  Since the SEBOK is merely a 'Guide’ to the Body of Knowledge, this References section makes eminent sense – it points to where the reader can go to get more of the Knowledge.

Comparison of the Structures

The table below compares the KA presentation structure of the two BOKs

BABOK	SEBOK	Remarks
Overview	Introduction	Neither of these sections are titled as such.  Both sections are untitled narratives.
Purpose of the Task	Purpose and Definition
Description	Purpose and Definition
Input		It is very surprising that SEBOK seems to have no equivalent section
Elements	Principles and Concepts Practical Considerations
	Process Approach / Activities of the Process	The BABOK has no equivalent
Techniques	Methods and Modeling Techniques
Stakeholders		The SEBOK has no equivalent section
Output	Artifacts
	References	The BABOK references are all collected at the end of the Guide, where it is far less useful for someone wanting to know more about a specific Task.

Comparing the BABOK and the SEBOK, Part 3

Knowledge Areas are subject matters of core interest to a profession or discipline.  They are the sort of knowledge often required to live the profession.  In the medical profession, a knowledge area might include physiology, how the body functions.  For project managers, an example might be scope management.

Knowledge Areas

For the BABOK, Knowledge Areas:

define what a practitioner of business analysis needs to understand and the tasks a practitioner must be able to perform.

In other words, it is an area that a Business Analyst should have knowledge on.

For the SEBOK, Knowledge Areas:

are groupings of information with a related theme

The SEBOK is reluctant to assert that an SE must know about the Knowledge Areas (henceforth KAs), whereas the BABOK claims the KAs are what the BA ‘needs to understand’ and ‘able to perform’.  The difference in these scope will become evident as we look at the KAs listed by each of the BOKs.  We can now say that the BABOK KAs are far more modest in scope than the SEBOKs.

The BABOK Knowledge Areas

The BABOK lists seven KAs:

1. Business Analysis Planning and Monitoring
2. Elicitation
3. Requirements Management and Communication
4. Enterprise Analysis
5. Requirements Analysis
6. Solution Assessment and Validation
7. Underlying Competencies

The BABOK KAs are closely related to skills.  One can develop ‘Business Analysis Planning and Monitoring’ skills, or ‘Elicitation’ skills.

The SEBOK Knowledge Areas

The SEBOK not only lists far more KAs than the BABOK, but the breadth and depth of the subject matter is in a different league.

The SEBOK KAs are divided into 5 Parts, each of which has KAs under it.  Here’s the full list of Parts and KAs under them:

1. Part 2 – Systems
   1. Systems Fundamentals
   2. Systems Science
   3. Systems Thinking
   4. Representing Systems with Models
   5. Systems Approach Applied to Engineered Systems
2. Part 3 – Systems Engineering and Management
   1. Life Cycle Models
   2. Concept Definition
   3. System Definition
   4. System Realization
   5. System Deployment and Use
   6. Systems Engineering Management
   7. Product and Service Life Management
   8. Systems Engineering Standard
3. Part 4 - Applications of Systems Engineering
   1. Product Systems Engineering
   2. Service Systems Engineering
   3. Enterprise Systems Engineering
   4. System of Systems
4. Part 5 – Enabling Systems Engineering
   1. Enabling Businesses and Enterprises
   2. Enabling Teams
   3. Enabling Individuals
5. Part 6 – Related Disciplines
   1. Systems Engineering and Software Engineering
   2. Systems Engineering and Project Management
   3. Systems Engineering and Industrial Engineering
   4. Systems Engineering and Procurement / Acquisition
   5. Systems Engineering and Specialty Engineering

The SEBOK list of KAs is comprehensive, ranging from the abstract subject of Systems, down to performance assessment of individual SEs.

At a first approximation, it seems to me that the scope of the BABOK KAs fall within this subset of the SEBOK KAs

1. …
2. Part 3 – Systems Engineering and Management
   1. Life Cycle Models
   2. Concept Definition
   3. System Definition
   4. System Realization
   5. System Deployment and Use

No surprise, SE is far more broad than BA if the KAs are to be the basis.  But that is not the main point of this series.  The key interest is where they overlap.   We will look more closely at these overlapping KAs in the next parts.

Comparing the BABOK and the SEBOK, Part 2

Business Analysis and Systems Engineering seem to share a substantial in their perceived areas of scope, so it might be informative to see what their respective BOK Guides say about the other discipline.

Do They Know Each Other?

It is interesting that neither the term “Systems Engineering” nor its variant “System Engineering” appear in the BABOK.  This is strange because the BABOK authors are evidently aware of the SE discipline, since the BABOK Bibliography includes these two SE-centric books:

Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. System Engineering, Coping with Complexity

Forsberg, Kevin, Hal Mooz, and Howard Cotter-man. 2005. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems

As for the SEBOK, it mentions “business analysis” three times, each time using it as a synonym for mission analysis, such as in this extract:

MA, in some domains called market analysis (glossary) or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise (p. 253).

Judging from this, the SEBOK considers business analysis as limited to mission analysis, which is only a part of the Concept Definition Phase

What is Business Analysis?

If Business Analysis is synonymous to Mission Analysis (according to SEBOK), it should be useful to compare and contrast BA as understood by the BABOK with MA as understood by the SEBOK. 

The table below lists the functions of BA as described by BABOK, and the functions of MA as described by SEBOK.  I tried to match them, with some degree of interpretive freedom on my part.

Business Analysis According to BABOK	Mission Analysis According to SEBOK
Liaison among stakeholders
Understand the structure, policies, and operations of an organisation
Recommend solutions that enable the organisation to achieve its goals	Analyse the solution space
Understanding how organisations functions to accomplish their purpose
Defining the capabilities an organisation requires to provide products and services
Definition of organisational goals
Define how goals connect to specific objectives
Determine courses of action that an organisation has to undertake to achieve those goals and objectives
Defining how the various organisational units and stakeholders within and outside the organisation interact.
	Establish a set of stakeholder requirements for a potential SoI (System-of-Interest)
	Focuses on the identification of the primary purpose(s) of the solution
	Part of the larger set of concept definition activities -
	Understand a mission / market problem or opportunity
	Initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity
	Define operational actions, not hardware / software functions; that is, it is focused on defining the problem space, not the solution space
	The primary products of MA are the revised ConOps of the enterprise, the operational concept, the operational scenarios for the mission, and the context in which the solution will exist.
	MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions).
	MA defines the problem space and analyses the solution space alternatives using quality attribute constraints driven by the enterprise objectives.

I could not match the two sets of functions and find very little, almost no direct intersection between what Business Analysis is according to BABOK, and what Mission Analysis is according to the SEBOK (which treats business analysis as a synonym for Mission Analysis.

And yet, my instinct tells me there is a strong intersection, it’s just that the two BOKs use very different terminology and very different ways of explaining.  (I find the BABOK a bit more refined in its explanations, while the SEBOK tend to ramble a bit).

Number of Pages

This is an easy comparison.  Version 2.0 of the BABOK has 253 pages.  The SEBOK is primarily laid to for reading online using a Wiki platform, but a PDF version is available for download.  This PDF runs to 850 pages.  Better have a full ream of office paper ready if you decide to print this.

Authors

The SEBOK lists 70 authors, some of whom I recognise as respected leaders in the SE discipline.  The ones I know by reputation include: Barry Boehm (but I know him from the software engineering field, not the SE field), Erik Aslaksen, Edmund Conrow, Dov Dori, Kevin Forsberg, and James Martin.

The BABOK also credits as Content Contributors about 19 names, of whom the only one I recognise (but recognise only the name, not what she’s about): Ellen Gottesdiener.  They do have an Expert Advisory and Review Group, from which I recognise the following names: Scott Ambler, Dean Leffingwell, Meilir Page-Jones, James Robertson, Suzanne Robertson, Steve Tockey.

Comparing the BABOK and the SEBOK, Part 1

I find it interesting that the disciplines of Business Analysis and Systems Engineering share an apparently substantial overlap in their areas of declared responsibilities and specialties.

In the domain of system related projects, both specialise in requirements development, in cost / benefit analysis, in solution assessment and selection, and in verification and validation of the solution.  Could it be they are one and the same thing?

The SE community recently completed its SEBOK Version 1.0 (Systems Engineering Body of Knowledge), available at http://www.sebokwiki.org.  The BA community, through the auspices of the IIBA, has its BABOK (Business Analysis Body of Knowledge), currently at version 2.0 (available at the IIBA website). 

I think it will be interesting to compare the two documents and see what each has to say in areas they have in common, but also in areas which the other is silent.  Where exactly are they similar?  How do they differ?

Since both documents are lengthy, I’ll do the comparisons in several parts. 

To start, let’s look at what each BOK has to say about their particular discipline. 

What is Systems Engineering?

What is Systems Engineering? SEBOK offers this brief definition:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems

This is a very thin definition, almost to the point of meaningless.  One can probably can use it to describe project management, or even portfolio management, both of which can be argued as enabling the realisation of successful systems. The SEBOK also provides a longer description:

“an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2012). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.

In the glossary, it provides two other definitions, taken from unrelated official documents. The first is from ISO/IEC/IEEE 2010 which says that Systems Engineering is an:

Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life.

The SEBOK also quotes the INCOSE Systems Engineering Handbook (v 3.2.2). The first sentence is exactly the same as SEBOK’s definition:

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

The focus therefore, of SE is defining what the customer needs, and delivering the solution that fills the need.

What is Business Analysis?

The BABOK provides the following:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

So, where SE is an ‘approach’ that ‘governs’ and ‘integrates’, BA is a ‘set of tasks and techniques’ and is meant as ‘liaison’. 

The BABOK continues:

Business analysis involves understanding how organizations function to accomplish their purposes, and defining the capabilities an organization requires to provide products and services to external stakeholders. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.

Here we get some clarity about the focus of BA work: the organisation.

Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.

Business analysts must analyse and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the business analyst will also work to facilitate communication between organizational units. In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

While BA work is clearly meant to identify the customer requirements, it is clear that BA work sits in the non-technical area of the organisation, specialising in what the organisation does and needs.  In contrast, the SE definition does not make it clear whether the SE is more focused on the technical aspects of the solution (we can assume so from the word ‘Engineering, but that is not the same as having it asserted directly).

A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.

When you do work that is in the BA domain, you are doing Business Analysis, regardless of title.  So if you are an SE, you might also be a BA.

I’ll continue the comparison in another post.

Mission Requirements

Clarity in Mission Requirements is critical concept to successful solutions.

People in the solution delivery profession are generally informed about requirements.  Business Analysts, Software Developers, Solution Architects, Project Managers, know about the terms business requirements and system requirements, as well as functional requirements and non-functional requirements.

But seldom heard is the term ‘mission requirements’, which is interesting because it is the most essential of all the requirements of a system. Mission requirements are the raison d’etre of the system, its reason for being, the purpose for which the system is being produced.  All other requirements are subordinate to the mission requirements, and are derived from the mission requirements. 

The reason for the total absence of mission requirements in enterprises is undoubtedly because the word ‘mission’ itself is not part of the business vernacular.  One hears of the ‘vision’ for the enterprise, and its ‘mission’ but that is something quite different.

The phrase ‘mission requirements’ comes from the military and aerospace community.  A mission refers to the intention of the system, often a weapons system.  For example, a fighter plane’s mission is to shoot down enemy aircraft.  A Patriot missile battery’s mission is to shoot down incoming missiles. 

A system is assigned a mission because the super-system (the system which contains the system of interest), has objectives, and they perceive that to achieve the objectives, the system must be able to meet the mission requirements.

Mission requirements focus on the external system, not the system being built.  It is no surprise that mission requirements are measured using metrics called ‘Measure of Effectiveness’ .  This is about how well the solution is impacting the super-system and helping it achieve its objectives.

Think about a car.  A car with a top speed of 100mph.  It is impossible to say whether such a car is suitable or not without considering the mission for which it will be used, the part it will play.  If the car is to be used for transporting kids to and from school, then it’s perfectly suitable.  If it’s to be used to win a race, then it’s probably inadequate.

There is a hierarchy of requirements, and not the simple categorisation into just two: business,  and system requirements, is not rigorous enough. 

At the top of the hierarchy is the mission requirements.  All other requirements are derived from it, or in support of it.  These requirements must be set out very clearly.

Systems Engineering–Coping with Complexity

A readable introduction to Systems Engineering. 

 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (Sometimes, I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Winning at New Products	Robert G Cooper	Amazon
Metrics and Case Studies for Evaluating Engineering Designs	William L. Chapman, F. David Van Voorhees, A. Terry Bahill, Jay Alan Moody	Amazon
The Anatomy of Major Projects	Peter Morris	Amazon
Systems Thinking, Systems Practice	Peter Checkland	Amazon
Turn Signals are the Facial Expressions of Automobiles	Donald Norman	Amazon
21sr Century Jet – The Making of the Boeing 777	Karl Sabbagh	Amazon
The Sources of Innovation	Eric Von Hippel	Amazon
Object-Oriented Software Engineering: A Use Case Driven Approach	Ivar Jacobson	Amazon
Principles of Software Engineering Management	Tom Gilb	Amazon
UML Distilled: Applying the Standard Object Modeling Language	Martin Fowler, Kendall Scott	Amazon
Real Time Structured Methods	Keith Edwards	Amazon
Object-Oriented Modeling and Design	James Rumbaugh	Amazon
Notes on the Synthesis of Form	Christopher Alexander	Amazon
The Rise and Fall of Strategic Planning	Henry Mintzberg	Amazon
Normal Accidents: Living with High Risk Technologies	Charles Perrow	Amazon
MANPRINT – An Approach to System Integration	Booher	Amazon
Value Analysis and Value Engineering	Frederick Oughton	Amazon
Invention by Design: How Engineers Get From Thought to Thing	Henry Petroski	Amazon
The House of Quality	J. Hauser, D. Clausing	Amazon
To Engineer is Human	Henry Petroski	Amazon
Product Development Performance	Clark	Amazon
Design Methods	Christopher-Jones	Amazon
Software Inspection	Tom Gilb, Dorothy Graham	Amazon
The New Rational Manager	Kepner	Amazon
Against the Gods: The Remarkable Story of Risk	Peter Bernstein	Amazon
The Sciences of the Artificial	Herbert Simon	Amazon
Managerial Economics	Evan Douglas	Amazon
Mastering the Dynamics of Innovation	James Utterback	Amazon
The Product Manager’s Handbook	Linda Gorchels	Amazon
Intellectual Capital	Thomas Stewart	Amazon
New Products: The Key Factors in Success	Elko Kleinschmidt	Amazon
Systems Engineering Guidebook: A Process for Developing Systems and Products	James N. Martin	Amazon
A Quantitative Approach to Software Management	Kevin Pulford	Amazon
Skunk Works	Ben Rich	Amazon
The New Organizational Wealth	Svieby	Amazon
Peopleware: Productive Projects and Teams	Tom DeMarco, Tim Lister	Amazon
A Methodology for Systems Engineering	A. D. Hall	Amazon This is a classic.
The Fifth Discipline: The Art and Practice of the Learning Organization	Peter Senge	Amazon
Guns, Gems and Steel: The Fate of Human Society	Jared Diamond	Amazon
The Blind Watchmaker	Richard Dawkins	Amazon

Visualizing Project Management

The 2nd edition of this book was my introduction to the subject of systems engineering.  Because it is one of the very few that discusses the critical importance of systems engineering to project management, I still consider it one of the best project management texts around. 

Project management is about organising the work required to deliver a product or service.  Its competence is in organising the work and making it go forward to completion within the planned cost and schedule.  It has no competence in determining whether the end product is going to be effective or not.  Systems engineering provides this competency.

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (sometimes I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Search for the Real and Other Essays	Hans Hoffman (ed.)	Amazon
Communicating Project Management	Hal Mooz, Kevin Forsberg, Howard Cotterman	Amazon
A Guide to the Project Management Body of Knowledge	Project Management Institute	Amazon
Ship of Gold in the Deep Blue Sea	Gary Kinder	Amazon
General and Industrial Management	Henri Fayol	Amazon
Star Teams, Key Players	Michele Jackman	Amazon
Superior Teams: What They Are and How to Develop Them	Dennis Kinlaw	Amazon
Lean Thinking: Banish Waste and Create Wealth in Your Corporation	James Womack	Amazon
Final Report of the Columbia Accident Investigation Board	NASA	Amazon
Theories of Human Communication	Stephen W. Littlejohn	Amazon
Phenomenology of Communication: Merleau Ponty’s Thematics in Communicology and Semiology	Richard L. Lanigan	Amazon
Communicate with Confidence! How to Say it Right the First Time and Every Time	Dianna Booher	Amazon
Powerful Conversations: How High-Impact Leaders Communicate	Philip J. Harkins	Amazon
How the Way We Talk Can Change the Way We Work: Seven Languages for Transformation	Robert Kegan, Lisa Laskow Lahey	Amazon
Jack Welch and the GE Way: Management Insights and Leadership Secrets of the Legendary CEO	Robert Slater	Amazon
The Power of Little Words	John L. Beckley	Amazon
The Professor and the Madman	Simon Winchester	Amazon
McGraw-Hill Dictionary of Mechanical and Design Engineering	Sybil Parker, ed	Amazon
Tutorial: System and Software Requirements Engineering	R. H. Thayer, M. Dorfman, eds	Amazon
The 7 Habits of Highly Effective People	Stephen R. Covey	Amazon
People and Performance: The Best  of  Peter Drucker on Management	Peter F. Drucker	Amazon
Dynamic Project Management	Deborah S. Kezsbom, Donald Schilling, Katherine A. Edward	Amazon (links to the new version of the book)
NASA GPG 7120.5 System Engineering	Systems Management Office, NASA GSFC	Amazon
NASA NPG 7120.5C Program and Project Management Processes and Requirements	AE/Office of Chief Engineer, NASA HQ	Amazon
DoDI 5000.2 Acquisition Management	DoD	Amazon
ISO 15288, “Systems Engineering: System Life Cycle Processes”	ISO	Amazon
Microsoft Secrets	Michael Cusumano,  Richard Selby	Amazon
Partnership Pays: Project Management the Øresund Way	Helena Russell	Amazon Website
The Path Between the Seas	David McCullough	Amazon
The Art of Systems Architecting	Eberhardt Rechtin, Mark W. Maier	Amazon (link to 3rd edition).  Some people prefer the older version authored by Rechtin
Systems Engineering: Coping with Complexity	Richard Stevens, Peter Brook, Ken Jackson, Stuart Arnold	Amazon
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed.	Craig Larman	Amazon
Apollo 13	Jim Lovell, Jeffrey Kluger	Amazon
Skunk Works	Ben R. Rich, Leo Janos	Amazon
Moving Mountains	William G. Pagonis	Amazon
The Bishop’s Boys: A Life of Wilbur and Orville Wright	Tom D. Crouch	Amazon
An Essay Concerning Human Understanding	John Locke	Amazon
The Innovator’s Dilemma	Clayton M. Christensen	Amazon
The QFD Book: The Team Approach to Solving Problems and Satisfying Customers through Quality Function Deployment	L. Guinta, N. Praizler	Amazon
Business @ the Speed of Thought	Bill Gates	Amazon
The New Rational Manager	Charles H. Kepner, Benjamin B. Tregoe	Amazon
Engineering Complex Systems with Models and Objects	David Oliver, Timothy P. Kelliher, James G. Keegan Jr.	Amazon
Tropic of Capricorn	Henry Miller	Amazon
Team-Based Project Management	James P. Lewis	Amazon
In Search of Excellence	Tom I. Peters, R. H. Waterman Jr	Amazon
Project Management	Harold Kerzner	Amazon
The Complete Idiot’s Guide to Project Management	Sunny Baker, Kim Baker	Amazon
Risk Management: Tricks of the Trade for Project Managers	Rita Mulcahy	Amazon
Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project	Tom Kendrick	Amazon
Making Hard Decisions	Robert T. Clemen	Amazon
Into Thin Air	Jon Krakauer	Amazon
Principles of Management	Leonard J. Kazmier	Amazon
The Wiley Guide to Managing Projects	Peter W. G. Morris, Jeffrey K. Pinto	Amazon
How to Make Meetings Work	Michael Doyle, David Straus	Amazon
Gnomologia, Adagies and Proverbs, Wise Sentences and Witty Sayings, Ancient and Modern, Foreign and British	Thomas Fuller	Amazon
The Visual Display of Quantitative Information	Edward R. Tufte	Amazon
Visual Explanations	Edward R. Tufte	Amazon
Blind Man’s Bluff: An Untold Story of American Submarine Espionage	Sherry Sontag, Chistopher Drew	Amazon
The Leadership Moment	Michael Useem	Amazon
The Human Side of Enterprise	Douglas McGregor	Amazon
Theory  Z:  How American Business Can Meet the Japanese Challenge	William G. Ouchi	Amazon
The Motivation to Work	Frederick Herzberg, Bernard Mausner, Barbara Snyderman	Amazon
Punished by Rewards	Alfie Kohn	Amazon
Management of Organizational Behavior: Utilizing Group Resources	P. Hersey, K. H. Blanchard	Amazon
Please Under-stand Me, Character & Temperament Types	David Keirsey , Marilyn Bates	Amazon
Have Blue and the 117A	David C. Aronstein, Albert C. Piccirillo	Amazon
Influence, the Psychology of Persuasion	Robert B. Cialdini	Amazon
Lewis Spacecraft Mission Failure Investigation Board Final Report	NASA Headquarters	Amazon
Death March	Edward Yourdon	Amazon