Writing Quality Business Requirements & Business Rules

1. Writing Quality Business Requirements & Business Rules October 2011 PM @ DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger

3. Gathering/Documenting/ReviewingBusiness Requirements and Rules A very important part of a project ! The most interesting part of a project ! The hardest part of a project !

4. TOPICS Definitions Where do Requirements and Rules come from? Characteristics of Quality Requirements and Rules Best Practices

5. Definitions “Abusiness requirement is a higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements.” “Abusiness rule is a specific, actionable, testable, directive that is under the control of the business and supports a business policy.” Definitions are quoted from the Business Analyst’s Book of Knowledge [BABOK]Guide, Version 2.0

6. Where do you find Requirements? Swim lane flow charts Functional decomposition diagrams Data flow diagrams Logical data models Use Case diagrams

7. Business Requirements continued Business Requirements: • The overall expectations of the system from the business perspective   • The higher-level statements of the goals, objectives, or needs of the enterprise • A condition or capability needed by a stakeholder to solve a problem or achieve an objective • A condition or capability that must be met or possessed by a solution to satisfy a contract, standard, specification or other formally imposed documents • Able to describe current or future state (as-is or to-be)

8. Where do you find Business Rules?

9. Business Rules continued Business Rules: • Are more precise, and generally fall under business requirements • Can translate into specific code that validates data entered or enforces desired behavior from the user • Describe what may or may not be done in a specific scenario • Provides the criteria, conditions and exceptions for a scenario • Can exist independent of requirements • Enforce policy • Determine when information may change or when values are valid • How decisions are made in a process • A change in a rule can mean different or additional requirements

10. Characteristics of qualitybusiness requirements & rules • Correct • Verifiable • Clear & concise • Complete • Consistent • Traceable • Feasible/Viable • Necessary • Prioritized • Free of implementation details

11. Correct A requirement or rule that is correct has the following qualities: • accurately describes the functionality to be delivered • does not conflict with any business process • does not contradict itself or any other requirement or rule • passes inspection (walk-through or user review) • based on knowledge of the business process Best practice…. contains a reference to the source of the requirement or rule (customer, stakeholder, or higher level system requirement)

12. Correct From this: The system must allow a customer to register for a test. To this: When a customer registers for a test, the system must provide a list of tests from which the customer will be allowed to choose only one.

13. Verifiable A requirement or rule that is verifiable has the following qualities: • possible to observe and evaluate whether the system met the requirement • stated so that it can be tested by • inspection, • analysis, or • demonstration

14. Verifiable From this: The system must be user friendly. To this: 1. The user interface must be menu-driven. 1.1 The user interface must provide all of the following features to assist the user with correct input * dialog boxes * help screens * radio buttons * drop-down list boxes

15. Clear & Concise A requirement or rule that is clear and concise has the following qualities: • ‘atomic’ (consisting of a single requirement) meaning it cannot be broken into smaller parts • easily read and understood by non technical people • Unambiguous; not susceptible to numerous interpretations • does not contain definitions, descriptions of its use, or reasons for its need • able to be clearly understand by someone moderately familiar with the business • avoids the use of jargon (unless defined in the glossary)

16. Clear & Concise From this: Most screens must appear on the monitor quickly. To this: The data summary screen must appear on the monitor within 3 seconds of the user accessing it.

17. Complete A requirement or rule that is complete will have the following qualities: • contains all the information needed to define the system function that it is intended to address • leaves no one guessing (for how long? 50% of what?) • where applicable, includes measurement units (inches or centimeters?) to aid in testing correctness and make it verifiable • where applicable, includes anticipated timeframes • written using complete sentences that reflect a full thought

18. Complete From this: The battery backup must support normal operations. To this: 1. The battery backup must support normal operations for 20 minutes. 1.1 Under a power outage situation, normal operations consists of all tasks related to serving customers. 1.2 Under a power outage situation, normal operations does not include: * running queries * backups * batch jobs

19. Consistent A consistent requirement or rule has the following qualities: • does not conflict with other requirements/rules OR with the business process • same terminology used throughout • does not create duplication or redundancy among the requirements or rules

20. Consistent From this: Business Requirement The electronic batch records must be Section 11 compliant. Business Rule An ongoing training program for 21 CFR Part 11 must be established at the sites. To this: Business Requirement The electronic batch records must be 21 CFR Part 11 compliant. Business Rule An ongoing training program for 21 CFR Part 11 must be established at the sites.

21. Traceable A requirement or rule that is traceable has the following qualities: • cannot be separated or broken into smaller requirements • source of the requirement or rule can be easily identified; it can be traced from Business Case, Charter, Scope or business input during a requirements-gathering or review session • can be traced through to specification, design, and testing

22. Traceable

23. Viable or feasible A requirement or rule that is viable/feasible has the following qualities: • can be achieved within the budget • can be achieved within the schedule • can be achieved using existing process/technology or process/technology included in the project • something the organization has the necessary skills to implement and utilize

24. Viable or feasible From this: 1.1 The replacement control system must be installed no later than 2 days after it arrives on-site. 1.2 The replacement control system must be installed with no disruption to service. To this: 1.1 The replacement control system must be installed no later than 48 hours after it arrives on-site 1.1.1 The 48 hours timeframe excludes weekends and Holidays. 1.2 The replacement control system must be installed causing no more than 12 hours of production disruption.

25. Necessary A requirement or rule that is necessary has the following qualities: • meets an objective but does not ‘gold-plate’ • critical for the operation of the system • leads to a deficiency if removed • comes from a source that has authority to specify requirements and can be traced to its source • will be used • might be needed to conform to an external requirement or standard

26. Necessary From this: 1. Baggage checks must be conducted as one part of terminal security precautions. 1.1 All travelers must submit to a baggage check . To this: 1. Baggage checks must be conducted as one part of terminal security precautions. 1.1 Travelers will be chosen at random for a baggage check .

27. Prioritized A requirement or rule that is prioritized has the following qualities: • answers the question “How essential is the requirement to the customer?” (eg-high, medium, low) • assists with decision making should time, costs or other priorities impact the project • does not try to “fix” existing problems that are not in scope of the project • usually reflects the relative value, cost and possibly risk involved For example – a “low” priority might have to be shelved if insufficient time or resources comes into play Customers have the lion’s share of the responsibility for establishing priorities. Priority is usually determined by the business team.

28. Prioritized

29. Additional notes on prioritization excerpted from the BABOK Prioritization can be based on a number of different criteria, including: • Business value – cost-benefit analysis of relative value to the organization. Target most valuable to develop first. Often used when there is incremental development. • Business or technical risk – selects those that present the highest risk of project failure. By selecting these first, the failure would occur after the least amount of expenditure possible. • Implementation difficulty – select those that are easiest to implement. This approach is used during a pilot of new software or a new development process so that the team can gain knowledge quickly, or to provide ‘quick wins’. • Likelihood of success – select those that are likely to result in quick and certain success. This is often used for a proof-of-concept when a project is controversial and early signs of progress/success are needed to gain support. • Regulatory or policy compliance – focus on those that must be implemented in order to meet regulatory or policy demands that may take precedence over other stakeholder interests. • Relationship to other requirements – if it is not of high value on its own, but is necessary because it supports or is critical for other high priority requirements/rules. • Stakeholder agreement – stakeholders reach consensus on which are most useful/valuable. May be used in conjunction with others above.

30. Free of Implementation Details A requirement or rule that is free of implementation details has the following qualities: • defines what functionality will be provided by the system • does not specify how that functionality can or should be implemented • allows the system developer to determine which technology is best suited to achieve the desired functionality • uses business terminology NOT technical terminology

31. Free of Implementation Details From this: The system will run a Java Script when the customer clicks the “Submit” button. To this: The system will process the order after the customer indicates that the order is complete.

32. Best practices to ensure quality requirements & rules As with all technical writing, there are techniques for writing the sentences used to document business requirements and business rules. Use simple, complete, well-structured sentences. Keep sentences and paragraphs short. Use the active voice. Use proper grammar, spelling, and punctuation. Use terms consistently and define them in a glossary or data dictionary that is part of the Requirements/Rules document. Write individually testable requirements/rules; watch out for multiple requirements/rules lumped together. Avoid redundancy and repetition.

33. Best practices to ensure quality requirements & rules - cont.Sentence Structure Each requirement or rule should be a simple, complete, well-structured sentence that • states one thing and states it well. • does not contain conjunctions (and, or, but …). • does not depend on other sources of information. • contains subject, verb (in the active voice), object, and appropriate modifiers; starts with “The (user, system, department…) will (or must)…”. • avoids using verbs that make the requirement/rule sound optional (should, might, may, could, etc.).

34. Best practices to ensure quality requirements & rules – cont. • Use formal inspections • project team review and sign off by Business Unit Decision Makers, Sponsor and IT Lead • peer review/ PMO staff • stakeholder review • Each requirement/rule should be understood by “knowledge peers” • revise • define • clarify Create User scenarios or prototypes to illustrate the requirement(s)/rule(s). Write test cases that will verify the requirement(s)/rule(s).

35. Best practices to ensure quality requirements & rules – cont. Each requirement/rule should emphasize “what” should be done, not “how” to do it. • avoid preconceived solutions • express the functionality needed • do not document how that functionality will be created • avoid technical terminology as this is most often associated with “how” Functional specifications take over to describe HOW it will be created.

36. Best practices to ensure quality requirements & rules – cont.Self-Check Each requirement/rule should be relevant, unambiguous, and clear. Read through them and ask, • Is this in scope for the project? • Does it define the behavior of a role or the system? • Is there doubt about the meaning of any of the words used? • Does the sentence have a single meaning within the subject area context? • Is the sentence clear to the target audience? • Is there one and only one requirement/rule expressed in this sentence? • Am I left wondering how many, when, or how often? • Are any unfamiliar words explained in a glossary or dictionary that is part of the Business Rules document?

37. Ambiguous terms to avoid Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

38. Ambiguous terms to avoid, cont. Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

39. Ambiguous terms to avoid, cont. Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003