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.

Churchill on Risk Management

Here’s an excellent quote form Winston Churchill, eminently applicable as the proper attitude to adopt in risk management.  The sentence comes after Churchill summarises the beliefs and convictions taken by the then British Prime Minister Neville Chamberlain on what Hitler will do the the limits of what he will do, taking the position that he (Chamberlain) has taken the measure of Hitler, and that he (Hitler) has satisfied his territorial conquest needs:

“The Prime Minister is persuaded that… He believes that… Mr. Chamberlain is convinced that… But all this lies in the region of hope and speculation.  A  whole set of contrary possibilities must be held in mind.  He may ask us to submit to things which we cannot endure; he may be forced to ask us to submit to things which we cannot endure.”  (Churchill, the Second World War Volume 1, The Gathering Storm)

I like this ‘a whole set of contrary possibilities must be held in mind’ assertion.  For this is what risk management is about – that things may not work out as we thought, or hoped, and we must be able to survive and recover when they do.

The Ten Qualities of Good Requirements

A solid database design provides a firm and extensible base an organisation’s data.  A well-architected solution brings with it a sense of integrity and elegance that allows systems to be extended easily, and yet retain its integrity.

If any of these are badly done, the resulting solution is flaky, troublesome, and a menace to update.

But bad requirements are even worse, for they are our map to what should be built.  If the requirement is wrong, the solution built is wrong.  If the requirement has gaps, then the solution will have gaps.  If the requirement is misunderstood, then the solution is wrong.

There is an art to producing requirements.

1. Requirements Must Have an Owner

2. Requirements Must be Singular

3. Requirements Must be On the System and Not the Operator

4. Requirements Must be Unambiguous

5. Requirements Must Not Specify the Solution

6. Requirements Must have a Rationale

7. Requirements Must be Tied to the Concept of Operations

8. Requirements Must be Justified

9. Requirements Must be Prioritised

10. Requirements Must be Contextualised

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.

Investing Bibliography

Value Investing

Calandro, Joseph. Applied Value Investing: The Practical Applications of Benjamin Graham's and Warren Buffett's Valuation Principles to Acquisitions, Catastrophe Pricing, and Business Execution. 2009.

Graham, Benjamin, and David L. Dodd. Security Analysis. 1996.

Graham, Benjamin, and Jason Zweig. The Intelligent Investor. 2003.

Klarman, Seth A. Margin of Safety: Risk-averse Value Investing Strategies for the Thoughtful Investor. 1991.

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.