What are the types of requirements in software engineering?

What are the different types of requirements in software engineering?

Teams must outline requirements to meet the needs of business stakeholders and users as well as the more technical features of the software. The three main types of requirements in software engineering are business, user and software.

Business requirements

Business needs drive many software projects. A business requirements document (BRD) outlines measurable project goals for the business, users and other stakeholders. Business analysts, leaders and other project sponsors create the BRD at the start of the project. This document defines the why behind the build. For software development contractors, the BRD also serves as the basis for more detailed document preparation with clients.

A BRD is composed of one or more statements. No universally established format exists for BRD statements but one common approach is to align goals. Write statements that match a project goal to a measurable stakeholder or business goal.

The basic format of a BRD statement is, "The [project name] software will [meet a business goal] in order to [realize a business benefit]." An example of a completed BRD statement is, "The laser marking software will allow the manufacturing floor to mark text and images on stainless steel components using a suitable laser beam in order to save money in chemical etching and disposal costs."

For this example, the purpose of the proposed software project is to operate an industrial laser marking system to mark stainless steel product parts, which is an alternative to costly and environmentally dangerous chemicals.

Business goals and benefits can be varied and sometimes interchangeable. Common business goals and benefits can include the following:

• Achieve a specific technical outcome, such as implementing a new technology.
• Achieve a specific logistical outcome, such as faster time-to-market.
• Increase market share or revenue, which facilitates business growth.
• Improve customer experience, satisfaction or relationships.
• Strengthen business continuance, security or compliance postures.
• Increase business productivity or efficiency, such as automating manual processes.
• Build the business's brand.
• Manage or reduce costs.
• Increase website traffic.
• Increase social media presence.

Organizations prepare a BRD as a foundation for subsequent, more detailed requirements documents. Ensure that the BRD reflects a complete set of practical and measurable goals as well as meets customer expectations.

Finally, the BRD should be a living document. Evaluate any future requirements, updates or changes to the project against the BRD to ensure that the organization's goals are still met.

User requirements

User requirements reflect the specific needs or expectations of the software's customers. Organizations sometimes incorporate these requirements into a BRD, but an application that poses extensive user functionality or complex UI issues might justify a separate document specific to the needs of the intended user. User requirements, much like user stories, highlight the ways in which customers interact with software.

There is no universally accepted standard for user requirements statements, but this is one common format: "The [user type] shall [interact with the software] in order to [meet a business goal or achieve a result]."

A user requirement in that mold for the industrial laser marking software example looks like, "The production floor manager shall be able to upload new marking files as needed in order to maintain a current and complete library of laser marking images for production use."

There might be many user requirements for any software project, each reflecting an expectation, goal or user story. In most cases, user requirements are high-level goals that reflect what the software should be able to do. They typically avoid any technical details related to how they accomplish the goals. User requirements frequently form the foundation for specific software requirements.

Software requirements

After the BRD outlines the business goals and benefits of a project, the team should devise a software requirements specification (SRS) that identifies the specific features, functions, nonfunctional requirements and requisite use cases for the software. Essentially, the SRS details what the software will do. It expands upon or translates the BRD and user requirements into features and functions that developers can understand and implement.

Software requirements typically break down into functional requirements, nonfunctional requirements (NFRs) and domain requirements.

Functional requirements. Functional requirements are statements or goals that teams use to define system behavior. Functional requirements define what a software system must or must not do. They are typically expressed as responses -- interactions or outputs -- generated in response to inputs or conditions. Common functional requirements include data input, data access, user authentication, alerting and reporting, online payments and integrations with other software.

A functional requirement can express an if/then relationship, as in the following example: "If an alarm is received from a sensor, the system will report the alarm and halt until the alarm is acknowledged and cleared."

Functional requirements might detail specific types of data inputs such as names, addresses, dimensions and distances. These requirements often include an array of calculations vital to the software working correctly.

Functional requirements are relatively straightforward to test because they define how the system behaves. A test fails when the system does not function as expected.

NFRs. Nonfunctional requirements relate to software usability. Nonfunctional software requirements define how the system must operate or perform. A system can meet its functional requirements and fail to meet its nonfunctional requirements.

NFRs define the software's characteristics and expected user experience (UX). They cover the following:

• Performance. This measures how quickly the software should respond or render an output.
• Usability. The level of difficulty that users experience in understanding or using a UI or software system.
• Scalability. The software's ability to handle more simultaneous users or transactions.
• Security. The ways in which the software safeguards processing and data against loss or theft.
• Maintainability. The ability of the software to be patched or upgraded over time.
• Compatibility. Compatibility involves the hardware, OS and other platform requirements for the software.
• Portability. The ability of the software to operate on different systems or platforms.

An example nonfunctional requirement related to performance and UX could be, "The pages of this web portal must load within 0.5 seconds."

Domain requirements. Domain requirements are expectations related to a particular type of software, purpose or industry vertical. Domain requirements can be functional or nonfunctional. The common factor for domain requirements is that they meet established standards or widely accepted feature sets for that category of software project.

Domain requirements can vary wildly but typically arise in military, medical and financial industry sectors. An example of a domain requirement for software in medical equipment is, "The software must be developed in accordance with IEC 60601 regarding the basic safety and performance for medical electrical equipment."

Another example of a domain requirement for the financial industry is, "The software should adhere to current Generally Accepted Accounting Principles standards for financial accounting and reporting."

Software can be functional and usable but not acceptable for production because it fails to meet domain requirements.

Examples of requirements in software documentation

An SRS often describes the software as a series of individual functional modules. In the laser marking software example, an SRS could define the following modules:

• The interface that translates marking image files into control signals for the laser beam.
• A UI that enables an operator to log in, select products from a library and start or stop marking cycles.
• A test mode to calibrate the system.

There are some industry standards for an SRS, such as ISO/IEC/IEEE 29148:2018, but organizations can still use a different preferred format for SRS statements. One common approach is, "The [feature or function] shall [do something based on user inputs and provide corresponding outputs]."

A few software requirements related to the laser marking system example might include the following:

• "The laser marking operation shall translate AutoCAD-type vector graphics files into laser on/off control signals as well as X and Y mirror control signals used to operate the laser system."
• "The software provides visual feedback to the operator, who shall be able to track the current state of the marking cycle overlaid on a graphic product image displayed on a nearby monitor in real time."

In addition to functional requirements, an SRS often includes nonfunctional requirements that identify attributes of the system or the operational environment. Nonfunctional requirements include usability, security, availability, capacity, reliability and compliance. They dictate development decisions and design requirements for the software, like password change frequency, data protection settings and login details.

A systems analyst or product manager typically puts together an SRS in collaboration with relevant stakeholders, such as the developer staff and business leaders. Ideally, every requirement delineated in an SRS should correspond with the business objectives that a BRD outlines. For third-party software contractors, the completed SRS provides the basis for cost estimation and contract compliance.

While the SRS typically includes functional and nonfunctional requirements, some organizations might differentiate between an SRS and a functional requirements specification. In these cases, the FRS serves as a separate document and delves into the how of a software product. An FRS often stipulates all of the fields and user interactions throughout the entire software product.

Characteristics of good software requirements

All types of software requirements require significant prep work as part of the product development process. Additionally, such efforts force organizations to think about why they undertake a project, what the software product should provide and how it will accomplish the desired goals. Requirements documents are a foundation upon which teams conceive, propose, budget and implement a software development project.

Consequently, requirements can have a profound impact on software development and business outcomes for months or even years. Prudent consideration and intellectual investment up front can improve outcomes dramatically.

Teams should ensure software requirements embody the following eight characteristics.

Clear and understandable. Software requirements must provide the utmost clarity. Write requirements in plain language, free of domain-specific terms and jargon. Clear and concise statements make requirements documents easy to evaluate for subsequent characteristics.

When researched and documented properly, software requirements form a roadmap that leads a development team to build the right product quickly and with minimal costly rework.

Correct and complete. The document should accurately detail all requirements. If it's a BRD, the document should detail all business goals and benefits. If it's an SRS, it should describe all features and functionality expected from the system. Use an easily readable format and go back to finish any to-be-determined entries. It rarely falls on one person to deliver a correct and complete software requirements document. Involve all relevant parties -- business leaders, project managers, development staff, customers and even users -- in careful and ongoing requirements collaboration.

Consistent, not redundant. Software requirements documents are often long and divided into multiple parts, each with specific requirements. Consistent requirements have no conflicts, such as differences in time, distance or terminology. For example, the difference between server and system might confuse some team members, so use only one to refer to the physical machine in the data center running the software. Only state a requirement once; don't duplicate it. Redundant requirements often lead to errors if the team changes or updates an iteration and the manager forgets to change or update repeated entries elsewhere in the document.

Unambiguous. No software requirement can leave room for interpretation. Even clear statements can still be subject to multiple interpretations, which leads to implementation oversights. For example, it might be clear to require that a function, such as a mathematical process, should be performed on a temperature measurement. But a requirement must specify the temperature measurement as degrees in Fahrenheit, Celsius or Kelvin. Phrase each statement so that there is only one possible interpretation. Collaboration and peer reviews ensure unambiguous requirements documentation.

Design agnostic. Software requirements documents should illustrate a result. Like an architectural diagram, the different types of requirements together detail what the development team should build and why but rarely explain how. Empower developers to select from various design options during the implementation phase of the software project. Don't stipulate specific implementation details unless they're necessary to satisfy business goals. A business might, for example, prohibit developers from using open-source components in a project, as the approach conflicts with its ability to sell or license the finished project.

Measurable and testable. The goal of a requirements document is to provide a roadmap for implementation. Eventually, teams must evaluate a completed project to determine whether the effort is successful -- for this, they must be able to objectively measure statements. For example, a requirement such as "must start quickly" is not measurable. Instead, use a quantifiable requirement such as "must initialize and be ready to accept network traffic within five seconds." This characteristic is particularly important for software subcontractors' work as unmeasurable statements can lead to cycles of costly rework. Prepare a software requirements document with testing in mind. Each statement should enable the team to create test plans and test cases that validate the completed build.

Traceable. It's hard to know when developers are done with a software project. Ideally, there is a direct connection between requirements documents and finished code. A project manager should be able to follow the provenance of a project from a requirement to a design element to a code segment and even to a test case or protocol. When a requirement does not trace to the finished code, the development team might not implement it, and the project could be incomplete. Code that is present without a corresponding requirement might be superfluous or even malicious. Conversely, when a project manager sees all requirements reflected in the finished code and it passes testing, the project is complete.

Managed document. Most software design documents are living and evolving entities that can change over time, sometimes frequently, through collaboration and review. Organizations often opt to manage design documents through an annotated version control system, which is similar to the system that manages the software versions in development. Version management helps ensure that every developer and project stakeholder is referring to the same document version for discussion and implementation. Version updates are generally circulated to the project team on a regular basis and made available through team sharing and collaboration tools.

Stephen J. Bigelow, senior technology editor at TechTarget, has more than 20 years of technical writing experience in the PC and technology industry.