Author: Adriana Beal
In discussions about the role of the business analyst, it is common to see professionals insisting on the importance of “going beyond requirements” when describing the BA work. These analysts argue that BA activities such as enterprise analysis and process improvement indicate the need for a broader description. Being myself a consultant who often works in activities related to business process modeling and process improvement, I fail to see the benefit of moving away from the term “requirement” when describing the work of a business analyst, and here I explain why.
The IEEE Standard Glossary of Software Engineering Terminology defines requirement as:
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
The BABOK provides a very similar set of definitions (differences underlined):
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
Simplifying a bit these statements, it is possible to define requirement as “a condition or capability needed to achieve an objective” (solving a problem can be considered an objective–something toward which effort is directed–, and therefore doesn’t need to be explicitly mentioned here). Based on this definition, it becomes easier to view “requirements” as the core aspect of the business analysis work–even for BAs who don’t belong to the IT space.
Take, for example, business process modeling activities. Process modeling is used to generate a visual representation of the flow and control logic associated with a sequence of related activities or actions. A process model, however, is not an end on itself: models may be created to better understand how certain business scenarios are handled, to help identify problems in the flow, to detect activities that don’t add value to the business, etc. Process models, in most cases, become a source of requirements, helping the organization (and, in particular, the business analyst) identify the conditions or capabilities needed to solve a problem (for example, a bottleneck, or errors caused by a faulty interface between business units), or to achieve another objective (e.g., increase productivity by reducing the time to perform a task or eliminating the wait time between tasks).
Business analysts exist to facilitate organizational change. They study business problems and opportunities and recommend solutions to help corporations achieve their goals. In doing so, BAs are constantly involved in discovering, identifying, analyzing, negotiating, and documenting requirements that address business problems and opportunities.
Pingback: 2wtx Mastering Business Analysis » Blog Archive » Beyond “requirements elicitation”
The point of bringing up the imperative definitions wasn’t to debate them per say, but to point out that many people take imperative statements as the definition of ‘requirement’ rather than the broader IIBA one.
That said, disagree with your casual approach. Also disagree with the assertion that the average IEEE member will pick one at random. The origin of the crisp definitions is a long history of confusion, particularly around the term ‘will’. The standard says, “lets pick some words, agree on a common definition, and be done with it”. It is the BA responsibility to understand the imperatives, elicit the appropriate one from the business and explain to the developers (who really should understand them as well. It a BA can’t understand 8 terms, the basic sub set of “shall, may, shall not” works pretty well.
Steve, I agree that opting for simplicity and focusing on “solving business problems” as the key responsibility of business analysts are very good references to keep in mind when discussing the BA role.
By the way, I hate to find the words “may” or “should” in requirement statements, and never use them!
Thank you for continuing to contribute to the discussion.
And on topic –
lists of duties and responsibilities and activities of the business analyst go on forever. My list, taken from the mouths of business analysts and from dozens of corporate and other organizational documents such as Business Analyst Guidelines, How to be a Business Analyst at —, The Business Analyst Guidebook for —, and so forth, extends now to eight pages, and it is just a list with no explanations. That’s about 300 activities business analysts perform as part of their every day jobs at various companies. This runs the gamut from “scheduling meetings for executives” to “writing acceptance test scenarios for users to run” to “preparing UML documents” to “preparing RFPS (requests for proposals)” to “contribute to enterprise architecture” to “Make sense out of chaos”.
What it all comes down to is one and only one real task and responsibility: solve the business problem. All the tasks and activities are subordinate to that. And, if the task the business analyst is assigned cannot be linked to the eventual solution of a business problem, then one of two factors exist: the business analyst is not doing their real job, or she isn’t a business analyst. No, only kidding about the last. The point is to keep it simple. The more focus you as a business analyst have on solving business problems, the more success you will have doing so, and the more value you will have to your organization.
This probably should be a separate track, but I’m not sure how to do that, so…
Nathan got into the ISO and IEEE definitions of the “imperatives” (as IEEE calls them – I think the reference is 809, while the BABOK mentions them in 1.6, page 204).
While there is value in clarifying, at least for the record, the differences between the various imperatives, I question the value of actually using the different options. Considering that ambiguity is one of the major contributors to misunderstood and misapplied requirements, employing multiple ways of expressing an imperative, even in an effort to reduce ambiguity, only exacerbates the problem. IEEE defines eight different imperatives. I suggest you ignore the options. Why? Because it is unlikely either the business stakeholders who approve the requirements or the solution team who craft the software will understand the fine differences in meaning behind each imperative, nor are they likely to have a copy of the IEEE, ISO, or BABOK standard beside them as they review the requirements. With eight possibilities there is an 87.5% chance that the author will pick the wrong imperative, and an equal chance that either of the reviewers of the requirements will interpret the imperative incorrectly. The odds are too great for mistakes.
Of course one could always put the IEEE or ISO definitions of the imperatives into the requirements document glossary, but I wonder how may of the readers of this blog would consult a glossary upon encountering the word ‘may’ or ‘shall’ just to be sure you understand the right meaning?
I opt for simplicity. Pick one imperative and stick with it. Choose “will”, “shall”, “must” or write the requirements with present tense action verbs, and use the same imperative for all requirements. Avoid the use of verbs of volition such as “may” or “should” because of the inherent ambiguity built into the verb.
Thanks to Laura, I just recovered a link to an article I had wanted to mention in this thread.
It has a diagram that illustrates what I was trying to convey at the beginning of this discussion, about considering requirements as part of solving the business problem, rather than something that comes after the problem is solved. Take a look at the illustration of the logical thought progression during business analysis. I think it represents quite well the relationship between solution definition and requirements:
http://practicalanalyst.com/2007/11/02/thought-problems-and-business-analysts/
Nathan, to me “gathering” and even “eliciting” requirements are poor words to describe the work of a business analyst. That’s why I like the word “discovering” better, and “doing requirements work” as well.
One thing that this discussion has made me realize is that there seems to be a huge difference between BA work as a consultant with an “establish brand”, which I am lucky to have, and BAs that are part of an organization that doesn’t recognize the value of the role.
Professionals like me are added to projects as a high profile consultants that are too expensive, and hence, too credible, to be ignored. We are never considered to be below a project manager hierarchically. Our position allows us to perform business analysis activities in a broader level than what I see described by other people. It is expected that we “facilitate organizational change”, determine business needs, propose solutions for business problems, and work on alternatives with both the business and technical teams to ensure that we reach the optimal solution. I am often asked “what do you recommend?” after I present the results of a research on technical alternatives, and feel comfortable adding my own views to the ones from the business and technical sides.
Sadly, it looks like many BAs are being limited either by their own restrictive view of their work, or an organizational culture that doesn’t allow them to fully use their expertise.
Adriana,
“Doing ‘requirements work'” is a good phrasing, and subtly different than defining BA by gathering requirements 😉
If the purpose, I’d say value proposition, of the BA is “facilitating organizational change” then the connection needs to be made between that and requirements. I don’t think the 8 responsibilities are out of the ordinary or that they make the connection. Now, in fairness the 8 Responsibilities are articulated explicitly from the developer perspective, i.e. the BA value proposition to the developer. Your comment adds adds understanding of both the business and technical needs as essential for the business value proposition.
Perhaps the difference in business and developer value proposition is the point. Can/should the BA elephant be productively described both ways, depending on the particular blindness of the audience?
For the internal audience it probably works the same way. Are going to pack all the parts around the part that satisfies our value proposition for doing the work. How is doing requirements work by understanding business and IT different than doing liaison work by creating a requirements document?
The large point, I think is that there is an added responsibility to make sure that those joining the inside see enough of the elephant to delivery on all the necessary external value propositions. At a base level this may be listing all the moving parts and acknowledging all of the different perspective on which is the most important.
Nathan,
I read the article before I read your comments, and also noticed the underlying assumption that users (or stakeholders) know what they need, which I agree is not always the case.
It rarely happens in the projects I participate. A big part of my business analysis work is about understanding the business problem or opportunity and figuring out the best solution for them. It’s definitely not simply “extracting” requirements from “business and government policies” (if only it were so easy :-).
Even though business representatives and corporate policies are sources for understanding the problem/opportunity and arriving to the requirements, at least in my projects stakeholders typically are too busy to delve into the situation and obtain a clear understanding of what changes are needed in order to achieve the desired result. As the business analyst, I am responsible for determining both the needs and the requirements to fulfill them.
To your second point, I think that knowledge of the technical world typically adds a lot of value to a BA’s work. It’s common for me to see the BA offering an alternative to simplify a technical solution by looking at both sides: what the technical team said about the complexity of what was originally requested, and what the real intention of the business was. In many cases a business requirement can be equally served with a different approach that the development team wouldn’t figure out by themselves only because they aren’t as familiar with the business need as the BA is.
Yet, to me it is still all about doing “requirements work”, even with the “something elses” we are describing here ;-).
An article pointed to by Modern Analyst is a good illustration, I think, of the issues at stake in the ‘requirements as the main focus’ and ‘something more’ discussion.
http://jerrytech.blogspot.com/2009/07/8-key-responsibilities-for-business.html
I’d be very interested in other’s opinions of the 8 responsibilities.
Resp 1: The source of requirements is current policy and “when possible” planned users (making the assumption that future users are those explicitly targeted, since unknown future users are hard to identify).
The something-more here would include how the user relate so and should relate to each other, what the overall objectives of all the users are and what value the overall objectives provide to the business. For adding transactions or reports the project may succeed with user level inputs, but only if the business expects nothing more than reworking individual user interfaces.
It makes the assumption that the users know what is best and are already part of a well structured operational structure. Not always a good assumption.
Resp 5: “Translate into technical requirements (not solutions); abstracting business complexity away…”
The something-more here would include an understanding of the IT architecture and solution to enable cost-benefit pushback on “user whims” from responsibility 2.
In various ways, the other 6 responsibilities make the same point that the BA operates between users and developers without encroaching on either.
This is indeed where requirements exist. But strikes me as a very narrow view that requires explicit recognition of something more to reliably contribute to successful projects.
THanks every1 a lot for responding to my query so fast.. I also wanted to know what’s the difference between a BA in a finance company and BA in software company.. What is the work each of them have got to do. Does BA in IT need to be good at coding skills.. Please tell me this also
Nitin, Both Adriana and Jenny have given you great suggestions. Adriana has written several posts helping new and senior business analysts alike. I don’t have a post specific to preparing for an interview here, but I like the idea and will work on it!
You might enjoy this interview with a recruiter about how he perceives business analysts: https://www.bridging-the-gap.com/thoughts-on-the-business-analyst-and-technology-leadership-job-markets-from-an-it-recruiter/ and this one about a manager’s perspective on what makes a great business analyst: https://www.bridging-the-gap.com/what-makes-a-great-business-analyst/
You might also want to check out http://www.modernanalyst.com, they have a repository of interview questions for business analysts.
Yes, Nitin, also explore the rest of Laura’s site (this one here at Bridging the Gap). A lot of what she writes is targeted toward new and transitioning BAs.
Jenny
Nitin,
I suggest you take a look at this page:
http://2wtx.com/business-analysis/resources/
There you will find a link to Laura’s eBook (which I highly recommend to anyone interested in starting a career in business analysis), and also to free resources like the article I wrote for Business Analyst Mentor (“Becoming a business analyst – assessing your competence gap”), plus tips for interviewing for a BA position and other resources that will help you better understand the hard and soft skills typically required from a business analyst.
Good luck with your interview!
Hey
I am a student of final year B-Tech (IT). I am interested to join a company for the Business Analyst profile…Can you all suggest me what exactly i need to prepare before going for the interview.. I mean what all can they ask me. Being an engineering student, i dont have much idea about the profile of BA …So please guide me by mailing on my id nitin.nitkkr@gmail.com
Thanks in advance
Mike: “as simple as possible, but no simpler” — the whole trick, of course, is finding that point. 🙂
A lot of discussion seems to revolve around whether BA is defined by an abstract result (aligning of what and how across domains), a concrete result (the requirements), a set of activities (requirement elicitation, process analysis, …), or a craft (techniques for concrete result, furniture making, elicitation for requirement documentation). Probably other formulations as well.
The term ‘requirements’ seems to be a useful term for all of these contexts, and so a good generator of violent agreement if only the term is correctly understood.
So, a few thoughts.
First here’s ISO’s rule: 6.10.8 Use of words
* The word “shall” shall be used to express mandatory requirements. * The word “may” shall be used to express optional requirements.
* Although the negative form of “shall” is “shall not”, the negative form of “may” is not “may not”, but is “need not”.
* The use of “may not” shall be avoided.
(IEEE has a very similar specification, but my google fu was weak so don’t have the reference.)
In addition to the wonderful recursion, there is an implicit definition of requirements as a collection of statements. This is a very powerful concept enhanced and supported by every ‘requirements management tool’ in existence. Even adding conditionals (if x then y shall z) this is still like representing Chartres as a set of stones. It misses the point, is really hard to do, and has the bonus of over constraining the stone masons craft.
But, it is a pretty pervasive understanding of what a requirement ‘is’. Adding layers of abstraction onto this concrete notion of an individual requirement requires substantial ans sustained effort.
A second point is from Michael Jackson’s “Software Requirements & Specifications”. Published in 1995, it captures a lot of the learning of a previous generation that seems to have been lost. Under the heading of “Requirements” basically accepts the “shall” definition above and says:
“Not surprisingly when we focus attention on the machine in this way we find that our customers are not very good at deciding on their requirements. … Traditionally, we software developers have thought of our customers as bears of very little brain. They ‘don’t know what they want’ we say to each other smugly. But in truth we achieved this perspective only by virtue of our own limitations and failures. We were the bears of very little brain.”
He goes on to point out that capturing IT requirements, even when done well, misses the interaction of those requirements with all the other non-IT related requirements and therefore cannot be successful.
We need to go beyond *software system related* requirements in his view.
I wish I were so lucky. When I began working with this department of the fesderal government we worked very hard to create a BA centre within the business area of acquisitions. After three years we had 15 BAs in training and were doing front wend analysis for IT as well as developing processes for commodity management. Shortly after I left the group to take a short term assignment, the group was dissolved by senior management and the BAs were all transferred to the IT branch in part because their senior directors complained we were doing IT work in a non-IT shop.
I subsequently joined the strategic management office of the business side and have been working on developing a new business model for the Branch and leading a process re-engineering project on the branch’s contracting processes.
I wonder how many times that scenario has played itself out. All the BAs I formerly worked with have moved away from that job, because they don’t have the IT only interest, or have continued to focus on requirements gathering for IT solutions as their only work.
Mike, I share your hope that the BA profession or role doesn’t evolve in a way to constrain the type of activity a business analyst is “allowed” to perform.
I am probably very lucky, as ThinkInternational (dba ThinkBRQ), the consulting firm I work for since 2005, always respected and valued the BA role, and got me involved in strategic thinking as well. Our work is indeed varied, and I hope that it continues to be so, going from establishing a vision to defining and managing requirements at the project level.
I think we have a case of violently agreeing here. I concur with your statement about the nature of your (and my) work revolving around the business.
I have tried to express my concern about these discussions and intiatives to define Business Analyst as a role. I have elsewhere written about how I see the profession as relatively young and hope we don’t go down the wrong road by constraining ourselves with defintions that are too tight they exclude people doing types of work, or too loose that people doing the work don’t see themselves or their work clearly in the boundary.
The former being exemplified by people who see BAs as only working in the IT domain. The latter by not recognizing the differentiation in domains of work and lumping them together into a single type.
I love these discussions, they are the best way to see the variety of work done by BAs throughout the world. I agree and support your view the most important context we have to keep in mind, as BAs, is the business. I also believe the two most common and important problems BAs have to deal with are 1 – not defining the problem correctly, and 2 – beginning with the solution (most often occurring with IT).
Mike – well said.
Adriana – it comes down to how vague the Business Analysis title is. Other jobs have titles that indicate what they do: Project Manager, Programmer, QA Tester, Trainer, etc.
I have seen different titles for the process improvement work you describe, especially if it is the job’s focus and is based on a method like Six Sigma.
Perhaps someone should do some ‘historical’ research on the origin of the BA title.
Mike,
I understand your point. “Requirements documentation for an IT solution is a very specific skill set and we should recognize that” — indeed, that is true, and I think most people recognize this specialty. My post, however, attempted to go beyond merely IT Business Analysis. Many business analysts — including myself — don’t work exclusively in the IT space. 40% of my work is related to process improvement that doesn’t require any changes in information systems or software applications, but rather defines organizational changes that could be changes in HR procedures, account management tasks, help desk organization, enterprise communication, etc. Even so, I’m comfortable with saying that my work as a business analyst revolves around business, stakeholders, and solution requirements, all the time, and that’s what I was trying to convey here.
I was reminded recently of a principle expressed by Einstein (paraphrased) – make things as simple as possible, but not simpler. A number of people have raised the point about understanding the ‘context’ in which we do our work. I believe we have to take care not to define ourselves and our work in a way that loses the context.
By stating everything we do is “problem solving” or everything we establish is a “requirement” for a solution may be losing the context of work, and the related specific skills and knowledge. Doctors, lawyers and engineers are all problem solvers, but within a specific context of knowledge. Even within those professions there are sub-domains of knowledge.
Requirements documentation for an IT solution is a very specific skill set and we should recognize that. A skill set the IIBA is helping to standardize and improve through the BoK. Certainly I agree process mapping is a skill that can be used in many ways, but I think BPM, at a strategic level, and BPI/BPR, at a tactical level, are domains of work very different from requirements elicitation and specification.
Like many other professions, business analysis has areas of specialization. Some of them may be strongly related, others more indelendent. The skills and knowledge may apply across areas of specialization, e.g. process mapping. But we should be careful not to normalize the terminology to the point where it loses context and meaning for those doing the work.
David W., David M. — yes, I think it wouldn’t be a bad idea for BAs to focus on doing the requirements thing better before thinking of doing anything else, considering how requirements are vastly recognized in the literature as the most challenging aspect of software development, and a crucial one, as it lays the foundation for all the subsequent project work.
From everybody’s comments, I see that there is a concern that business requirements are not always analyzed before jumping into solution requirements. This would definitely be an issue, as the solution requirements are supposed to “describe the characteristics of a solution that meet business requirements and stakeholder requirements”, as defined by the BABOK.
“Going beyond the requirements thing” was Rahul’s phrase, and I you’re right, he meant going beyond SOLUTION requirements and actually doing something with them once we’ve got them.
My point goes straight to the heart of doing the ‘requirements thing’ a whole lot better. After all, analysing business requirements has to be part of the core skillset for a business analyst.
When all we do is collect solution requirements and features and deliver them straight to developers ‘as is’, we devalue the role of business analyst and the benefits we can bring. Sadly, this is the main activity for a lot of business analysts, which is probably why the agile community holds the views they do about the role.
In order to get these core skills working and add more value as business analysts, we need to understand that requirements is not just about the solution, that just covers some of the necessary levels — and that we need to analyse the requirements that we do elicit (not just throw them over the wall as they’ve been given to us).
According to the Standish Group, around one third of the factors that contribute the success or failure of projects is directly in the realm of requirements and scope. If we can solve some of these problems, we can directly contribute to lifting successful projects from only 32% to 50% or better. How awesome would that be. Let’s take on that challenge, and become the enablers of successful business change that we know we can be.
Woh, lots of comments…
My immediate thought is that we should focus on doing Requirements a whole lot better than we have done to date as a profession. Get the core skills working before expanding your scope.
David, thank you for clarifying. If by “going beyond the requirements thing” you (and others) mean “going beyond the SOLUTION requirements thing”, then we are on the same page ;-).
Exactly. I am saying that we do need to focus on solution requirements, just not to the exclusion of everything else — which is what was meant by “going beyond the requirements thing” — otherwise we run the risk of missing the business context, which is vital (as the BABOK makes clear).
That’s what I mean by putting the ‘business’ back into ‘business analysis’, i.e. let’s not make it all about software development, let’s make it about the value that will be realised once the business change has been made.
David, welcome to the discussion!
I couldn’t agree more when you say “We need to understand requirements at a number of levels — from the very highest idea of mission, objectives, business case (…) through to stakeholder (user) requirements, functional and non-functional requirements (…)”.
I don’t think I agree, though, with your statement that “‘going beyond the requirements thing’ means bringing the ‘business’ and the ‘analysis’ back into business analysis.” The BABOK, for example, differentiates between business requirements, stakeholders requirements, solution requirements, etc. Business requirements are defined there as “higher-level statements of the goals, objectives, or
needs of the enterprise”. Identifying this type of requirements certainly requires understanding–and analyzing–the business.
“Going beyond the requirements thing” is the right call to make, because this challenges us to go to the heart of and understand better what is meant by the very terms ‘business analysis’ and ‘requirement’.
Too many people who go by the title of ‘business analyst’ are really nothing more than what I would call glorified requirements secretaries — they document what management and operations say they want from a solution and pass that on to the developers (internal or external).
That’s not to say that the requirements are not important, they are, in fact they are vital to any business change. So it’s less what we mean by ‘requirement’ and more about the level at which we capture it and what we do with it.
We need to understand requirements at a number of levels — from the very highest idea of mission, objectives, business case, problem statements, and business requirements through to stakeholder (user) requirements, functional and non-functional requirements, software specifications, in-code comments, and acceptance tests.
The focus is often simply on solution requirements — how management and operations want to interact with a solution, and the functions and information the solution needs to perform and use. This neglects the background, reason, and justification for the initiative. By failing to understand this, we increase the likelihood of implementing a solution that answers what people think they want, rather than what the business needs. Even when this hasn’t been established up front, we can ask investigative questions to challenge why people want a change or solution (e.g. the six journalistic questions [who, what, when, where, how, and the all important why], and even the “five why’s” to get to the root causes not just the symptoms).
This is concentration on the technical perspective misses out the first part of the title: ‘business’.
As well as getting to the key drivers behind the need to change, we also need to ensure that we add value to the process — that we indentify business rules that apply across the business; that we filter requirements to ensure that only those that will actually solve the real problems get through (avoiding solution bloat) and be achievable in shorter timescales; that we ensure that they are unambiguous, complete, accurate, and fit for purpose; that we help direct the scope of the solution toward an appropriate combination of process improvement, organisation change, and technology; that we apply our experience in knowing what is feasible or achievable, and what may answer the problem more easily, etc.
In short, that we fulfil the second part of the title: ‘analysis’.
So “going beyond the requirements thing” means bringing the ‘business’ and the ‘analysis’ back into business analysis.
Jennifer,
I think any BA will agree with the statement that “we are not just documenters”.
In my view, documenting requirements is not the primary part of the job as a BA. Let’s take my own consulting experience. In 99% of the time the business side doesn’t actually know what the solution is–just what the problem they are facing is. They start telling me “we know what we want, this is how our workflow will look like”. Then I do some analysis based on what they told me, and start to find holes: “you said this step in your workflow is to prevent fraud, but see, it would be easy to still have a fraud happen if the person does X then Y using your proposed workflow. The only way to prevent that would be to use alternative A, B or C.”Then the business look and say, “Oh! right! We hadn’t thought of that. Let’s have a meeting with everybody to go over these alternatives”.
And this goes on and on. While doing analysis, it’s common for BAs to find holes in the stakeholders initial assumptions, that requires rethinking the solution. This is quite different from simply listening to the business say what they want, and then translating it into requirements artifacts that both business and technology can understand.
I think that the only thing we aren’t agreeing here is whether to consider requirements as part of solving a business problem, vs. something that comes *after* the problem is solved. I am in favor of the first understanding, and it looks like you and Steve are in favor of the second.
Adriana, this seems to be a hot topic and going through all the comments I can understand why. I would like to add that our role/function in the organisation should be to solve the business problem, how we do that is probably what differentiates one BA from the next. You say “you need to know the conditions or capabilities you need to solve the problem to actually solve it” I would like to say that we need to understand the problem and its impacts, then come up with a solution, here the solution is either a process change, system change or something as simple as education of the business unit you are trying to solve the problem for. Based on this the comment Steve made about solving the problem first and then looking at the requirements makes sense, I suppose it depends on how long you have been doing this? I find that the newer BA’s (been in the profession for less than 2 years – and there are many) focus on the end product being the specification document too much and this narrows their view. I realise I am treading on water here but if you look at someone who has been around for more than 10 years and someone who has been around for 2 years the solution to the problem will be very different because the way they approach it will be different. I find that the longer you practise the easier it becomes to solve the problem first and then look at documenting the requirements. What I am actually trying to say is it is all about communication, relationships and personal preference. The BABOK is there to guide us and provide us with a standardised view but if I only did what the BABOK said I should do I would not be able to fulfill my role in the organisation. We are not just documenters.
Jenny, I think you summarize the main point very well: the issue isn’t whether a BA “goes beyond requirements”, but rather about understanding what requirements are and how requirements analysis happens in varied contexts. Thanks for contributing!
Steve, I agree that the comment about “going beyond requirements” is an attempt to “break the mold” of focusing just on capturing requirements in formal documentation. Also agree that no one is suggesting that BAs shouldn’t do requirements.
My point, though, reinforced by what Jenny said, is that it isn’t necessary to frame the issue as “BAs must go beyond requirements”. The main problem here seems to be the rather limited vision that some people have about requirements (associating them with written formal specifications only). To me, the best approach is to clarify what “requirements” mean, rather than say that what BAs do goes beyond requirements.
When you say “the suggestion is simply that business analysts should focus on solving the business problem and use requirements as the way of specifying the solution, but solve the problem first”, I think it’s a matter of semantics, as Jenny said.
If we use the definition “requirement is a condition or capability needed to achieve an objective”, and consider “solving a business problem” our objective, identifying the requirements becomes part of the process of solving the problem (i.e., you need to know the conditions or capabilities you need to solve the problem to actually solve it). So, to me it doesn’t make sense to say “solve the problem first, then take care of the requirements”. What do you think?
I think the issue that you mention is not about leaving requirements behind, but to break a lot of business analysts out of the mold of just focusing on the production of a requirements document which is derived from asking a business person what their requirements are and then converting the result into a formalized document. There is a lot more to being a business analyst than doing requirements recording, or at least there should be.
You are right about business process modeling as a source of requirements, but you might be surprised at the large number of business analysts who have never diagrammed a business process, and ask why it is necessary when the activity is suggested. I’m talking business analysts with years of experience.
Revisiting the discussions on the subject, it appears to me that no one is suggesting that business analysts do not do requirements or that they should relegate the requirements definition process to a minor role. The suggestion is simply that business analysts should focus on solving the business problem and use requirements as the way of specifying the solution, but solve the problem first.
Hi Adriana,
Yes, I agree with you. Regardless of what specific task I am working on, ultimately, the analysis usually comes down to, “What do you really need to do, and why?” That is the core of the requirement. Everything else is just a tool or a context for eliciting, analyzing, and validating the requirements. As an analyst, one may have a preference for tools or techniques to do that analysis.
Therefore, the issue isn’t whether a BA “goes beyond requirements,” but rather whether he/she can explain how all business analysis is requirements analysis in varied contexts. As with many things in our profession, it’s a matter of semantics and communication.
Pingback: 2wtx Mastering Business Analysis » Arquivo » New resources to come, and a discussion about requirements as the main focus of the BA work