In the work that I do I have to clearly define the difference between what the business process will do (customers, workers, users, etc.) and what the software itself will do. In addition, I have to know what each of the "tiers" (database, server, front end, etc.) of software will do. In all, my job is to clearly define an "activity system" and what all of the actors in that activity system are going to do (and why).
A good tool in this that I learned for Agile Coach Rod Claar is to write your use cases / scenarios / stories in the following format:
<Actor> can <Function> so that <Business Value>.
This is an important pattern for people at all levels of the organization to understand.
The Actor is the person or system or entity that is doing something; your system will have a finite amount of these; the business analyst will have to determine what roles the system tiers will play and what the business people and users will play, it's a big undertaking.
The Function is the thing that the role is going to do. It should be written as an activity.
The Business Value is the *reason / justification* for the actor to do the function. It is the thing that *should* allow people to assign priority and determine what's next. It is the context and is very important.
Aside from these three process characteristics of actor, function, and business value, there are other parameters such as:
- Inputs
- Outputs
- Time
- Success criteria
- Failure modes
There are many parts and aspects of the system that we have to take into account when designing one.
