How are you other BA's handling technical request/changes to scripts that have no effects on the end user?
This is something that often pops up in the real work that boils down to the similarities and differences between what're known as user requirements and system requirements.
As you can see, system requirements can be broken down into functional and non-functional requirements themselves. That said, even system requirements should have acceptance criteria (just like user requirements) to denote what the work should ultimately result in.
User stories can, in theory, be used to capture acceptance criteria for both functional and non-functional system requirements. Capturing these requirements in the backlog provides transparency into what's being worked on, the value it's projected to provide, and the level of effort the team has forecasted for the work relative to other work items.
So long as the acceptance criteria is present, the team has a goal to test against and build for in order to provide value.
At the end of the day, use what makes sense but make sure the goals for the new requirements are captured so the team has something to shoot for before calling it "done".