One of the practices of Agile Teams, that you might have heard of and is very popular, is writing “user stories”. A very important part of the User Story is the absence of the HOW. A good user story is one with no HOW.
For the Business Analysts (BAs) audience, user stories will resemble Business Requirement Document (BRD). I usually get that talking to BAs about user stories. A good point to bring up comparing the user stories to BRDs is that there is no HOW in both of them.
Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on what is required, rather than on how to achieve it, which is usually delegated to a Systems Requirements Specification or Document (SRS or SRD) or other variation such as a Functional Specification Document.
Agile has 4 values and 12 principles. If you look at the history of software development, you will find that these values and principles are not something out of ordinary for its time. These are basically a collection of better practices put together, which is well thought through. Nevertheless, there might be new slogans and names used for them (and for a reason).
My advice is not to simply forget the practices in place all at once and try to learn from scratch. Ask yourself, why there was a process existed and if it is important to continue having that or not. Agile is about knowing what and why to do to get to the goal more effectively. Ask yourself, why there is no HOW in BRD before questioning why there is no HOW in user stories. What would be the reason(s) that we leave the HOW for other people to figure it out?