Business Analysis: Eliciting Nonfunctional Requirements

In this section you are introduced to a case study based on a real project. The case study will be used throughout the course to provide example nonfunctional requirements.

In the context of use intended in this course, an entity represents a person or thing that physically exists. Therefore, an entity is thought of as a noun. Examples of entities include user roles, stakeholders, functional departments, groups, and organizations. This lecture presents a summary of entities for the case study project.

A Relationship Map is a visual diagram that allows you to see a broad view of connections between business entities. A relationship map presents an illustration of who plays a role in the business processes and operations, and helps you gain a high-level understanding of which roles interact and why. The current-state relationship map is shown to understand the premise for the case study project.

A relationship map is a broad view of the business entities impacted within the scope of a project. A relationship map is shown to understand the direction or desired outcome for the case study project.

This job aid describes four core models that Roxanne recommends for all projects.

This lesson introduces the operation group of nonfunctional categories concerned with how well users can interact with and operate a software system or product.

Operation requirements define how well the software system performs for daily use by the user. While functional requirements describe what tasks the system is to perform, the operation requirements describe how well the system performs the tasks. Generally, these requirements are of greatest concern to users who come in contact with the software system by using the functionality. Stated simply, the users’ view of automation is a software system that either does the work for them, or helps the user do the work better, faster, and cheaper.

Access Security is defined as the extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.

A question that best states the user’s concern for Access Security is: How well is the system safeguarded against unauthorized access?

This lecture explores aspects to consider when eliciting access security requirements.

Accessibility is defined as 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.

A question that best states the user’s concern for Accessibility is: How easy is the system to use by people with varying capabilities?

This lecture explores aspects to consider when eliciting accessibility requirements.

Availability is defined as the degree to which users can depend on the system to be up (able to function) during “normal operating times.”

A question that best states the user’s concern for Availability is: How dependable is the system during normal operating times?

This lecture explores aspects to consider when eliciting availability requirements.

Confidentiality is defined as the degree to which the software system protects sensitive data and allows only authorized access to the data.

A question that best states the user’s concern for Confidentiality is: How well does the system make sensitive data available to authorized users?

This lecture explores aspects to consider when eliciting confidentiality requirements.

Efficiency is defined as the extent to which the software system handles capacity, throughput, and response time.

A question that best states the user’s concern for Efficiency is: How fast, how many, and how well does the system respond?

This lecture explores aspects to consider when eliciting efficiency requirements.

Integrity is defined as the degree to which the data maintained by the software system are accurate, authentic, and without corruption.

A question that best states the user’s concern for Integrity is: How accurate and authentic are the data?

This lecture explores aspects to consider when eliciting integrity requirements.

Reliability is defined as the extent to which the software system consistently performs the specified functions without failure.

A question that best states the user’s concern for Reliability is: How immune is the system to failure?

This lecture explores aspects to consider when eliciting reliability requirements.

Safety is defined as the degree to which a software system prevents harm to people or damage to the environment in the intended context of use.

A question that best states the user’s concern for Safety is: How well does the system prevent harm to people and the environment?

This lecture explores aspects to consider when eliciting safety requirements.

Survivability is defined as the extent to which the software system continues to function and recovers in the presence of a system failure.

A question that best states the user’s concern for Survivability is: How resilient is the system from failure?

This lecture explores aspects to consider when eliciting survivability requirements.

Usability is defined as the ease with which the user is able to learn, operate, prepare inputs and interpret outputs through interaction with a software system.

A question that best states the user’s concern for Usability is: How easy is it to learn and operate the system?

This lecture explores aspects to consider when eliciting usability requirements.

This lesson introduces the revision group of nonfunctional categories concerned with developing and maintaining a software system or product.

Revision requirements define how efficiently the software system can be corrected or fixed when errors occur, and how easily new features can be added. Revision requirements are generally of greater concern to the users who read the software system documentation to understand the design and usage of the system, and change source code or data that drive the system. As such, the users’ view of quality is a system that is easy to maintain and easy to demonstrate that performance requirements are being met.

Flexibility is defined as the ease in which the software can be modified to adapt to different environments, configurations, or user expectations.

A question that best states the user’s concern for Flexibility is: How easy is it to modify the system to work in different environments?

This lecture explores aspects to consider when eliciting flexibility requirements.

Maintainability is defined as the ease with which faults in a software system can be found and fixed.

A question that best states the user’s concern for Maintainability is: How easy is it to upkeep and repair the system?

This lecture explores aspects to consider when eliciting maintainability requirements.

Modifiability is defined as the degree to which changes to a software system can be developed and deployed efficiently and cost effectively.

A question that best states the user’s concern for Modifiability is: How easy is it to change the software system, and at what cost?

This lecture explores aspects to consider when eliciting modifiability requirements.

Scalability is defined as the degree to which the software system is able to expand its processing capabilities upward and outward to support business growth.

A question that best states the user’s concern for Scalability is: How easy is it to expand or upgrade the system’s capabilities?

This lecture explores aspects to consider when eliciting scalability requirements.

Verifiability is defined as the extent to which tests, analysis, and demonstrations are needed to prove that the software system will function as intended.

A question that best states the user’s concern for Verifiability is: How easy is it to show that the system performs its functions?

This lecture explores aspects to consider when eliciting verifiability requirements.

This lesson introduces the transition group of nonfunctional categories concerned with how well the system system adapts to the technological environment.

Transition requirements describe the ability of the software system to adapt to its surrounding environment. Users who come in contact with the software system by managing the upkeep of the system are generally most concerned with transition requirements. That is, users view quality as a system that:

• Can be moved efficiently to other operating environments

• Connects easily with other systems

• And, Lends itself to reuse

Installability is defined as the ease with which a software system can be installed, uninstalled, or reinstalled into a target environment.

A question that best states the user’s concern for Installability is: How easy is it to install, uninstall, and reinstall the software system?

This lecture explores aspects to consider when eliciting installability requirements.

Interoperability is defined as the extent to which the software system is able to couple or facilitate the interface with other systems.

A question that best states the user’s concern for Interoperability is: How easy is it to interface with another system?

This lecture explores aspects to consider when eliciting interoperability requirements.

Portability is defined as the ease with which a software system can be transferred from its current hardware or software environment to another environment.

A question that best states the user’s concern for Portability is: How easy is it to transport the system to another environment?

This lecture explores aspects to consider when eliciting portability requirements.

Reusability is defined as the extent to which a portion of the software system can be converted for use in another system.

A question that best states the user’s concern for Reusability is: How easy is it to convert for use in another system?

This lecture explores aspects to consider when eliciting reusability requirements.

Considerable effort has been expended over several decades to improve the quality of software products and systems. A number of quality models have evolved to aid the improvement of quality. This lecture will help you understand components of a quality model.

This lecture will help you gain insight into the approach taken by McCall, et. al. This foundational approach led to the development of many subsequent quality models.

This lecture explores the quality model developed by McCall, et. al.

This lecture explores the quality model developed by Boehm.

This lecture explores the quality model developed by Hewlett-Packard.

This lecture explores the quality factors presented by ISO/IEC.

This lecture presents a 6-step process for developing nonfunctional (quality) software requirements.

This lecture presents possible formats that may be used to represent nonfunctional requirements.

Download a template for representing nonfunctional requirements in a standalone deliverable.