So now we're really getting started as to who you are as an analyst, what you do and how. The analyst collects and disseminates product information. In collecting product information, you learn about the system as it is and the context in which it works. From this, you identify the real needs and look for problems and opportunities available from the existing systems and existing technologies. This may include things such as databases, APIs, cryptography protocols, network protocols and other techniques. The analyst also is responsible for exploring alternatives. For example, in security of the Internet of things, Telnet is generally used at least right now. But it's not secure. Given your project, you might look at the alternative of should SSHP be used instead. Probably not due to resources and design conflicts, but maybe sometime in the future. It's a consideration. Analysts also generally are the individuals who write the requirements specifications, including the use cases, functional requirements and nonfunctional requirements. In writing the requirements models, they are very helpful tools in providing more clarification of statements. You can also have graphical representations that are simpler to access. These graphical representations provide a clearer view for both the developers and customers. Graphical representations may include, graphical analysis models, tables, equations, formal languages, storyboards, prototypes and more. We'll get into that in another course, in how we can diagram things. Throughout the process, we also do requirements validation. In validation, we ensure that the requirements statements possess all desired characteristics and that the system described in the requirements, will satisfy the user needs. Sential participants and peer reviews of requirements documents and review designs, also look at the requirements, the designs, the code and test cases to ensure that requirements were interpreted correctly. The analyst needs to negotiate between the different types of users and the developers to prioritize the requirements. Each requirements should be managed well. It must be recorded, maintained and have tracking information from all the way from inception to the verification. By monitoring this tracking status, this allows us to create traceability information and traceability matrices. Traceability matrices link requirements to other system elements and track links to original features and what needs to be described. Given that software engineering teams frequently have quick turnaround times in terms of employees, these links and documents allow for quicker training and change of control rather than relying solely on tacit requirements. There is much room for learning and miscommunication as you move through the various roles in the production cycle. So, at least start early in trying to get it right. Before we can understand the system that we need to build, we must focus on how to get an initial understanding of the system as it is. How to identify the challenges and the opportunities and how to discover analystic real needs of our stakeholders of the system to be. The preliminary phase of the requirements engineering process involves a great deal of knowledge acquisition. This includes knowledge that we need to understand first about the system that was. This includes, the structure, business objectives, policies, rules, stakeholder responsibilities and others. On an interesting note, some stakeholders may be involved in the process in such a way that they don't even realize that they have stake in the system. For an example, in a case study that I saw, there was an automated university system where part of the process involved an assistant retrieving a form from a mailbox, glancing at it and moving it to the next person's mailbox. No one acknowledged that transition, even the assistant who was doing the job. So how do you make sure not to miss this kind of interaction? Understanding the organization can help here. Next, we deal with understanding the domain in which the problem world is rooted. This includes, concepts involved in the domain, the objectives specific to it and regulations that may be imposed on it. For example, you may get a job, and you get contracted out, and you are suddenly working with a satellite monitoring system. I don't know anything about satellite monitoring. Even those who have worked in the field for years may only know about specific pieces that they have dealt with and they can't describe the rest including where you really fit in. These stakeholders can help us to some degree but know that you may end up feeling totally lost. If the stakeholders are already using some kind of system, automated or not, we need to learn what the objectives of that system are, who the actors and the resources involved are, what the tasks and workflows are and what problems were raised in the current context that make them want to change. The output of this exploration, is a preliminary draft proposal that describes the system as is. How it fits into the domain and the organization, the identified problems, opportunities to be exploited and hopefully, some potential alternatives in view of the opportunities that you've discovered. This will be used in evaluation phase at both the elicitation phase and in the requirements analysis phases. It's also very helpful to create glossaries of terms as you learn. This should be appended to your document as well.
