Business analysis identifies business needs and determines solutions to business problems — the solution may not be software at all; requirements engineering is the narrower process of formulating, documenting and maintaining a system's software requirements.

* Requirements engineering is the software-shaped subset of business analysis — the other three solutions never produce a software requirement at all. *

The two are nested rather than rival, and the difference is how far back the question starts:

• Business analysis is a research discipline of identifying business needs and determining solutions to business problems. Solutions often include a software-systems development component, but may also consist of process improvement, organisational change, or strategic planning and policy development. So a business analyst is allowed to reach the conclusion "you do not need software here — you need to change who signs off on the invoice."
• Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements, and to the subfield of software engineering concerned with that process. It takes over once a system is (part of) the answer, and its output is a specification someone can build against.

The consequence for practice: a project that jumps straight into requirements engineering has silently already accepted that software is the solution. That is often right, but it is an assumption — and it is the assumption behind a lot of expensive systems that automated a process nobody should have been running.

Tip: "Requirements engineering" names both a process and an academic subfield, which is why the same phrase can describe what someone did last Tuesday and what a research group studies. In day-to-day project life the roles blur, and one person often wears both hats — which is why "business analyst" and "requirements engineer" get used almost interchangeably.

Go deeper:

• Business analysis (Wikipedia) — the wider discipline, including the solutions that are not software.

Attach a countermeasure to each attack path, cost it out, then prioritise the ones that block the most (or cheapest) paths.

Countermeasures in Attack Trees:

• Shown as green boxes that block attack paths
• Dotted lines = attack paths that are blocked by countermeasures

Example - "Guess Password" tree:

Process:

1. Build the attack tree
2. Identify countermeasures for each path
3. Cost-benefit analysis of implementing each countermeasure
4. Prioritize based on which countermeasures block the most/cheapest attack paths