Skip to main content

Tag: Requirements

Enterprise Analysis: Process or Content?

In earlier posts, I have been reasoning that the IIBA and BABOK are on their way to defining a generally applicable framework for requirements management best practices, and that the BABOK 2.0 will be the first significant manifestation of the distinction between process (the requirements life cycle) and content (the nature, or domain, of the requirements being managed).

Viewing the requirements management life cycle in that way, however, requires us to scrutinize the way in which Enterprise Analysis (EA), as currently defined in the BABOK, fits in:

  • EA is content because it is carried out specifically in the domain of business planning and business strategy.
  • EA is process as well, because it is a crucial first step in the requirements life cycle.

The question becomes: is there an EA-like step in the requirements life cycle within other domains?  Let’s explore this question by considering another domain, that of enterprise e-learning infrastructure and delivery (there are many other domains we could choose as well).  From the business strategy point of view, this is a tactical and operational aspect of the enterprise.  But from the e-learning director’s point of view, there is, of course, strategy involved, addressing questions about workforce trends, globalization of the enterprise, the presence of electronic performance support practices, learning-related data privacy, and many others.

So the e-learning director must:

  • Create and maintain the e-learning architecture
  • Conduct feasibility studies of e-learning infrastructure and delivery solutions
  • Determine the scope of e-learning infrastructure and delivery projects
  • Authorize the initiation of those projects
  • Interface with the project team to manage the projects’ value, track benefits, manage change and risk, etc.

Hmmmm.  Looks a lot like BABOK’s Chapter 2: Enterprise Analysis.  Which is the point being made. “Enterprise” is the content.  “Analysis” is the process.  An e-learning director reading BABOK Chapter 2, while pretending the title was “E-Learning Infrastructure and Delivery Analysis” would get some great guidance.

Writing Effective Project Requirements

Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Importance of Requirements
Requirements are considered by many experts to be the major non-management, non-business reason projects do not achieve the “magic triangle” of on-time, on-budget, and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

Various studies, have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems, the most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst’s dilemma. The analyst often does not know what questions to ask, and the stakeholder does not know what information the analyst needs. Since the analyst doesn’t ask, the stakeholder doesn’t state requirements.

The requirements phase is also considered by many experts to be the most difficult part of any project due to the following:

  • The requirements phase is where business meets (IT) information technology.
  • Business people and IT people tend to speak different “languages.”
  • Business: “It has been determined that if we convolute the thingamajig or maybe retroactive the thatamathing, our profitability may, if we are extremely lucky, rise beyond the stratospheric atomic fundermuldering.”

In other words, English is an ambiguous language, and we tend to speak and write in a manner that makes it even more ambiguous, convoluted, and unclear.

Building Valid Requirements
The requirements analyst truly is responsible for the failure or success of the requirements on a project. With that at stake, building valid requirements up front is crucial. The four steps to this goal are: elicitation, analysis, specification, and validation.

Elicitation
The term elicitation is the industry-accepted term for getting the requirements from the stakeholders. Elicitation, however, implies much more than just capturing or gathering the requirements from users.

The truth is, one of the surest ways to fail in requirements is to say to your users, “Give me your requirements,” then stand back and “catch” them.

Why doesn’t this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.

So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.

The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

Analysis
Analysis involves refining (or analyzing) the stakeholder requirements into system, then software requirements. Analysis is a critical step, that is too often omitted or bypassed in projects.

Analysis is the critical transition from stakeholder or business terminology, to system or IT terminology. For example, stakeholders talk about “Monthly Marketing Report,” while systems talk about file “MoMktRpt.doc.”

Analysis involves brainwork, but it is not a magic process (nor is any other part of software engineering, for that matter). Analysis is usually done in conjunction with various modeling techniques. Modeling-creating diagrams using standard notations-allows analysts to more fully understand processes and data in a rigorous manner. This understanding allows them to convert the often non-rigid stakeholder requirements into more concise, rigid system and software requirements.

Common modeling techniques include the following:

  • Traditional systems
  • Dataflow diagrams to understand processes and activities
  • Entity-relationship diagrams to understand data
  • Object-oriented systems:
  • UML (Unified Modeling Language) diagrams, especially class diagrams for analysis, but also possibly collaboration diagrams

Specification
The specification sub-phase involves documenting the requirements into a well-formatted, well-organized document. Numerous resources are available to help with writing and formatting good requirements and good documents. For general writing assistance, books on technical (not general) writing should be used. A major resource is the set of IEEE Software Engineering Standards.

Validation
Once a requirements specification is completed in draft form, it must be reviewed both by peers of the author and by the project stakeholders in most cases. If detailed stakeholder requirements were written and signed off by the stakeholders, they may not need to participate in reviews of more technical system and software requirements. This presumes good traceability matrices are in place.

The specifications are reviewed by a group of people to ensure technical correctness, completeness, and various other things. Often checklists are used to ensure all requirements in all possible categories have been elicited and documented correctly.

Validation is actually a quality assurance topic. All documents produced throughout a project should undergo validation reviews.


This information was drawn from Global Knowledge’s Requirements Development and Management course developed by course director and author Jim Swanson, PMP. Prior to teaching for Global Knowledge, Jim worked 25 years for Hewlett-Packard as a business systems developer, technical product support, and senior project manager. Prior to HP, Jim worked as a Geologist for the US Geological Survey.

 

Copyright © Global Knowledge Training LLC. All rights reserved.

Requirements Management: Process vs. Content

In my most recent entry, I suggested that the BABOK 2.0 introduces the separation of process (planning, elicitation, documentation, analysis, verification/validation) from content (software development, etc.). And if you read that entry, you know I am of the opinion that this is a smart move on the part of the IIBA and the BABOK committee and authoring community.
Why? To put it simply: everyone does requirements management! And the process framework that will be represented by BABOK 2.0 will be valuable in many different disciplines.

For example, consider the practice of Instructional Design (ID): it too defines an approach that includes:
• Gathering (needs assessment, task analysis, workplace assessment)
• Analysis • Documentation (Student Performance Objectives)
• Solution identification (delivery mode, material selection, etc.)
• Management of requirements through the content development process
• Verification/validation of the content (Kirkpatrick levels 2-4, Kolb learning cycle, psychometric analysis of related exams).

This is not to say that the BABOK would become the reference body for ID itself – that subject area is sufficiently covered. Viewing the ID process through the BABOK lens, however, further strengthens the fundamental notion of the separation of the requirement from the solution.
 
You may have noticed Enterprise Analysis has not been mentioned yet – I hope you stay tuned to read my thoughts on how that fits in…..

Meanwhile, I encourage you to share with me, and your fellow readers, your thoughts on this thread as it develops more fully over the next few entries.

A BA by Any Other Name?

Quick – what are the job titles of the people who attended the panel discussion Defining the Various Roles and Responsibilities of the BA Professional at the Project World / BA Summit in Palo Alto? If you answered Business Systems Analyst, Data Warehouse Analyst, IT Business Analyst, Systems Analyst, Process Analyst, Product Manager, Program Manager, Process Manager, Business Architect, Web Analyst, Requirements Analyst, Solution Architect, Business Business Analyst (really!), Application Architect, Operations Engineer, Operational Analyst, Information Architect and Business Analyst, you are correct!

And the one element common to those jobs, unanimously agreed by the attendees, is requirements management. Interesting. Not business analysis, but requirements management. For as the titles suggest (and as confirmed by several hours of job description investigation at monster.com), many of these jobs are defined within specific domains (business process, Web apps, data warehouse, etc.) and are connected to the domain of enterprise strategy by virtue of their contribution to the value chain.

Now some points to consider: 

  • Given the above, it seems safe to say that not everyone who does requirements management is a business analyst. 
  • The IIBA, the BABOK, IIBA chapters, and BA-related media and events are very interesting to anyone who does requirements management. 
  • Excepting (perhaps) the Enterprise Analysis section, the BABOK presents a useful framework for any job involving requirements management.

The IIBA’s plans for the BABOK 2.0 (see the subsection “What changes are planned for version 2.0?” here) represent significant benefit to BAs as well as requirements management practices in general. The two changes that I think are vital in terms of their direction-setting nature are: 

  • Requirements management tasks reframed as applicable toward iterative, agile, and maintenance activities 
  • Applicability to business process based solutions as well as software solutions

I interpret these changes as a separation of content (business analysis, process analysis, data warehouse analysis, etc.) from process (plan/manage requirements, elicit, analyze, document, validate).

If the BABOK is broadened to include a general treatment of requirements management, does it strengthen or weaken the IIBA’s ability to professionalize the BA role? I say it strengthens it significant way. And I hope you come back in a couple of weeks to learn why.


Terry Longo

has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL/ITSM, Project Management and Business Analysis curriculums in the US (see http://www.hp.com/education/sections/pm_bus_analy.html). Terry can be reached via email at [email protected]

The Business Analyst and Project Manager Rolled into One!

Terry Longo’s Monthly Blog

During two of the three recent Project Summit / Business Analysis World conferences, I had the privilege of moderating a roundtable discussion whose topic was “The Dual Role of Project Manager and Business Analyst: Is it Possible?” It is, of course, no surprise that it is not only possible, but very common. (In my informal polls of audiences at my presentations, it seems that roughly 10-30% of the people in the audience are playing both roles).

The underlying question of course is “Can it be done well, and what are the benefits, costs, and risks?” And, in light of our intensifying efforts to professionalize the business analyst role, this question is vital, for it has significant implications for the organization relative to:

  • Job definitions 
  • Career paths for people aspiring to or in PM- or BA-related roles 
  • The manner in which stakeholders engage with requirements teams and solutions teams 
  • The nature and rigor of the requirements-related language present in the organization’s culture 
  • The design of processes, policies, and tools underpinning PM and BA activities 
  • The practitioner’s ability to distinguish between requirements-related change and risk and project-related change and risk

As far as the factors that make it workable with acceptable results, the two I hear about most are: 

  1. Small projects 
  2. The absence of compliance-related documentation requirements. This is interesting, since being in a compliance environment demands so much in the way of documentation of project and requirements activities, that it can be overwhelming for one person.

The questions in my mind now are (a) if there are other factors in favor of the dual role assignment, what are they, and (b) if there are no advantages on larger projects, why are we (the collective we, of course) doing it to ourselves?

Much of the answer lies somewhere in the current recognition of the role of the Business Analysis Center of Excellence, a part of the charter of which would be to understand more deeply the dynamics of the dual role, and only support it where it is justifiable in terms of risks and benefits.

Without that risk/benefit view, it seems to be, well, risky.


Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through http://www.hp.com/education/section/pm_bus_analy.html or at [email protected]