Requirements Management and TOGAF

… or any Enterprise Architecture framework.

As you may know TOGAF puts Requirements Management in the centre of its ADM method:

TOGAF ADM
TOGAF ADM

As one might expect, since this aspect of enterprise architecture is so prominently placed, it will be given a lot of attention in the TOGAF standard, right? Not so. The number of pages dedicated to this phase in the ADM in the 9.1 version of TOGAF is 8 pages.

Preliminary 12
Architecture Vision  10
Business Architecture  14
Information Systems Architecture  16
Technology Architecture  18
Opportunities and Solutions  10
Migration Planning  8
Implementation Governance  8
Architecture Change Management  10

There are an additional number of pages dedicated to Integration Requirements Management, one aspect of Requirements Management, and there is considerable attention for stakeholder analysis and the motivational model, which to a large extend translates into requirements of course. But many of my students in the TOGAF trainings I give are left with a lack of clarity and tooling to tackle this supposedly important phase.

The problem with requirements management is the meagre metamodel entities associated with it in the TOGAF metamodel:

  • Requirement
  • Assumption
  • Constraint
  • Gap

In ArchiMate this has (as yet, keep in mind the ArchiMate metamodel is working hard to get in line with TOGAF) not yet improved much. Remember in the ArchiMate 1.0 standard the word non-functional did not appear at all, so we are getting there.

SABSA Business Attribute Profile

Things are improving however. Some organisations have adopted the SABSA Business Attribute Profile. In fact, the Open Group has adopted SABSA not only for security architecture, but also for requirements management, thus introducing a robust and proven process to develop architectures on solid requirements, aligned with business capabilities.

The 6×6 matrix usually developed in the application of the SABSA framework looks a lot like Zachman:

SABSA Master Matrix

Within this framework, the Business Attributes Profile plays an important role. It is the basis for requirements gathering.

SABSA High Level General Business Attributes

In general, I have found similar lists of quality attributes useful enough (for example the ISO/IEC 25010:2011 standard, one which I have used extensively since 1997, especially while working on software in the medical sector). But there is also a risk associated: only experience (should I even say wisdom?) will tell you which attributes are important and how to implement them. This should be strongly stakeholder-driven, so an important quality for enterprise architects is to be able to explain these attributes to the relevant stakeholders and take their input to formulate your quality attributes in a SMART way.

After all, you want your architecture to be requirements-driven. Right?

Geef een reactie

This site uses Akismet to reduce spam. Learn how your comment data is processed.