While many large companies still describe their requirements using the written word, there is a huge amount of evidence that pictures (i.e. modelling languages) are a clearer and more reliable method of communication. A 2016 survey of Australian business analysts across 30 organisations (government, big business, SMEs) found that while 14% used one or more of the popular languages (DFD, UML, BPMN) regularly, the vast majority 76% did not or only very occasionally. This shows that a small number of…
Continue ReadingWhat Happens After User Stories?
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 ReadingThere’s More to Modelling than Runways and Catwalks
How often have you seen a TV clip from a fashion show – Milan, London, New York – and thought to yourself “What on earth are the models wearing?!”. Business analysts can be guilty of something similar. Sure it’s a model, but what does it mean, what’s it trying to say? In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the…
Continue ReadingData Modelling & Object Oriented Development
At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or – if they only deal with requirements investigation – then someone else in the team will need to verify that the data to support new functions will be available. To produce a data model (a logical view of the data) the technique of choice has been, and still remains, the…
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 ReadingEvent-Based Analysis & Modelling
Many business analysts mix structured techniques with UML and use events as the entry point to their analysis activity. An event can be any activity, action or business process where the system under investigation needs to respond. In this approach to business analysis, once the scope of the system has been identified, the first deliverable is a table (a list) of events. Event-based analysis aligns very well with UML and object-oriented development as both are based on how a system…
Continue ReadingHow To of Essential Modelling
Also called abstract or business modelling, essential modelling can be an extremely valuable tool for the business analyst. Instead of modelling how things are done (the current system), or how they might be done (a proposed system), we model what is done, or what might be done. For example the purpose of a Customer Service Department is to provide customers with a level of service they expect (or the company defines). Things like call centres and customer relationship management systems…
Continue ReadingUML – Business Context
“Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system. In the following extract from our Modelling Requirements with Use Case & the UML course manual we’ll take a brief look at which of the 13 diagrams…
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