Elicitation (BABOK KA)

14350 Views
20 Likes
4 Comments

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

19314 Views
2 Likes
0 Comments

No matter what requirements gathering process you subscribe to-waterfall, unified, or another approach-your discovery will be markedly easier if you can identify the right subject matter experts from the beginning. Whether they exist inside or outside your organization, people who intimately know your project's product or service, its actors, and its building tools will help you create more inclusive requirements, identify your unknowns, and grow in your own knowledge of the industry.

18447 Views
7 Likes
0 Comments

In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly.

In particular, I'll be mentioning storyboards, wireframes and prototypes.
I'll also cover what level of quality and detail you should adopt when applying these techniques.

12405 Views
7 Likes
0 Comments

In a large enterprise, communication is complex and full of red-tape; e-mails, conference calls, meetings on top of meetings, memos, document management portals, and so on.

Wouldn’t it be nice to find a single resource that has all the answers?

6245 Views
0 Likes
1 Comments

In previous articles, I discussed ways in which business analysts can become organizational consultants, driving innovation, problem solving and strategic solutions within their companies.

In addition to the traditional tools of project business analysis and the emerging tools of enterprise business analysis, another toolkit can be exceptionally helpful.

This is the rich group of practices from the Quality and Process Improvement methodologies, including Six Sigma, Lean, Theory of Constraints (TOC) and Systems Thinking.

Although these methodologies are used in many organizations, their tools have not yet been widely incorporated into either project or enterprise business analysis.

In this article, I will focus on combining a Voice of the Customer (VOC) with the “Ends Planning” exercise from Idealized Design.

Author: Sam Cherubin

6547 Views
0 Likes
0 Comments

Business isn’t going to walk hand in hand with IT until we’re ready to truly partner with them. Here’s how.

I’ve had some interesting conversations about the role of business analysts and the best practices most of them use for requirements-gathering. And I’ve noticed a major contradiction between our desire to be effective partners with the business and the way we go about gathering system requirements.

The contradiction is this: current best practices lead us to gather requirements for a new system by using procedures that, right from the start, cause tension and adversarial interactions between IT and business people.

Author: Mike Hugos

16028 Views
4 Likes
0 Comments

The ubiquity of software project failures – with failure defined as projects that fundamentally failed to meet business-sponsor expectations, missed scheduled completion dates, or exceeded budget – is a pronounced theme in any number of independent research reports on custom software development. The Standish Group, for example, cited that only 31% of projects delivered 100 percent of the expected value, were on-time, and on-budget and a report from the Aberdeen Group found 90 percent of projects came in late, of which 30 percent were simply cancelled before delivery.

Analysts and users alike cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group’s annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. Requirement miscommunications is also the primary factor behind the prevalence of rework, which according to industry statistics, can add up to 40 percent of the total development effort within a given software project. A 2005 survey conducted by iRise and Decipher found that almost three-quarters (73%) of organizations budget for rework, thus, in effect, planning for failure. Moreover, almost one-third set aside more than 25% in their budgets for these change orders, money that could be funneled directly into innovation rather than re-doing work that should have been com¬pleted the first time.

Ultimately, rework costs companies the ability to get to market quickly and saps competitive advantage; while companies are busy fixing applications, their competitors are busy capturing market share.

The solution to these costly, frustrating problems is the creation of accurate requirements before development even begins. By allowing the business analyst to col¬laborate with stakeholders, users, architects, user expe¬rience designers and developers early on in the development process, all parties are involved in the definition of the product and all parties know what will be built long before a single line of code is written.

20600 Views
8 Likes
1 Comments

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

14418 Views
3 Likes
1 Comments

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

150757 Views
100 Likes
12 Comments

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

21258 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops
14737 Views
3 Likes
1 Comments

“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross

I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended.

Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.

Author: David Wright

13909 Views
1 Likes
0 Comments

The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.

In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices

18357 Views
8 Likes
8 Comments

A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time.

After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no.

Let’s see this concept in practice in the “Requirements for My New Car”: a fable.

Page 6 of 6First   Previous   1  2  3  4  5  [6]  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC