Core Requirements Component: Processes (Use Cases)

A process is a business activity that transforms input (data) into outputs. Many BAs and systems analysts now use the phrase use case interchangeably with process (processes were discussed in Chapter 4). From the perspective of most business stakeholders, processes are the most important requirements. Processes, as a requirements component, are much more difficult to name and define than data. It is easy to recommend that process names start with a verb and include a noun (data), but verbs are much more ambiguous than nouns and activities are much more difficult to describe than things (data). Consider a simple example like receive order. What does the word “receive” imply? Would record order be more descriptive? Receive is passive, whereas record is active. But does either word really describe the work that is done in the business? Would validate order be clearer, or is recording a completely different activity from validating? There are many subtle nuances in the English language, from which these verbs are taken. Deciding which one is the most meaningful for a particular project is very subjective, but there is no denying that processes are one of the most important of the core requirements components.

Process descriptions are important for almost every project in which a BA is involved. The title business analyst comes from the focus on understanding and representing the business, processes being a key component. Processes are analyzed using decomposition diagrams, data flow diagrams, workflow diagrams, and use case descriptions.

Core Requirements Component: External Agents (Actors)

An external agent is a person, organization, or system with which a business area interacts. These external agents are known by many different names: actors, externals, or interfaces. The word external as part of the name is important. BAs must be aware of the scope of a requirements area. Actors are external to the software solution in UML diagrams and are used in use cases.

It is important for analysts to identify external agents for several reasons. Ideally, they are identified during project initiation because knowing all of the external interfaces helps with project planning and estimating. Each external agent must be represented in a project by a stakeholder. These stakeholders are key resources for requirements elicitation. They may be external to the company or just external to the project. When they are external to the company, the analyst may have limited access for requirements elicitation. The larger the number of externals, the longer requirements elicitation, reviews, and approvals will take.

Another important reason to identify external agents is that they may interface with the solution or final outcome of a project. Because their issues and concerns must be addressed in the solution design, their needs (requirements) are very important.

Externals also must be considered when security of data or process is important. Many of the nouns defined as entities will also be external agents. For example, a customer is an external agent because he or she is outside the project, and customer is an entity because there is important information about customers (attributes) that must be stored (first name, last name, etc.) Be sure to use the nouns (i.e., customer and vendor) consistently.