The LFM Applied

Jerrad is writing a Logical Functional Model for a website. He is approaching the problem exactly right: figure out what the user actions are, and then organize them into a user-sane order. His example is all about searching, so the LFM could be very small, just a few different FindXxx methods. He has so many different ways to search, though, that his approach of separating the different types of searches makes a lot of sense as well. Deciding how to partition your LFM is a core issue that can mean the difference between the LFM being understandable or a jumbled mess. My philosophy here mirrors what I do everywhere else: start simple and expand into more detail as needed. For example, in a drawing program like Microsoft Visio there are a lot of actions that can be done with shapes on the active page. I would initially put all of these into Logical.Page.Shapes, but when it eventually grows so large that understandability and discoverability start to suffer I would split it out into e.g., Logical.Page.Shapes.Creation and Logical.Page.Shapes.Formatting and Logical.Page.Shapes.Editing.

Jerrad asks how to write an LFM for an application that has multiple user roles. For each of his features, a user can take a variety of actions and an administrator can configure a variety of things. Both the user and the administrator have to be authenticated before they can do anything. Different multi-role applications work in very different ways (e.g., in some everyone starts out a user and then authenticate up to admin but in others people log in as one or the other (and presumably have different UIs); in some when a user authenticates up to admin the administrator features tack on to the user features but in others the administrator role effectively replaces the user role), but the user actions in each case are very similar:

• Authenticate as a user.
• Authenticate as an administrator.
• Execute user actions.
• Execute admin actions.

Jerrad wonders whether partitioning actions based on role is the right thing to do:

• Application
  • Login(UserRole, ...)
  • Logout
• User
  • DoSomething
  • DoSomethingElse
• Administrator
  • ConfigureSomething
  • ConfigureSomethingElse

This could work, especially if there a huge number of actions in both the user and administrator branches. In my mind the most important thing is what is being done, not who is doing it, though, so I would probably start with a strictly functional view though:

• Application
  • Login(UserRole, ...)
  • Logout
• FunctionA
  • ActionA
  • ActionB
• FunctionB
  • ActionA
  • ActionB
• Configuration
  • ConfigureSomething
  • ConfigureSomethingElse

or

• Application
  • Login(UserRole, ...)
  • Logout
• FunctionA
  • Execution
    • ActionA
    • ActionB
  • Configuration
    • ConfigureSomething
    • ConfigureSomethingElse
• FunctionB
  • • Execution
      • ActionA
      • ActionB
    • Configuration
      • ConfigureSomething
      • ConfigureSomethingElse

The most important thing here is not whether you have the "right" model but rather that you spend time discussing it with your team and develop something that makes sense to everyone. Not very prescriptive advice, I know! <g/> But staying focused on actions, and keeping away from a scripting/VBA object model, is the main point. One practice I have found helpful is to compare the test cases you could write with your LFM to the steps listed in your help documentation. Test cases that sound like help steps are a Very Good Thing!

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: michhu at microsoft dot com. Great coding skills required.