What you have is a set of specifications, not a set of user stories. They are not the same things, and trying to apply user-story principles to specifications isn't likely to get you where you want to go.
In addition, you are misunderstanding what "negotiable" means. Negotiable doesn't mean fuzzy or ambiguous objectives; it means the details of a story (or even its inclusion in the scope) can be negotiated between the story owner and the development team for optimal results.
User stories are independent vertical slices of functionality. For example:
As a customer
I can select coffee or milk
as my beverage base.
As a customer
I can select milk, chocolate, or sugar
as extra ingredients to add to my beverage base.
These are user stories because they have a point of view, a testable feature description, and some context. While the product has some clear dependencies (e.g. you wouldn't find it useful to vend sugar without a base beverage) implementing the selection features could be done independently.
"Negotiable" doesn't mean a story is ambiguous or ill-defined. Using an example from one of the stories above, negotiable means that the Product Owner and the Development Team can negotiate about:
- The priority or ordering of the stories. Perhaps it makes sense to select a base beverage before adding extra ingredients.
- The content of the story. Perhaps the team thinks adding Stevia to the list of ingredients is a good idea, or thinks that adding a separate "hot chocolate" story makes more sense than multiple stories about milk and chocolate.
- The size of a story. Maybe ingredients should each be in their own stories.
- The scope of a story. Maybe milk should be left out of one story or another, as adding milk as both a base and an ingredient is harder than expected because of architectural decisions made earlier in the project.
In other words, negotiability is primarily a function of the process. It is only a function of the story itself insofar as ensuring the story isn't so prescriptive that it can't be successfully implemented within a single iteration.
The INVEST mnemonic can help you write better user stories, but they aren't an iron shackle. The real issue here is that you need to fix your process so that you're actually generating user stories rather than complex, entangled specifications.
Each of your existing stories should be decomposed further, and then re-examined against the INVEST principles to see if they provide a more agile set of inputs to your project. Lather, rinse, and repeat until you've achieved a Product Backlog that meets your organizational goals and that works well with your team's development process.