Your business analysis should break the requirements into four major core components: data, processes, external agents/actors, and business rules. A process is something a person or thing does that gets stuff done. It’s the collection of individual steps, activities, or other processes that together transform data and achieve an end goal (for example, “pay vendor invoice” or “find a local doctor”).
Processes and use cases (written accounts of the sequence of steps performed by a user of an application to accomplish a complete business transaction) may be implemented as programs, modules, screens, or reports and can be manual (people perform each individual step) or electronic (systems perform each step).
More and more, processes have elements of both, where a person does some part of the process and systems or technology does other parts, such as “balance checking account.”
Process requirements can be documented and represented in many forms. Use cases are a popular technique for process definition, but other techniques such as user stories, process flow diagrams, or workflow models are equally, if not more, useful depending on the need or documentation audience.
Whichever techniques you use for requirements, the processes and use cases identified in those requirements are named with a verb phrase: verb and noun, where the verb is the transformation activity being performed, and the noun is the thing or piece of data being transformed.
In technology-based processes, the documentation assures that modules and methods talking to the computer can access the right data, perform the right calculations, print reports, display screens, or correctly transmit information needed.
In manual processes, documentation gives the people who will be performing those activities an idea about what needs to be done, what steps to take, and what data to access or provide. It also helps with actor identification, data calculations, and error or business rule checking.
