role-iq-logo
Rock [Azure]
See all Azure roles

Microsoft Azure Developer: Aligning Functional and Non-functional Requirements

Effective and relevant across many software development methodologies, defining functional and non-functional requirements can help you get clear on exactly what you need to build in an application or system, and what qualities you expect from it.
Course info
Level
Beginner
Updated
Sep 18, 2018
Duration
1h 20m
Table of contents
Description
Course info
Level
Beginner
Updated
Sep 18, 2018
Duration
1h 20m
Description

To plan, build and ship a successful system or application, you need to first get clear on exactly what you need the system to do, and what qualities you expect from it. In this course, Microsoft Azure Developer: Aligning Functional and Non-functional Requirements, you will learn foundational knowledge to discover, write, and refine your functional and non-functional requirements. First, you will see how to extract requirements from larger business ideas, and why the distinction between functional and non-functional is important. Next, you will explore ways to discover unspoken assumptions, and integrate these ideas in user stories and acceptance criteria. Finally, you will work on estimating the effort in your tasks, and how to make sure your own efforts are testable and measurable. When you’re finished with this course, you will have the skills and knowledge needed to take vague business goals and break them into clear, achievable tasks.

About the author
About the author

Simon is a staff author at Pluralsight. With a 30-year background in programming and teaching, he obsesses on making complicated subjects accessible, memorable, and easier to learn. Since 2002, he's recorded dozens of popular and highly-rated training courses. His current focus is on iOS and computer science topics.

More from the author
Databases: Executive Briefing
Beginner
48m
Nov 1, 2018
More courses by Simon Allardice
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi. I'm Simon Allardice, and welcome to this Microsoft Azure Developer course on Aligning Functional and Non-functional Requirements. We're taking one area, one specific activity within the software development process, dealing with functional and non-functional requirements and using these ideas to help design better applications. We'll begin by getting clear on these terms, functional and non-functional, where they differ and where they overlap to see what we should look for in any initial project specification. We'll break apart larger business goals into achievable chunks of work and estimate the level of effort involved and revise any requirements that aren't written well. We'll take ideas like reliability, scalability, and responsiveness into specific, measureable targets that can be tested and verified. Now this course is part of the Microsoft Azure Developer series, so we'll talk about several ways to apply these ideas when creating cloud-based applications in Microsoft Azure. But this course is a little different from the typical Pluralsight Microsoft Azure course. I won't be spending any time in Visual Studio or configuring a lot of resources in the Azure portal because this is primarily a course about ideals, about concepts. So it's a bit more lecture style. But this is not a course full of bullet points. You'll find a lot of scenarios, analogies, and visuals. I've done my best to keep it as informal and conversational as possible. I hope you enjoy. Let's begin.

Refining User Stories and Acceptance Criteria
In the previous module, we talked about several general aspects of a project and how to prompt ourselves to think about different categories of non-functional requirements, like usability, reliability, and performance. We're now going to shift our focus to more individual, specific user stories given certain tasks we want to accomplish, certain functional requirements, things we want this application to do. How can we make sure we write them at the correct level? How we can verify and validate that we're accomplishing what we set out to do? And user stories allow us to take a slightly different perspective, one that emphasizes the user of a system rather than the system itself. And that makes it a little easier to stay aware of both the functional and non-functional aspects of anything we're trying to accomplish in the system.