How to become a Business Analyst?
How to become a Business Analyst?
Become a Business Analyst rules represent another type of documentation that should be pulled from use case proper refer to in a dedicated section. Business rules are rules from the business area that constrain business processes. These rules document separately because they would distract from the flow of the use case. Because they often apply to more than one system use case. For example, an airline system might include a rule that the weight of an airplane must never exceed its maximum weight capacity. This rule is active during a number of use cases, for example, Check in passenger and Load cargo. Rather than restate this rule in every use case that it applies to, list it separately as a business rule and refer to the rule from the use cases.
Become a Business Analyst
Business rules may be store the “low-tech” way, for example, in a book. At the other end of the spectrum, are rules engines—software that manages and enforces business rules. Either way, it’s not enough to record the rules—you must also specify which rules apply to which use cases. This makes it easy to identify which use cases need to be tested when a rule changes. When an automated rules engine is used, there is another advantage to linking use cases to a rule. It is inefficient to have the software, at run time, check all business rules for every use case when only some applications.
Why isn’t the Business Analyst’s job over after dynamic analysis?
The dynamic requirements lack a complete description of the “nouns” of the business. Also, the precise numerical relationship between the “nouns” is undefined. You read about a municipality with human resources (HR) system. Because they had not worked out the numerical relationship between employees and unions. they end up purchasing an HR system that allows an employee to belong to only one union. When, in fact, some employees belong to more than one. As a result, the software could make only a single deduction of union dues for each paycheck, the data tables were set up incorrectly. The input screens used to assign employees to unions were incorrect.
Guess who had to pay for all those corrections?
Had the BAs perform a proper static analysis. They would have included the employee-union rule in the requirements documentation, diminishing the chances that it would be missed in the software and ensuring that, at the very least, the cost of the fix would be borne by the developers.
Aren’t these issues addressed in the dynamic analysis?
It is true that many of these issues are contained within the system use-case descriptions. For example, in a banking system, the relationship between customers and accounts might be found in a system use case. Open a new account. However, since dynamic analysis does not include a rigorous approach to examining the “nouns,”. It is likely that some important requirements will be missed. Also, since these rules are dispersed throughout the use cases, there is the possibility for internal inconsistency within the BRD. For example, a system use case Open new account might allow up to three people to co-own an account. While a system use case Query account activity allows for only one owner. In addition, future requirements for enhancements to the system may add new inconsistencies.
What does static analysis have to do with this?
The static analysis focuses on the “nouns” of the system. It provides a rigorous method for ensuring that all of these nouns are fully analyze and documented. Requirements that cut across system use cases but relate to the same classes of objects (nouns) are centralized in a set of diagrams and accompanying documentation. This makes it easier to ensure internal consistency within the BRD. Each system use case description is verify against the static model. As future system use cases are added, these two are a check against the static model, ensuring that business rules are obeyed in future enhancements.