A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk
The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect.
Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also very different from Risk analysis. A risk assessment is a documented, point-in-time questionnaire at best. A risk analysis can be much more useful when the input variables are selected and formulated correctly. By "useful", I mean that they reflect reality closer to what a human can correlate and fit to normalized patterns.
Without invoking the book, "Software Security Engineering: A Guide for Project Managers", I can tell you that security requirements engineering, as you request, is not a clearly-defined problem to solve in cyber risk. Many document-heavy projects based on Waterfall or other lifecycle prescriptions were abandoned in Information Technology and Application Development circles in the late 1990s. Today, our practices and value chains are aligned towards Scrumban, the most-modern evolution of xp.
If you can follow the FAIR model, then you'll understand how information risk will fit into your organization. This exists outside of your business processes -- it's a standard language to communicate with the multitude of players who could show up to the cyber risk conversation. Threats, as in TCom and TCaps, are an important piece of the FAIR model, so you must quantify threats in order to quantify risk. You must also understand the business. If you identify a vulnerability, or a control-set issue, then you will want to elicit root cause. Root cause is never a patch -- it's always back to the business process, typically consequence management or even crisis management.
If you want to see how you can truly fit these pieces together, I suggest you do check out FAIR, but integration is key -- and OpenSAMM makes that integration cleaner than anything else I've seen. If you need a strategic map to forecast your future outputs (or collect the right input variables in the first place), then OWASP OpenSAMM can be fit to any cyber risk need. You'll see the correct language around "security requirements engineering", "threat assessment" (your risk analysis), "design review" (your threat modeling), and much more explicitly defined and explained within.