Tuesday, 06 December 2011 08:41

Stop Gathering Requirements

Written by
Rate this item
(17 votes)

The common response by a business analyst when asked to describe his or her primary activity is “I gather requirements”.  Management tells business analysts when assigning them the next problem to solve:  “Go gather the requirements”.  This is unfortunate.  Let’s examine what one would do if one were truly to “gather requirements”.

As a business analyst gathering requirements, I grab a basket or some suitable container in which to place the requirements I gather (one needs a basket to put things that are gathered).  I go to the business community and ask them to give us the requirements.  I collect the requirements and then transcribe them as carefully as possible, recording them word for word, onto the organization-prescribed template – a Requirements Document.  I then take the Requirements Document back to the stakeholders to make sure we transcribed the requirements correctly.  The stakeholders may add some new requirements or change some of those they had previously given us which I dutifully transcribe into the Requirements Document.  Then I take the Requirements Document to an authority that approves it.  Having obtained the approval, I turn the Requirements Document over to the solution team and my job is done.

The concept of “gathering requirements” comes from a basic premise:  there are requirements out there someplace that the business analyst has to find.  This means that users or stakeholders have the requirements to be gathered in the first place.  Do users or stakeholders really have requirements?

Users Don’t Have Requirements

That’s right, users don’t have requirements.  Nor do stakeholders.  Nor does anyone in the business.

The job of the user is not to create requirements for us.  The job of users of a system is to sell more product, book orders, enter payables vouchers, or produce payroll.  Even if they were assigned by their manager to take a few weeks off the production line and write up some requirements, they are not trained or skilled in the job of writing requirements.  However, the business analyst is.

Some organizations attempt to make defining requirements the job of the business.  Here are reasons why that approach won’t necessarily work:

  • Users are focused on their own jobs.  They see the business, problem and solution from the perspective of their part of the business process.
  • The best user for the job of explaining issues may not be the one given the assignment to write requirements.
  • Users don’t know what IT wants – they don’t know what requirements are.  For example, they may not know what non-functional requirements are and/or how to express them.
  • Users may not want to commit to a specific requirement or set of requirements for fear they will be held responsible for those requirements and may give us vague or ambiguous statements if anything at all.
  • Users don’t know what is available technologically.
  • Users may not be able to visualize the solution because they are too close to the problem or simply cannot see it.
  • Users are not aware of the overall implications of what they ask for and are likely to specify requirements that conflict.
  • When asked for their requirements, users feel obligated to specify something whether it is pertinent, useful, required, incidental or non-germane.

So where do requirements come from?  They are analyzed into existence.  Requirements are defined or created by the business analyst.  The business analyst’s job is to define the solution to a business problem.  The requirements document is the representation of the complete and accurate statement of what must be done to solve the business problem.  Requirements are a business analyst’s job, not to gather, but to create.

Gather Information, Not Requirements

So if users don’t have requirements, what do they have?  They have information.  They provide us with relevant information:  how they do their job, what they would like to work differently, what a solution may look like, why they perceive there is a problem, what a solution will mean to them, who else may be impacted by the problem or solution.  They can describe the business problem, define the problem domain, identify conditions that cause the problem, and tell us which solutions are preferable.

What do we gather?  Not requirements.  We gather information.

It is from this skillfully elicited information that we, the business analysts, derive and define the solution to the business problem and we write this solution as a set of requirements.  These requirements state completely and accurately what must be done to solve the problem.  We analyze the information to deduce the solution.

The goal of the elicitation phase of the business analyst solution cycle is to gather information, not requirements.  Whoever gathers the most information wins.

What’s in a Word?

There is more to this than just changing our language and using a new catch phrase.  We also change our expectations by doing so.  We assume users really don’t know what they want and make it our job to help them determine the solution to their business problem.  As Steve McConnell says, “The most difficult part of requirements gathering is not the act of recording what users want; it is helping users figure out what they want.”

The interesting aspect of this change to our vocabulary is that we improve our ability to elicit pertinent information, information that will lead us to the solution.  When we expect users to have requirements, we ask questions focused on “What do you want (or need)?”

When we assume users do not have requirements and defining requirements is our responsibility not theirs, we begin to realize that we need a bigger and better view of the problem:  a domain view, one that allows us to gain business insight and knowledge of what is going on with the business process.  At that point, our line of questioning changes to:

  • “How do you do what you do?” How do you perform your tasks?
  • “What information do you need to do your job?  Where do you get it? What do you do with it?”
  • “What don’t you like about the current process?”
  • “How do you know…?”
  • “Where does the information you use come from, and where does it go when you finish with it?”
  • “What happens if we don’t solve this problem?”

We will also find that we might expand our elicitation focus away from the one Subject Matter Expert (SME) who “has the requirements” to a number of stakeholders who work in the business process so that we can confirm the information we have received and so that we can get different perspectives.  We might also find we want to spend some time observing the business process to further understand what is needed and what conditions exist that are causing the problem, in other words, what must be changed to solve the problem.

And when we are not collecting requirements from stakeholders, we are forced to do the job we are being paid to do:  analyze.  When requirements are only the result of analysis, we are not tempted to simply copy requirements statements received from stakeholders into our requirements document.  We are more likely to spend time verifying information, distilling it down to its essence, eliminating requests that do not contribute to the solution, identifying additional questions that need to be asked of stakeholders, reconciling conflicting information, and so forth.

Though we are defining requirements, the business community still has to agree to the solution.  Stakeholders are going to be using the solution in their day-to-day operations long after we have gone on to solve other problems.  As we are defining their solution we are going to confirm requirements with those who are affected by the changes in their processes.  We inculcate a partnership with stakeholders:  they provide the information; we do the analysis and produce a solution; they confirm the solution will work for them (or provide additional or revised information so we can come up with a new solution).  It is an iterative process that requires the business analyst to establish a good relationship with the user community so that there is no problem when the business analyst shows up in user’s office for the seventh time, Columbo style, to ask just one more question.

Removing the Obstacles

Will changing our thinking about gathering requirements really improve our requirements process?  Consider that if users don’t have requirements, they can’t change requirements.  They can only change information.  I don’t think anyone would have a problem with changing information.

When users don’t have requirements, then there is no single user we have to find to give us requirements.  We are no longer subject to locating “the right person with the right requirements”.  We can focus on information rather than individuals.

When all users have is information, then they are not giving us solutions, they are giving us information that we may or may not use to define the requirements.

“Changing customers and users” means only that the information changes not requirements (unless you choose to alter them).  We do not need to have “technically sophisticated users” when users are not supplying us with requirements.  We do not need users to “articulate their requirements”, just what they need to make their jobs easier or better.  We do not need users to “understand the big picture”; it is our job to put together the big picture from the information users give us.

Get the facts first.  You can distort them later – Mark Twain

There’s another subtle benefit when you gather information instead of requirements:  increased confidence and better relationships with the business community.  Users may have trouble defining requirements for you because of the criticality that such definitions have.  No one has trouble describing what they do for a living.  Users can identify what they like and do not like about the current process.  And, as they describe the current process and what they would like to see to make it better, they will gain confidence in you because you are listening to them.  You understand their situation first, then you analyze the information and come back with the solution.  When you return for their confirmation, they realize that you are listening to them and are truly interested in solving their problem.

Here’s one last tip.  As business analyst you are defining the solution to the problem as a set of requirements.  Basically you own the requirements.  That is, you are fully responsible for their accuracy and currency.  It is your job to make sure you have not included your own assumptions and so forth.  However, throughout the process refer to the solution as theirs.  Requirements define the solution to the business’ problem.  The requirements document that describes the solution belongs to the business analyst; the solution belongs to the business.  When you refer to the solution as belonging to the business community, they will take possession of it and participate more fully in its development.

Changes in Platitudes, Changes in Attitudes

It is not only a matter of changing a word or two in our process definition:  it is a matter of changing how we go about our job, too.  As Dr. Stephen Covey says, “Seek first to understand, then to be understood.”  Gather information and analyze that information into requirements.  The more information you get, the better your analysis will be.  The better your analysis, the better your solution will be.  And when we change our expectations and attitude, the stakeholders change theirs as well.

It is a good feeling to end an information gathering session with a group of stakeholders and have them say to you “Good session.  When will you be back with our requirements?”  And even better to have them say, “When you do what you have described in these requirements, our problem will be solved.  Thank you!”

Don't forget to leave your comments below.

Read 38532 times
Steve Blais

Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development.  He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.

Comments  

0 # tony 2011-12-06 03:48
Great read. I once managed a team of BA's and dutifully defended this perspective, but eventually I was the one who was run out of the company. To wit "I don't understand what is so difficult about gathering requirements. Your team is a bunch of glorified secretaries. All you have to do is listen to the users and write down what they say..." And my all time favorite from another 30yr veteran - "why are the requirements so difficult? The RFP was typed in black and white?!?" Of course, my clients had different opinions, like "You are the first consultant or IT guy to actually LISTEN to us" and "this is the first system we feel confident about before we even see it..." How does one go about finding [employment at] companies who actually believe in the value of the BA??
Reply | Reply with quote | Quote
+1 # Bennett 2011-12-06 03:56
Excellent blog Steve, enjoyed that. The only part I'm trying to wrap my head around is whether the BA ' owns ' the requirements. I can understand that the BA elicits or creates them or even held accountable for their accuracy and completeness. But should not ownership should be relegated to those who actually ' require ' the solution ? A close analogy would be that the Developer, DBA, Data Analyst etc does not ' own ' the data. They process it or ensure it's integrity.
Reply | Reply with quote | Quote
0 # Tony Heap 2011-12-06 04:10
Hi Steve, This is absolutely on the money, I couldn't agree more with your perspective. I've been working recently with too many "requirements gatherers" and not enough "solution designers". I think it's really important to drive a change of mindset in the BA community (and also, maybe more importantly, in the project management community) to the point where everyone understands that the BAs are defining the solution, not just gathering requirements. I also agree with Tony above - PMs in particular don't see the analysis/design aspect of the requirements phase. In particular, I've worked with several who think that the requirements can be gathered without the need for any input from the technical team. My own experience is that the requirements (functional design) is often constrained by the technical (or internal) design - and it is necessary for me to iterate backwards and forwards between the business and tech teams until we converge on a solution that works for both. I even don't really like the term "requirements" - I much prefer "functional design" - and I also prefer the job description "solution designer" to "business analyst", because I think it better describes what we (are supposed to) do - but terminology sticks, so I'm not pretending that this will change any time soon. But until we do, project managers and other observers will continue to assume that all we do is "gather".
Reply | Reply with quote | Quote
+1 # Countman 2011-12-06 04:27
A very thought-provoki ng article with a lot of good content. However, I have one major bone to pick with the description of a BAs role, and it all revolves around excessive solution-centri city. Some sample statements from the article that raise my hackles include: - Users don’t know what is available technologically . - Users may not be able to visualize the solution because they are too close to the problem or simply cannot see it. - The business analyst’s job is to define the solution to a business problem. The requirements document is the representation of the complete and accurate statement of what must be done to solve the business problem. - Requirements define the solution to the business’ problem. For the first couple of items, yes, I agree that users are not the ideal providers of end requirements. However, they need not know about solutions, they need to know three things: 1. What is their business 2. What causes them pain 3. What are the goals they are pursuing Answe ring these questions and probing the answers generates a lot of information, which provides material for the BA to analyze and use in synthesizing requirements. Item 1 helps frame the problem and define the relative importance of various requirements. Item 2 provides a reflection of currently unmet requirements. Item 3 provides clues to requirements for a desired future state that may not have direct roots in the current situation. It is the BAs role to stimulate conversation with the users and stakeholders that exposes the information, and the techniques mentioned in this article are indeed of the right nature for this. However, a BAs role is not to DEFINE THE SOLUTION. It is to define the PROBLEM in sufficient detail that it DESCRIBES the solution, and with sufficient coverage to ensure there are no relevant aspects of the solution left undescribed. In other words the requirements identify features that need to be present (i.e., are required) in order for the solution to be successful. The solution may have a whole host of features not covered by requirements, but these would not be directly relevant to solving the problem. Defin ining the solution is a design process, not one of requirements identification. There may be multiple ways to satisfy the requirements, and the project needs to pick one to put into place. E.g., if a requirement is to ensure only valid data gets captured in a particular data element, you can ensure success via a dropdown list, radio buttons, checkboxes, comparison of entry to reference data, etc, etc, etc. So the right thing for the stakeholders to say should be: "When you give us a solution that addresses these requiements, our problem will be solved." Delivering that solution is a project management problem, not one of business analysis. The business analyst's job is understanding the requirements and communicating them. This includes all of the factilitation and capture for identifying the requirements; analysis to ensure completeness, fit, and relevance of requirements; documentation and discussion to ensure the requirements are both available to and accurately understood by those developing and agreeing to a solution.
Reply | Reply with quote | Quote
0 # colin 2011-12-06 09:57
A great article that explains exactly what BAs really have to do in order to deliver a DLR Specification that defines what the business really wants. My only disagreement would be with your references to the BA "defining the solution to the problem". While the BA may be involved in this activity, in many organisations it is the role of the Solution Architect (or similar) that has the responsibility for defining one or more solutions that meet the requirements. Solution Architects (should) understand the capabilities of an organisation's existing, planned and potential applications, and suggest the best way that these can be utilised to meet the requirements. BAs should be involved in the process to understand how the requirements will be delivered and the possible impacts of the solution.
Reply | Reply with quote | Quote
0 # Gerwin 2011-12-06 16:33
Great article. There is the perceived responsibility for BAs to come up with the solution to an identified problem after gathering the information and applying a certain level of analysis to understand the real cause of the problem. What would be the point of all the analysis if it stops there? The logical next step is to come up with recommendations that would either solve the problem or provide a temporary workaround, or at the very least facilitate this process. That's where I think the real value of BAs come in.
Reply | Reply with quote | Quote
0 # Tony Heap 2011-12-06 17:45
@ Countman & Colin - My personal view is that the split between the responsibilitie s of the BA and the Solution Architect causes problems in many organisations. To my mind, there is little value in having a BA "capture" or "gather" the requirements for a Solution Architect to then define the (functional) solution. To me, they are one and the same process - creating the requirements *is* defining the (functional) solution. I much prefer a split whereby the BA defines the (functional) solution and the architect is responsible for the technology solution (i.e. the internal aspects of the system). I completely agree with Steve when he says that the BA should "create" (not "gather") the requirements. In fact I would go further and say that the BA "designs" the functional solution - and whilst BAs continue to deny that they are performing a design activity, they will not be adding half of the value that they could with a change of mindset. That' s only my view though :)
Reply | Reply with quote | Quote
0 # Michal Mintowt-Czyz (Minty) 2011-12-06 18:20
Good Article, however I would be very careful about you use of the word "Solution". (I agree with colin, December 06, 2011) The BA role is to define what the business Want, but not How it is to be delivered.
Reply | Reply with quote | Quote
0 # steve blais 2011-12-06 19:20
Hi Bennett I'm using the word "own" to only imply that the business analyst / author of the requirements document or delegate is the only one who should be allowed to physically change the document. This same approach is taken by Scrum in that the Product Owner "owns" the Product Backlog and is ostensibly the only one allowed to change it. This way the developers cannot arbitrarily make changes to the requirements without notifying - not necessarily getting permission - the business analyst so that the requirements document (or Product Backlog) can be kept up to date. Following this practice we have a better chance of keeping to the principle that the requirements document should reflect the delivered system, and vice versa.
Reply | Reply with quote | Quote
0 # steve blais 2011-12-06 19:38
Tony and Tony: You are both correct. But there is a certain amount of blame to be placed on the business analysts themselves for the attitude of project managers and others toward us. It is easier for business analysts to place the responsibility for the requirements on the business and just record what is given to them. That way when the solution doesn't match, the business analyst - and the project manager and solution team, I might add - can say "we've given you what you stated you wanted. We have it in writing. It's your fault if it doesn't solve your problem." What the business analyst needs to understand is that the solution to the business problem is our job, and in many cases, our only job. And further that the customer and users and other stakeholders do not know what it will take to solve the problem, either from a business or technical point of view. That is why business analysts exist. If the customer could express the exact specifications of what is to be built in software to the developers there would be no need for business analysts. We are not there to translate. We are there to assist the business in determining what the real problem is - sometimes using our investigative and analytical skills to identify problems beyond the symptoms reported by the business. We are there to gather information, define the problem domain and the business processes within it (sometimes for the first time ever) and analyze the information to produce the best business solution and provide that solution to the solution team in a form which they can use to implement the technical solution - a document, user stories on cards, a product backlog, whatever form will work. This is not easy. It requires critical thinking, risk taking, elicitation, negotiation, listening naively, a large dose of analysis, and above all taking full responsibility for defining the business solution to the business problem. It may be more work and higher risk, but the satisfaction (and ultimately the promotions up the corporate ladder) is high, and even more important, you gain the respect of your peers, especially those pesky project managers.
Reply | Reply with quote | Quote
+1 # steve blais 2011-12-06 21:19
Colin and Countman and others with the issue of "solution": The re are two points here. One is that the business analyst does not (and should not) always recommend an IT solution. The business analyst is analyzing the business problem, whatever it might be. A recommended solution might be to change procedures or processes on the business side without any software being developed. Remember that business analysts live on both sides of the aisle - IT and business. In many companies business analysts do not work for IT. In the mid-90s that was the general trend. Now IT has appropriated business analysts to work for the technical side. So if the only "solution" to the business problem is the one that IT delivers, what would we call a solution that does not involve IT. Note also that even non-IT solutions have requirements: the specifications of what is to be done. If the solution is to relocate departments closer to each other to reduce a communications problem (actual solution) there are requirements to effect the relocation. Stating that the business analyst provides a solution helps the business analyst focus on the real problem and the business solution and not simply on what the solution team needs. Secondly I believe we really have two problems and two solutions. The first problem is the business problem and the solution is the business solution: what the business needs to do to solve the problem. Those in the business affected by the problem should be able to understand what the solution is (as embodied in some document stating what needs to be done) and those impacted by the changes the solution will bring about should be able to understand those impacts and what might be expected of them as a result of the change. The second problem is that the business solution exists only on paper (or index cards or backlog list) and not in reality. The second solution is the implementation or the technical solution which defines how the business solution will be implemented. That is the job of the solutions architect, the systems analyst, and/or the development team. They must determine how the business problem will be solved and produce the working implementable solution. This second solution will impact and change the first solution as Tony Heap suggested in his first post in an iterative fashion. The two solutions should be relatively coincident so that the technical solution is usable by the business to solve the problem. I thought of using the term "proposed solution" but that is misleading in that once the business signs off on what they want it is no longer "proposed" except maybe to the solution team who might change it for technical reasons. "Business solution" and "implemented solution" gets too cumbersome. I recognize that there is a certain possessiveness (and perhaps pride) of the solution by the solution team, and perhaps rightfully so. I was a programmer and systems analyst for a good thirty years and always felt that the solution was mine - or the team's. However, when business analysts look at the requirements as defining a business solution to the business problem they are somewhat compelled to take more responsibility in the production of those requirements and produce a better product. There is also precedence for this separation of solutions. When an architect or interior designer listens to the customer and builds a model of the building or draws a picture of the room they offer it as their "solution". Their "solution" exists only as a model. When approved it must be then implemented or built. That, as anyone who has had a house built or worked in the building trades knows, is yet another problem, or series of problems. In many professions, "solutions" are represented on paper first to gain agreement, e.g. a government regulation, before it is implemented. And that's kind of the idea I had in mind when I say the business analyst prepares the "solution".
Reply | Reply with quote | Quote
+1 # Adiop 2011-12-06 22:19
I think the article addresses the core of Business Analysis. The rest is all semantics. The BAs describes the capabilities to be found in the solution. Eventhough the BA does not directly provide the solution (it's the role of developers to do so), the BA has a lot of influence over the solution.
Reply | Reply with quote | Quote
0 # Scott Firestone 2011-12-06 23:35
Great article with regards to the elicitation process with stakeholders - ie not being a glorified secretary, rather getting to the root of the stakeholders' needs by asking questions. I particularly like the quotations to illustrate the points made. As others here have commented, I also feel that getting too involved in the solution is not necessarily the role of the BA. Some delivery teams do not like it when we unnecessarily "prejudice the implementation of the solution".
Reply | Reply with quote | Quote
0 # Countman 2011-12-07 03:54
A little addition to my last note. In some cases, I may be aware of business models from operations research, economics, various industries' best practices or other non-technology sources that offer a good framework for solving certain problems. However, getting technology experts to accept such frameworks is often a challenge requiring a lot of persuasion. This ties back to Scott's comment about prejudicing the solution - a lot of technology experts will resist such solutions proposed by a person they perceive as being fundamentally a business person, and therefore "treading on their turf" by attempting to lead into solution space. Therefore, the classic division between BA being problem definition focused and designers and developers who are solution focused comes into existence as a convenient default line of division of responsibilitie s. Not to say it is not worth pushing the envelope once in a while, but it is unreasonable to EXPECT a player with a particular set of skills to exercise skills and authority in an area where they are generally not as strong. This applies as much to technically-ori ented people leading requirements definition as to BAs leading solution work.
Reply | Reply with quote | Quote
0 # steve blais 2011-12-07 05:19
Countman and Scott You are correct in your general assessment of territorial imperative. I have been involved in and observed many such disputes between developers and business analysts centering on "crossing the line". Sometimes the project nearly grinds to a halt as the development manager sends business requirements back time after time to get the business requirements to be devoid of any technical implication. Ha ving been on both sides of the equation, I agree with you that the business analyst should keep away from over-specificat ion and from technical constraints. Business requirements - whether you call them a solution or not - should be implementation agnostic. The implementation should be left up to the solution team, if for no other reason than to keep the peace and further collaboration. There are exceptions, such as when the business has a technical requirement such as a regulatory constraint. One of the techniques I have used and pass on to those I work with to keep the peace is to ask the lead technical person, or systems analyst or whoever takes the requirements (in whatever form) from the business analyst to work on what they want to see. What do you need to increase the chances of your implementation success? Do you want use cases or user stories or marked up screen shots or a list of requirements? The answers sometimes might surprise you. Regardless, by delivering to the solution team what they need to be successful will ease the job of turning the requirements into a working solution.
Reply | Reply with quote | Quote
0 # Leslie 2011-12-07 07:19
On first read I agree with Countman's assertion that we build problems not solutions, but then on further thought, I would say that I generally specify the problem in terms of a solution. So a term that is some combination of the 2 might be more appropriate (but I am by no means an expert on spoken language, so don't ask me). Anyway, the article gets the point across very well - my nitpick would be of the 'creation' of requirements. I agree with the point being made, but again it's a terminology thing. My preference would be to say that the BA gathers information and uses this to 'formulate' the requirements - suggesting to me that the requirements already exist, it is the BAs job to present them from their findings, not to 'create' them (which sounds like it could mean that the BA makes them up). As Ia see it, the BA creates as little as possible. The BA role is to learn, discover, analyze and present. ------ --------------- --------------- --------------- ----- Everything from here on is rambling: As an analogy I was thinking of an Archaeological dig. The pieces are there to be found. One can gather the pieces by picking them up from the ground, but in order to get to the whole picture one has to dig, and dig carefully (carefully being analogous to interviewing stakeholders who might feel they have better things to do than explain their role to an IT person). As you discover the relics they are pieced together to make artifacts (hmm, interesting term that). The presentation made at the end of a dig (or sprint) will contain parts of the picture that is buried beneath the site. As with requirements gathering, an archaeological dig will never give you a complete picture of what happened at that site, but will be enough to draw a picture that satisfies most customers. -------------- --------------- --------------- --------------- ---------- And everything from on is promotional Wh ich leads me to an article I posted to BA Times about an analogy between requirements analysis and building a jigsaw puzzle. Maybe the archaeological dig might be a better analogy.
Reply | Reply with quote | Quote
0 # steve blais 2011-12-07 08:27
Hello Leslie Good hearing from you. I love your analogy of an architectural dig. It seems to hold together. Being somewhat of an archeological artifact myself though, i wonder at the implication of age and oldness in what the business analyst finds among the piles of dirt (irrelevant information). Granted some systems are old enough to be relics and the facts and nuggets we pull out certainly seem to be from some dark age before Babbage, but in general IT work is deemed to be new and on the edge and exciting and all that. I do wonder about your early comment about specifying the problem in terms of the solution. I may be misreading or misunderstandin g what you are saying. It sounds backwards. It sounds like a common complaint of business analysts that the business requests a solution and we have to figure out what the problem is. Or IT has created a solution and we have to create a problem so the solution can be implemented. Or even worse, someone in the business or IT has just bought a whiz-bang software package and now we have to justify it by figuring out a problem to apply it to. Shouldn't we be defining the solution in terms of the problem? Or did I totally miss your point?
Reply | Reply with quote | Quote
0 # Nick Panagopoulos 2011-12-08 02:37
BAs are hunters, not gatherers!
Reply | Reply with quote | Quote
0 # Duane Banks 2011-12-16 14:03
Steve, you and I once haggled over, "creating requirements into existence." I have understood requirements to be pre-existing--t hat is, to the extent of BA involvement. To my mind, BAs "develop" requirements--e licit, analyze, specify, validate--to completion (not necessarily to existence). Since you distinguish requirements from information, the concept of doing so is akin to that of developing requirements. So, when you say "analyzed into existence," you are referring solely to the solution specifications, since prior to analysis there was only information. . By information you are referring only to the problem defintion (correct?). Regarding the issue of solution, as a BA, I consider myself a contributer of both the problem and solution spaces. Though, for the solution, at a more abstract level than designers and developers (@Tony Heap, I prefer the term "functional specification" over "functional design," as the word "design" lead to potential confusion). Regarding requirements ownership, I asserted in our previous discussion, "the business owns the requirements. The BA is the caretaker," which I still choose to believe. However, your concept of separating information and requirements supports your argument that the BA owns the requirements. Thanks for writing this article!
Reply | Reply with quote | Quote
0 # Akarsh MG 2012-01-09 15:38
Excellent thought-provoki ng article with a lot of good content and great Comments!!
Reply | Reply with quote | Quote
0 # Manikandan K 2012-01-17 18:11
Steve, Gr8 thoughts...very nice to articulate what the actual problem rather than to identify the solution on day 1 / worse timing the effort sans visioning it on long horizon.
Reply | Reply with quote | Quote
0 # Elizabeth White 2012-01-24 07:01
Great article. I just returned from maternity leave to my BA role and it was great to read this article. I have a feeling I will be using the reasoning of this article and some of the feedback comments with my future PMs when I describe what my role is!
Reply | Reply with quote | Quote
0 # Tony Heap 2013-07-28 16:49
Hi Steve - hope you don't mind a shameless plug - I have referenced this article as one of the inspirations for a new article I have just published myself: There's No Such Thing as a Requirement
Reply | Reply with quote | Quote
0 # Tony Heap 2013-07-28 16:50
...for which the URL is http://www.its-all-design.com/theres-no-such-thing-as-a-requirement/
Reply | Reply with quote | Quote
0 # Kim 2013-07-29 15:15
My company has moved to the Business owners writing the user stories and our UX designers are including some pretty detailed annotated functional rules with their designs? What's left for an IT BA to do? Can you provide some insight on how I can show added value to the role now?
Reply | Reply with quote | Quote
0 # Johannes 2014-06-10 03:28
When asked what I do as a BA my pat answer is that I’m an investigative reporter.
I investigate some issue/problem and record what I discover. I then analyse the information gathered to gain some insight. I then report my findings and my conclusions from the insights gained. Form these insights and conclusions I propose what is required to overcome the issue/problem.
You gather information to gain insight. Only once you have insight can you propose a solution. This solution requires certain actions and changes to implement it. A solution implementation strategy. So as BAs we design implementation strategies for solutions to issues/problems.
I have never liked this idea that a BA is a requirements scribe. So it is good to find likeminded people.
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

© BA Times.com 2016

DBC canada 250