OK, so you’ve had some great sessions with users and stakeholders. What they want the system to do is neatly captured in a number of user stories. Now what? While user stories do a great job of expressing functional (and often non-functional) requirements in words that business users can understand, that’s not the case for developers. Remember that a business analyst is the communicator between the business AND the developer. There just isn’t enough information in a user story for…
Continue ReadingUse Case Fragments
A previous IRM article Event Based Analysis and Modelling described how business functionality in a requirements package can be broken down into a table with column headings – Event, Trigger, Initiator, Use Case name, etc. Each business function is a separate event and has a unique number. A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing…
Continue ReadingHow to Write Use Cases
A previous IRM paper – How to use Use Cases – highlighted the need for clear and logical thinking when documenting the primary and alternate flows of a use case. A use case diagram is all well and good for communicating the scope of a particular event but to explain what’s happening inside the use case we need to revert back to a textual description. The How to use Use Cases paper described a relatively simple event – a student registering…
Continue ReadingHow to use Use Cases (With Examples)
Many business analysts and business users get frustrated at the perceived lack of information in a use case diagram. “It’s all very well drawing a picture” they say but what about the details – what’s actually going on? When producing project documentation, use case diagrams are rarely used on their own. They will generally be accompanied by a textual use case and if they’re complex, may also have a supporting activity diagram to show what’s going on “inside” the use…
Continue Reading