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.
Class Deals by MOOC List - Click here and see Coursera's Active Discounts, Deals, and Promo Codes.
Course 1 of 5 in the Requirements Engineering: Secure Software Specifications Specialization.
Syllabus
WEEK 1
The Software Requirement Specification Process and Cost
Software Requirements are a vital part of the Software Development Lifecycle. While there are many ways to go about collecting and recording requirements, the cost of bad requirements is high. Here we discuss what Software Requirements Specifications are and some challenges in writing them well.
WEEK 2
Starting to Build Requirements- What does the customer want?
We need to figure out what the customer wants. And moreso- what they need! How do you develop a relationship with you customers and learn about the overall domain and potential solutions? Here you will learn about the requirements engineering process, what it entails, how to develop a relationship with your customer, and some tips to succeed early on.
WEEK 3
Software Lifecycles
Not all requirements documents are created equally- if at all (formally). How you work with requirements partially depends on the software lifecycle used. Here we learn about the different software development lifecycles and discuss how they affect the requirements we produce.
WEEK 4
Goals and Models for Elicitation
To increase flexibility to change in software development, the agile lifecycle was produced. The agile process much changes how we deal with requirements. We discuss these challenges and your role as a requirements analyst. We also begin to analyze the types of statements that you want to form as you elicit data to move towards clarity.
