In our last video, we talked about one, eight in the vision and scope document, the business requirements, documentation, and the importance of knowing if some or all of that has previously been done. So now we're going to move into section two, which is really focused on the scope of the project up to now, all of our sections have really been around what the vision is for the project. And now we're going to get into what personally I always zone in on it's the features. It's those kind of high level requirements. I will tell you that when I get a vision and scope document from the stakeholder, the first place I go is to the features and then I back up and read the rest of the document. I know that seems like that's out of order.

But it is because the features are the thing that we're going to focus on as VA is to document our requirement. messing around. And I want to look at those features. First, get a feel for what those are. And then go back and look at all the things related to the vision to make sure again that our features are tying into what the vision is that's laid out in the document. So the feature section is probably the one that as a VA you're going to pay the most attention to and it's also the section that will be the most painful for you if it is not filled out correctly, meaning if the features are not well defined, so let's go ahead and take a look at some example features related to our example project that we've been using in this vision and scope document.

So we have six features here, which is not a complete set of features. For this example project or probably for any other project you are most likely never going to have only a list of six But for the purposes of an example for this course, I've just listed out six here. So we have feature one ability to share the majority of content across the sites for all regions. And we know that supported in the above vision information, because in our other videos for this course, we talked about the fact that we only want 20% of the content on the different region sites to be region specific, and 80% of the content should be the North America site content that is reused at the other regions. So we know that that feature one is supported in our vision statement. Next, we have ability to have one single point of entry on the back end update sites for all regions.

So this isn't necessarily something that has been spelled out in the vision statement, but it doesn't have to be this is a feature related to how they want to admit Stir the site. So this is getting into actual functionality. And that statement on its own doesn't necessarily need to be supported in the vision because it's getting more into the details of the how. So it's not something that we would need to say, Oh, well, we didn't say that there needs to be one single point of entry. That doesn't need to be in the vision statement, mp3 ability to map URLs from retired domains to the new domains. Again, this makes sense.

While it's not something that was mentioned in the vision, it doesn't need to be it's a feature. So what we want to do is make sure that we know that we're taking multiple sites and taking it down to just one site. But we know that people customers could have those current sites as like favourites or bookmarks. So we want to make sure that those URLs aren't just dead that they don't just take them to nowhere or they get a message that says the site is up anymore, we want to redirect them to the new site so that then they could bookmark that new site. So we want to make sure that there's mapping to those new site domains. Or if maybe there isn't going to be a new one, maybe there will be for North America as an example, we have three sites that we're going to consolidate into one, maybe we'll keep one of the current domains, and we just have to redirect the other two.

But in any case, we want to make sure that that redirect happens. So that's one of our features that we have here. ability to schedule content and image updates to the site. So we're saying here that we want to be able to make a change using that back end entry point is the place where we're administering the site, make it change, but schedule it so that that change doesn't actually happen until say, 6am tomorrow morning, you don't want to have to get out of bed and go make an update at six in the morning. So you want to make sure That the site allows for scheduling those changes. Next, we have ability for site admins to access a change log.

So again, another feature that they want to have of the site is to be able to track the changes that have been made to the site. Next, we have ability to revert changes to previous version. So they're saying that if I make a change, I want to be able to change it back to the previous version. So now let's talk a little bit about the fact that these are what we would call high level requirements. These major features are not meant to be anything that gives you any amount of detail. This is supposed to be a guiding path for you of just what it is the major features.

So for each of these major features, you could have one requirement you could have 10 requirements, you could have 20 requirements, when you get into actually documenting the requirements related to that feature. That's where you're going to get into the details and where you're going to have multiple pieces of information, and most likely multiple requirements. So this gives you that kind of starting point. This is why this area is so important to us as business analysts is because this is going to drive our initial conversations. So I always take these major features and take each one of them and do some analysis on each one and start jotting down my questions that I have for each of these features. You can do that through an Excel spreadsheet, you can do that through a Word document.

Sometimes I even just take the vision and scope document and for each feature output questions underneath each one of them so that when I have my initial meeting for requirements, that's where I'm going to start. I'm going to start by asking some questions related to those features to start drilling down and getting those requirements. So it's really important to do analysis on those features. Make sure that you're thinking about what questions do you have related to those so that you can start defining what the requirements are for each of those features, you want to also make sure that you're thinking about the amount of detail that's needed for each of these features. So sometimes you're going to see where they're not really clear on what they want. So if you have a feature that seems like it's not fully defined in and of itself, it's vague, it's using vague language, then you're going to want to go back to the stakeholder and have a conversation with them.

Again, as part of the reviewing the draft of the vision and scope, you're going to want to say you know what I think we need to take this particular feature and have a little bit more detail to it. have it be a little bit more concise so that we are sure that we're not leaving anything up to interpretation related to the feature. While the feature doesn't need to have a lot of detail to it what it has there needs to be specific Effie six, for example, ability to revert changes to previous version. That's very specific to me, that says that they only want to be able to revert changes to the previous version, not to five versions ago or 10 versions ago, if that statement said ability to revert changes to previous versions, there would just be an es en version that changes things now. So does that mean that that feature isn't correct or isn't specific enough?

It does not. What it tells you is that they want to be able to revert changes back more than one version. So when you have your requirements sessions, one of the questions you would ask related to features Six would be, how many versions back? Do you want people to be able to make changes to? So if they made a change, and they realized they needed to roll back to a previous version, how far back can they go? Just the last version?

The version before that the version before that? How many versions Do you want them to revert back to? And then that becomes one of your detailed requirements related to reverting changes. So you have to be able to tell the difference between what is vague, and what is just an actual feature that needs to be defined, of course, through the requirements. So let's take a look at the another one ability to share the majority of content across the sites for all regions. So if this one says ability to share the majority of content, and it didn't say across the sites for all regions, because maybe the Stakeholders assumed you know, that's what they mean, because they've talked about that in the vision statement, it doesn't matter that they've talked about that in the vision statement, you can't assume that that's what they mean for this feature.

So that would be a scenario where you would want to go back to them and say, we need to clarify this a little bit more when you say ability to share the majority of content. What are you referring to sharing the content? How, and then they may look at you funny and say, Well, like I said, in the vision statement across the sites for all the regions, like they might be saying, hey, dummy, you should know that. And as a BA, you really need to be able to develop a thick skin and not be concerned with the fact that somebody may talk to you that way. Whether they mean to or not, it's that whole not making assumptions thing because we have to train ourselves as bs to not make assumptions. I think that sometimes our stakeholders actually think that we should make assumptions.

They write things in a way that they think we're To know what they mean, and we probably do know what they mean 80% of the time, but that other 20% of the time, if we make an assumption, and it's the wrong assumption, then we're moving forward with documenting things incorrectly. So we don't want to make assumptions. And we don't want the stakeholders to force us to make assumptions. So we want to help them make things clear in their documentation so that we're not being put in that position.