Sorry this is a long post! TLDR; at the bottom.

Hey guys, I just recently got a new job as a Business Analyst at a new government department. I previously worked as a developer of an enterprise system and have decided to make the switch over to the BA role. 

Now I am at a new department, new team, and I have a scary new career of which I know nothing about. I was hired for my IT experience and they needed someone to gather requirements for a new enterprise application that has yet to be implemented. I also showed initiative in the interview that I am willing to learn in my new role, so I guess that's why I got the job even though I don't have the experience yet.

A little background on this new project I'm on: My section consists of several developers on different teams supporting several different applications. Some of these applications are being used in different regions. Currently, there is no system to track bug reports or for end users to easily request for a new service to be done. It's all done through emails. The product they want to implement, and for which I am responsible for gathering requirements and delivering, is a new ticketing application for managers and developers to use in order to manage service requests for support.

One month in I am still completely lost. My supervisor would like me to create a requirements document so I researched on what a BRD was and how to write one. But that proved to be pretty difficult at the start. Initial meetings with dev team leads were awkward. They didn't really care much about the product. They were happy with their current process of managing everything through emails. The product was kind of forced on them by the section manager. So requirement meetings were a little challenging. They wanted to see a demo of the product so they can get a better idea of what they want, but I barely know the product (since I'm still new) and I'm having my own challenges trying to get any information from the one (and only) developer who is developing this new product.

Activities I've done so far:

• Identified who the stakeholders are
• Attended an initial requirements meeting with some of the stakeholders and asked about their current processes
• Attempted to write a BRD (then realized it was too early on in this stage)
• Read up on some documentation on the product
• Working with the one developer to strip the product down from its out-of-the-box version to something I can demo for the clients

Challenges:

• Stakeholders aren't forthcoming and are generally uninterested in the product being implemented
• Timelines: This project has been sitting for almost 8 months when I joined. My manager would like to get this out in the next 3 months or so. Seems unrealistic!
• Documentation: There so many documents to write, and no clue where to start!
• Small team with little support. It consists of me (the BA), my manager (responsible for managing this project), and the developer. That's it! There isn't even a QA team. I suspect I will be the one doing the testing.

TLDR; So in summary, I am a former developer joining a new team as BA with zero experience in the field.

Any help on where I should go from here is much appreciated!

Thanks!

Nobee

That's great. Yes, it definitely helps. The challenges you mentioned about creating a BRD in an unstructured environment is exactly the kind of thing I encountered when I tried to write one.

Okay, creating user stories seems like the best approach. I'll try it that way. Now, is this similar to a use-case? I just came off a 4-day BA course this week and there was a heavy emphasis on business use-cases and system use-cases. From the business use-case, we derive the system use-case, and then from the system use-case, we determine the basic flow. I'm just trying to get all these documents straight in my head so that I am not duplicating information. It's very confusing at this stage, and a lot of documentation seem to blend in together and overlap.

Thanks for the help!