Presentation is loading. Please wait.

Presentation is loading. Please wait.

October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger.

Similar presentations


Presentation on theme: "October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger."— Presentation transcript:

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

2 2

3 3 The hardest part of a project ! A very important part of a project ! The most interesting part of a project !

4 4

5 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 Analysts Book of Knowledge [BABOK] Guide, Version 2.0 5

6 6 Project Origination Business Case Legislation Regulations Estimates Initiation Project Team, Sponsor, Stakeholders Charter Scope Planning Business Modeling 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

7 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

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

9 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

10 Correct Verifiable Clear & concise Complete Consistent Traceable Feasible/Viable Necessary Prioritized Free of implementation details 10

11 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

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

13 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

14 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

15 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

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

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

18 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

19 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

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

22 22 Business Requirements ID No. Function - Feature - Requirement Users Prior ity Origin Related Business Rules Excerpts from the Business Rules document G-1 A bicycle license service must be added to MyDMV. PublicH 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. PublicH Bus Case 1.1.2 1.1.2 A bicycle safety exam must be available in the My Bicycle License Service Center. G-3The new MyDMV Bicycle license service must include the process for a user to complete a request for an original bicycle license online. PublicHBus 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.

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

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

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

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

27 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 lions share of the responsibility for establishing priorities. Priority is usually determined by the business team. 27

28 28 ID No. Function - Feature - Requirement UsersPriorityOrigin Related Business Rules UR-1 It is critical for the customer to have a way to cancel the transaction. Public H Bus Case1.1 UR-2 It is important for the customer to be able to change their order. Public L Scope1.2.1 UR-3 It is important to provide alternate methods of payment for the customer to choose Public M Users1.3

29 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

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

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

32 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

33 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

34 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

35 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

36 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

37 Ambiguous TermsWays to Improve Them acceptable, adequateDefine 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. betweenDefine whether the end points are included in the range. depends onDescribe 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? efficientDefine 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

38 Ambiguous Terms Ways to Improve Them flexibleDescribe the ways in which the system must change in response to changing conditions or business needs. improved, better, faster, superiorQuantify 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, optimizeState the maximum and minimum acceptable values of some parameter. normally, ideallyAlso describe the system's behavior under abnormal or non-ideal conditions. optionallyClarify 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

39 Ambiguous TermsWays to Improve Them robustDefine how the system is to handle exceptions and respond to unexpected operating conditions. seamless, transparent, gracefulTranslate the user's expectations into specific observable product characteristics. severalState how many, or provide the minimum and maximum bounds of a range. shouldn'tTry to state requirements as positives, describing what the system will do state-of-the-artDefine what this means. sufficientSpecify how much of something constitutes sufficiency support, enableDefine exactly what functions the system will perform that constitute supporting some capability. user-friendly, simple, easyDescribe 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


Download ppt "October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger."

Similar presentations


Ads by Google