Requirements Engineering: Secure Software Specifications Specialization

In Elicitation: Artifact and Stakeholder Driven Analysis, you will learn to use both recorded and presently unrecorded knowledge in your elicitation techniques. As you get started in finding out about the new product, you must first learn about the product that was (if there was one) and then learn about the system to be. Oftentimes, you'll find yourself in an environment you know nothing about! This course will help you find ways to learn about the domain, the system that was, and the system to be. Please review: "Who this class is for to determine if you are ready to take this graduate level course".

In Requirements Goal Development and Language Analysis, we move from the spoken word to precise writing. A first step in this is writing goals. We will talk about goals used in requirements engineering and, from this, writing use cases from what we learn. Use cases can be in diagram and written form. Then- the villains enter- misuse cases and abuse cases are discussed in how we can deal with them in a Requirements environment. In gathering requirements, you'll have many questions remaining. Often this leads to the need of more interviews and group sessions. We'll go through how to handle group meetings, dealing with inconsistency, and handling conflict between stakeholders.

Risk Analysis, Assessment, and Prioritization looks at how you can manage conflicts at system levels, but it can also be applied to lower level assessments. How do you manage and document conflict, along with alternatives? In analyzing alternatives, you must consider risks. In this course, we'll look into how to analyze risk, evaluate risk, document risks, and use this information for prioritization of requirements. Qualitative and Quantitative approaches will be covered.

As requirements are being gathered and prioritized, they also need to be documented. In Diagrammatic Notations and Software Requirements Specification Writing, we discuss and practice the process of turning requirements into something readable to the customers at a high level, and the developers. When a designer or developer reads your document, they should be able to understand the overall idea, the scope, the domain, the resources, the expectations, and why alternative choices are not selected. To create a document in this way, you use a balance between storytelling (with pictures!) and complex diagrams.