Latest / DevQuestions with Tim Corey / 099 How Do You Gather User Requirements? How Do You Perform UAT?

Transcript

099 How Do You Gather User Requirements? How Do You Perform UAT? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_01: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_01: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_01: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_01: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:26
  SPEAKER_02: How do I gather user requirements?
• 0:29
  SPEAKER_02: And when I'm done, how do I get through user acceptance testing in a reasonable manner?
• 0:35
  SPEAKER_02: This is a question that Vinny asked over on that suggestion site.
• 0:38
  SPEAKER_02: I want to address it in today's episode of DevQuestions.
• 0:41
  SPEAKER_02: Now, if you want to get your question answered, go to suggestions.imtimcorey.com and either leave a suggestion or upvote one that matches what you're looking for.
• 0:50
  SPEAKER_02: Now, with this question, I'm going to break it apart into two parts.
• 0:53
  SPEAKER_02: First of all, the user requirements side, where we're going to cover three tips.
• 0:57
  SPEAKER_02: I'm not going to go into everything because that's a whole course.
• 1:00
  SPEAKER_02: That's not one big episode of Dev Questions.
• 1:03
  SPEAKER_02: But the other side, we'll talk about the user acceptance testing just a little bit at the end.
• 1:07
  SPEAKER_02: So let's start off with the user requirements.
• 1:11
  SPEAKER_02: How do you gather good user requirements?
• 1:14
  SPEAKER_02: And the first step I think, and the first tip I have, is make sure that you get the overall idea or purpose for your application or for your change.
• 1:25
  SPEAKER_02: So what's the goal?
• 1:27
  SPEAKER_02: What is the goal of what you're doing?
• 1:29
  SPEAKER_02: Make sure that the clear purpose is stated.
• 1:32
  SPEAKER_02: That way, everything else can point back to that purpose.
• 1:36
  SPEAKER_02: Often you get so caught up in the details.
• 1:39
  SPEAKER_02: Well, you want this thing changed and this thing updated and this thing tweaked and done a list.
• 1:45
  SPEAKER_02: Or I want this to be web based and I want this to be SQL driven, I want this to be.
• 1:50
  SPEAKER_02: Stop, take a step back.
• 1:52
  SPEAKER_02: What's the overall purpose?
• 1:54
  SPEAKER_02: What's the goal here of what we're doing?
• 1:57
  SPEAKER_02: Because if you can't point to a specific goal or purpose, then anything goes.
• 2:03
  SPEAKER_02: And it gets kind of murky along the way when it comes to what are good requirements.
• 2:08
  SPEAKER_02: So if you have a purpose, if you have a goal, and this goal is to do X, then everything else can point back to that goal.
• 2:17
  SPEAKER_02: Everything else can say this fulfilled or this is part of fulfilling that goal.
• 2:24
  SPEAKER_02: So that's number one.
• 2:25
  SPEAKER_02: Number two is talk to the users.
• 2:28
  SPEAKER_02: And by users, I mean the real users.
• 2:31
  SPEAKER_02: Often, project managers and developers will talk to managers in the department or the higher level team leaders or things like that.
• 2:42
  SPEAKER_02: They'll have meetings and conference rooms and they'll talk through what are the requirements.
• 2:47
  SPEAKER_02: That's not the right people to talk to.
• 2:49
  SPEAKER_02: Maybe you have to talk to them, but go visit the lowest paid employees in the company.
• 2:56
  SPEAKER_02: Find the ones who are doing the actual work.
• 3:00
  SPEAKER_02: The work that no one really pays attention to, the work that is the actual heart of the company.
• 3:08
  SPEAKER_02: Find the people who are just doing the job and talk to them.
• 3:12
  SPEAKER_02: And when you talk to them, get to know what they do, have them train you briefly on what they do, ask questions of them as you go through and say, hey, why do you do it that way?
• 3:25
  SPEAKER_02: And then after that, talk to them about, well, what would make your job better or easier?
• 3:31
  SPEAKER_02: What's one thing you would change?
• 3:34
  SPEAKER_02: Those people, the people who are actually doing the job, will know much more about the system than their bosses will, than their boss's bosses will, than the vice president will.
• 3:45
  SPEAKER_02: In fact, often you'll find those other people are clueless about how the actual job gets done.
• 3:53
  SPEAKER_02: And that's where you find a lot of the flaws in the system.
• 3:58
  SPEAKER_02: The places where they're being covered up, but they're not really the greatest parts of the system.
• 4:05
  SPEAKER_02: For instance, I was as a part of a team that was purchasing a very expensive software product.
• 4:12
  SPEAKER_02: We were looking at a few different ones.
• 4:14
  SPEAKER_02: We were talking to one salesperson.
• 4:15
  SPEAKER_02: We said, Hey, can you show us what one customer that uses this, how they work?
• 4:22
  SPEAKER_02: Can you take us to a customer?
• 4:24
  SPEAKER_02: And so we went and visited a customer who used this data system, and we interviewed them.
• 4:30
  SPEAKER_02: And we interviewed a low-level employee, an employee that was really at the bottom of the totem pole of just entering data.
• 4:37
  SPEAKER_02: And we said, How do you use this system?
• 4:40
  SPEAKER_02: And the employees show us the process, and part of that process was, and now I take the data out and I put it in Excel.
• 4:48
  SPEAKER_02: And I manipulate it and then I put it back in the system.
• 4:51
  SPEAKER_02: And the salesperson said, Wait, you did what?
• 4:55
  SPEAKER_02: Why would you ever do that?
• 4:57
  SPEAKER_02: And so that revealed a flaw in their system.
• 5:01
  SPEAKER_02: Their system was not designed or set up to do the way the things, the way they wanted it done.
• 5:07
  SPEAKER_02: And so they actually had to pull data out, manipulate it, and put it back.
• 5:11
  SPEAKER_02: However, not even their boss knew that happened.
• 5:14
  SPEAKER_02: Because that employee just kind of covered over that flaw.
• 5:19
  SPEAKER_02: They got the job done.
• 5:21
  SPEAKER_02: They had a job to do, they did it.
• 5:23
  SPEAKER_02: And it wasn't pretty, and it wasn't like it was designed to happen, but they got the job done.
• 5:29
  SPEAKER_02: Now, if you don't know about that, you replicate that.
• 5:34
  SPEAKER_02: So instead, find out those flaws.
• 5:36
  SPEAKER_02: Find out what those users know because they'll have a history with the company.
• 5:42
  SPEAKER_02: They'll know all the ins and outs and the tweaks and the workarounds for the system.
• 5:47
  SPEAKER_02: Get to know those, have them train you on them.
• 5:50
  SPEAKER_02: So you know, here's the things that our system struggles with currently.
• 5:55
  SPEAKER_02: We don't want to replicate that in the new system.
• 5:57
  SPEAKER_02: So that's number two, talk to the users, but talk to the right users.
• 6:01
  SPEAKER_02: So, first of all, find the purpose of a system, the overall goal.
• 6:05
  SPEAKER_02: Number two, talk to the right users.
• 6:08
  SPEAKER_02: And then number three, be specific in your written requirements.
• 6:13
  SPEAKER_02: So you're talking about writing down the user requirements for a new project.
• 6:18
  SPEAKER_02: Make sure that you use specific language.
• 6:22
  SPEAKER_02: For instance, I worked for a company once as a consultant where we came in and we had to write some software to control a conveyor system.
• 6:29
  SPEAKER_02: And that conveyor system moved boxes around.
• 6:31
  SPEAKER_02: We had a scanner, my software was tasked with reading that scanner's input, going to the database, finding the right spot for that device, that box, and then send it down the right conveyor system.
• 6:43
  SPEAKER_02: Well, we had a goal of 30 boxes per minute.
• 6:47
  SPEAKER_02: My system had to control 30 boxes per minute of speed.
• 6:53
  SPEAKER_02: So when I met that, I was able to say, and the system is now done.
• 7:00
  SPEAKER_02: Now they came back to me and said, that's not fast enough.
• 7:04
  SPEAKER_02: It needs to go faster.
• 7:06
  SPEAKER_02: Well, at that point, we had clear written documentation that said 30 boxes per minute, not more, not faster, not ambiguous words, 30 boxes per minute.
• 7:22
  SPEAKER_02: So it was very easy to have a conversation of I get that.
• 7:26
  SPEAKER_02: You want faster.
• 7:27
  SPEAKER_02: Now, the requirements were 30 boxes per minute.
• 7:32
  SPEAKER_02: You want more than that now that you've seen this.
• 7:35
  SPEAKER_02: So let's talk about a change.
• 7:38
  SPEAKER_02: And that change comes with expenses.
• 7:41
  SPEAKER_02: But see, it's a very clear conversation then of that's not what we agree to originally.
• 7:47
  SPEAKER_02: So this is a change.
• 7:50
  SPEAKER_02: Therefore, this is more time, more money.
• 7:54
  SPEAKER_02: And it's not an argument then with you versus them, it's a discussion of how you want to address this going forward, because we have very clearly met the requirements.
• 8:05
  SPEAKER_02: So very clear requirements will save you a lot of time and frustration.
• 8:12
  SPEAKER_02: Now, on the other side, when it comes to user acceptance testing, this is where the user goes through and says, yes, you have completed the job, or we need to fix these things.
• 8:22
  SPEAKER_02: Let's talk about a couple of points here about how to make this better.
• 8:27
  SPEAKER_02: And the first point goes back to the three things you did earlier with user requirements.
• 8:32
  SPEAKER_02: The clearer you are about those user requirements, the better.
• 8:36
  SPEAKER_02: So review the goal.
• 8:38
  SPEAKER_02: What's the goal of a software application?
• 8:40
  SPEAKER_02: And did I meet it?
• 8:41
  SPEAKER_02: And then let's match what actually happens to our requirements.
• 8:47
  SPEAKER_02: Do those two things match?
• 8:49
  SPEAKER_02: And if they do, then we have a successful launch of an application.
• 8:54
  SPEAKER_02: If not, we need to remedy something.
• 8:56
  SPEAKER_02: But it's a very clear process.
• 8:58
  SPEAKER_02: The more times you can take the gray out of the system, it's black and white instead.
• 9:04
  SPEAKER_02: It's either yes or a no.
• 9:05
  SPEAKER_02: The more time you can have that rather than the gray, the better.
• 9:09
  SPEAKER_02: The easier it will be for the user acceptance testing.
• 9:12
  SPEAKER_02: Okay?
• 9:13
  SPEAKER_02: I hope that answered your question, Vinny.
• 9:15
  SPEAKER_02: If you have a question, make sure you let me know over on suggestions.iamtimcorey.com.
• 9:19
  SPEAKER_02: Thanks for listening.
• 9:20
  SPEAKER_02: And as always, I am Tim Corey.
• 9:22
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 9:25
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 9:29
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 9:36
  SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
• 9:41
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 9:48
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.