Welcome to requirements goal development and language conflicts. This is one course of the secure software requirements and specifications specialization. After eliciting requirements from the stakeholders, we need to analyze these requirements. If you recall from the elicitation course, remember that none of the steps in gathering techniques works alone. Elicit, analyze, document, manage, consolidate. Rinse and repeat. In this specialization, all of these topics are covered towards the goal of creating requirements documents that cover functional, nonfunctional, and what we can call pervasive requirements. These requirements will be truly helpful to designers and developers while also reflecting the customer needs. In software requirements solicitation for secure software development, we go through many different ways to help us identify the stakeholder needs together with alternative ways of addressing the system to be. This provides a lot of information at the functional and the nonfunctional level. In learning software requirements, nonfunctional requirements are generally ignored. This is especially bad in the case of security. Security isn't so much a nonfunctional requirement, although, well, technically that's how it's classified, it's more a pervasive requirement. So always keep security in mind. Using the techniques of artifact driven elicitation and stakeholder driven elicitation we can drive forward in creating our software requirements document. Do remember that this is an iterative approach. And it's a combination of techniques from both the artifact driven elicitation and the stakeholder driven elicitation. These two techniques of artifact and stakeholder elicitation should be used simultaneously. Your answers are not going to be perfect. So you will need to go back and forth with you customers many, many times to create a satisfactory and complete document in the end. The techniques we discuss here give us domain understanding and overall elicitation guidelines. The results we get though will need more effort. For each requirement, the risk and the alternatives must also be evaluated. Risk analysis, evaluation, and negotiation will be discussed in the course Risk Analysis Assessment and Prioritization. Then, the third step of writing the software requirements specification document is covered in the course called Diagrammatic Notations and SRS Rating. In the particular course, we are focusing on starting to organize and evaluate our requirements through the writing of goals, use cases and misuse cases. We also begin to look at conflicts and ways to deal with those conflicts. In dealing with conflicts, we'll also learn some negotiation techniques. At this point, we assume that we have some requirements elicited from our stakeholders. Now, we need to perform analysis, including risk analysis and negotiation. Not everything is possible and some needs aren't really needs. In this course, we're talking about how to deal with conflicting stakeholder viewpoints, nonfunctional requirements, pervasive requirements and saying more things like this, in order to reach agreement by all parties, or at least most parties. We'll also go over how to identify critical objectives that were not missed. We'll also go over how to identify critical objectives that are not met because they were missed in elicitation. Many of these will include safety hazards, security threats and consideration of potential development risks. These start off as unknown unknowns, which is referenced in the elicitation course. These need to be found and identified in order to get new requirements which will lead to a realistic, robust system to be. We'll also be asking, what is best for the system? Alternative options may arise from different ways of meeting the same objectives. We may assign responsibilities, add or remove automated functionality. And we also need to resolve some of these conflicts and risks. We'll evaluate alternatives in terms of their contribution to nonfunctional requirements and the reduction of risks and their conflicts. Please note that when we talk about risks in this course, this term involves much more than security vulnerabilities. As we code, bugs, security vulnerabilities, intrusion vulnerabilities, etc, become an issue. However, most of these can not fully be addressed, or really addressed at all, until we get to the software design, the coding and the testing levels. For more information on approaching security in software design, see the course in software design in the secure software engineering certificate. The fundamentals of computer and network security and the applied cryptography courses will aid you also, in learning how to implement secure software. Right now, though, we're asking how do we even find our what these requirements are, to address secure software. We've talked about that a little bit but now when we get into risk, security is going to be coming up a bit more. Finally we'll talk about requirements prioritization, given all of the data that we've analyzed. We might not be able to implement at briefing due to particular constraints. So what do we do? Techniques to resolve conflicts, to address cost and schedule constraints and how we can support incremental development will all be discussed here.
