Any software testing is to be based on its agreed functionality. When the business requirement for a system or a part of the system, or a change is given by the business client, it is analysed, documented and the business analyst gets a confirmation or sign off from the business client. This would be the agreed business requirements. This includes usually any provisos, risks or assumptions.
The system analyst then design the system and defines how the system or the change is built. It may happen that a part of the requirement may not be suitable to be automated or be able to be completely satisfied according to the requirements. The analyst of course would need to suggest alternatives in some cases and his/her owen recommendations.
Then the relevant parties need to agree for a particular system solution. Then this would be the basis for the s/w testing.
The test analyst needs to look at the system from the top, divide it logically by areas, functions or in any suitable way. This assists in developing a test strategy, structuring the test plan, then writing individual test cases.
The test plan should say how each part needs to be tested.
Then the test scenarios and test cases are developed. Usually the scenarios and test cases are put into a data base to assist in re-use. Normally you do not write a test case newly for every test. You will re-use or modify an existing one for a given sitation.
The test cases are built from the business scenarios – what happens in reality, then added for additional abnormal situations. The system test would be to test the system to an extreme level. But the user acceptance test (or UAT) is for business scenarios and not to the extreme level of system test.