This specialization is intended for software engineers, development and product managers, testers, QA analysts, product analysts, tech writers, and security engineers. Even if you have experience in the requirements realm, this course will expand your knowledge to include new viewpoints, development styles, techniques and tools.
For anyone seeking a graduate degree, certificate, or professional degree in computer science, these courses will additionally give you a broad understanding of how requirements engineering is performed and help you get a first foot forward into your upcoming careers.
The Software Requirements specialization focuses on traditional software requirements elicitation and writing techniques, while also looking at requirements from a security standpoint. In traditional methods, non-functional requirements, such as security, are often ignored overall. In this specialization, students will be introduced to ways of eliciting requirements from stakeholders, how to analyze these requirements, conduct risk mitigation and analysis, prioritize requirements, document, and bring security concerns into the software lifecycle early on.
Requirements Gathering for Secure Software Development
In Software Requirements Elicitation for Secure Software Development, we're going to discuss the overall software requirements process as it applies in waterfall, spiral, and agile models. You'll learn about each of these processes and your goals as a software requirements analyst. This is not an easy task! Who do you talk to, when, and what kind of knowledge are you trying to obtain, in any software life cycle? How do you handle obstacles as you go?These are the questions we will focus on answering in this specialization.
Requirements Elicitation: Artifact and Stakeholder Analysis
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".
Requirements Specifications: Goals and Conflict Analysis
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.
Software Requirements Prioritization: Risk Analysis
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.
SRS Documents: Requirements and Diagrammatic Notations
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.
None although a vague knowledge of programming and the software development process is helpful.