Getting It Right

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Anyone developing software will agree that getting it right—building software that is destined for success—is critical. It is no fun to build the wrong software or to build software that fails—fails to do what is needed, fails to delight its users, fails to meet its users’ needs. Managing requirements, and the process of defining requirements can materially contribute to building the right software. But business rules are not requirements, and they must be found, developed and managed differently. What you will learn: The differences between rules and requirements. How they can and should be developed together. What techniques work for capturing and managing them. What to watch for.

    3 Favorites

    Getting It Right - Presentation Transcript

    1. Getting it Right Rules and Requirements in Software James Taylor Scott Sehlhorst
    2. Agenda
      • Challenges in Specifying Systems
      • Business Rules Specification
      • Requirements Specification
      • Using them together
    3. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone
    4. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Implementation of complex software takes too long
    5. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Implementation of complex software takes too long Changing existing applications takes too long
    6. Challenges in Specifying Systems Elicitation of requirements, processes, rules is error prone Maintenance costs are excessive Implementation of complex software takes too long Changing existing applications takes too long
    7. The Challenges / Goals
    8. The Challenges / Goals
    9. The Challenges / Goals
    10. Enabling Business Agility
      • Managing Rules and Requirements Independently
      • Enables and Encourages Easy-To-Change Solutions
    11. Rules & Requirements
      • Both capture business knowledge
      • Both clarify customer needs and expectations
      • Both reflect business need
    12. Why Separate Rules from Requirements?
      • Rules change independently of requirements
      • Rules are reused throughout the requirements
      • Isolated rules can be analyzed for accuracy and completeness
      • Separation in documentation leads to separation in implementation
      • Simplified approval process
      • Reuse yields reduced work
      • Reuse allows leverage of rules across projects
      • Analysis can be automated
      • Faster implementation
      • More maintainable code
      • Simplified change management
    13. Different Models for Different Needs
    14. Agenda
      • Challenges in Specifying Systems
      • Business Rules Specification
      • Requirements Specification
      • Using them together
    15. What are Business Rules?
    16. What are Business Rules?
      • “ … directives intended to influence behavior.”
    17. What are Business Rules?
      • “… formal expressions of knowledge or preference, a guidance system for steering behavior...”
    18. What are Business Rules?
      • “… statements of the actions you should take when certain business conditions are true.”
    19. What are Business Rules?
      • “… heuristics or tools to make business decisions ”
    20. What is a Rule?
      • Computation Rules
      • Inferences
      • Process Flow Rules
      • Action Enablers
      • Data Edits and Constraints
    21. Capturing Rules
      • The capturing of rules can be summarized in the following steps:
        • Document your process
        • Identify decisions in the process
        • Identify and validate the rules that make up each decision
    22. Documenting Rules
      • Documenting Rules
        • Each individual rule is documented distinctly
        • Sets of rules are combined to reach decisions
        • Rules can have hierarchies and relationships to each other
        • Decisions (rulesets) can have dependencies on one another
    23. Agenda
      • Challenges in Specifying Systems
      • Business Rules Specification
      • Requirements Specification
      • Using them together
    24. Requirements Framework
    25. Agenda
      • Challenges in Specifying Systems
      • Business Rules Specification
      • Requirements Specification
      • Using them together
    26. Rules and Requirements Overview
    27. Rules and Requirements Overview
    28. Rules and Requirements Overview
    29. Rules and Requirements Overview
    30. Traceability (Rules <-> Requirements)
    31. Traceability (Rules <-> Requirements)
    32. Traceability (Rules <-> Requirements)
    33. Traceability (Rules <-> Requirements)
    34. Process Candidates for Business Rules
      • Multiple decision steps in the process
        • Assess, Compare
        • Calculate, Compute
        • Check, Confirm
        • Qualify, Decide
        • Determine, Diagnose, Evaluate
        • Estimate, Process
        • Test, Validate, Verify
    35. Process Candidates for Business Rules
      • Symbolic reasoning
        • if then
        • unless
        • only if
        • is a necessary condition for
        • is a sufficient condition for
        • consequently
        • therefore
    36. Process Candidates for Business Rules
      • Complex rules, decisions, multi-level reasoning
        • risk analysis
        • underwriting
        • identifying allowed combinations / configurations
    37. Framework for Documentation
      • Process Documentation or Use Cases or Both?
    38. Process Documentation
    39. Use Cases
      • Look for Rules in the following
        • Description
          • Embedded constraints
        • Triggers
          • Action enablers
        • Preconditions
          • Constraints
        • All Flows
          • Computations
          • Decisions
    40. Use Case: Description
      • A pilot performs an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy.
      • A pilot performs an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy .
      • A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights.
      • A pilot performs an FAA mandated list of equipment and operational inspections [see FAA-1] prior to flights.
    41. Use Case: Triggers
      • Every Friday at 5pm
      • Order size exceeds $1KK
      • More than 100 orders are queued
      • It is time to process pending orders [See BR021, Order-processing triggers ].
    42. Use Case: Preconditions
      • The amount of the loan has been identified:
        • Loan amount is below $250K
        • Loan represents >80% equity
      • A maximum amount for the loan has been identified [See BR033, Determining proper loan process ].
    43. Use Case: Normal Flow
      • 1.  User provides personal information. [See FR22 for details]
      • 2.  System requests loan approval
          • Includes loan amt, down-payment amount, credit rating
      • 3.  Loan-Approval System responds that loan is approved.
      • 4.  System requests loan initiation
      • 5.  Loan-Processing System responds that loan has been created and funds are available
      • 6.  System notifies user that loan has been approved.
      • 1.  User provides personal information per BR1255 [Required Loan Application Information]
      • 2.  System requests loan approval per BR1256 [Required Loan Approval Information]
      • 3.  Loan-Approval System responds that loan is approved.
      • 4.  System requests loan initiation per
      • 5.  Loan-Processing System responds that loan has been created and funds are available
      • 6.  System notifies user that loan has been approved.
    44. Review of Use Cases & Rules
    45. The one slide you need
      • The rules of a decision are not part of requirements, or of processes
      • Decisions are important and different
      • Managing rules, requirements and processes separately but traceably gives you maximum accuracy while retaining agility
      • Beware of hidden decisions, hidden rules
      • Managing rules in parallel with requirements always helps
      • Managing rules at design and execution time, with a business rules management system, really helps with volatile rules
      • Rules Are Not Requirements!
    46. Thanks James Taylor – [email_address] Scott Sehlhorst – [email_address]
    47. Resources
      • Blogs
        • www.edmblog.com
        • www.ebizq.net/blogs/decision_management
        • www.tynerblain.com/blog
      • Wikis
        • www.smartenoughsystems.com/wiki
      • Articles
        • http://www.businessrulesgroup.org/brmanifesto.htm
        • http://wiki.ittoolbox.com/index.php/What_makes_a_good_Business_Rule?
      • Books:
        • Smart (Enough) Systems , Taylor and Raden, Prentice Hall
        • Use Cases: Requirements in Context , Kulak and Guiney
        • Writing Effective Use Cases , Cockburn
        • Patterns for Effective Use Cases , Bramble, Cockburn, Pols, Adolph

    + Scott SehlhorstScott Sehlhorst, 2 years ago

    custom

    811 views, 3 favs, 2 embeds more stats

    Why and how to separate business rules, and busine more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 811
      • 685 on SlideShare
      • 126 from embeds
    • Comments 0
    • Favorites 3
    • Downloads 41
    Most viewed embeds
    • 125 views on http://tynerblain.com
    • 1 views on http://feeds.feedburner.com

    more

    All embeds
    • 125 views on http://tynerblain.com
    • 1 views on http://feeds.feedburner.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories