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.

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.