Presentation is loading. Please wait.

Presentation is loading. Please wait.

What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne.

Similar presentations


Presentation on theme: "What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne."— Presentation transcript:

1 What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne

2 Agenda Who am I? Whats this stuff about a house on the hill? BABOK context Avoiding ambiguity Audience tips Questions

3 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

4 Whats 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

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

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

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

8 Definition of requirements types Business requirements User requirements Functional requirements Quality of service requirements

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

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

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

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

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

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

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

16 Standard sentence structure [ ] [ ] [ ] 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?

17 Diagrams and tables A picture is worth a thousand words: Web page mockups Report mockups Data and process models Tables are useful too…

18 Decision Table example

19 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?

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

21 Missing values If years of service…then … is less than 5forfeit employer contributions. is more than 5vest employer contributions.

22 Double negatives All members with three or more beneficiaries should not be migrated." "The system shall migrate only members having fewer than three beneficiaries."

23 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?

24 Audience tips What are your tips for avoiding ambiguity?

25 Questions?


Download ppt "What colour is the house on the hill? Waterloo – Wellington IIBA Chapter presentation April 11, 2007 David Milne."

Similar presentations


Ads by Google