The Essential Guide to Requirements Management and Traceability
Attributes of Functional vs Nonfunctional Requirements
Functional requirements describe what the system must do, perform or act in a specific way, depending on the context.
This might vary from industry to industry. But when considering functional vs. non-functional requirements in the medical device industry, for example, a functional requirement might consider throughput, analytical sensitivity, specificity, or time to result. A non-functional requirement would consider attributes, characteristics, or properties the system must have. This might consider EMC/EMI compliance, reliability, or safety-related properties.
What are user stories and how do they help?
When considering requirements and defining those requirements, you’ll find it helpful to consider integrating user stories. A user story is basically the description of a software feature from the user’s perspective. The story defines what you want the system to do and how that affects the overall experience. Acceptance criteria should also be included with user stories, which are the conditions the product needs to address to be acceptable to the client. Create at least one acceptance criterion for each user story. A few examples may include:
- A search field needs to be easily accessible by the user· A search is started once the user hits the “submit” button
- The display language is English
- No more than 150 characters can be typed into the search box
User stories are helpful in the context of non-functional requirements, as they allow you to take a deeper dive into the user experience and see how to make that process smoother.
Why are metrics used more in nonfunctional vs. functional requirements?
Many non-functional requirements help companies measure the success of a system, so those requirements must be verifiable. The metrics must be either qualitative or quantitative. You might require, for example, that a system be able to handle expansion in the future. That’s a qualitative goal, but let’s take it a step further and make it quantitative as well. With a waterfall approach, the expansion would be similar to qualitative “user needs.” For example, you might require that the system handle at least 30,000 users within the next three years.
The benefit of focusing on quantitative goals is that the goal is non-ambiguous and you and the client can agree on what success looks like.
What are requirement specifications? What is a requirements specification document?
What are requirement specifications? What is a requirements specification document?
A software requirements specification, also known as an SRS , addresses what the software will do and expectations with regard to its performance. The document also highlights what the product needs in terms of user functionality. Most documents include an overarching purpose and define functional and non-functional requirements. A few sections that you may want to include in your SRS document include:
- Include a brief overview of the system, along with any relevant background details and terms that need definition upfront.
- Overall description. Include any assumptions made about the project, its business values, and the overarching project vision.
- Specific requirements. Define specific attributes to be included in the system, functional requirements, and any relevant database requirements.
If you want to view an SRS document example of an SRS, Michigan State University has one that can give you a starting point for creating your own document.
Tracking Requirements: Why Traditional Documents May Miss the Mark
Traceability is critical to project success. Gartner highlights one of the main reasons why companies struggle to achieve the benefits of traceability:
“The most widely adopted tools for requirements continue to be general document software such as Microsoft Office or Google Docs (40% to 50% of the market) due to cost, availability, and familiarity. Yet these often lead to poorly managed requirements, thus eliminating and exceeding any cost benefit the tools themselves have. Requirements end up captured in a variety of documents and spreadsheets supplemented by post-it notes in unmanaged versions with no traceability or reuse. This creates a more costly user acceptance testing cycle, both in the time to execute as well as remediation of issues found late in the process, where they are far more costly to address.” – Gartner Research
Software and hardware teams must work together and collaborate throughout the development process to define market requirements, functional vs. non-functional requirements, test cases, and other critical pieces of information. This becomes a challenge, however, when teams use different tools and terminology and work with different methodologies.
The answer is to connect data, conversations, and decisions in an intuitive, accessible, visible tool that supports Live Traceability™n in the product development process. This gives you the ability to consult and collaborate with people about requirements within the system, capture decisions and actions, and keep that information associated with the requirement. Down the road, if you need to revisit decisions or need help with change management, all data is stored and easy to find.
Moving Forward with Functional vs. Nonfunctional Requirements
Every software project has a vision, a goal, and a destination that you want to reach. Functional and non-functional requirements help you to reach that goal more easily through setting clear boundaries. These requirements help you answer the most critical questions and ensure that products are developed with success in mind.
Functional requirements vs. nonfunctional requirements are critically important, but since non-functional goals are focused heavily on the user experience, these are arguably more critical. Understanding the role of each category empowers you to define and track each with greater success and create a road map that delivers on your client’s expectations.
