In order to get the information that we need, we can use a combination of two main types of techniques. These include artifact driven elicitation and stakeholder driven elicitation. An artifact driven elicitation, artifacts include any existing information about the system that can be gathered from a number of sources. These can include things like pre-existing documents about the current system, data samples, questionnaires, conceptional grids, scenarios of interactions between system components, system prototypes, reusable knowledge, and a lot more. Basically, what can you get from the company? If we were unfamiliar with the system as is, one way is to start by collecting, reading and analyzing the existing relevant documentation. This background study is sometimes called content analysis. A background study supplies information that can be used later. In the content analysis, we learned about the terminology, objectives and policies that we're taking into account in creating the system as it was. We also learned about the distribution of responsibilities among the stakeholders and the main users of the system. Big challenge of this, is that there could be tons of information. The key information needs to be extracted. And it may be inaccurate or, very frequently, it's quite outdated. So in order to sort out this information, we try to acquire some meta knowledge, basically, for guidance. What is needed in the system? What is not? Model driven approaches can provide a solution for this. However, first we need to learn about the organization, itself. This can be very, very basic. Such as what does the organization do? How does work flow? What policies do they have? Who cares at all about this product? You can begin to learn about this, first, by talking to your customers, obviously. However, customer contact takes a lot of time, so we should try to get some background knowledge first. You could start looking at documents that exist within the organization, if available. These might include things like organizational charts, business plans, policy manuals, financial reports, existing meeting minutes regarding the product, job descriptions, so much more. Organizational charts will help you to understand the connection between the management and the employees, and all the levels involved, therein. Business plans will help you to see what the key goals of the company are and how that ties to the product. How it ties to the product that was, as well as the product that is to be. Policy manuals can let you better understand the underlying environment. For example, are there areas that require different government clearances? How important is security, from both the human and the computing senses? Financial reports can reveal key stakeholders and company holders who should be talked with. Meeting minutes may include complaints and suggestions for the upcoming project. And in learning about the system as it was, it may reveal how the stakeholders tie into the system as it is involved in their current jobs. Given that, job descriptions also help determine potential stakeholders who use the product. Next, we examine and try to understand the overall the overall domain. Sometimes the general domain is something that you're already very familiar with, but maybe not entirely. Be careful of that, you probably don't know everything. At other times, you may be thrown into a project where you know little to absolutely nothing about. For example, let's say that you just got contracted to do a job for the government where your software will do satellite monitoring. Most of you probably have no knowledge about satellite tracking system other than, yep, they exist. So, what do you do? To start, you need to do some research. Consider books, surveys, and published articles. Google Scholar can be one of your best friends. You will not become an expert, but you will be able to begin to learn questions to ask in the area of the stakeholders. So that you can actually communicate them and better understand and try to clarify what you're talking about. Within these books and surveys and articles, notice, particularly, regulations within the domain. You can also notice in these are documents, if there are similar systems out there. When working in domains that you know little about, similarity recognition is challenging and you may be wrong. However, it does give you an idea of questions to begin asking your stakeholders in order to clarify some of your knowledge. And, also, it will help you not sound like an idiot when you're talking with them. Learning about the domain for something like a movie search database, is much simpler than learning about, say, satellite systems. But, again, the point of all this, is to gather background knowledge to guide your understanding so that you can question. The more questions, the better questions you can ask early on, the more information you'll be able to get from your customers. As we gain knowledge of the organization and the domain, we can simultaneously learn about the system as it is. From the artifact perspective, well, you have to see what's available. Not all companies are going to have everything. User manuals are likely the most common resource that you'll be able to get your hands on, but they're also likely very big. You don't want to read through them in complete thoroughness. So other resources that you might pull out, are things like information flow reports, designated work procedures, and some written business rules. You may also have access to defect reports, complaints, whether those complaints are from higher ups, workers, the people who are paying you, who knows, and you may also be able to get change requests. All of these will help you to understand the system as it was. Why stakeholders are desiring a new system, and how the stakeholders are related to the system.
