The business analyst role and related activities emerged organically from the hi-tech and information technology industries. Historically viewed as an intermediary step on other career paths, only recently has it begun to emerge as a profession in its own right. The purpose of this post is to provide a quick overview of the standards driving professionalization of the business analyst role within the information technology context.
Like Old Testament prophets, business analysis pioneers recorded their ideas in foundational texts, most of which predate the third party standards from IIBA, PMI, and IEEE. Business analysis professionals should have at least a passing familiarity with each of these texts as they undergird the third party standards and are historically significant for the profession.
The Book of Weigers
Software Requirements, by Karl Weigers and originally published by Microsoft Press in 1999, is now on its third print edition. This seminal work on requirements engineering is frequently referenced by other texts. Weigers approaches the topic of requirements engineering from a prescriptive viewpoint but has updated the text to account for trends in Agile development. Major topic areas include:
- The Definition of Software Requirements
- Requirements Development
- Requirements for Specific Project Classes
- Requirements Management
- Implementing Requirements Engineering.
Weighing in at just over 600 pages, this massive tome is the one resource no business analyst should be without. In 2004, Weigers authored More About Software Requirements: Thorny Issues and Practical Advice with 200 more pages of new material.
The Book of Fowler
UML Distilled, by Martin Fowler and originally published in 1997, is also on its third print edition. The Unified Modeling Language (“UML”) provides visual models for describing software systems and is probably best known for popularizing use cases. However, UML is tailored to object-oriented software development and is thought by some to be too technical for most business audiences. Hence, it tends to be used in the design phase of projects. Joy Beatty and Anthony Chen attempted to address this shortcoming with their Requirements Modeling Language (“RML”) described in Visual Models for Software Requirements (2012). RML models are more readily understood by business stakeholders.
The Book of Schwaber
Although there are various flavors of Agile development, probobably the most widely used is Scrum. Ken Schwaber and Jeff Sutherland, two of the original signatories of the Agile Manifesto, described Scrum in The Scrum Guide. A more detailed discussion of Agile with Scrum can be found in Agile Project Management with Scrum by Schwaber. User Stories Applied (2004) by Mike Cohn is an early and comprehensive guide to writing Agile stories (in lieu of requirements).
International Institute of Business Analysis (“IIBA”): A Model-Based Standard
The IIBA has documented the tools and techniques used by business analysts in its Business Analysis Body of Knowledge Guide (“BABOK Guide”). The IIBA standard is organized around the Business Analysis Core Concept Model (BACCM).
The BABOK Guide defines six knowledge areas for business analysts:
- Business Analysis Planning and Monitoring
- Elicitation and Collaboration
- Requirements Life Cycle Management
- Strategy Analysis
- Requirements Analysis and Design Definition
- Solution Evaluation.
The IIBA targeted the content of the BABOK Guide to five working contexts or perspectives: Agile, Business Intelligence, Information Technology, Business Architecture, and Business Process Management. Accordingly, the information in the BABOK Guide is generalized and not specific to the software development context.
Project Management Institute (“PMI”): A Process-Based Standard
The Project Management Institute recently (2017) documented its business analysis standard in The PMI Guide to Business Analysis. This document serves as a business analysis “body of knowledge” and is supplemented by its predecessor, Business Analysis for Practitioners: A Practical Guide (2015).
The PMI Guide to Business Analysis organizes the Business Analysis role as a series of processes which align with its approach to project management:
- Needs Assessment
- Stakeholder Engagement
- Traceability and Monitoring
- Solution Evaluation.
The components of the PMI standard are similar to IIBA’s, but are organized differently and are somewhat more detailed and prescriptive. Like the IIBA standard, it is not specific to the software development context.
ISO/IEC/IEEE Standards: A Deliverables-Based Standard.
The Institute of Electrical and Electronic Engineers (“IEEE”) and the International Organization for Standardization / International Electrotechnical Commission (“ISO/IEC”) jointly developed international standards for software engineering that are described in the following documents:
- ISO/IEC/IEEE 12207 Systems and Software Engineering – Software Life Cycle Processes defines the processes and products required throughout the software development lifecycle (“SDLC”), including the acquisition, supply, development, operation, and maintenance of software.
- ISO/IEC/IEEE 15288 Systems and Software Engineering – System Life Cycle Processes provides a common system engineering process framework for a wide range of project contexts. The framework includes technical, project, agreement, and enterprise process categories. Each constituent process includes a purpose, activities, and outcomes.
- ISO/IEC/IEEE 29148 Systems and Software Engineering – Life Cycle Processes – Requirements Engineering describes the processes and products for the requirements engineering process throughout the SDLC.
ISO/IEC/IEEE 29148 encapsulates IEEE’s requirements engineering standard. Unlike the IIBA and PMI, IEEE gives scant attention to processes, tools, and techniques. Rather, it prescribes the format and content for progressively more detailed requirements information deliverables:
- Business Requirements Specification (BRS)
- Stakeholder Requirements Specification (StRS)
- System Requirements Specification (SyRS)
- Software Requirements Specification (SRS).
IEEE states that ISO/IEC/IEEE 29148 may be used independently or as a supplement to the other two standards. It is most relevant to software projects utilizing a prescriptive approach to requirements; however, practitioners of Agile and other adaptive approaches to requirements will also find useful ideas to supplement a story-based approach. The ISO/IEC/IEEE 29148 committee took the IIBA’s BABOK Guide into account when developing its standard for software.
Which is Best?
The IIBA and PMI standards are very similar and differ mainly in their organization. Both support recognized and well-regarded certifications for business analysis professionals. Both do a good job of outlining processes, tools, and techniques for business analysis. IEEE shines in defining the resulting deliverables. Business analysts working within a prescriptive requirements framework would do well to marry either the IIBA or PMI approach with the IEEE deliverables.
Business analysts working in an adaptive or Agile framework will probably not have a need for the IEEE deliverables. Furthermore, it may be counterproductive to graft the PMI process-based approach to requirements onto an Agile project. On the other hand, an Agile business analyst may be well served by viewing the IIBA standard as a toolbox and applying its tools and techniques in support of Agile projects.
The decision between prescriptive and adaptive approaches to technology development is correctly made at the project, departmental, or firm level and the approach to business analysis should align with it. Although Agile provides many benefits to “greenfield” projects that are relatively self-contained, a prescriptive approach may be better suited for other projects, such as the purchase or replacement of commercial off-the-shelf software (“COTS”) and projects executed under a statement of work or government contract.
Why Are These Standards Important?
You may be thinking, “I can rely on my expert judgment and experience; these standards aren’t important to me.” Or, “my company has its own standards for requirements management; I’ll just go with what my sponsor and project manager recommend.” Sponsors, project managers, IT personnel, and business SMEs are domain experts. They usually know very little about best practices for gathering, documenting, and managing requirements.
Numerous studies have found that a poor understanding of requirements is at the root of at least half of all project failures. As business analysts, we have a duty to educate our project team members on requirements best practices and ensure that all parties are on the same page. This is rarely easy. You will get pushback. Always remember that you are the expert in this particular domain. The IIBA, PMI-BA, and IEEE standards provide a credible and solid foundation from which you can support your recommendations and approach. You have an opportunity to increase your personal standing and that of your profession by demonstrating your subject matter expertise and competency in the skills, tools, and techniques of your craft. Make the most of it!
Tell me what you think. What do you see as the relative merits of these standards? Do you recommend other foundational texts? What are the pros and cons of greater professionalization of the business analyst role and activities?