Nonfunctional Requirements Course Roadmap

Lesson Overview

Hello and welcome.

I am excited for the opportunity to help you master the nonfunctional requirement categories presented in this course.

This course answers a question that is critical to the success of any system development project, “How can the system’s nonfunctional requirements best be defined?”

Simply defined, while functional requirements describe what the system must do, the nonfunctional requirements define how well it must do it.
Nonfunctional requirements embody important elements of quality for software systems. A thorough specification of nonfunctional requirements creates systems (whether developed or purchased) that:

Have more realistic time and cost estimates
Have few errors
Result in greater user value and satisfaction
Are more comprehensive
Better fit business needs

This course includes and extends the content presented in my book, The Quest for Software Requirements, which applies a user-focused classification for various categories of nonfunctional requirements. The intent of the book and this course is to bring greater consistency, clarity, and understanding to the term nonfunctional.
In the lessons presented in module 1, we’ll explore:

A definition of nonfunctional
Factors that contribute to difficulties in understanding nonfunctional requirements
A user-focused approach for classifying nonfunctional requirement categories
The anatomy of a nonfunctional category
How to reduce the risk of missing these vital requirements

In module 2, I’ll introduce you to a case study based on a real project. I’ll give you an overview of the project, and provide an explanation of a current-state relationship map, as well as a project-scope relationship map. Example nonfunctional requirements for the case study project will be shared in later course modules.

The nonfunctional classification presented in this course comprises three software user needs:

Operation, wherein the user is concerned with using the functionality of the system
Revision, wherein the user is concerned with changing the source code or data that drive the system
Transition, wherein the user is concerned with managing the upkeep of the software

We’ll discuss these three groups of nonfunctional requirement categories in module 3, 4, and 5 respectively.

Over years of mentoring and coaching on business analysis and requirements management practices, I have repeatedly found that people struggled in formulating nonfunctional requirements. When asked to review a requirements specification, I found the functional requirements section to be quite lengthy (not necessarily a metric of quality, mind you), while the nonfunctional requirements section was, far too often, blank or empty.

This course is my personal quest to help people understand these hard-to-identify and overlooked nonfunctional requirements. My experience has shown that an increased knowledge leads to people asking more questions that elicit nonfunctional requirements. This generally results in a significant reduction in missed requirements. The goal is to define better requirements (helping project teams identify requirements that they otherwise wouldn’t have), which contribute to better systems.

To maximize your on-demand learning experience, I encourage you to print the downloadable materials provided. These supplemental materials align with the visuals presented in the training videos and can improve your comprehension. Furthermore, the printed materials serve as quick-reference job aids following the training, which can improve your retention.

Thank you for choosing Requirements Quest for your requirements training needs. I look forward to helping you simplify and master nonfunctional requirements.

Have a question? Ask now!

Access Security: The extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.
Accessibility: The extent to which the software system can be used by people with the widest range of capabilities to achieve a specified goal in a specified context of use.
Assumption: An influential factor for the development of requirements that is believed to be true, but is yet to be validated.
Availability: The degree to which users can depend on the system to be up (able to function) during “normal operating times”.
Business Requirement: A specification that describes WHY the project is being done, and WHAT the project team is expected to accomplish.
Confidentiality: The degree to which the software system protects sensitive data and allows only authorized access to the data.
EARV: An acronym that represents the iterative nature of the requirements development discipline, standing for: Elicitation, Analysis, Representation, and Validation.
EARVC: An acroynm for the iterative process of eliciting, analyzing, representing, and validating the requirements to establish a baseline and more effectively control future changes to the requirements.
Efficiency: The extent to which the software system handles capacity, throughput, and response time.
Elicitation: Any activity, casual or structured wherein the Requirements Producer is actively working with stakeholders or business artifacts to further refine the clarity and consistency in the requirements.
Flexibility: The ease with which the software can be modified to adapt to different environments, configurations, and user expectations.
Functional Requirement: A specification that describes functionality that must be built into the system to enable the users to perform their goals or tasks. Functional requirements identify the processing that the system must perform on the inputs of information and materials to prepare and present outputs of information and materials.
Installability: The ease with which a software system can be installed, uninstalled, or reinstalled into a target environment.
Integrity: The degree to which the data maintained by the software system are accurate, authentic, and without corruption.
Interoperability: The extent to which the software system is able to couple or facilitate the interface with other systems.
Maintainability: The ease with which faults in a software system can be found and fixed.
Modifiability: The degree to which changes to a software system can be developed and deployed efficiently and cost effectively.
Nonfunctional Requirement: A specification of HOW WELL a software system must function.
Operation: In a classification of nonfuntional categories, a group that describes the user needs for using the functionality of a system. The user perceives the system as tool to automate tasks.
Portability: The ease with which a software system can be transferred from its current hardware or software environment to another.
Reliability: The extent to which the software system consistently performs the specified functions without failure.
Requirement Producer: Any individual who is responsible for capturing the requirements. In more explicit terms, the Requirement Producer is any individual who is responsible for driving the process of eliciting, analyzing, representing, validating, and managing changes to the requirements.
Requirement Receiver: Any individual who is responsible for developing a solution to the defined requirements.
Requirement Supplier: Any individual who is responsible for defining the business and user needs to be satisfied.
Requirement Supporter: Any individual who is responsible for assisting the Producers, Suppliers, and Receivers in applying the requirements management process. The Requirement Supporters review the requirements, as well as the requirements approach, to offer suggestions for improvement on future project efforts. That is, they are process champions and support the activities of the process and look for ways to improve the process.
Requirements Analysis: The process of analyzing the information elicited, resolving conflicts, documenting assumptions, constraints, and dependencies, and working with the stakeholders to establish priorities.
Requirements Change Control: The process of maintaining a set of approved or baselined requirements throughout the lifecycle of the development project.
Requirements Elicitation: The process of identifying stakeholder classes, defining the project scope, identifying requirement sources, and applying techniques to gather the information.
Requirements Representation: The process of specifying the business needs using a combination of graphical models and textual documents.
Requirements Validation: The process of reviewing the represented information with the stakeholders for quality characteristics such as completeness, correctness and feasibility.
Reusability: The extent to which a portion of the software system can be converted for use in another system.
Revision: In a classification of nonfuntional categories, a group that describes the user needs for changing source code or data that drive the system. The user perceives the system as a set of programmed language statements.
Safety: The degree to which a software system prevents harm to people or damage to the environment in the intended context of use.
Scalability: The degree to which the system is able to expand its processing capabilities upward and outward to support business growth.
Stakeholder: In the context of requirements management, any individual that a Requirement Producer (for example, business analyst) is likely to engage with directly or indirectly during the requirements development and management processes.
Stakeholder Profiling: In requirements management, a technique for identifying the topics of expertise, the stakeholders who have proficient and expert-level knowledge of the topics of expertise, and a tool for planning the engagement of stakeholders.
Subject Matter Expert (SME): A person that beholds an immense amount of knowledge about a single subject, and can therefore be considered an expert.
Survivability: The extent to which the software system continues to function and recovers in the presence of a system failure.
Transition: In a classification of nonfuntional categories, a group that describes the user needs for managing the upkeep of the software. The user perceives the system similar to hardware.
Usability: The ease with which the user is able to learn, operate, prepare inputs, and interpret outputs through interaction with a system.
User: In the context of software requirements, anyone who affects or is affected by the system under development. A user is anyone or anything that provides inputs to the system and receives outputs from the system.
User Requirement: A specification that describes user goals or tasks that the users must be able to perform through interaction with the system.
Verifiability: The extent to which tests, analysis, and demonstrations are needed to prove that the system will function as intended.

Nonfunctional Requirements Course Roadmap

Lesson Overview

Training

Resources

About

Contact