Internal vs. External

There may be people, organizations, or systems that are inside the scope of a project. They would also be considered stakeholders. They can provide requirements because they operate within the business area under study. Systems inside the scope may include existing software applications and manual procedures. It is important to differentiate between external agents and internals because a project does not control the externals but may change the role of the internals. In other words, employees who are inside the business area may have their work changed by a project solution. Roles may change, procedures may change, and systems may change. External agents are called external because they cannot be changed by a project. Customers, vendors, and government agencies are examples of external agents that are not under the control of a project. This is a critical distinction and one that should be made during project initiation activities (project initiation was discussed in Chapter 3).

Core Requirements Component: Business Rules

A business rule is a condition that governs the way work is done. Business rules are typically described with a sentence or two. They may be named or numbered to allow them to be linked or traced to other requirements components. They may start out high level or detailed; either way, the analyst should ask questions to refine the rule to be very specific and clearly written. Business rules are a key requirements component because they frequently tie the other requirements components together. When the rule “an order over $500 gets free shipping” is revealed, it brings together several other requirements components: data (order total amount, shipping charges), process (calculate shipping charge), and external agents (customer, shipper). A great resource on business rules is Business Rules Applied by Barbara von Halle (2003).

Some analysts consider business rules to be “requirements” and others do not. They argue that business rules are constraints of an organization, not “needs.” This is another debate that is important to be aware of so that your communications with other team members are clear. It doesn’t really matter whether or not you consider a business rule to be a requirement. The important part of business analysis is that business rules must be elicited, documented, and confirmed. They may be included in the requirements package or in a separate document.

It is important for the analyst to write business rules carefully. References to data (nouns) must use the exact same nouns as defined in the data requirements. Similarly, verbs must be used consistently with their use in process and use case names. There are some commercially available syntax systems for documenting business rules, such as RuleSpeak (Ross, 2003). In addition, there are software systems called business rule engines that store and execute rules. Rules are very complex, and each organization should have some standards around documenting rules. Rules are often reused in an organization by different departments. This argues for a rules administrator and shared repository. Rules are frequently changed in many organizations, so it is important to clearly define rules and maintain them separately from business processes, use cases, and data structures. While some rules will logically be represented in a data model (entity relationship diagram), most must be described with more detail than can be shown in an entity relationship diagram.