if only H and I, or if only H or I? in any case, we can't tell, because we don't know what the dependencies of the other columns are on these two
for example, H could be order number, I could be order timestamp, and on the assumption that no two orders have exactly the same timestamp, either one of them could be the primary key, but if J is product number and K is product name, then K depends on J and not on the key
Store_Item looks like BCNF (although i am not sure, and i'm too lazy to look it up), with Sku, PromoID, and Vendor forming a 3-column composite primary key, and Style and Price depending on the key
same with Software, it looks like another 3-column composite key
They're apparently using Rutherford notation. To translate:
H, I, ----- J, K, M
means that the combination of attributes H and I imply a specific combination of attributes J, K, and M. In database terms, that makes the combination of H and I the primary key. Further translating:
means that the presense of a value for J implies a value for M. Since J is a single attribute instead of a tuple set, this means that the presense of a value for J requires a presense of a value for M. SQL can do this via constraints, but it isn't pretty. A "real world" example of this would be that if a measurement for something is specified (for example a weight or length) as J, the presence of a unit (as M) is required. Early in the use, the contrapositive was assumed (no J enforced no M), however later in use that restriction was frequently ignored.
This notation was often used in Hierarchical Database implementations, but not often for relational implementations.
That weirdness of the notation kind of helps explain why relational folks aren't fond of it. The weirdness makes a lot more sense if you think in Hierarchical terms, where that actually makes sense (in its own, hierarchical way). It is also why I haven't seen Rutherford taught since the mid-to-late 1980s... It was a "blast from the past" to see the notation again.