Something I have been struggling to wrap my head around is a conceptual structure for all the different kinds of requirements that could feature on a software project.
Go to any renowned resource on BA skills and you will typically see the discussion of business requirements, user requirements, functional & non-functional requirements. To understand & document the user requirements, it is almost ubiqitously recommended to use techniques such as process modelling, use cases or user stories. This makes sense,to a degree, because an obvious place to start is what do the users actually need to be able to do with the solution.
But where this falls down in my mind is that systems may need to do many things that are not a user 'doing something' via a user interface. For example it may need to send a 'leave a review' email to customers one month after their order dispatch date. In fact, I've worked on multiple projects where there are no human users at all, and the system just exchanges data with other software systems and executes workflow (and I refuse to go down the semantic rabbit hole of saying systems are people, or the people the pay for the system are still users etc.).
I guess what I'm driving at is that a lot of the existing resources/literature seems to focus so heavily on what the user needs to do - considering their processes and the tasks they perform. But that's only part of the reality of building software.
I'm keen to understand where people start or what conceptual framework they use to approach requirements which have nothing to do with a user actuallly doing something. Or where they'd start on a project for a system which didn't even have human users.
Also a side question - given the rise of agile, how do people reconcile use cases with user stories. Has anyone had success using use case approach on a scrum project, for example? The two seem to be wildly different techniques in terms of scope, but people often talk about them as though they are achieving the same thing.