Requirements Elicitation Projects (7,271 words)

This article is a transcript of the BA Video Series Linkedin Live video on Requirements Elicitation

You can also listen to this via our podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com

Listen to this small clip from the podcast:

Speakers:

Simon Board

Manasi Mohandas

Zoha Hamza

Vijay Nair

Intro

Vijay Nair:

Welcome everyone on LinkedIn to the latest episode on requirements elicitation. So we have on in our panelists to Simon, Manasi and myself Vijay. So let's kick off by introducing the topic for this session, which is the requirements Elicitation.

So there are so many definitions. It really depends on which angle we are approaching this. So these sessions, we are specifically looking at the business analyst as a profession and, the type of activities that a business analyst gets involved.

So requirements in the business analysis world is researching and discovering business requirements of a product or system or process or project from the, different stakeholders and then working with them at least in the software development team, working with these developers or the build team to actually implementing requirements.

We use all kinds of approaches and tactics to apply there. So in this session, our speakers will actually share some of their project experiences and how they approach projects using different business analysis techniques from the BA tool kits.

So that note, I think we're ready to, first of all, have a quick intro from our speakers, starting with the Simon.

Simon Board:

Sure. Yeah. thanks me, Jay and well, yeah. Welcome to everyone for joining the stream. it's great to see you all here. And probably you've heard from me, in some of the messages in LinkedIn, and we've been in contact and things. so yeah, it's great to see you all in, in the live session. So I guess in terms of my intro then, in terms of my BA backgrounds, I come from sort of an e-commerce background and, I've worked for a couple of big retailers, such as new look and Deb Adams as well, where I've launched the e-commerce solutions.

and also, replatformed some of their existing systems as well. And that, that's kind of one of the examples that I'm going to talk to you about today. and then in terms of their BA video series, so you, might've got a few messages from me or. Or heard from me around the actual series. so myself and VJ have really picked this up as, as our own little initiative is something we do kind of outside in our own time.

and it's amazing just to see how it's kind of gone from, from a group of roughly 10 people to now about 170. so it was great to have you all on boards and I hope you find these sessions useful. and I'll kind of focus for these sessions really is. Instead of just teaching you about a certain topic, we provide sort of our real world experiences, which I think is one of the big benefits that, that kind of this series will provide you with some real life real world experiences, within the sector, and how we're going about doing things, in organizations.

Manasi Mohandas:

So my background is a mix of, Development. I was in a platform development team back in India, working for a product software, which is a banking solution for personal and corporate banking, which is a customized billing and pricing solution, basically. So for my first four years was mainly in the Java and the skill development and from their own, I was the Guinea pig was sent to onsite to fix and phase the client for, you know, production issues and all these things.

So I got a flavor of how it looks like in client side. And then I moved on to a business analyst role. And then I did my masters in data analytics and now, again, a BA working for a Washington one in Belfast. And right now I work for an onsite public sector project, which I'll be more talking about today.

And that's me.

Project Experiences

Simon Board:

Great. Thank you, Marcy. So on that note, I think we're ready to kickstart with the project experiences, starting with the, if Simon, if you want to go ahead and then minus C and I think I can also chip in with some of the project experiences as well. So. Simon. Cool. Yeah. Thanks VJ. so yeah, just to give you a bit of a background of what I'm going to talk to you about today.

So, as I mentioned, I work for, currently a software, analysis company, but previously my experience has been in the retail sector, working for the likes of new looking dominance and one of those projects, That I've worked on was basically, replatforming an old, e-commerce platform called Oracle ATG.

I don't know if some of you have heard of it, but, we basically replatformed over to, SAP Hybris. So this was another web platform, basically that enhanced some of the capabilities of the business. The reason we did that is basically ATG was a bit slow and it was unable to support the kind of a flux of users that we got on the site because, we started getting more and more customers coming onto the eCommerce site and we therefore needed something that was more responsive and more kind of capable to deal with that many customers.

So we did this B sort of big replatform and big restructure and the way. The way the business did things completely changed, and the processes. So it kind of involved, first of all, sort of migrating the existing processes from ATG over to this new platform Hybris, but it also involved a lot of other things, such as re-engineering of, of the business processes and also sort of training of staff, to be able to operate with the, with the new, platform.

So a big part of that was actually managing the stakeholders, across multiple teams. and what I'm going to do, I'm going to quickly, I made a list all of the stakeholders, just because I'll, I'll forget how many stakeholders have to deal with, but it was basically, a load of stakeholders across multiple teams.

and some examples of those, where the trading team. Position team, the fulfillment team, customer services, CRM team content team. so as you can tell, there are a lot of stakeholders involved in that process, different views, different backgrounds, different experiences, and also have different inputs into the solution.

So, for example, the trading team, we're interested in all of the merge stuff. getting the adverts out there on the site, putting up the content, and promotional stuff, to customers, we had the customer acquisition teams that was all around the analytics. The SEO, the kind of affiliate management side, of the eCommerce solution, we have the fulfillment team.

so they're involved in the, kind of the returns, order fulfillment, stock control, those kinds of things. the customer service teams. So the refunds customer queries, and also this click to chat function that we have on the website as well. the CRM team, then we're all around the personality.

Personalization customer service, that kind of thing. Then finally the content team. So they looked after the UX, the copywriting, the editorials, and all of the photography as well. so there was, there was quite a range of stakeholders for this project and, and that made it pretty difficult to, to kind of go into those requirements, elicitation, meetings and actually be able to sit down with each of those teams to, in order to, to refine and define the requirements.

So the reason I've called out all of those stakeholders is when you think about requirements elicitation, you have to think of the kind of stakeholders. That you will be going into these meetings with. So all of these different people in all of those different teams will have different RA responsibilities and areas, and also seniority as well.

So you'll have senior members of the team, but you're also having the people that are more on the ground and actually doing those activities. So when you think of requirements solicitation, you need to understand your stakeholders and also the role and responsibility within those projects to make sure those sessions run smoothly.

So that was just a bit of background, really into all the difficulties that I kind of faced when gathering these requirements. so I had to be kind of strategic when I'm putting those meetings in place, you know, rather than just having these long, big workshops, I had to think really, is that the best way of doing things?

You know, how am I gathering those requirements? Maybe some stakeholders prefer one-to-one interviews and face-to-face interviews, or just being emails. and, in order to give time to respond and things like that, because take, for example, like workshops, they're all well and good because you can have multiple stakeholders in those meetings and it saves you time as a BA.

Going round each individual and having these one-to-one sessions, but it might not be the best approach in some circumstances, you know? I'm sure we've all had plenty of, of meetings where, We've been involved in these long, long workshops that last seven hours. And you'll find that after two hours, you know, people get disengaged with those, you know, they, that their eyes wander around the room and they start playing with their phone or, or doing whatever.

So you just have to be conscious of that. These workshops are well and good. And there are, there are pros to having those workshops, but. You have to also be sensible on kind of thinking what's the most, kind of interactive and best way to engage with people. and in these sessions is it's also given people, time to have a break as well.

So that's kind of a key thing, like taking your lunch breaks and taking your coffee breaks and yeah. That, that can seem like quite a trivial thing. But when these stakeholders are in sort of seven hour meetings, right, their mind wanders, as I say, they might get fed up. They may lose interest in the topic.

especially as, because there's so many stakeholders and. And each person is kind of putting their view forward. it's quite a crucial element of that, you know, interacting with people, giving people that time to have a break, and really, kind of, kind of making it interactive is if you can. You know, providing the likes of a PowerPoint or something visual on the screen that they can actually see and interact with, as opposed to you just talking at them for seven hours, you know, it, it's far more interactive.

So in terms of hints and tips for that, but that I learned on this project, it's, it's keeping people interested in those sessions. And it's also being strategic about the kind of technique that you use, for a certain circumstance. So I'll give you a quick example actually, of, you know, I was talking about the photography team and the merchandising team.

yeah. Your requirements, solicitation sessions are not always as formal as you think they're going to be. They're not always in an office setting. You know, you don't always have a room to use. there's been circumstances where I've actually been out in the field and an OMA nasty issue. She'll talk about this, in more detail on some of the projects that she's worked on.

but I've been in the likes of photography studios. I've been outside to, to things like farms and industrial places gathering requirements. so it's not always as straightforward as just having a meeting room, sitting people down and having a nice office environment where you can type notes and have these interactive sessions.

So you kind of gotta be adaptive as well. to certain scenarios and situations like I've been out in the likes of laboratories and on field sites where you've just got a note pad and you've got to scribble down your requirements in, in some car, you know, as I say, on the back of a fag packet kind of thing, and then turn them into requirements.

so there are difficulties around that as well. And I know people sometimes slate the likes of, Excel documents and things. But often I use that originally to actually gather my requirements because it's, it's easy to, to put them in an Excel spreadsheet and filter them and prioritize them in the initial state, especially just even to get it up.

On screen to stakeholders and say, well, these are the kind of less of requirements I've gathered so far in this Excel document. Can you quickly review them? Because I know everyone loves JIRA and I love JIRA too. You can do all sorts, like query things, prioritize things in a backlog, but. It can sometimes be difficult to see the word through the trees when you're looking at JIRA, you know, I'll, I'll send them a link and go, well, here's user story.

Number one, two, three, four, go and have a look at that user story. And a lot of people, I found just a too busy to do that, and they never ended up looking at that in JIRA. so that can be some of the difficulties. Whereas I find if you have it up on screen, you have a spreadsheet or a visual there, you know, or even a process map.

Or something, just showing something visual that they can actually interact with. I've found that's far more beneficial that way, to do that. So there are just a couple of tips, that I would, I would recommend for people. also just touching on the whole personality thing and, you know, I was talking about seniority of people.

there are different stakeholders that you have to deal with. Some are more senior than others and everyone. Unique personality, you know, we're all made up different. You know, we all have different DNA, you know, without going too much into science or anything, I'll leave that for the scientists, but everyone you speak to is different and how you interact with people is different.

And you have to adapt as a business analyst, I think, to all these different situations and scenarios. So. Becoming an expert in requirements. Elicitation I find is, is quite tricky. It's not like learning a language, for example, you know, once you've learned those words, those words always stay the same.

They stay consistent. They're, they're easy to remember. Whereas when you're dealing with stakeholders, all of those stakeholders is different and all the scenarios you'll come across a different, but yeah. I guess something that can help you deal with that is being prepared when you go into those meetings and having the stuff ready to assist you.

And a lot of those sessions are actually about preparation in advance. I think that's quite crucial, you know, it's setting up those meetings in the calendar is making sure all your stakeholders are actually available to attend those sessions. and that the time is convenient to them. so it's working around people's calendars and it's making sure that, they're able to attend those sessions and provide the most input into those sessions.

So. That was actually something that I didn't realize when I initially was a business analyst, I thought, well, just put a meeting in the diary. Everyone will turn up and you're having an amazing session. Everything will run smoothly, but in reality, it doesn't, if you don't put that preparation in advance and work out, who's attending why they're attending, you know, what are they there for?

How are they trying to communicate their point across and actually taking those stakeholders opinions? you know, when you're going into those sessions, they're all important things. So it's, it's a lot of prep in advance. If you can, the more prepared you are for something the better that session is going to run.

If you just turn up at nine o'clock and expect that seven hour session to run smoothly, it won't, and, and I've kind of found that out the hard way as well. when I've gone into these sessions, I think, well, as long as we've got everyone in the meeting, then we'll achieve a good outcome, but that wasn't the way.

so throughout doing those sessions in that project, I found that. There are a lot of takeaways in terms of prep in advance, having the material there to actually reference, being engaging for stakeholders as well. No one likes a long boring meeting, you know, in enough meetings as it is without, another meeting dragging on and on.

So it's keeping those meetings focused as well. a lot of the people that come in there, you could have people that love to talk. and that's great in terms of gathering requirements sometimes, cause they give you a lot of input, but at the same time that can change the focus of the meeting. So you have to kind of make sure those meetings stay on track as well.

So. There are a few kind of top tips like Anne in terms of, the actual project itself. we basically reviewed all those stakeholders. As I say, took into account the way they did things, and actually put those sessions in place. Once we'd run the sessions. We basically gathered all of those requirements.

we put them into JIRA. we formed the product backlog and we walked through those user stories with them, just making sure that all of the requirements we had gathered in those sessions are accurate. So my kind of top tips for after the session would be that once you've gathered those requirements, send out the list of.

kind of requirements that you gathered and all of the actions and takeaways from those sessions as well. because it's important to communicate that after, the stakeholders as well. just to make sure they know what's happened in those sessions and for people that have missed those sessions.

So they're kind of the takeaways for after it's, it's making sure you thank everyone for their time as well. also reviewing those notes and actions as well and actually actioning them. After the session. So going back quickly to the project, so once we gathered all the requirements, we got them out to JIRA.

we pass them over to the dev team who then went and developed those, requirements. And for this particular project, the, the commerce re platform, we actually went out to a supplier. so we got a procurement. I don't know how familiar people are with, with procurements and things, but basically we went out to the supplier who was Hybris.

So SAP, is the actual name of the company who implement Hybris. We went out to them, gave them their requirements and they implemented the solution. Once they had done that, there was this whole phase of making sure the stakeholders are aware how to use the new platforms. So that involved things like, process mapping, the, the, obviously the as-is situation and the, to be as well and supporting those users with using the new system.

So that involved me getting involved in the kind of training aspects of it, go into each of those teams and making sure they can use the new platform. and just supporting and handholding them through that. so that came with its own challenges. You know, people saying, Oh, I used to be able to do this process in the old system.

Why is it not working in the new system? So there was a lot of saying, well, okay, You know, give it time, give it training. and once you've done that, your, your processes will be far more efficient. So I think it's about setting that message as well to people to be patient, with what we're doing. You know, we're here to gather the requirements and the whole purpose of that is to provide loads of benefits down the line, such as, you know, bulk uploading of things, making your processes far more efficient.

And I think kind of setting the scene as well, in the requirement sessions and just saying these are all the advantages, that you'll get from, from doing these sessions, is, is a big part of it. So. I think I've probably talked enough, to be honest. I hope that I hope that was helpful. I hope. Well, I gave you some tips and I, I tried to relate it to a real world example as well.

Cause I think that's where the benefit sometimes is because. You can read all these books around requirements, solicitation, all of the techniques and, and kind of procedures and things you follow. But I think kind of the real value is actually digging into how those sessions are run and some, you know, hints and tips and experiences from, from kind of.

Where I'm we, you know, the experiences that I've had within those typical projects. so anyway, it's given me a shout. If you have any questions around this or, you know, any hints and tips, I'm happy to kind of message you on LinkedIn or, yeah, you can catch me on WhatsApp. We have a WhatsApp group as well, where we, we ping kind of questions and, and things like that.

And obviously we've got a Q and a session where I can handle. Additional questions. So, on that note,

Manasi Mohandas:

Yep. Sure. Thanks. So, when you, whenever you say about requirements gathering, there are stages where we enter a project and that is very critical.

So sometimes we might be at the start of the project and it's a new project, and sometimes we might be going inside a project which has already been there. And we're just going into one sprint and starting the requirement at the middle of the project. So your stakeholder changes that time. So, whenever we did was introducing, I was thinking you could, you could actually briefly, in a wider category, you can say that it's a domain discovery or user discovery and a requirement discovery.

So you can categorize it as these three discoveries. So when for me, for this public sector project, I was starting that project. So domain discovery was the first thing I had to do. It's a prerequisite before you start a government discovery, because you need to know the domain which you're working with.

I had absolutely no idea of the domain I worked with. So it's not always books and articles. Definitely. That helps, but. Actually speaking that requirement might be implemented somewhere else in that building. So you D you need not really go and do that if it's already there, so speak to people. Sometimes you think these people are not relevant to us, but that's not the case.

You have to think about you. You have to speak to probably everyone you see and understand what is happening in the building or in the organization, and what other teams are doing. And what, what was the history behind this organization? And what is the future of this organization is very important when you, when you think about the domain, because, you can just think about a minor piece of requirement and just work on it.

But if you think about how this organization was formed, why did they reach where they are now and where they're going? Those are the big management meetings, which we hate to go inside, but those give you a big vital picture of how it goes and what you should be doing in the future. So that's something which I felt was very useful during the domain discovery stage.

And. Sometimes, if you had going in between a project, you might not have the time to do this domain discovery, then you have to get it from your team. So a team relationship is very important when you, when you enter a project in between, because all of your prerequisites for the next requirement, you get the inputs from within the team and not.

Possibly from like, you know, outside the team, because you cannot really go to your product owners or business users and ask the same thing, which they have been doing for four years saying, okay, I'm a very new BA can you speak about the solution, please? I don't know about this. You cannot really do that when you go inside in the middle of a project.

So you have to get that engagement from within the team. And that is, that is the way you have to do the Prius. Before really stepping on requirement analysis. And second, I would like to just compare two projects, which have been in one is in Belgium, which is the financial domain, and this is the public sector domain.

And you have to be very careful about the pace of the project. When I joined this public sector project, I was too fast for this project. So. People were annoyed in the beginning. I want this, I want that. So that's not the way it took me. It took me a really good time to understand the pace of the project and the organization.

So you have to keep that in mind and don't annoy people with your pace. If it's slower, you have to speed up. And if it's, sometimes you have to downplay your skills and speed. It's not bad. It's if, if it actually fits into what you're doing, it's actually a good thing to do. And that's, that's my understanding of what it's my it's purely my understanding.

It could be wrong. And if you're, if I'm wrong, you're right. I will. I'm always ready to correct as well. So that's my understanding about domain discovery stage and coming to you. So discovery is my actual work experience, where I went to a farm, with a particular officer and I spent the whole day with her understanding what she's doing.

And that's the first time I was ever been in a farm. And I didn't have. God that time. So I traveled like two and a half, three hours in a bus down to that place. It's a slight effort. And you know, that effort actually gained her trust. So she was saying, Oh, this girl is interested in coming down to this area and understand what we are doing.

So, those are the minor actions that is not intentional. I didn't do it to impress her. I just did it. I just wanted to go there and see what they're doing. So, and in terms of the project, I was working in financial domain in Belgium. It's not. That's just building was done. And the B sometimes when you're a BA.

Or your stakeholders might not really know what your, what your roles are. So they might come to you asking for a few help. So I was mostly supporting them as well with their minor helps. So then people have a tendency to just turn them down and say, see, I'm not a developer. I cannot fix this. So I'm not at this thing.

I cannot do this. See, you have to be. You have to be more open in terms of your user interaction. So even if it's a slight, slight thing, you can just go to your developer and ask, see they need this help. How can you do that? And that is a process of earning trust and being comfortable with the user. So I spent almost, you know, this user, you said discovery stage.

I spent almost all my time in really getting that. Trust and the relationship with the user. And it's sometimes that affects me negatively as well, because I get emotionally going into as well. So that's a challenge of being too much involved with the users and emotional connect you get with the user.

And then it becomes very hard to prioritize what is important for you. So that is a difficult stage where you are in, if you get too involved. So you have to know the boundary, but you have to draw the line between the user connection you have. And. You have to think about whom you're working for. So that is what I have to say about user discovery.

So sometimes take that little effort to go into places and really see what they're doing when Simon was saying about, you know, it's, it's a one-to-one interaction. So there were 12 offices in this particular, particular project I'm working in. And I actually spoke to all the 12th separately. During the start of the project and believe me, the 12 have different opinions about how this should be, but we were actually aiming at transforming a paper-based system and an online digital system.

And people do have difference of opinion, starting from me being in an iPad. We need a Samsung. So for the differences start there and only if you speak. To the, to the users, if there are a hundred users, a sampling technique, you know, will be very useful in terms of a user interaction, because you can take a sample of based on age, gender culture, and just speak to either one or two on those samples and see what they feel like.

It's very different culture to culture, age, to age and gender, gender. So you have to understand the differences in the user you're dealing with. And. You have to adapt your technique and strategy when it's, these are not strategies of techniques, which I intentionally has done. This is just, I'm trying to formulate in a structure.

Now I understand, okay, I've done this way. And this is a good way to do as well because, taking a sample that was not in until I was just randomly picking people, but that turned out to be when I think back was actually samples from different groups of people. So user discovery stage, you have to really get involved and earn the trust and.

Everybody will say no, the user understand the user. I would like to say, feel the user. You might not be able to always really go and physically feel what they're doing, but you can take a small effort to mentally connect and mentally feel what they're doing. So imagine you S when he was better, we see a retailer.

You have to think about you as a retailer, going to do your job. And how do you feel? What, what is the best thing you like to do? So that is an, that is what you call feeling. The user, that's a new term, which I got yesterday. So it's feeling they used it as a something you can, you can really do. as a BA and understand what the user really feels like.

And in that user discovery stage, one more thing I want to say is be transparent as much as you can. There there'll be hidden agendas and strategies for organizations, for management, for users, for everybody we see, but keep that strategies out, have a broader or open mind and be transparent. And then only they will be transferring back to us.

So. That's that's the only advice I would like to give them that you, so discovery stage and going back to requirements stage, there is an important thing, which really stopped me from collecting requirement is how do you do that? How should be something which you should take away from your requirement?

You should just concentrate on who, what and why. So if you think about how do you do that? How, what is the technology you're going to do that it is really going to stop your thinking process and it didn't turn will affect, you know, Collecting the requirements as, as an a. open-minded way and you'll be more focused on, you know, it's more like going to use it and saying, see, I have a Microsoft, assure platform with SQL and Java and you know, this, this, this thing.

And, this is the product which I have, you have to step out from that thinking of technology and technical aspects. And you, you really have to think about. Or use it as a user, as a common man, start speaking common man's language. So nobody is going to, if you go to a farm where I went to, and if I'm going to say, see, I have a product in Android, this thing, and this is going to be this ma this GB Ram is going to be there.

And no, this doesn't really make sense to them. They're there, they're non-technical people and people I have worked with, they have immense knowledge in their domain, and I really wanted their knowledge. To really do something. So if you, you should not be a stopper for the information flow you should, you should just let them, let them just give you the information and just stay back downplay when you regret.

And don't think like all stages are therefore showing off that something I've always seen in all the stakeholders, meeting all those big, big meetings. People often take meetings as a place to show off their skills. You will get time. You will get your time, show off your skills. You have to understand what exactly you have to do and where you should not be strictly not doing it.

So, yeah, that's, that's my overall experience or, you know, what advice I can give on? You said discovery, domain discovery and requirement discovery. So you have to do your prep. That is used to discovery and domain discovery before literally stepping in requirement discovery. And something I learned from recently from this project is called benefit type notices.

So, that would be something really useful in terms of prioritizing. And that is in line with safe. Like you have to do, you have to understand if there's a short job, short job, which makes much value. You have to get it first. So those are the kinds of, you know, in safe. There'll be principles, which literally tell you how to prioritize.

And you can use those techniques to really prioritize your tasks. You might be thinking in your head, so this is important, but it might not be when you really, really write it down in terms of value. And when I say value, it's not necessarily financial value, it could be something like a functional value.

For the project I'm working now, it's more like a staff morale issue and it's a functional value. They can't, they can't use paper for all over the life and people are using digital devices. So it's not all about financial values, which we have to really prioritize on. And. And the financial banking software that I worked for, it's all about money.

So if there is a mistake in money, it's, it's the financial criticality, which is the benefit type orthosis comes from. So do a benefit type orthosis. there are techniques in safe where you can actually write down the priority and, you know, do a benefit type. This is in terms of a number. I don't really remember what number it was.

You can, you can see the value as a number form, and then you can decide, okay, this is the priority and this is not the priority. So if required, use those techniques. To, you know, really understand the priority using the benefit type, what this is. And just one more, not advice. I'm not big enough to give an advice, but one more tip, I would say is a reiteration.

So you might think your rights. There are instances where I thought I was a hundred percent, right. Like 99.9%. Right. And my developer has let go. And just, can you just check it once? What would they use it? And we, we just have a tendency, like, okay, we have checked it twice. We don't check it the third time.

So that's something you have to take. Take away from your mind, go check it with the user. They might get slightly annoyed, but you might be building up something so stupid, which you think is 99.9%. Right. Which is absolutely wrong. So if you think there is a doubt of like 0.1 percentage in your requirements on your understanding retreat.

Get it confirmed with your user again again, and just don't think be responsible for getting requirements so that the other team is not involved in any other process. It's completely wrong. We have standups in your daily life. So just talk to your team in the morning. See. this is the recruitment is coming.

And what do you think? So that could be people who we think their skills are different. Could really give you input on that. So talk to your team, keep them posted about what requirements are coming. And sometimes there are, trust me, there's instances where you think our governments is required and it might be already existing.

Zoha Hamza:

I've been working as a BA process analyst, database analyst, and higher education, in different renowned universities.

And I worked on digital transformation, process transformations, mostly. so my stakeholders have been students, faculty academics, visitors, you know, foreign visitors for, Speakers from around the world. And then, there was one particular university where I've dealt with coroners police and you know, all that, political sort of stuff there.

So, I was. I have, worked on, creating new database for one of the universities and one was digital documentation and the third is redefining the processes. so exactly like, I was just, sorry, I just missed your name Muncie. yeah, yeah. I was just listening to her. Exactly. I would, like do, agree to.

Each and every point she said that you need to understand your users and stakeholders, and then you get the requirement. And this is absolutely what I've been doing. feeding them, understanding them and then making them speak and then, you know, making them, you know, making things happen. This is what I believe in.

You speak to them. You make them, fair things, because I know at times it is super difficult. excuse me, to get information out of certain people. And, you have to go to them over and over, over and over and over and over until they speak out, you know, various techniques, various methods. you can, you know, I, I mostly believe in workshops, focus groups at times, observations, shadowing, you know, certain, you know, I believe personally, you know, when you see them working, what they want, what they deploy, it works actually, you know, what they are looking for.

So, yes. And then again, I would agree again that, you know, you need to, you have to go back to them. Not once, not twice, but at times, you know, multiple times just to get real facts out. So yeah, I'll be known. so would you like me to elaborate a bit on the projects I've worked on or? Yeah, so my most current project is, it's a very renowned university and, the COVID paint, everything went online.

So. They wanted everything to be moved online. You know, that examination did recruitment everything. So we had to redefine everything from scratch and bring it up online. Now the difficult thing here was that the students were not very, happy about it because you know, like I was facing my, you know, internet problems just now, you know, they've been facing all these, you know, when you've got an exam, you just fix them and you can log in.

Quite a nerve wracking thing for a student. So, so I know, you know, we had literally series of chats with all her students, you know, manage the multiple rounds of, you know, chat, you know, fandom and sing them. We literally had to convince them that, you know, if this happened, that would, you know, this is the only way out.

So yeah. So everything online and we are, now you're working on the recruitment tank because they are thinking of making everything online from now on. But, so yeah, working on that before that it was digital transformation and they were moving on to another, you LMS again, you know, students didn't like idea.

I think I, I would say my most difficult stakeholders in higher education. I've been students. you know, because, you know, we have like around 800 students and then you serve where you get so many different ideas and qualities, opinions, and, and, you know, as a, for a higher education point of view, student is your most important stakeholders.

You're getting revenue from them. So you need to make them happy at all costs. And when you have unions, it's very difficult to do, you know, influence them at times. So, yeah, so my, my, likewise, so they didn't want the LMS new LMS. They were happy with the current, portal. So we literally had to make more cups to show it to the union.

I mean, you know, until the union was going to win, we couldn't go ahead. and then it was academics and, you know, the management and stuff, they were so influential, so, yeah. And then, Before that it was, I was working in st. George's university and, we had coroners and police as my, stakeholders.

So we were defining and designing a new, system reporting system that would facilitate everybody. And, you know, w which would be cost-effective and efficient. Also distributing everything in time. Just-in-time. Again, it was quite an outbreaking thing, convincing such high authorities and speaking to them when they have different views and convincing them that this would work.

so yeah, so we had like multiple, multiple rounds off, you know, I think it was requirement. Elicitation was the biggest challenge we had, you know, we had to face, even when the, it went on developing the broad, Sophia went on development. Application of Anton development was developing. We still have to go back multiple times and, you know, to make adjustments and make changes.

So, yes. So this is, this has been my journey so far, and I asked him, he agreed to each, like, I think I missed five, one spot point. I was just trying to log in. I missed what he was saying, but I was able to catch up one month conversation and I agree. Absolutely great. Thank you. so, so far,

Conclusion

Vijay Nair:

On that note, let's end the session and, until next time have a great Friday.

This article is a transcript of the BA Video Series Linkedin Live video on Requirements Elicitation

You can also listen to this via our podcast

If you are a business analyst interested in accessing more of these topics, then join the BA Video Series now! and sign up to the product updates: www.bavideoseries.com