Writing Quality Business Requirements & Business Rules

October 2011 PM @ DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger

2

Gathering/Documenting/Reviewing Business Requirements and Rules A very important part of a project !

The most interesting part of a project !

The hardest part of a project !

3

4

Definitions

“A

business 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.”

“A

business 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

5

Where do you find Requirements?

Project Origination • Business

Case

• Legislation • Regulations • Estimates Initiation • Project Team,

Sponsor, Stakeholders

• Charter • Scope Planning • Business

Modeling 1.

2.

3.

4.

5.

Swim lane flow charts Functional decomposition diagrams Data flow diagrams Logical data models Use Case diagrams

6

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) 7

Where do you find Business Rules?

Current manual or automated processes Project Team, Sponsor, Stakeholders Legislation Commissioners' Regulations Federal or State Regulations 8

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 9

Characteristics of quality business requirements & rules



Correct



Verifiable



Clear & concise



Complete



Consistent



Traceable



Feasible/Viable



Necessary



Prioritized



Free of implementation details

10

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) 11

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.

12

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 13

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 14

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) 15

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. 16

Complete

A requirement or rule that is complete qualities: will have the following      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 17

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 18

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 19

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. 20

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 21

Traceable

Business Requirements

ID No.

Function - Feature Requirement

G-1 A bicycle license service must be added to MyDMV.

Users Prior ity Origin

Public H Bus Case

Related Business Rules

1.1.1

Excerpts from the Business Rules document

1.1.1 A new service called ‘My Bicycle License Service Center’ will be added to MyDMV. G-2 The new MyDMV Bicycle license service must include the process for a user to complete the required bicycle safety exam online.

G-3 The new MyDMV Bicycle license service must include the process for a user to complete a request for an original bicycle license online.

Public Public H H Bus Case Bus Case 1.1.2

1.1.3

1.1.2 A bicycle safety exam must be available in the ‘My Bicycle License Service Center’. 1.1.3 An original license transaction will be allowed only if the client also holds a valid or renewable NDID or Driver License.

22

Viable or feasible

A requirement or rule that is viable/feasible qualities: has the following     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 23

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.

24

Necessary

A requirement or rule that is qualities: necessary has the following       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 25

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 . 26

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.

27

Prioritized

ID No.

Function - Feature Requirement

UR-1 It is critical for the customer to have a way to cancel the transaction.

UR-2 It is important for the customer to be able to change their order.

UR-3 It is important to provide alternate methods of payment for the customer to choose

Users Priority

Public Public Public

H L M Origin

Bus Case

Related Business Rules

1.1

Scope Users 1.2.1

1.3

28

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.

29

Free of Implementation Details

A requirement or rule that is free of implementation details the following qualities: has     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 30

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. 31

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.

32

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.).

33

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).

34

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.

35

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?

36

Ambiguous terms to avoid

Ambiguous Terms

acceptable, adequate

Ways to Improve Them

Define what constitutes acceptability and how the system can judge this. as much as practicable at least, at a minimum, not more than, not to exceed between depends on efficient Don't leave it up to the developers to determine what's practicable. Make it a TBD and set a date to find out Specify acceptable minimum and maximum values. Define whether the end points are included in the range. Describe the nature of the dependency. Does another system provide input to this system, must other software be installed before your software can run, or does your system rely on another one to perform some calculations or services? Define how efficiently the system uses resources, how quickly it performs specific operations, or how easy it is for people to use. Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003 37

Ambiguous terms to avoid, cont.

Ambiguous Terms

flexible

Ways to Improve Them

Describe the ways in which the system must change in response to changing conditions or business needs.

improved, better, faster, superior Quantify how much better or faster constitutes adequate improvement in a specific functional area. including, including but not limited to, and so on, such as, etc.

maximize, minimize, optimize normally, ideally optionally reasonable, when necessary, where appropriate The list of items should include all possibilities. Otherwise, it can't be used for design or testing. State the maximum and minimum acceptable values of some parameter. Also describe the system's behavior under abnormal or non-ideal conditions.

Clarify whether this means a system choice, a user choice, or a developer choice.

Explain how to make this judgment Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003 38

Ambiguous terms to avoid, cont.

Ambiguous Terms

robust seamless, transparent, graceful several shouldn't

Ways to Improve Them

Define how the system is to handle exceptions and respond to unexpected operating conditions. Translate the user's expectations into specific observable product characteristics. State how many, or provide the minimum and maximum bounds of a range. Try to state requirements as positives, describing what the system will do Define what this means. state-of-the-art sufficient support, enable user-friendly, simple, easy Specify how much of something constitutes sufficiency Define exactly what functions the system will perform that constitute supporting some capability. Describe system characteristics that will achieve the customer's usage needs and usability expectations Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003 39