Elicitation (BABOK KA)

18624 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.

8341 Views
2 Likes
1 Comments

Industry experts agree -- the success of any software development project depends directly on the definition of complete, high-quality, accurate requirements. Today's business analyst (BA) takes a lead role in defining those requirements. BAs are responsible for eliciting, analyzing, communicating, and validating requirements for a huge variety of business processes and information systems.

Since the activities of a BA are so critical to a timely, cost-effective, successful software project, it is important to equip the modern BA with a toolset that supports and accelerates all requirements definition activities, as well as provides the BA with practical guidance and resources to support this rapidly evolving role.

This toolset, known as a Business Analyst Workbench, allows analysts to do the following:

  • Gather and record stakeholder needs from a variety of sources
  • Interpret and analyze this information to produce a set of solution requirements
  • Collaborate with stakeholders to validate the requirements
  • Communicate the agreed-upon requirements to those who need to design, build, and test the solution

A Business Analyst Workbench can dramatically increase the accuracy and efficiency of both requirements definition and test definition. But what should you look for when evaluating a potential workbench?

A full-featured Business Analyst Workbench should satisfy four main criteria:

  • Support for multiple requirements approaches
  • Support for all phases of the requirements definition lifecycle
  • Intelligent integration with other application lifecycle management (ALM) tools
  • Inherent change management of requirements

Author: Tony Higgins

12693 Views
3 Likes
1 Comments

A question was asked in the Modern Analyst forums. I paraphrase:

"How does a BA do their work in an Agile project? Can you give some practical examples?"

I've thought quite a bit about this topic and have experience with BAs on agile developments as a project manager and business analyst.

As a project manager I get frustrated by (but understand) the analyst’s need to move through the sensible steps of understanding the problem domain, documenting it, socialising it and then briefing the solutions team.  Many BAs struggle with breaking away from that paradigm, but to work in an agile style you have to get comfortable with the concept of 'just good enough.'

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.

And, lastly, at the end of the development phase of the project we kicked back into formal gated style UAT and release management.

I think the things I articulated there are useful guidelines for any BA or Project Manager on any project, but these dimensions enabled an agile approach in a waterfall type environment. I put myself forward as the product owner and acted as a proxy for the business stakeholders.

Will it work for you?

It depends on where you are working and your relationship with your client groups. A while ago I put this question of the readers of my blog: "Can the BA act as a proxy for the client?"  I got a resounding no from people that I respect and so I'll re-state that my circumstances above are probably the exception to the rule.

What I have learnt is that the BA can be a very useful person, and even play a crucial role, on an agile project.

Before I go on to speak about that I need to qualify what an agile project is: Originally when people talked about agile software development they were talking about precisely that: software development. The project community has always had a problem separating out the project lifecycle from the software development cycle. If you don't know the difference between these two concepts you need to go find out.
Here is one explanation.

So anyway, projects run many software development activities and naturally the processes and methods bleed into one another. And agile development was soon mixed into the concept of agile projects. And that's fine, but it presents a set of challenges for organisations wanting to transition from one way of doing things to another.

Have you ever learnt to juggle? I did. Hours of practicing in front of my bed so I didn't have to bend down to pick up the balls all the time. But I practiced with three balls and if I try to juggle four or five it's just too hard. I could set aside the time and practice until I get it right, but really, I am satisfied with three. It works for me, so why sweat the effort?

Same goes for shifting project methods. Sure your project office is sick of spending months and millions of dollars on wasted projects, but the various other participants in the project aren't feeling the same pain.

And smart, talented business analysts are one of those groups that aren't feeling the pain. Really, in my experience, excellent business analysts are often enough of a catalyst to break the cycle of project failures. Good requirements management, stakeholder engagement and change management really will get you there, even in the most formal waterfall environments. So why do they have to shift their whole way of doing things? They have achieved mastery of their profession, and now you want them to throw all that away and start again?

Well, yes. An agile approach in an agile environment is so much easier for everyone on the project.

Unfortunately an agile approach in a non agile environment struggles. And that environment is basically the stakeholders, the project team and the organisation's bureaucracy. So you end up using hybrid methods like agile in the developer space but more structured at the top end of the project.

The antipathy business analysts often feel towards agile methods isn't helped by the caustic tone of the agile gurus who advocate direct interface between the customer and the development team. Several of them publicly disparage business analysts and actively promote their removal from the process.

I think the key to getting master business analysts to work on agile projects effectively is helping them find a pain point they want to address, and finding a valuable place in the project for them.

The first point probably comes with either maturity – it's not all about them – or with a series of failed projects (naturally not their fault.). The second point – the BA's role – that was your original question, and it doesn't have anything to do with choices of models.
I think the role of the BA on an agile project is two-fold. Your number one role and priority is to facilitate clear requirements. It isn't to document them and it isn't to elicit them. It's to facilitate their clear transmission to the development team.

In some cases this simply means scheduling and booking meeting rooms, while in other cases it requires the BA's professional questioning and modelling skills to draw out an idea and ensure it is elaborated sufficiently for the developers to understand the full dimensions and context of the requirement.

Developers should, ideally, be in the workshops where requirements are teased out, so documentation is a secondary aspect to this work. It is about facilitating communication.

It's also about making sure the client is fully considering other stakeholders. Enterprise scale projects often have many stakeholders, and in less mature organisations the product owner or project sponsor isn't always considering the needs of his or her peers. The BA can help with that.

So, you see my idea of the role of a BA on an agile project is quite different from the traditional and industry view of what a BA does. It becomes much more people focused and much more about understanding the drivers, values and context of the business requirements than the details of the requirements themselves.

I believe these are key success factors that all excellent BAs apply in their job no matter what the project methodology.

I hope this is useful for you. And I am glad to be corrected by people who know better:" Agile Experts, what say you?"

Author: Craig Brown

132631 Views
100 Likes
12 Comments

Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.

In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.

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.

Author: Glenn R. Brûlé

6669 Views
0 Likes
0 Comments

Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles.

Why is it, then, that a systematic requirements engineering (RE) system is so rarely established?

Where do the problems lie when it comes to implementing such a system?

This paper outlines the challenges and how these may be met using the example of the automotive industry.

Authors: Michael Gerdom and Dr. Uwe Rastofer, method park Software AG

18740 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

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

12392 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

12170 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.

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

15748 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.

Author: James Shoemaker

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











Copyright 2006-2020 by Modern Analyst Media LLC