“What colour is the house on the hill?”

Waterloo – Wellington IIBA Chapter presentation

April 11, 2007David Milne

Agenda

• Who am I?

• What’s this stuff about a house on the hill?

• BABOK context

• Avoiding ambiguity

• Audience tips

• Questions

Who am I?

• Systems Analyst at Manulife

• Been a Business Analyst of one kind or another since 1986– DMR– Ernst & Young– City of Kitchener– Manulife

What’s this stuff about a house on the hill?

• Fair Witness

• "It's white on this side".

• “Incorrect interpretation of the requirement; applying personal filters to the information that alter the intent.” 5.11.4.1, page 210

• As analysts we must be like fair witnesses

• http://en.wikipedia.org/wiki/Fair_witness

BABOK context

• Definition of the Business Analyst Role (1.4.1)

• Definition of a requirement (1.4.2)

• Definition of requirements types (1.4.3)

• Task: Verify Requirements (5.11)

Definition of the Business Analyst Role

• A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.

• The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

Definition of a requirement

Requirements vary in intent and in kinds of properties. They can be functions, constraints, or other elements that must be present to meet the needs of the intended stakeholders. …For clarification purposes, a descriptor should always precede requirements; for example, business requirements, user requirements, functional requirements.

Definition of requirements types

• Business requirements

• User requirements

• Functional requirements

• Quality of service requirements

Business requirements

• Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise.

• They describe such things the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success.

User requirements

• User Requirements are statements of the needs of a particular stakeholder or class of stakeholders.

• They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution.

Functional requirements

• Functional Requirements describe the behavior and information that the solution will manage.

• They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.

Quality of service requirements

• Quality of Service Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have.

• They are also known as non-functional or supplementary requirements.

Task: Verify Requirements

• Validate Requirements describes how the Business Analyst determines that the functional and quality of service requirements will fulfill the original business requirements.

• Verify Requirements describes how the Business Analyst determines that the requirements documentation is of sufficient quality to begin solution development.

Process and Elements

• The Business Analyst must verify that requirements have been specified uniquely in well written, unambiguous requirements statements.

• Good requirements are unambiguous, complete, verifiable, consistent, correct, modifiable, traceable, testable, and usable after development.

Avoid ambiguity

• To be unambiguous, all readers of a requirement should arrive at the same interpretation of its meaning.

• Requirements that are written in simple, concise, straightforward language are more likely to be unambiguous.

• All specialized terms and terms that might be subject to confusion should be well defined.

Standard sentence structure

• [<restriction>] <subject> <action verb> [<observable result>] [<qualifier>]

• When no beneficiary information has been entered and the “Submit” button is clicked the system shall display a warning message.

• Is this a good or bad requirement? Why?

Diagrams and tables

A picture is worth a thousand words:

• Web page mockups

• Report mockups

• Data and process models

Tables are useful too…

Decision Table exampleIf a policy is in wind up status and a member submits a lump sum deposit then decline the deposit. If a member submits a lump sum deposit and has no current bank information on the system then decline the deposit. Decline a member’s lump sum deposit if their current bank information has not been verified.

Member Lump Sum Deposits

Policy status is active Y Y Y Y N N N N

Current bank information Y Y N N Y Y N N Conditions

Verified bank information Y N Y N Y N Y N

Accept the deposit X Actions

Decline the deposit X X X X X X X

i.e. vs e.g.

• What does i.e. mean?

• What does vs mean?

• What does e.g. mean?

• What other abbreviations should we avoid?

Inconsistent terms

• The system shall produce the “Monthly Sales Summary” on the first business day after each calendar month end.

• The “Monthly Summary of Sales” shall be available via the Reporting Services server.

Missing values

If years of service… then …

is less than 5 forfeit employer contributions.

is more than 5 vest employer contributions.

Double negatives

• All members with three or more beneficiaries should not be migrated."

• "The system shall migrate only members having fewer than three beneficiaries."

Check for ambiguity

Construct questions about each requirements statement to verify that it is unambiguous.

The system shall produce a Sales Summary at monthend.

• Who gets the report?• What media is used for the report?• What happens if a backdated sale is entered into

the system after the report is produced?• How long do we keep the report?• When is monthend?

Audience tips

• What are your tips for avoiding ambiguity?

Questions?