Hi Mohoq,

The definition I use of high level requirements is that they are statements of what the solutiuon must be able to do without any implication of the physical solution. A functional requirement would be a statement of what the computerised solution must be able to do.

In either case, they are statements of something that can be done. Doing something is (in this context) a process.

If you wish to document all the processes of the entire solution (computerised or not) then use high level functional requirements as a starting point. If you only wish to document the computeised processes then use functional requirements.

There is a many to many relationship between high level requirements (or functional requirements) and processes. E.g. The high level requirement "be able to order materials" might as you suggest be satisfied using "order materials" process. But the high level requirement "be able to order the building of a house" might also use the process "order materials" as well as (say) "plan work schedule".  Given this, while you might want to record which requirements are satisfied by which processes (and vice versa) as this is a many to many a table of some sort might be a better solution that noting the processes against the requirements.

Hope this helps.

Guy

It works much better the other way around.

Requirements are, when you boil them down, just statements that are objectively true of the final system. No intrinsic sequence unless you happen to build it in. (This shall happen after that).

A process is a directed graph of activities. Generally you can get the requirements by asking 'what do you do', what doesn't work well, and gathering requirements around the new process. A crucial aspect of processes is that you have inputs, outputs, and invariants. These may or may not have been captured in your requirement set.

Use cases, with the scenarios defined, are also sets of activities. To keep it textual all the paths through are flattened and listed separately. No reason not to represent it as an activity diagram though. The key difference is that it is one actor that walks through the activities (card in the slot, card out of slot, enter pin, select transaction, ...).

It's a little baffeling how you have requirements (unless they are just a list of complaints) without something rather like either a process or a use case.

There should absolutely be tracability from a requirement to it's origin in a process, use case scenario, or other business entitiy and to the classs, packages, or subsystems that satisfy it.