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

2

3

The hardest part of a project !

A very important part of a project ! The most

interesting part of a project !

4

“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

6

1. Swim lane flow charts 2. Functional decomposition

diagrams 3. Data flow diagrams 4. Logical data models 5. Use Case diagrams

1. Swim lane flow charts 2. Functional decomposition

diagrams 3. Data flow diagrams 4. Logical data models 5. Use Case diagrams

Business Requirements:

The overall expectations of the system from the business perspective  The higher-level statements of the goals, objectives, or needs of the enterpriseA condition or capability needed by a stakeholder to solve a problem or achieve an objectiveA condition or capability that must be met or possessed by a solution to satisfy a contract, standard, specification or other formally imposed documentsAble to describe current or future state (as-is or to-be)

7

8

Business Rules:Are more precise, and generally fall under business requirementsCan translate into specific code that validates data entered or enforces desired behavior from the userDescribe what may or may not be done in a specific scenarioProvides the criteria, conditions and exceptions for a scenarioCan exist independent of requirementsEnforce policyDetermine when information may change or when values are valid How decisions are made in a processA change in a rule can mean different or additional requirements

9

CorrectVerifiableClear & conciseCompleteConsistentTraceable

Feasible/ViableNecessaryPrioritizedFree of implementation

details

10

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

From this:

The system must allow a customer to register for a test.

12

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.

A requirement or rule that is verifiable has the following qualities:

possible to observe and evaluate whether the system met the requirementstated so that it can be tested by

inspection, analysis, or demonstration

13

From this:

The system must be user friendly.

14

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

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 partseasily read and understood by non technical peopleUnambiguous; not susceptible to numerous interpretationsdoes not contain definitions, descriptions of its use, or reasons for its needable to be clearly understand by someone moderately familiar with the businessavoids the use of jargon (unless defined in the glossary)

15

From this:

Most screens must appear on the monitor quickly.

16

To this:

The data summary screen must appear on the monitor within 3 seconds of the user accessing it.

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 addressleaves 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 verifiablewhere applicable, includes anticipated timeframeswritten using complete sentences that reflect a full thought

17

From this:

The battery backup must support normal operations.

18

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

A consistent requirement or rule has the following qualities:

does not conflict with other requirements/rules OR with the business processsame terminology used throughoutdoes not create duplication or redundancy among the requirements or rules

19

From this:Business RequirementThe electronic batch records must be Section 11 compliant.Business RuleAn ongoing training program for 21 CFR Part 11 must be established at the sites.

20

To this:Business RequirementThe electronic batch records must be 21 CFR Part 11 compliant.Business RuleAn ongoing training program for 21 CFR Part 11 must be established at the sites.

A requirement or rule that is traceable has the following qualities:

cannot be separated or broken into smaller requirementssource 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 sessioncan be traced through to specification, design, and testing

21

22

Business Requirements          ID No.

Function - Feature - Requirement

Users Priority

Origin Related Business

Rules

Excerpts from the Business Rules document

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

Public H Bus Case

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

Public H Bus Case

1.1.2 1.1.2 A bicycle safety exam must be available in the ‘My Bicycle License Service Center’.

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 H Bus Case

1.1.3 1.1.3 An original license transaction will be allowed only if the client also holds a valid or renewable NDID or Driver License.

A requirement or rule that is viable/feasible has the following qualities:

can be achieved within the budgetcan be achieved within the schedulecan be achieved using existing process/technology or process/technology included in the projectsomething the organization has the necessary skills to implement and utilize

23

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.

24

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.

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 systemleads to a deficiency if removedcomes from a source that has authority to specify requirements and can be traced to its source will be usedmight be needed to conform to an external requirement or standard

25

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 .

26

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 .

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 projectdoes not try to “fix” existing problems that are not in scope of the projectusually 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

28

ID No.

Function - Feature - Requirement

Users Priority Origin Related Business

RulesUR-1 It is critical for the

customer to have a way to cancel the transaction.

Public H Bus Case 1.1

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

Public L Scope 1.2.1

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

Public M Users 1.3

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

A requirement or rule that is free of implementation details has the following qualities:

defines what functionality will be provided by the systemdoes not specify how that functionality can or should be implementedallows the system developer to determine which technology is best suited to achieve the desired functionalityuses business terminology NOT technical terminology

30

From this:The system will run a Java Script when the customer clicks the “Submit” button.

31

To this:The system will process the order after the customer indicates that the order is complete.

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.

Keep sentences and paragraphs short.

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.

32

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

Create User scenarios or prototypes to illustrate the requirement(s)/rule(s).

Write test cases that will verify the requirement(s)/rule(s).

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

34

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

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 Ways to Improve Them

acceptable, adequate Define what constitutes acceptability and how the system can judge this.

as much as practicable Don't leave it up to the developers to determine what's practicable. Make it a TBD and set a date to find out

at least, at a minimum, not more than, not to exceed

Specify acceptable minimum and maximum values.

between Define whether the end points are included in the range.

depends on 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?

efficient 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 Ways to Improve Them

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

The list of items should include all possibilities. Otherwise, it can't be used for design or testing.

maximize, minimize, optimize State the maximum and minimum acceptable values of some parameter.

normally, ideally Also describe the system's behavior under abnormal or non-ideal conditions.

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

reasonable, when necessary, where appropriate

Explain how to make this judgment

Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

38

Ambiguous Terms Ways to Improve Them

robust Define how the system is to handle exceptions and respond to unexpected operating conditions.

seamless, transparent, graceful Translate the user's expectations into specific observable product characteristics.

several State how many, or provide the minimum and maximum bounds of a range.

shouldn't Try to state requirements as positives, describing what the system will do

state-of-the-art Define what this means.

sufficient Specify how much of something constitutes sufficiency

support, enable Define exactly what functions the system will perform that constitute supporting some capability.

user-friendly, simple, easy 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