One of the habits from Stephen Covey's Seven Habits of Highly Effective People, is to begin with the end in mind. So, it is with this video, we'll be introducing the end of analysis phase, which is the system proposal. It's important as we begin analysis phase to have our target or our goal in mind, which is to prepare, in many cases, a formal document proposing a system and its requirements. We're going to explore every dimension of this document as a part of this module. After this video, you'll be able to identify the artifacts from plan phase that we revised during analysis phase. You'll also be able to describe the new artifacts that we create during analysis phase. By the end of this video, you'll be able to list, at least, one diagram type that we use to understand the current business process. Taking a look at where we've come, and where we're going. In the first module, we explored plan phase, and we briefly talked about things like creating a project plan and managing the triple constraint. All of this then feeds into analysis phase. At the end of analysis phase, we'll have a system proposal. The system proposal is a detailed list of requirements, as well as diagrams that describe the system being proposed. The system proposal then serves as the input into the design phase. We'll be spending most of the time in this course in analysis phase, since the role of the BA or the business analyst is the greatest during analysis phase. We will wrap up the course by talking about design phase and the role of the BA or continuing role of the BA in design phase. But for these modules, we're going to focus mostly on the analysis phase, the types of activities, and the types of documentation artifacts that the business analysts creates during these phases. During analyze phase, we clarify requirements, we understand the current process, which is often the first step and often skipped when doing business analysis, and then we develop changes to the current business process. All of these result in a system proposal that is then used as input into the design phase. A system proposal is the end of analysis phase. All of the deliverables are combined, from analysis phase, are combined into a system proposal, which is then typically presented to management. Different organizations have different names. Many of them might not use system proposal, they might use something else. In principle though, the documentation is largely the same. It's a packet of requirements, as well as supplementary diagrams, and other documentation that describes the system to be implemented. Typically, organizations will make a decision at that point as to whether they move forward or decide to put it on the shelf. This is a list of potential deliverables, some of which we created during plan phase and others of which are new to analysis phase. The system request, the work plan, and the feasibility analysis are all things that we talked about in the earlier module. However, they're not completely done after that phase. As part of analysis phase, we often dust them off, revisit them, and iterate them. This means that we add additional detail or perhaps new information has become available and we need to revise those artifacts for whatever reason. In analysis phase, we then move on to creating new artifacts and deliverables. These include requirements, which is where we will spend a lot of our time writing good unambiguous requirements for the system. Tool that helps us elicit requirements as use cases, and we'll spend time learning how to write a use case and draw a use case diagram, which tells us how use cases relate to one another. Your process model, we will use data flow diagrams to describe the process model, and we'll explore in-depth how to create those diagrams and how to balance those diagrams. Finally, we'll use a technique called entity relationship diagrams to describe the data model of the system. This usually describes what types of data the system stores and how that data relates to the other pieces of data in the system. What is missing from the list that you see here are the human element of what needs to go on during analysis phase. We talked about the concept of organizational readiness in the earlier module. During analysis phase, you need to continue your organizational readiness activities, and we will have suggestions for you as to what those activities could be. You'll also need to think about project teams. Who will be doing the work? Not just a list of tasks that need to be accomplished. So, there's a lot missing here, but this will, at least, get you started with the important artifacts that will be creating in analysis phase, and this is where we will be spending most of our time. We begin analysis phase by trying to understand the system as it currently works or the process, I should say, as it currently works. This is often the most neglected step in analysis phase. It's very tempting to sit down and dream up how you want things to work without regard to how things currently work. In oftentimes, we find that we actually don't fully understand how things currently work. I give you an example. When I worked for 3M, one of the things that our customers would tell us that we would do is, we would often come in and ask a lot of questions about how their current process works, and they would give us feedback that is part of that process they came to a greater understanding of their own internal processes. Oftentimes, we talked to say, five people, and the five of them would have a different definition of what occurs during the same business process. All of that is to illustrate that understanding the current process should be an important step in your analysis phase. How do we do that? Well, one of the ways that we do that, not the only way, would be to use something like a swim lane diagram or a flow chart to document the current process. In the best possible case, a flowchart of the current process might already exist. However, you have to take care because this flowchart might not be up-to-date, and so the process of updating the flowchart can often lead to new insights about the process. So, we use a swim lane diagram or a flow chart to document the current process. That's just one idea for how to start analysis phase. As we move ahead in this lesson, we're going to dig into how we create requirements and the different dimensions and aspects of writing requirements. Then after that, we'll move on to other tools, such as use cases, prototypes, and so on that help us further refine what the system should be.
