Here at ArgonDigital we stress the importance of modeling (no, not super-modeling) and creating visual requirements – it is much easier for business and development users to review and utilize models compared to pages of ‘system shall’ requirements. With that in mind business analysts do not always know what models to use depending on the situation. Here are several tips to help you pick the right model out:
What’s the the most important part of the software?
Many of you are familiar with the trifecta of People, Systems and Data – these are the 3 drivers behind every software project. The new software is going to have some number and type of users, links to other systems, and will contain data.
Your project is likely to have a stronger focus on one of these aspects – there may be 30 different user groups that will be accessing the system or 20 other systems that the new software will integrate with or 25 separate business data objects that exist in the system. Discovering the primary driver of these 3 will determine which high level model is appropriate to create: an organization chart for people, a system context diagram for systems, and a business data diagram for data. Each of these models will provide a general background that will allow for more detailed models to be created.
For example, in a user driven system, you may find that your organization chart will lead you to create process flows for the various users to capture the necessary functionality. If more detailed requirements are needed, then actor lists, master end user lists and permissions matrices can be created to provide detailed user specific requirements.
Similarly, for systems-heavy projects, data flow diagrams and process flows can show how people and data interact with the systems involved in a project. Additional detail can be derived when the user interface is crucial for certain processes – wireframes and display-action-response models will show detailed user interface requirements. The same methodology also applies to data driven projects: data dictionaries, state diagrams, report tables and data flow diagrams are different flavors of detail around the objects in a business data diagram.
What’s the software going to be used for?
Every project to implement software has a reason behind it – portals for customer access, analytics so the business can report and analyze information, task automation to reduce costs or a myriad of other possibilities. When a business analyst can establish what the primary business object is, it is easy to identify which features directly tie into that business objective. Taking one more step forward, these same features tell you which models need to be created to accurately document the requirements for that functionality.
General categorizations are examples of applying the methodology of creating models for the features needed to achieve the business objectives. For instance, portal features are heavily user-driven and therefore need more people models; analytics features deal primarily with data and thus require data models; and task automation is people doing work in various systems which will lead to the creation of people and systems models. Identifying what needs to be built is the first step to documenting and modeling those items – linking back to business objectives ensures those items are the ones that will bring the greatest return on investment.
People familiar with ArgonDigital’s methodologies will recognize a couple of common concepts here – working from business objectives and using models in conjunction. Those concepts are invaluable in software projects in a multitude of ways, including helping business analysts select the correct models for their projects.
