The scenario is simple: You’ve been tasked to determine the requirements for a new project. You’ve done your homework by reviewing existing documentation. And, now, you’ve arranged to have a meeting with a Subject Matter Expert (SME).
So, where does one begin on this path to enlightenment? When you talk to the SME for the first time, do you start by outlining everything that you think you’ve learned already?
People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation. This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.”
Maybe it’s time to get back to the basics behind requirements and why we need them. In this 3-piece article series, we are getting back to the basics of requirements. Our first installment addresses how to ask the right questions.
No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.
Prior to the creation of something as potentially complex and ubiquitous of a website, an analyst must create a thorough, precise set of requirements in consultation with the right subject matter experts and business stakeholders. But unless one is armed with the proper planning procedures and techniques, the prospect of creating requirements for something as vast as an online business presence or functioning e-commerce system (or both) can be intimidating.
There are a myriad of requirements elicitation methods. The BABOK lists nine (Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, Survey/Questionnaire), but there are many more methods out there such as protocol analysis , job application design , and so on).
Interaction skills are a soft skill set that includes tactful communication, mediation, and diplomacy. BABOK divides interaction skills into three broad areas: facilitation and negotiation, leadership and influencing, and teamwork. All of these skills encompass the ability to navigate politics, even in tricky territory, in order to bring people together in consensus on a project, to mitigate conflicts, and to help people feel heard.
In an ideal world, a single, full-time, expert user would indeed be sitting within view—“on sight”—of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations.
As Business Analysts, we are involved in requirements development and management day in and day out with most of the time spent on eliciting, analyzing and specifying business and software requirements for multiple projects. We follow or adopt multiple frameworks, approaches and tools that help us to successfully gather and analyze requirements. Having done all these things to ensure the success of the projects, we still end up in a few projects wherein we have “missed” few requirements.
It is wise to use whatever techniques we can to discover the 'real' requirements and business rules before embarking on development. We all seem to know that it is cheaper to fix problems earlier rather than later in an IT project. So why do so many of our projects exhibit the same mistakes?
In this article, I’ll show you how you can apply three specific business analysis elicitation or requirements gathering techniques as part of facilitating all or part of a meeting even if you aren’t in a business analysis role.
brought to you by enabling practitioners & organizations to achieve their goals using: