Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

Many Business Analysts are using the IIBA’s BABOK 2.0 (Business Analyst Body of Knowledge ) which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9 from an Enterprise Architecture viewpoint also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.

BABOK 2.0 Knowledge Area (KA) 4 covers Requirements Management and Communication which “describes the activities and considerations for managing and expressing Requirements to a broad and diverse audience” (The other KAs: Plan Requirements, Management Process, and Requirement Analysis will not be included here).

The tasks from this KA “are performed to identify business needs (the why of the project; whereas requirements are the how), the state the scope of their business solutions, ensure that all stakeholders have a shared understanding of the nature of these solutions and that those stakeholders with approval authority are in agreement as to the requirements that the business solution shall meets.”

It manages a baseline, tracks different versions of Requirements documents, and trace requirements from origin to implementation.

This area includes five steps described below.

1. Manage Solution Scope and Requirements

In this step, we “obtain and maintain consensus among stakeholders regarding the overall solution scope and the requirements that will be implemented”. Requirements may be baseline following an approval and a signoff. That means that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirements must follow a Change Management process and will require additional approval. As changes are approved, a Requirements Management Plan may require that the baselined version of the requirements be maintained in addition to the changed Requirement. Additional information is often maintained such as a description of the change, the person who made the change, and the reason for the change. As requirements are refined or changed as the result of new information, changes will be tracked as well.

A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.

2. Manage Requirements Traceability

Traceability consists of understanding the relationship between Business Objectives, the requirements, the stakeholders, other deliverables and components to support the business analysis among other activities. It also allows documenting “the lineage of each requirement, its backward and forward traceability, and its relationship to other requirements”. The reasons for creating relationships are “Impact Analysis”, and “Requirements coverage and allocation”. A coverage matrix may be used to manage tracing.

3. Maintain Requirements for re-use

Requirements re-use is another important aspect in the process and there is a need to manage knowledge of requirements following their implementation, identify the requirements that are candidates for long-term usage by the organisation. “These may include requirements that an organisation must meet on an ongoing basis, as well requirements that are implemented part of a solution” (e.g. regulatory, contractual obligations, quality standards, service level requirements, etc.). Each will have to be clearly named, defined, and available to all analysts.

4. Prepare Requirements Package

This step consists in selecting and structuring a set of requirements “in an appropriate fashion to ensure that the requirements are effectively communicated to, understood and usable” by the various stakeholders. This Requirements Package could have different forms such as a documentation (can be managed in a Requirements Repository), presentations, templates, etc.

5. Communicate Requirements

This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.

The BABOK bundles Requirements Communication together with Requirements Management.

Requirements Analysis is another KA which describes “how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results”. BABOK 2.0 Requirements Analysis being not really covered within TOGAF 9, there are no comparisons done at this stage.

Within TOGAF 9, the objective of the Requirements Management activity is to define a process whereby all kinds of requirements, including most notably business drivers, concerns, and new functionality and change requests for Enterprise Architecture are identified, stored, and fed into and out of the relevant Architecture Development Method (ADM) phases. As such it forms part of the activities and steps carried out in each of the ADM Phases. Architecture requirements are subject to constant change, and requirements management happens throughout the entire Enterprise Architecture implementation lifecycle.

It is important to note that the Requirement Management circle denotes, not a static set of requirements, but a dynamic process.

As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.

Enterprise Architecture has specific techniques to gather requirements. TOGAF as a framework uses a method based on what we call a “Business Scenario” which is used heavily in the initial phases A & B of the ADM to define the relevant business requirements and build consensus with business management and other stakeholders.

A Business Scenario ensures that there is a complete description of business problem in business and architectural terms. Individual requirements are viewed in relation to one another in the context of the overall problem; the architecture is based on complete set of requirements that add up to a whole problem description; the business value of solving the problem is clear and the relevance of potential solutions is clear.

Below is a mapping between the two approaches.

BABOK 2.0 sets up a framework for the requirements development and management, which seems to appear as a standard used by many organizations around the world. Between TOGAF 9 and BABOK 2.0, there is almost 1:1 correspondence but there may be more details and activities in the first one. TOGAF is a methodology whereas the BABOK is methodology agnostic, so it can be tricky to translate between the two but nothing prevent an Enterprise Architecture team to use this analogous technique.

If an organization follows the TOGAF methodology and Business Analysts use BABOK, the later will provide a lot of useful information, as a reference; BABOK won't give you direction for an Enterprise Architecture.

Sources: Chapter 4 IIBA’s BABOK 2.0, TOGAF 9

What is Enterprise Analysis: does it differ from Enterprise Architecture?

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area Activity in Enterprise Analysis	Definition	Enterprise Architecture (e.g TOGAF 9)	Differences, observations
Requirements Elicitation	This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don't know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered	Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed	Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized
Business Requirements Analysis	This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified	Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms	The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity
Enterprise Analysis	Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project's direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).	Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project
	Strategic plan development		Done outside of the Enterprise Architecture process by business people but is a key source of information
	Strategic goal development		This is done outside of the Enterprise Architecture initiative by business people but is a key source of information
	Business Architecture development		Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap
	Feasibility Studies		Done during Phase A: Architecture Vision (with a Business Scenario)
	Business Case Development		Done during Phase A: Architecture Vision (with a Business Scenario)
	New Project Proposal		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Selecting and Prioritizing New Projects		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Business Opportunities		This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions
	Launching New Projects		This is done during Phase F: Migration Planning
	Managing Projects for Value		This is done during Phase F: Migration Planning
	Tracking Project Benefits		Once the project is in production, it is no longer part of the Enterprise Initiative
Solution Assessment and Validation	Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution	Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration.
Business Analysis Planning and Monitoring	Explains how to decide what you need to do to complete an "analyst effort" (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done	Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase	Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and Communication	Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst's work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used	Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).	SMART techniques are equally used. Communication plans are defined.

 

This diagram below is a draft map BABOK® and TOGAF 9; more work is required!

 

Observations

There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

• Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people
• Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted
• Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.
• Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: - Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).
• Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.
• Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.
• Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.

http://www.theiiba.org/am/

Requirements Management and Enterprise Architecture

I was describing a while ago the relations between Requirements Management and other types of user’s demands.

Let me restate my definition of what that is. Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.

(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).

Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.

• Business and Functional requirements

They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.

Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.

Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.

• Non-functional requirements

They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.

• Project constraints

These are restrictions on projects due to the budget or the time available to build a product or service.

• Design and architecture requirements

They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

• Project drivers

These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.

• Project issues

They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

• Testing requirements

It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.


Requirements Management and Enterprise Architecture cannot be dissociated.

Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.

With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.

IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).

The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.

Do not miss Enterprise Architecture Governance!

Many people are considering Enterprise Architecture as a way to align IT to Business not only through the use of formalized processes. When looking at the various components of enterprise Architecture such as baselines, all kind of principles, modelling, target architectures, views, impact analysis among other of things….governance often appears as something maybe secondary. To be successful, Enterprise Architecture governance should be at the core of any program.

To build baselines, gap analyses, target architectures without a proper EA framework may end in a dead end. All new business initiatives should be validates against the current Enterprise Architecture, all exceptions have to be monitored, documented, and probably escalated. All changes on existing services, applications or infrastructure have also to be compliant with the existing Enterprise Architecture. This could be at any level, Technology Architecture (or infrastructure), Application Architecture etc..

When starting to think about your Enterprise Architecture initiative, there are two very important considerations that needs to be considered:

-How do we implement governance in the Enterprise Architecture and what are the associated processes
-How do we ensure adherence and a real collaboration in the processes

Furthermore, it is important to identify the differences between IT Governance and Enterprise Architecture Governance. Standards such as ITIL, COBIT or CMMi focus on IT Governance but none of them really refer to this EA Governance.

Governance lies at the heart of the Enterprise Architecture processes. It should be a framework that there is a logical consistency underlying the enterprise architecture structure. This structure in its broadest context means that we understand all the relationships between artifacts which are formalised.

Looking at the various EA frameworks it appears that these processes are never really clearly identified and documented.

I have identified 6 of them. Obviously each company will have to design them in a way which fits the company’s structure:

Enterprise Architecture Governance - PPM

This process identifies how any new demand or business initiative is routed to an Enterprise Architecture team for a first level assessment and impact analysis. The process also integrates at a high level Project Management and ensure that deliverables are still aligned with the initial architecture definitions.

Enterprise Architecture Compliance

All changes to business processes, information, technology, application and solutions are subject to architecture compliance. This step ensures that all changes are compliant with the existing Enterprise Architecture. If not compliant, request for exceptions go through review. In the case of an exception, the Architecture review board may issue a waiver to approve the exception. Alternatively, it may deny the exception.

Enterprise Architecture Waiver

In the event that a project sponsor's petition for an exception to the Enterprise Architecture is denied by the Architecture review board, the project sponsor may opt to appeal that decision to the Executive board, which has the authority to overrule the Architecture review board.

Enterprise Architecture - Standard Management

New company’s Standards should be the result of an investigation. Once a study or a proof of concept is finalized and presented, the latest may become a standard.

Other situations may occur when an existing standard is upgraded or there is a need for harmonization and consolidation. In both cases, standards have to be documented according to existing templates, be validated and approved by the Architecture review board, and finally approved by the IT Management team (eventually the CIO).

Enterprise Architecture – Standard Waiver

In case of exception, a waiver exception form has to be completed and be approved by the Architecture review board and the IT Management team.

Enterprise Architecture Requirements

Architecture often deals with drivers and constraints, many of which are beyond the control of the enterprise (changing market conditions, new legislation, etc.).
Architecture requirements are therefore invariably subject to change in practice. This process collects, identifies, stores and feeds requirements.

Enterprise Architecture Annual Revision or Changes

The architecture team is responsible for creating Enterprise Architectzre and revising it as an example, each year as recommended in many frameworks. Industry analysts and subject matter experts should be involved as needed in the process.

The Enterprise Architecture is updated at least on an annual basis to:

1 Incorporate amendments that were previously approved
2 Incorporate new technical standards, patterns and services, information, solutions, and business processes
3 Evolve the future-state road maps to reflect changes in business strategy

The structured architecture creation/revision process is defined by the architecture team in place and approved by the Architecture review board.

At the completion of the annual revision cycle, the updated Enterprise Architecture is submitted to the Architecture review board for approval and adoption.

Enterprise Architecture and ITSM Changes

There is a need to determine if a change (RFC) has to go through architecture compliance. If, in the opinion of the architecture team, the project has a low architectural risk, they may conditionally exempt the project from the architecture compliance process. This should be a step in the Change Management process.

There may exist additional processes…every company can extend its Enterprise Architecture governance the way which is appropriate.

That governance is put in place not just for ensuring compliance but also for ensuring enterprise wide collaboration.

Enterprise Architecture governance must ensure that decision makers across all disciplines in the company apply the same design patterns and are aligned to common design objectives.

Are there any relationship between Demand Management, Requirement Management, Request Management and Change Management?

In the context of IT, Demand Management is a process which manages the complex and strategic IT demand requests issued by the business. In this process we prioritize, consolidate, schedule the requests, enabling the business users and IT to collaborate efficiently at every step, cutting costs and accelerating resolution. Normally, this is an activity belonging to Portfolio Management which is the the process of determining (and monitoring) how much money the enterprise should spend on the various categories of IT-enabled business investments. Demand Management works with both business and its IT peers through an ongoing and iterative process that aggregates demand for IT services, represents the resources requested and their costs to the business, and helps optimize the deployment of IT resources over time. Demand Management is often covered by Portfolio Management solutions or Request Management solutions.

A few examples are Mercury ITG, Clarity (Niku) from CA, Compuware Changepoint and Borland Tempo.

These suites are more in the PPM market than anything else and these vendors should be considering to link PPM suites with IT Service Management suites for several reasons.

Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

Solutions such as RequisitePro from IBM and Telelogic Doors support that process.

Here we see in some way some identical concepts with Demand Management and potential links also with IT Servie Management.

But let’s still define two additional concepts.

ITIL doesn't have a separate process for Request Management as it does, for instance, with Incident Management in version 2. The Request Management will manage (from request to fulfillment) the goods and services requested by users based on the catalog provided. Standardized goods and services can be made available to the end users through self-service interface or by calling the Service Desk. When handling the request the Request Management will also refer to the SLA.. Version 3 should clarify the situation and define a new process, where Service Requests are now a function of Request Management which ties on the Change Management process (In version 2, Service Requests were a part of the 'Incident Mangement' life cycle).

The Change Management process ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents and improve day-to-day operations. Changes are issued either from Incidents, Problems or customer’s requests. There are also touch points between Project Management and Change Management.

Finally and to keep it very simple, everything is about a user asking something to an IT department, with different levels of importance. From a new product to a new service, from a additional or new feature to a physical piece of hardware, allowing the business to be more efficient.

There should be a clear alignment of these concepts with an end to end process, integrating IT Service Management at the end. All demands should end up in the ITIL Change Management process and vendors should integrate their platforms to facilitate that integration.