First, don't get too invested in following the formalism to the tee, it's more important to capture the the needs of the business and get on with the work then to obsess with how exactly it should be done.
That said, the user story format is:
As a <user in some business role>
I want <to do something>
so that <I can get some business value>.
The reason is that you want to understand what they are actually after, rather then just accept a specification from them; the idea is that you are there to provide your expertise and solve a problem for them, not to execute a set of instructions. You want to find out why the user wants that something done in a wider context of their business goals - so that you can build the right thing.
When it comes to value, you have to think in terms of the bussines/domain value it provides for the user. Also, don't think about the user role as some generic role defined by the system, or a job title, but rather think in terms of what it means in the context of the business (or whatever the endeavor in question).
As an administrator (what does that role actually entail?),
I want to define a model
(if you all understand what a "model" is in this context,
you don't need to go into more detail than that; describe intent, not the feature)
so that (what?).
The "what" (value) part could be something like: my subordinates can proceed with their work. Now, I'm making that up, of course, and it's probably not a best example of a "business value". But maybe it is; maybe their business currently has a bottleneck when it comes to producing these models, and the employees are mostly sitting around waiting, so they see business value in removing this bottleneck? Again, I'm making this up, but, it is important to obtain this information. However, you can't guess this - you have to talk to your customers / domain experts (users or their bosses), and ask them what the value is (and maybe you'll need to steer the conversation a bit in order to extract this information - ask a lot of "why" questions).
Next, the "independence" bit: stories should be independent enough so that you can move them up and down the priority queue; so don't think "independent in functionality", but rather can you work independently on them following your usual development practices that let you do cool things like use mock data, fake services, etc.
Finally, what does "small" mean?
Small enough to be confident that it can be done within a couple of days, or maybe a week, using the simplest approach possible. Something that will let the user achieve their goal in the simplest way; it may be just the bare bone features, and it may look ugly, but the goal is to be usable so that they can get their value from it. And if you didn't capture what's the value in the story, you can't be sure that you are delivering it.
And, yes, it may take some time, but it shouldn't take, like, a month - if it looks like it might, split it into smaller independent peaces of work (you don't have to do them all in the same sprint - that's something to negotiate).
Note that once you have the initial stories captured so that you have a good understanding of the business needs, as you are dealing with the backlog over time, you can refine them, split and negotiate them as the need arises according to whatever organizational strategy your team uses within the process.
Because you have captured the value and because you are expanding your understanding of the domain constantly, and because you have access to domain experts, you (your team) are the one(s) who are in the best position to make decisions about what is the best way to do all these things, in a way that delivers the most value to the business, and the most important value first (so that if they decide to wrap up the project at some point, they get their most important business needs met). Except for general advice, nobody can really make these decisions but you (the team), and if you can't, then either go "pester"1 the domain experts until you have enough understanding so that you can, or build something small, get feedback, and learn from it for the next round (or do both).
Once you commit to a story and start getting into technical details, drop the story format; the story is there to provide context.
1 Don't really pester them; you want them to be cooperative :)