A comprehensive set of requirements is crucial for any software project. Requirements identify the product's business...
needs and purposes; they clarify the features, functionality, behaviors and performance that stakeholders expect.
When documented properly, software requirements form a roadmap that leads a development team to implement the right product quickly and with minimal costly rework. There are common types of software requirements documentation, as well as tried-and-true characteristics to help define requirements.
Software requirements are a way to identify and clarify the why, what and how of a business's application. The actual types of software requirements and documents an IT organization produces for a given project depend on the audience and the maturity of the project. In fact, organizations often draft several requirements documents, each to suit the specific needs of business leaders, project managers and application developers.
Let's start with a look at several different types of requirements in software engineering.
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 typically outline a BRD, which defines the why behind a software project.
A BRD is composed of one or more statements. There is no universally established format 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. Such statements would look like this:
"The [project name] software will [meet a business goal] in order to [realize a business benefit]."
Here's a detailed BRD statement example:
"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, which is an alternative to costly and environmentally dangerous chemicals, to mark stainless steel product parts.
Organizations prepare a BRD at the start of a software project, and it forms a foundation for subsequent, more detailed requirements documents. Discuss the BRD at length with stakeholders and ensure that it reflects a complete set of practical and measurable goals -- and meets customer expectations. When a business acts as a software development contractor, the BRD also serves as the basis for more detailed document preparation with its client.
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 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. Thus, 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 here's 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."
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, non-functional requirements and requisite use cases for the software. Essentially, the SRS details what the software will do, and it expands upon or translates the BRD into features and functions that developers understand.
An SRS often describes the software as a series of individual functional modules. In the laser marking software example, an SRS could define these modules: the interface that translates marking image files into control signals for the laser beam; a UI that allows an operator to log in, select products from a library, and start or stop marking cycles; and 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. Here's one common approach:
"The [feature or function] shall [do something based on user inputs and provide corresponding outputs]."
And here are a few software requirements in the laser marking system:
"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 a visual feedback to the operator, who shall track and display 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 non-functional requirements that identify attributes of the system or the operational environment. Non-functional requirements include usability, security, availability, capacity, reliability and compliance. They dictate development and design decisions 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. Ideally, every requirement delineated in an SRS should correspond with business objectives outlined in the BRD. For third-party software contractors, the completed SRS provides the basis for cost estimation and contract compliance.
While the SRS typically includes functional and non-functional requirements, some organizations might distinguish between an SRS and a functional requirements specification (FRS). 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. Additionally, such efforts force organizations to think about why a project should be undertaken, what the software 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.
Craft software requirements that embody these seven characteristics and you will have better, more effective requirements documentation -- namely SRSes, but not exclusively.
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.
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 read 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 -- in careful and ongoing requirements collaboration.
Consistent, not redundant. Software requirements documents are often long and divided into multiple parts -- each with its own specific requirements. Consistent requirements have no conflicts, such as differences in time, distance or terminology. For example, the difference between server and system will 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, in the course of the project, 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, like 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 help ensure unambiguous requirements documentation.
Design-agnostic. Software requirements documents should illustrate an end 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. As an example, a requirement like, "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 work done by software subcontractors, 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 actually done with a software project. Ideally, there will be 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.
Dig Deeper on Topics Archive
Related Q&A from Stephen J. Bigelow
Just because software passes functional tests doesn't mean it works. Dig into stress, load, endurance and other performance tests, and their ... Continue Reading
Don't neglect form factor as part of your data center server selection. Instead, figure out what type of environment you need and learn which server ... Continue Reading
Learn how load balancing in the cloud differs from a traditional network traffic distribution, and explore the different services available from AWS,... Continue Reading