- 1. Requirements Management
- 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
- 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
- 4. Requirements Traceability
- 1 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 2 How to Create and Use a Requirements Traceability Matrix
- 3 Live Traceability vs. After-the-Fact Traceability
- 4 How to Overcome Organizational Barriers to Live Requirements Traceability
- 5 Requirements Traceability, What Are You Missing?
- 6 Four Best Practices for Requirements Traceability
- 8 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
Is There Life After DOORS®?
This post was written by Richard Watson, a former IBM® DOORS® Product Manager for nearly 20 years.
I started by managing the creation of an integration between DOORS and Mercury TestDirector and eventually picked up the DOORS family, working with Telelogic and then on to the acquisition by IBM.
How did DOORS become a market leader?
“If Bill Gates can have Windows, I want to have DOORS. Now tell me, what does DOORS mean?”
Initially created by QSS and then Telelogic, DOORS was the market leading requirements tool in the 1990s and into the 2000s. Industry analysts moved focus to application lifecycle management (ALM) solutions in the 2010s and it was difficult for any vendor to claim a defined market share, let alone market leadership.
Three decades ago, it was possible to persuade prime contractors to mandate use of a single tool across their entire supply chain. With early success in the UK defense industry, DOORS became the market leading requirements tool; in the early 90s there was only two tools to choose between. Rational® entered the requirements business in 1998 and held 2nd place in the market.
The acquisition of Rational and then Telelogic by IBM consolidated the requirements market into a single vendor, which offered four different requirements solutions: DOORS, Requirements Composer, Requisite Pro, and Rational® DOORS® Next Generation. Only two of those solutions now survive to make up the DOORS family.
Where are we today with requirements management solutions?
Working styles have changed dramatically since the 90’s and teams are being asked to move fast and work collaboratively with teams across the organization. In order to satisfy this new way of working, requirements management vendors needed to adapt and invest in the interface and useability of their products.
Users are demanding ease of use so more people can enter information directly into a tool rather than sending Word or Excel documents to a tool user for import.
The industry has changed. It’s no longer possible for an OEM (Original Equipment Manufacturer) to mandate a single product or vendor across supply chains and in fact, standards such as ReqIF (exchange) and OSLC (integration) have come about to help products work better together. Again, this requires investment from the vendors so that interoperation does not sit just within a single tool chain.
RELATED ARTICLE: Why Migrate to Jama Connect?
The Inside Story: Data-Model Diagnostics for IBM® DOORS®
What’s next after DOORS?
Requirements management has been accepted by the engineering industry as an essential discipline, regardless of what process is used or what type of system is being produced. What changes is the level of formality adopted (process) or the regulation that must be complied with (industry standard).
Best practices for systems engineering have been prescribed in many industries. It’s not just about DO178 or ISO 9001, we now see engineering regulation or compliance needs in automotive, medical, finance, and many other industries.
It is no longer possible for a single product or vendor to drown a marketplace. We have different users wishing to make their own decisions about which best of breed solutions are right for their organization. One tool will not fit all users’ needs. An organization’s investment in their data is far more than the investment they make in tools, and the focus now comes down to availability of data and how that flows across an engineering community (integration) and the value chain (exchange). Don’t forget, it’s your data – not the vendor’s!
I have seen that there is life after being the Product Manager for DOORS and have chosen to work with a vendor (Jama Software) that has a single focus on engineering, reinvesting revenues into their products and therefore, investing in their users. Let’s see where this next roller coaster takes me. One thing I know for certain, there’s more fun ahead!
Requirements Gathering is the process of understanding what you are trying to build and why you are building it.