BAs Will Falter Until They Learn to Discover REAL, Business Requirements

Featured
31599 Views
11 Comments
20 Likes

Abstract

This paper’s primary purpose is to make educators aware of critical requirements concepts that customary courses and literature fail to address appropriately. Widely-accepted conventional requirements models continue to create creep—changes to settled requirements which are a major cause of project overruns. Business Analysts and others will continue to encounter such creep so long as they follow flawed models focusing on requirements of a product or system being created without adequately also discovering the REAL, business requirements the product must satisfy to provide value. Much of the difficulty comes from mistakenly trying to interpret these qualitatively different concepts in terms of familiar similar-sounding models, such as depicting them as merely different requirements levels. The two types of requirements are distinguished and the powerful Problem Pyramid™ tool is described as a way to more reliably get both right quicker with less effort and aggravation. Educational implications are discussed.

1. Introduction

Anyone who has ever done a project of practically any type is familiar with creep—changes to presumably settled requirements. Creep changes are a major cause of project budget and schedule overruns.

Creep continues despite considerable attention to defining requirements over the past 20 years. During that period, requirements have been recognized as a topic within their own right. Many courses and books, and more recently certifications and tools, now exist with respect to various aspects of requirements and Business Analysis, the discipline commonly charged in a project with defining requirements.

While each offers its respective benefits, they have not succeeded individually or collectively in coming close to curtailing creep. My analysis indicates that the root cause of this persistent problem is following a widely-accepted and widely-taught conventional, but flawed, model of requirements which cannot help but create creep.

The solution is adopting and learning to apply effectively a more appropriate model which this paper introduces. Said more appropriate model needs to be taught to Business Analysts (BAs) and others who define requirements.

The challenge is overcoming entrenched ways of thinking. Educators cannot look to a body of research, because few investigators are aware the second model exists. Moreover, those who are most familiar with the conventional requirements model often have the greatest difficulty understanding distinctions between the models. Instead, they mistakenly try to frame the new model in terms of the old one. For instance, they’ll dismiss the differences as merely differences in requirements level, which is a flawed concept in the conventional model.

In contrast, when experienced business analysts learn the differences between the two models, many indicate they finally understand why their customary practices haven’t curtailed creep; and many express gratitude and confidence that they now have a more reliable way to get requirements right.

2. Conventional Model and Creep

Books on requirements almost always state, usually in about their first paragraph, that they are dealing with requirements of a product, system, or software; and my informal surveys of attendees at my seminars and speeches confirm that when most people use the term “requirements,” they too are referring to requirements of a product/system/software.

Many people also refer to these as “functional requirements” or “functional specifications;” and those terms bring along with them their “nonfunctional” counterparts. To cut repetition, I’ll refer to all these as simply “product requirements.”

I’m highlighting the “product” aspect in order to make an important distinction between these requirements and what I call “REAL, business requirements.”

Figure 1 depicts graphically a widely-held and widely-accepted conventional model of requirements which indeed does refer to and distinguish “business requirements.”

Conventional Requirements Model

Figure 1. Conventional Requirements Model

This conventional requirements model depicts the difference between business and product requirements as simply a difference in level of detail, which sometimes also is called a “level of abstraction.”

According to the requirements-levels conventional model, business requirements are high-level and vague and decompose into product requirements, which are detailed.

Thus, the model says that if a requirement is detailed, it’s a product requirement; whereas if it is high-level and vague, it’s a business requirement.

For instance, the increasingly influential International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) [1] embraces this model. Section 1.3.2.1 of the recently-released BABOK v2 (Version 2) describes several requirements levels, including business requirements, stakeholder requirements, solution requirements consisting of functional and nonfunctional requirements, and implementation requirements. It defines business requirements as:
“higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things [as] the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.”

A related and also widely-held bit of conventional wisdom is that creep—changes to requirements after they supposedly have been settled—is inevitable and is caused by unclear product requirements.

In the quality assurance (QA) and testing community, the main issue with requirements is generally considered to be “lack of testability,” which is due to lack of clarity. If a requirement is not clear enough to create a test to demonstrate the requirement has been met, then it’s likely that the developer won’t know what to develop; and QA/Testing won’t be able to tell anyhow whether what’s developed is right.

Real Requirements3.1. REAL Is for Emphasis, Not an Acronym

To distinguish these from the flawed conventional levels-of-detail model, I refer to them as REAL, business requirement.

REAL is not an acronym but rather is all capitals to make it stand out even when automatic reformatting obscures italics, bold, underlining, and other typical means of emphasis.

Furthermore, REAL requirements are those one ends up with after making and correcting various false starts. The objective is to reach the REAL, ending requirements more immediately without having to spend so much effort circuitously defining and reworking incorrect requirements on the way.

3.2. Product vs. REAL, Business Requirements

REAL, business requirements are from the perspective of and in the language of the user, business, customer, or stakeholder. The user’s requirements are to do their business, whether at work or personal, for profit or not for profit. REAL business requirements are conceptual and exist within the business environment, which means they must be discovered rather than merely gathered.

REAL, business requirements are business deliverable whats that provide value when delivered (or are met or satisfied). Value comes from meeting business objectives through solving problems, taking opportunities, and meeting challenges. There usually are many ways to accomplishing the REAL, business requirements.

In contrast, product requirements represent a human-defined product which is presumably one of those possible ways how presumably to satisfy the presumed business requirements. Humans define designs; and a product is a design, albeit high-level.

The product provides value if, and only if, it meets the REAL, business requirements. Presumptions have a way of being wrong. The more one presumes, the more likely they will be wrong. Because product requirements so often involve presumptions, they often are wrong.

4. Real Cause of Creep

While clarity and testability are important, much of creep occurs because the product requirements, regardless of how clear and testable they are, turn out not to meet the REAL, business requirements.

The primary reason the product requirements don’t meet the REAL, business requirements is because the REAL, business requirements have not been defined adequately, which in turn is primarily due to people following the flawed conventional wisdom that the product requirements are the requirements.

The levels-of-detail model pictured in Figure 1 is flawed because business requirements are whats and product requirements are hows. Whats do not decompose into hows. Rather, hows are a response to whats. All the hows detail in the world will not make up for not knowing the whats detail. The conventional wisdom approach of emphasizing only the hows detail can lead only to presumptions; and presumptions cause errors and creep.

Figure 2. More Appropriate Model that Cuts Creep

In contrast, Figure 2 depicts the more appropriate model that is the key to cutting creep. REAL, business requirements need to be defined in detail. They are hierarchical; and no matter how far down in detail they go, they are always business deliverable whats that provide value when delivered, satisfied, or met. One goes to lower levels of detail to increase clarity, not to describe a product.

However, when REAL, business requirements have been defined in detail, which can be selective based on priorities, then it usually is a relatively straightforward process to translate them into a product which in fact meets the REAL, business requirements and thereby avoids creep.

Often one can do a lot of copy and paste, so the two may end up looking very similar. That can be a trap, because it can fool people into thinking they can skip the detailing of the REAL, business requirements, which of course is the flawed conventional wisdom model described in Figure 1 that causes creep.

Part of the flawed conventional wisdom, which of course can become a self-fulfilling prophecy, is that creep is inevitable because business situations and associated requirements change so constantly. Indeed, human-defined product requirements are very likely to change, especially when they were designed without being responsive to REAL business requirements.

On the other hand, REAL business requirements tend to change much less. It’s often the changing awareness of REAL business requirements that have been there all along that is characterized erroneously as requirements changes.

Consider the situation where a competitor comes out with a superior product, which is often cited as an inevitable but unpredictable source of requirements changes. Is it not clear that the change is a product? Its superiority is due to better meeting known REAL business requirements and/or meeting ones that the competitor is more aware of than we are.

Had we used appropriate techniques to discover the REAL business requirements that our competitor obviously was able to identify, we could have designed a product equal to or better than theirs. Often, superior design actually is due to more fully discovering REAL business requirements that some call “nonfunctional,” such as aspects of usability.

Furthermore, introduction of competitive products is hardly unpredictable; and REAL business requirements include likely competitive capabilities and other changes that product marketing specialists really ought to be able to anticipate to some extent. Effective Business Analysts find out about them.

5. Powerful Problem Pyramid™

Probably the thing that most people remember from my book is the powerful Problem Pyramid™ tool. It is eye-opening to see the tool reveal the mistaken thought processes that cause so many projects to fail to deliver value.

People’s fascination with the Problem Pyramid™ tool also is frustrating because it seems to distract them from the essential distinction between product and REAL, business requirements. Using the Problem Pyramid™ to perpetuate product focus will continue to cause creep. Rather the power of the tool is its ability to help discover the REAL, business requirements.

The Problem Pyramid

Figure 3. The Problem Pyramid™

Figure 3 shows the Problem Pyramid™, which consists of six boxes or steps that should be performed in the numbered sequence.

Box 1 must be done first. It involves identifying the problem, opportunity, or challenge that will provide value when addressed appropriately. Not surprisingly, it’s common for the problem not to be identified correctly, which makes chances for proper solution essentially impossible.

To help get the problem right, we identify measures of the problem. Box 2 describes the measures of how things are now that tell us we have a problem; and Box 3 identifies Goal Measures that tell us the problem has been solved, the opportunity has been taken, or the challenge has been met. Achieving the Box 3 Goal Measures provides the value, so identifying and quantifying the value is part of getting the problem right.

One doesn’t solve a problem directly. Rather one must identify and deal with the causes of the problem. Box 4 describes the current As Is process Causes that result in the Box 2 measures which tell us we have a problem.

Box 5 is the Should Be, the REAL, business requirements deliverable whats that when delivered reasonably will lead to accomplishing the Box 3 Goal Measures which achieve the value. The Problem Pyramid™ identifies the high-level REAL, business requirements which then need to be driven selectively down to greater detail. No matter how far down in detail they are driven, they are always business deliverable whats that provide value when delivered.

Box 6 is the design of a product how to satisfy the Box 5 REAL, business requirements whats. Box 6 is where we get the product requirements depicted on the right-hand side of Figures 1 and 2. Box 6 should be a response to Box 5.

However, instead people ordinarily start with Box 6 and not surprisingly fail to provide desired value, because they haven’t defined the Box 5 REAL business requirements whats that the Box 6 product how must satisfy in order to provide the Box 3 value. By following the numbered sequence from Box 1 through Box 5 before getting into the Box 6 how, project success improves dramatically.

Getting the REAL, business requirements right in the first place is the key to providing value and cutting creep. The Problem Pyramid™ is a difficult but powerful tool to get the problem, value, and REAL requirements right. It takes training, skill, and guided practice to develop proficiency; but the effort pays off.

6. Educational Implications

The first step in teaching these concepts and techniques to Business Analysts and others is to make the educators themselves aware that a different model exists and needs to be taught. Hopefully, this paper serves that purpose.

In order to teach the concepts and techniques, the educators must understand them. They must be clear on the difference between REAL business requirements and product requirements; and they must be proficient at applying the Problem Pyramid™. My book [2] and relevant articles available on the Internet, including [3], [4], and [5] are valuable resources for helping both educators and students understand these ideas.

I teach this information in a very interactive two-day seminar [6] which maps closely with my book and does not get into defining product requirements (which is the topic of a separate two-day class [7]). However, I’d guess most educators would be looking for ways to include the ideas along with other requirements topics in a broader class.

I’d suggest starting conceptually, describing REAL business requirements and how they differ from product requirements, including the flaws in treating them as different requirements levels, and why making these distinctions is essential.

Concrete examples help make the distinctions clearer. It’s usually easy to elicit likely requirements for generic types of projects; or students could offer requirements from real projects with which they are familiar.

Then the students analyze the requirements to determine whether they are product or REAL business requirements; and for ones that are product requirements, they must identify the REAL business requirements that the product presumably is satisfying. Some additional examples are included in reader discussion comments for article [3].

Learning to use the Problem Pyramid™ is more difficult. I ask each student to develop Boxes 1-5 of a Problem Pyramid™ for some problem, opportunity, or challenge they are currently encountering.

Then as a class, we apply the review guidelines to systematically evaluate and improve a Problem Pyramid™ shared by one of the students. We capture everything, using different colors to contrast the student’s original version with suggested changes and final agreed upon contents. As time permits, the class can review other students’ Problem Pyramids™ one-at-a-time. Then all students review and revise their own.

Traditional techniques for teaching the well-known elicitation and analysis techniques all can be used with respect to REAL business requirements. I have the class observe and then critique student groups who interview me playing various user roles for case study situations. Subsequently, students use various analysis techniques to help understand the data they and their classmates have uncovered, and especially to identify further questions they now realize need to be answered.

Students use a Problem Pyramid™ for the case situation to determine when they sufficiently have identified the Boxes 1-4 REAL problem, measures, value, and causes to warrant defining the Box 5 Should Be top-level REAL business requirements.

Then the students practice drafting top-level requirements and critiquing each other’s results. They can develop high-level conceptual designs to show how the requirements might be addressed and can develop implementation estimates. Based on this information, they can practice requirements prioritization, tradeoff analysis, and negotiation of implementation projects.

Students drive top-level REAL business requirements selected for implementation down to greater detail, typically two or three levels at a time, followed by reviews and adjustments. They should identify, and possibly carry out, needed additional data gathering and analysis.

This brings the students to a junction with conventional requirements education’s typical focus on writing product requirements specifications and use cases. The difference is that the product and actors’ usage of the product are specified based on satisfying the detailed REAL business requirements.

7. References

[1] International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge, Version 2 (BABOK v2), International Institute of Business Analysis (IIBA), Toronto, 2009.

[2] Goldsmith, Robin F., Discovering REAL Business Requirements for Software Project Success, Artech House, Boston, 2004.

[3] Goldsmith, Robin F., “Conventional Requirements Model Flaw Misses REAL Business Requirements,” Requirements Networking Group featured article, 2007-01-31.

[4 Goldsmith, Robin F., “ROI is Deceptive Without REAL Requirements and Quantified Intangibles,” Requirements Networking Group featured article, 2007-03-20.

]5[ Goldsmith, Robin F., “Should BABOK Include Shorthand?”, Requirements Networking Group featured article, 2008-11-11.

]6[ Go Pro Management, Inc., Defining and Managing User Requirements, two-day seminar presented in various public and in-house venues, see www.gopromanagement.com.

]7[ Go Pro Management, Inc., Writing Testable Software Requirements and Use Cases Workshop, two-day seminar presented in various public and in-house venues, see www.gopromanagement.com.

Author: Robin F. Goldsmith, JD is President of Needham, MA consultancy Go Pro Management, Inc., which he co-founded in 1982. He works directly with and trains business and systems professionals in requirements, quality and testing, project management, software acquisition and outsourcing, Return on Investment (ROI), metrics, and process improvement. A frequent speaker at leading conferences, he is the author of the Proactive Testing™ and REAL ROI™ methodologies, and the recent Artech House book, Discovering REAL Business Requirements for Software Project Success.

This paper was presented at IEEE 17th Requirements Engineering Conference (RE’09) in Atlanta, GA August 2009.


]
Like this article:
  20 members liked this article
Featured
31599 Views
11 Comments
20 Likes

COMMENTS

Dennis posted on Tuesday, January 12, 2010 9:08 AM
The author acknowledges the difficulty of others understanding/accepting this concept. To help new concepts be understood, multiple examples of the concept can help. E.g., provide a dozen formerly believed to be "real requirements", and then provide the dozen "REAL" requirements for which the former dozen were only product, system or service requirements.
DRN
Dave F posted on Tuesday, January 12, 2010 1:16 PM
Robin importantly points out that requirements stability comes from understanding what's going on from the business perspective and innovating changes from that same perspective. To understand the real business perspective it’s important to understand the actual workers and customers who execute the business (not just the managers & SMEs); to understand that they work the way they do for a reason. They work with intent, so either the current way of meeting intents has problems or the intents themselves need to change. The former requires a deep understanding of their work to better support (and not break!) intent, the latter implies a need for better educational support or different motivations.

So the REAL (detailed and stable) business requirements come right from the heads of the people for whom you’re innovating a new solution--from their intents and how they realize them. Check out Karen Holtzblatt's fun and informative article "Don't Ask Your Customers" for more insight into capturing requirements: www.incontextdesign.com/articles/dont-ask-your-customer-comic
flotree
Dennis posted on Tuesday, January 12, 2010 2:35 PM
Agreed. E.g, Is the requirement a specified report or digging deeper is the requirement the end product of a series of events for which the report one piece of data that triggers some of the other events and neither human intervention nor the report actually is needed. What is the worker's/customer's intended outcome, and what is most efficient process to achieve that outcome and still comply with legal, ethical and moral security and internal control parameters.
DRN
Leslie posted on Tuesday, January 12, 2010 3:43 PM
Thanks for this. It's nice to read an article from someone who 'Gets it'.

Product vs. REAL, Business Requirements:

This conventional requirements model depicts the difference between business and product requirements as simply a difference in level of detail, which sometimes also is called a “level of abstraction.”
-----------------------------------------
According to the requirements-levels conventional model, business requirements are high-level and vague and decompose into product requirements, which are detailed.

I wrote an article about a year ago that attempts to distinguish between the business model and the system model. The way to think of them is that the business model and the system model are not high and low level (parent/child) models, but sit side-by-side. Traceability is almost always from the Business -> (to the) System, but this does not need to imply a hierarchy.

Like a typical company structure, there is a business unit and an IT (systems) unit. The IT department satisfies the needs of the business (and other departments, including themselves), but that does not require us to think of IT as a subservient department to the business.

Consider the following Diagram.
http://www.umllmu.com/pages/Blogs/Section2_files/clip_image008.gif

To the left is the business. To the right IT. The business contains 'Business Needs'* .. the IT 'System Requirements'. There is no overlap. But there is traceability. The business needs are mapped to system solutions.

Notice that I also show zero overlap between business 'requirement'** types and system requirement types. Having the same requirement type in both domains causes a heck of a lot of confusion IME.

Business Needs:
Business processes may or may not, trace to (system) functional requirements (not all business needs are implemented).
Business rules may be implemented by functional or supplementary requirements**.

System Requirements:
Functional requirements may trace from business needs, but may also come from elsewhere.
Supplementary requirements (in my world) are anything that is not directly captured within a use case, but are restrictions on the functional requirements.
Stakeholder requirements, are system requirements that do not come directly from the business needs. These originate from anyone with a vested interest in the final product and do not need to trace from anywhere (except for an explanation of why they are a good idea).

Levels of Abstraction:
There may be levels of abstraction within each domain model by adding detail to components. For example, a business use case shell may be detailed by adding business objects and roles to the steps of the use case. The 'shell' and the detailed use case are at different levels of abstraction. A system class containing detailed attributes and operation descriptions, may be abstracted (upward) into an object that is captured by a use case.

Does it mean anything to say that a business model artifact is at a higher level of abstraction than a system artifact?

To summarise, business needs and system requirements are easier to manage if kept independent from each other and treated as 2 distinct domains.

Great article.

* - I do not call business needs 'requirements'. These are genrally processes that are already in place and therefore do not need to be described in terms of requirements, but in terms of 'this is what it is'.

* - I'm using the word 'requirements' to capture business processes and business rules, since although they are NOT requirements as such, they do act very much as requirements when modeling them.

*** - There are arguments for and against supplementary requirements being purely non-functional requirements. This is not an argument for discussion here.
baldrick
zarfman posted on Tuesday, January 12, 2010 10:50 PM

Greetings:

Zarfman writes - The majority of my business experience is in the fields of finance and accounting. Accordingly that experience has given me points of view that may or may not conflict with yours.

Goldsmith wrote - REAL, business requirements are from the perspective of and in the language of the user, business, customer, or stakeholder. The user’s requirements are to do their business, whether at work or personal, for profit or not for profit. REAL business requirements are conceptual and exist within the business environment, which means they must be discovered rather than merely gathered.

Zarfman writes – I suggest that a business analyst not trained in the business, art or science is going to have a very difficult time discovering REAL business requirements couched in the language of the business, art or science. An example is FASB 133.

FASB 133 amends FASB Statement No. 52, Foreign Currency Translation, to permit special accounting for a hedge of a foreign currency forecasted transaction with a derivative. It supersedes FASB Statements No. 80, Accounting for Futures Contracts, No. 105, Disclosure of Information about Financial Instruments with Off-Balance-Sheet Risk and Financial Instruments with Concentrations of Credit Risk, and No. 119, Disclosure about Derivative Financial Instruments and Fair Value of Financial Instruments. It amends FASB Statement No. 107, Disclosures about Fair Value of Financial Instruments, to include in Statement 107 the disclosure provisions about concentrations of credit risk from Statement 105.

If one has no experience in that area of accounting, discovery is questionable.

Zarfman writes – Even if all REAL, business requirements are discovered. The end product whatever that may be, is at the mercy of its implementers’ and their knowledge and skill. It is possible that the REAL requirements exceed the knowledge set of the implementers’. Moreover, patents have been known to block implementation unless a licensing fee is paid.

Rewards’,

Zarfman
zarfman
Tony Markos posted on Wednesday, January 13, 2010 12:05 PM
Very sound principles; who can logically argue about the need to put the "Business" back into Business Analysis. But in a world of development efforts driven by use cases (i.e. product focused modeling), how praticial is such an approach?

Question for Robin: What as-is modeling technique do you espouse?

Tony Markatos
ajmarkos
ModernAnalyst.com posted on Thursday, January 14, 2010 4:30 AM
Posted by Tom Miller on LinkedIn:

I've read the article/presentation. If I am getting it right, the author is claiming that BA's are not reliably getting the "....REAL , business requirements" due to wondering off into the world of "product" rather than the world of "...REAL...." concepts.

He offers the power pyramid as a tool for helping to try to implement discovering "...REAL..." requirements. And he shows humility/frustration in that BA's mistake the "map" of the power pyramid for successfully "getting" what he is trying to teach.

In conclusion, I'm not sure I get it or got it. I am not sure you can get it without specific real-world training in the different mindset he is promoting.
admin
ModernAnalyst.com posted on Thursday, January 14, 2010 4:30 AM
Posted by Domenic Dichiera on LinkedIn:

Couldn't agree with you more - and the associated article is spot-on.
I've found that poorly defined requirements are caused by so called Business Analysts who grew into the role from being either a technology specialist or a business domain expert - neither of which truly understand business analysis, let alone what REAL business requirements are. They all seem to be attacking the problem from the perspective of arriving at a computer system, instead of determining how to solve burning business issues.
admin
ModernAnalyst.com posted on Thursday, January 14, 2010 4:31 AM
Posted by Leslie Munday on LinkedIn:

Thanks for this. It's nice to read an article from someone who 'Gets it'.

Product vs. REAL, Business Requirements:

This conventional requirements model depicts the difference between business and product requirements as simply a difference in level of detail, which sometimes also is called a “level of abstraction.”

According to the requirements-levels conventional model, business requirements are high-level and vague and decompose into product requirements, which are detailed.

I wrote an article about a year ago that attempts to distinguish between the business model and the system model. The way to think of them is that the business model and the system model are not high and low level (parent/child) models, but sit side-by-side. Traceability is almost always from the Business -> (to the) System, but this does not need to imply a hierarchy.

Like a typical company structure, there is a business unit and an IT (systems) unit. The IT department satisfies the needs of the business (and other departments, including themselves), but that does not require us to think of IT as a subservient department to the business.

Consider the following Diagram.
http://www.umllmu.com/pages/Blogs/Section2_files/clip_image008.gif

To the left is the business. To the right IT. The business contains 'Business Needs'* .. the IT 'System Requirements'. There is no overlap. But there is traceability. The business needs are mapped to system solutions.

Notice that I also show zero overlap between business 'requirement'** types and system requirement types. Having the same requirement type in both domains causes a heck of a lot of confusion IME.

Business Needs:
Business processes may or may not, trace to (system) functional requirements (not all business needs are implemented).
Business rules may be implemented by functional or supplementary requirements**.

System Requirements:
Functional requirements may trace from business needs, but may also come from elsewhere.
Supplementary requirements (in my world) are anything that is not directly captured within a use case, but are restrictions on the functional requirements.
Stakeholder requirements, are system requirements that do not come directly from the business needs. These originate from anyone with a vested interest in the final product and do not need to trace from anywhere (except for an explanation of why they are a good idea).

Levels of Abstraction:
There may be levels of abstraction within each domain model by adding detail to components. For example, a business use case shell may be detailed by adding business objects and roles to the steps of the use case. The 'shell' and the detailed use case are at different levels of abstraction. A system class containing detailed attributes and operation descriptions, may be abstracted (upward) into an object that is captured by a use case.

Does it mean anything to say that a business model artifact is at a higher level of abstraction than a system artifact?

To summarise, business needs and system requirements are easier to manage if kept independent from each other and treated as 2 distinct domains.

Great article.

* - I do not call business needs 'requirements'. These are genrally processes that are already in place and therefore do not need to be described in terms of requirements, but in terms of 'this is what it is'.

* - I'm using the word 'requirements' to capture business processes and business rules, since although they are NOT requirements as such, they do act very much as requirements when modeling them.

*** - There are arguments for and against supplementary requirements being purely non-functional requirements. This is not an argument for discussion here.
admin
Leslie posted on Thursday, January 14, 2010 1:44 PM
Ooops! How did that get in there twice!

May I quote this - 'put the "Business" back into Business Analysis' Coming from an IT background, I never needed to put 'Business' back, I have learnt to put it in once and leave it there.

I speculate that part of the problem is re-using use cases to model the business world. They are good for BPM, but perhaps if these where renamed Business Cases (remove the 'use').

I do like to stress the removal of the word 'requirements' from BPM. Why are there requirements? What does 'requirement' mean in the business world? For the most part we are not modeling business requirements, but the business 'as-it-is'. Anything that is business 'to-be' is a business 'need', or a business process change. The only 'requirement' is to change the way the business operates.

When discussing Business Process Modeling, I teach that the analyst should consider that the business may operate in any technological age. That is, the business process may be the same .. no matter when it implemented, be it:
- in the future,
- with today's technology,
- with 1960's technology,
- or even prior to 1900s.

When writing business process needs, imagine that the only technology available to the business is pencils, erasers, paper, filing cabinets, etc.

When a customer makes a request of the business, it doesn't matter how they do it. Could be postal mail, could be an in person visit, telephone or online web site. The business process should be the same.

When the business worker, collects the customer details, they may be entering them in a spreadsheet, speaking them into a voice recognition device or chiseling them into a rock wall. It doesn't matter, so long as they get the details.

I have worked in places where there is so much confusion between BPM and application modeling, that it is impossible to draw a line between the 2 models.

On a final note; what does it mean to state that a product use case is describing business use cases, but with MORE detail?

Leslie.
baldrick
ModernAnalyst.com posted on Sunday, January 17, 2010 12:46 AM
Posted by Leslie Munday on LinkedIn:

I believe that what the author is discussing is 'not good' requirements creep. Not good, meaning that the requirements creep is caused not by business changing their priorities, or changing their process, but because the product that is released at the end of an iteration is not appropriate for use in production. The reason being, because emphasis went directly into product requirements, without proper consideration for the business requirements.

With agile, you may argue that being in constant contact with the SME is a way around this. To some extent I'd agree, but you are not in contact with every SME, and I doubt that any single SME knows ALL the business needs.

Hence the argument for proper business modeling up front where every SME is solicited for input.
admin
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC