The fact table is the only table with measures by definition, it has to be defined what measures we have.
So each measure column like Revenue, Quantity,... every column is right clicked one after the other and added to the list of measures by that.
Each measure has a name and will be a basic measure. Calculated measures are defined later, they allow simple arithmetic of basic measures, e.g. sum(revenue) is one basic measure, count(employee) the other measure and the calculation measure1/measure2 = sum(revenue)/count(employee) is the revenue per headcount. Note that calculations on row level, e.g. value=price*quantity are not supported by BWA on the fly. These have to be added into the ETL flow of DataServices and are calculated when loading the BWA.
The most important setting of a measure is its aggregation formula, is it sum(), avg(), count(), or whatever
The other interesting thing with measures is unit conversion. Right now we would aggregate 10 tons with 5 pounds returning 15????, but if there is a unit conversion table available, the conversion into one unit can be done on the fly. With quantities it is less important as these would probably be converted during the BWA load anyhow and some quantities cannot be converted anyhow, 3 pieces plus 5 gallons are what? But with currencies and they changing exchange rates you have the option, either convert using a specific date and deal with that in the ETL flow or used today's exchange rate. It really depends on whom the data is shown to. If you have 100EUR and 100USD and you ask the sales person about the revenue, he will say "I made 250USD because of the conversation rate at that time". A Financial person will say "We have two bank accounts, one for USD one for EUR and by today we have 150USD".
With the measures defined, we need to tell what columns should be shown as dimensions and how.