jama-logo-primary
  • Product
    • JAMA CONNECT®
      • Product Overview
      • Features
      • Integrations
      • Pricing and Licensing
      • Why Jama?
      • Trial
    • Customer Success
      • Success Programs
      • Support
      • Community
  • Solutions
    • Solution by Industry
      • Aerospace and Defense
      • Automotive
      • Software Development
      • Financial Services and Insurance
      • Government
      • Industrial Manufacturing
      • Medical Device & Life Sciences
      • Semiconductor
    • Solution by Function
      • Requirements Management
      • Requirements Traceability
      • Risk Management
      • Test Management
      • MBSE
    • Compare
      • IBM® DOORS®
      • DOORS® Next®
      • Jira® Software
      • Polarion
  • Company
    • Company Information
      • About Us
      • Leadership
      • Careers
      • Requirements Traceability Alliance
      • Partners
      • Customers
      • Contact Us
    • News and Events
      • Events
      • Press Room
  • Resources
    • Content Library
    • Guide to Requirements Management and Traceability
    • Discovery Center
    • Customer Stories
    • Webinars
    • Product Demos
    • Support
    • Community
  • Blog
  • Get Started
  • Search
  • Menu Menu
Follow a manual added link
Follow a manual added link

The Essential Guide to Requirements Management and Traceability

Chapters
  • 1. Requirements Management
    • Overview
    • 1 What is Requirements Management?
    • 2 Why do you need Requirements Management?
    • 3 Four Fundamentals of Requirements Management
    • 4 Adopting an Agile Approach to Requirements Management
    • 5 Conquering the 5 Biggest Challenges of Requirements Management
    • 6 Three Reasons You Need a Requirements Management Solution
  • 2. Writing Requirements
    • Overview
    • 1 Functional requirements examples and templates
    • 2 Product requirements document template and examples
    • 3 How to write system requirement specification (SRS) documents
    • 4 Adopting the EARS Notation to Improve Requirements Engineering
    • 5 Jama Connect Advisor™
    • 6 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
    • 7 How to Write an Effective Product Requirements Document
    • 8 Functional vs. Non-Functional Requirements
    • 9 What Are Non-Functional Requirements and How Do They Impact Product Development?
    • 10 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
    • 11 8 Do’s and Don’ts for Writing Requirements
  • 3. Requirements Gathering and Management Processes
    • Overview
    • 1 Requirements Engineering
    • 2 Requirements Analysis
    • 3 Requirements Gathering Techniques for Agile Product Teams
    • 4 A Guide to Requirements Elicitation for Product Teams
    • 5 What is requirements gathering?
    • 6 Defining and Implementing a Requirements Baseline
    • 7 How Long Do Requirements Take?
  • 4. Requirements Traceability
    • Overview
    • 1 What is Traceability?
    • 2 What is Requirements Traceability and Why Does It Matter for Product Teams?
    • 3 How to Create and Use a Requirements Traceability Matrix
    • 4 Live Traceability vs. After-the-Fact Traceability
    • 5 How to Overcome Organizational Barriers to Live Requirements Traceability
    • 6 Requirements Traceability, What Are You Missing?
    • 7 Four Best Practices for Requirements Traceability
    • 8 Requirements Traceability: Links in the Chain
    • 9 What Are the Benefits of End-to-End Traceability During Product Development?
  • 5. Requirements Management Tools and Software
    • Overview
    • 1 Selecting the Right Requirements Management Tools and Software
    • 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn
    • 3 Application lifecycle management (ALM)
    • 4 Is There Life After DOORS®? 
    • 5 Checklist: Selecting a Requirements Management Tool
  • 6. Requirements Validation and Verification
    • Overview
    • 1 Requirements Verification and Validation for Product Teams
  • 7. Meeting Regulatory Compliance and Industry Standards
    • Overview
    • 1 Understanding ISO Standards
    • 2 A Guide to Automotive Safety Integrity Levels (ASIL)
    • 3 Compliance Management
    • 4 What is FMEA? Failure Modes and Effects Analysis
    • 5 What’s a Design History File, and How Are DHFs Used by Product Teams?
  • 8. Project Management
    • Overview
    • 1 Managing Project Scope — Why It Matters and Best Practices
  • 9. Measuring Requirements
    • Overview
    • 1 Identifying and Measuring Requirements Quality
    • 2 Status Request Changes
  • 10. Systems Engineering
    • Overview
    • 1 What is Systems Engineering?
    • 2 The Systems Engineering Body of Knowledge (SEBoK)
    • 3 What is MBSE? Model-Based Systems Engineering Explained
  • Glossary

The Characteristics of Excellent Requirements

How can you distinguish excellent software requirements and software requirements specifications (SRS) from those that could cause problems? In this post, we’ll start by discussing several different characteristics that individual requirements should exhibit. Then, we’ll then look at the desirable traits a successful SRS should have as a whole.

Characteristics of Effective Requirements

In an ideal world, every individual user requirement, business requirement, and functional requirement would exhibit the qualities described in the following sections.

Complete

Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the developer to design and implement that bit of functionality. If you know you’re lacking certain information, use TBD (to be determined) as a standard flag to highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed with construction of that portion.

Nothing says you need to make the entire requirements set complete before construction begins. In most cases, you’ll never achieve that goal. However, projects using iterative or incremental development life cycles should have a complete set of requirements for each iteration.

Using minimal requirements specifications runs the risk of having different people fill in the blanks in different ways, based on different assumptions and decisions. Keep requirements details verbal instead of written also makes it hard for business analysts, developers, and testers to share a common understanding of the requirements set.

Correct

Each requirement must accurately describe the functionality to be built.

The reference for correctness is the source of the requirement, such as an actual user or a high-level system requirement. A software requirement that conflicts with its parent system requirement is not correct.

Only user representatives can determine the correctness of user requirements (such as use cases), which is why users or their close surrogates must review the requirements.

Feasible

It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment. To avoid specifying unattainable requirements, have a developer work with marketing or the BA throughout the elicitation process.

The developer can provide a reality check on what can and cannot be done technically and what can be done only at excessive cost. Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility.

Necessary

Each requirement should document a capability that the stakeholders really need or one that’s required for conformance to an external system requirement or a standard.

Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the-customer input, such as a use case, a business rule, or some other origin of value.

RELATED ARTICLE: 8 Do’s and Don’ts for Writing Requirements

Prioritized

Assign an implementation priority to each functional requirement, feature, use case, or user story to indicate how essential it is to a particular product release.

If all the requirements are considered equally important, it’s hard for the project manager to respond to budget cuts, schedule overruns, personnel losses, or new requirements added during development. Prioritization is an essential key to successful iterative development.

Unambiguous

All readers of a requirement statement should arrive at a single, consistent interpretation of it, but natural language is highly prone to ambiguity. Write requirements in simple, concise, straightforward language appropriate to the user domain. “Comprehensible” is a requirement quality goal related to “unambiguous”: readers must be able to understand what each requirement is saying. Define all specialized terms and those that might confuse readers in a glossary.

A good way to help ensure requirements are written in concise, unambiguous language is to use requirements templates like the EARS models.

Verifiable

See whether you can devise a few tests or use other verification approaches, such as inspection or demonstration, to determine whether the product properly implements each requirement.

If a requirement isn’t verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable.

Characteristics of Effective Software Requirements Specifications (SRS)

It’s not enough to have excellent individual requirement statements. Sets of requirements that are collected into a software requirements specification (SRS) ought to exhibit the characteristics described in the following sections.

Complete

No requirements or necessary information should be absent. Missing requirements are hard to spot because they aren’t there! Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness. “I don’t know of any way to be absolutely certain that you haven’t missed a requirement,” says Karl Weigers, author of Software Requirements, Third Edition. “There’s a chapter of my book that offers some suggestions about how to see if you’ve overlooked something important.”

Consistent

Consistent software requirements don’t conflict with other requirements of the same type or with higher-level business, system, or user requirements. Disagreements between requirements must be resolved before development can proceed. If you spot a pair of conflicting requirements, you might not know which one (if either) is correct until you do some research. Recording the originator of each requirement lets you know who to talk to if you discover conflicts in your software requirements specification.

Modifiable

You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed separately from other requirements so that you can refer to it unambiguously.

Each requirement should appear only once in the SRS. It’s easy to generate inconsistencies by changing only one instance of a duplicated requirement. Consider cross-referencing subsequent instances back to the original statement instead of duplicating the requirement. A table of contents and an index will make the SRS easier to modify. Storing requirements in a database or a commercial requirements management solution makes them into reusable objects.

Traceable

A traceable requirement can be linked backwards to its origin and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct. Traceable requirements are uniquely labeled with persistent unique identifiers. They are written in a structured, fine-grained way as opposed to crafting long narrative paragraphs. Avoid lumping multiple requirements together into a single statement; the individual requirements might trace to different design and code elements.

READ MORE: [Answered] The Most Asked Questions About Writing Requirements

How Do You Know If Your Requirements and SRS Exhibit These Attributes?

The best way to tell whether your requirements have these desired attributes is to have several project stakeholders carefully review the SRS. Different stakeholders will spot different kinds of problems. For example, analysts and developers can’t accurately judge completeness or correctness, whereas users can’t assess technical feasibility.

You’ll never create an SRS in which all requirements demonstrate all these ideal attributes. However, if you keep these characteristics in mind while you write and review the requirements, you will produce better requirements documents and you will build better products.

READ MORE: Requirements Management – Living NOT Static

In This Webinar, We Discuss the Benefits of Modern Requirements Management

DEFINITION OF A SOFTWARE REQUIREMENTS DEFINITION:

A Software Requirements Definitions (SRS) is a description of a software system to be developed. It is modeled after business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

Ready to Find Out More?

Our team of experts is here to answer any questions and learn how we can help enable 
your continued success. Get started by filling out this form so we can connect!

CONTACT US
Next Up: 8 Do’s and Don’ts for Writing Requirements
Previous: What Are Non-Functional Requirements and How Do They Impact Product Development?

CONNECT WITH US

  • Facebook
  • LinkedIn
  • Twitter
  • Youtube

USA
135 SW Taylor Suite 200
Portland, Oregon, 97204

EUROPE
Amsterdam Queens Tower
Delflandlaan 1, 1062EA Amsterdam
The Netherlands

© 2023 Jama Software

  • JAMA CONNECT
  • Product Overview
  • Pricing and Licensing
  • Success Programs
  • Trial
  • COMPANY
  • About Us
  • Careers
  • Customers
  • Press Room
  • Contact Us
  • RESOURCES
  • Resource Library
  • Events
  • Press Room
  • Blog
  • Success Programs
  • User Community
  • Support
  • Privacy Policy
  • Cookies
  • Privacy and Security
  • Legal
  • Preferences
Scroll to top