There is no single "best" analysis process.  Your goal as a systems analyst should be to learn a number of different techniques for conveying the requirements of your system or report to the develop in a clear and unambiguous way.  It sounds like you are already writing project charter or scope documents of some kind.  You also mentioned use cases which is a great start to documenting functional requirements (don't forget there will be non-functional requirements to capture as well).

Here is an example of a sample analysis process you could follow:

1. Understand the high-level scope of the system you are developing.  This could be done in a Scope Document/Project Charter, etc.
2. Model the "things" of the business domain in which you are developin your system.  Ideally, this will be some form of a business entitiy model.  These are often created used a UML Class Diagram notation where each class is a business entity, and the attributes of the class or the defining characterstics of the entity.
3. Describe each entity of yoiur business entity model in a business glossary. This helps create a clear and common vocabulary for all to use, eliminating confusion between teams.
4. Develop a use case diagram (before writing any use cases).  The use case diagram helps organize at a high-level how the system will meet the users needs.
5. Write use case specifications iteratively to capture functional requirements.  I emphasize interatively because this is the biggest mistake I see analysts make.  Use cases work best when they are slowly evolved from a brief description, to a outline of the main flow and most important alternative flows.  Once the highest priority use cases have been outlined you can then begin detailed out your fully-described use cases. Following this interative process leads to more well organized use cases and far less rework of use case specifications over time. (See the Use Cases category in the Modern Analyst Interview Questions for the different levels and formats of a use case). Remember, use cases are to document the functional requirements or "what" the system should do.  They should never refer to physical screen design.  Save this for the functional specification.
6. Create a list of non-functional requirements.  Typically this list will be categorized by the different types of non-functional requirements that may exist such as usability, reliability, interoperability, scalability, extensibility, security, etc.
7. Document screen design and behavior in a functional specification.  Some groups include their use cases within the functional specification document.  That's fine, it really is arbitrary whether to put them together or not.  I like to keep them separate only because the functional spec gets so large and by keeping them separate I can organize information more effectively.  The functional spec often is used to outline the screen design, the variations that can occur on the screen and under what conditions these variations occur.  Specific events such as the behavior that will occur on a click of a button or selection of a dropdown should be documented.  Additionally, the data that populates in a screen and its controls and how that data is saved should be documented.  Whenever possible the functional specs should describe the behavior of the system in logical terms so that the physical solution that the developers will implement is not constrained.  Though the functional spec will inevitably contain some physical description such as the screens that will be built.
8. Some systems analysts will also be responsible for create test cases.  Use the use case scenarios as a foundation for developing your test cases.

This is just one example of an analysis process.  Each organization will approach things in a slightly different way.