Chapter 3 - Pete - Requirements Analysis - v1.0 PDF

**Chapter 3 - Pete - Requirements Analysis - v1.0** We\'re going to assume that you\'ve done the legwork and optimized your business processes. At least on paper, your processes take advantage of all the new opportunities that are out there and they align perfectly with your vision, your mission, y...

**Chapter 3 - Pete - Requirements Analysis - v1.0** We\'re going to assume that you\'ve done the legwork and optimized your business processes. At least on paper, your processes take advantage of all the new opportunities that are out there and they align perfectly with your vision, your mission, your USP, and your business model. What comes next is a requirements analysis. Think of a requirements analysis as one big party at which everyone gets to make a wish concerning your future enterprise information system. And the guiding thread of every decision are the optimized business processes. First things first, who do you invite to this big celebration? Naturally, you\'re going to need someone that is skilled in reading and writing business process models, so a business analyst. You\'ll also need key IT experts such as the system architect, network administrators, programmers, and developers. And since data is at the heart of your information system, you want to invite your data privacy officers. You\'re also going to invite the key decision makers of your organization, key board members, both because they\'re responsible for your strategy and because they ultimately have to sign off on any requirements list you compile. Now, since you\'re attending this course, I\'m going to assume that you currently have none of these roles. So you may be tempted to think that you play no role in a requirements analysis. And that\'s where I need to make a quite significant correction. You, the end user of an information system, whether you are the employee that works on a computer all day, the customer that engages with a company through its information system, or the supplier that regularly exchanges data with a company through an electronic data interface. You not only play a role in a requirements analysis, you are, in fact, the guest of honor. Because at the end of the day, you are the ones that fill any business model with life. And any enterprise information system is just an instrument that is there to help you do that better. So when we talk about the requirements of a new enterprise information system, the question we\'re really asking is, what do you need from the EIS? So now that we\'ve settled that, let\'s get a little academic and look at three perspectives from which the requirements of a new enterprise information system are looked at. We need to figure out what functions and features the new system needs to deliver from a business perspective, from a systems perspective, and from a user perspective. Let\'s start with the business requirements. Your new EIS needs to provide functions and features that allow your organization to reach its strategic objectives, its long-term goals. That\'s one of the reasons the key decision makers of your company need to be involved in the analysis. They\'re the ones that set the long-term goals, and they\'re the ones that live and breathe the business model. So they\'re the ones that are best qualified to explain what the new information system needs to deliver from a business perspective. As an example, if a company\'s main strategic objective for the next five years is to switch to just-in-time manufacturing, then the business requirements concerning a new EIS would certainly prioritize optimal inventory management, material requirement planning, and supply chain management. The next perspective is that of system requirements. The question here is, what does the system need to provide in terms of technical capabilities? For example, how fast does it need to be? What processing power and memory do you need? How important is scalability, so the ability of the system to handle increasing workloads without sacrificing performance? What other hardware, software, and networks will the system need to be compatible with? What level of data security and encryption do we need? Don\'t think of business requirements and system requirements to be separate from each other. They\'re not at all. They\'re simply two perspectives from which to identify the requirements of the EIS, and they often overlap, like two intersecting circles. Here\'s where you come in, the end user. We need to know the user requirements. What we mean by this is, we need to know exactly how you will use the future information system, whether as an employee, as a customer, as a supplier, or as another major stakeholder. For starters, we want to know what features and functions you generally want this new system to provide you with. We summarize this in short and formal documents called user stories. Later on, we\'ll get into more technical detail. We\'ll walk through every step of a new business process you\'re involved in and ask you as precisely as possible what you do and what you need in each step. We also create documents to summarize this, which we call use cases. Just like with business requirements and system requirements earlier, there are many user requirements that will overlap with the other two types of requirements. This is, once again, because user requirements are not separate from business requirements and system requirements. They\'re simply a third perspective from which to analyze the same underlying object, your future enterprise information system. Depending on the size of your organization and the scope of your digitalization project, your requirements analysis phase might last anywhere from a few weeks to several months. It will involve dozens to hundreds of meetings, workshops, interviews, and surveys. Your soft skills will be an incredibly important and underestimated success factor during this time. And as we said before, the underlying driver through which to identify the requirements of your information system will always be your future business processes. They are the fundament that determines what you need and what you don\'t. At the end of the requirements analysis, the deliverable that you need to be holding in your sweaty hand is a document with a highly detailed list of all the requirements that your future information system needs to fulfill, grouped and ranked in terms of priority. This document is called a requirement specification. Think of a requirement specification like a job ad in a job forum. You haven\'t hired a candidate yet, but you now know exactly what you\'re looking for. And like in recruiting, your next step will be to take a close look at all the options that are available out there and identify which ones best meet your requirements.