There were so many really wonderful, thought-provoking questions on the BA Toolkit: Top Models for Complete Requirements webinar that I decided there was too much to answer in one blog. I have already completed Part 1, so here is Part 2.
A. Yes, our Visual Modeling Essentials class covers all the models. In fact, this webinar is a summary of that class.
A. Yes, it needs to be detailed enough to understand the business rules that are enforced by process. However, my own personal preference is not to include separate textual business rules on the diagram or as separate notes or attachments to the use case narratives, since the process business rules are already part of the narrative. If that sounds a bit confusing, let me explain.
The data business rules should be included as part of the relationships between entities on the data model and documented in the data dictionary. Likewise, the business rules that relate to attribute constraints belong in a data dictionary. However, often there are process business rules. For example, if there is a rule that users are locked out of their accounts after three failed login attempts in 24 hours, both the number of times and the time limit are rules that need to be accounted for in the use case narrative. And, for that matter, the 24-hour time can actually be an actor, but that’s a subject for a different blog.
A. I think I touched on this in the Q&A, but I’d like to expand and clarify. Let me start by saying it is important to follow your organizational standards if any are in place. Back in the age of dinosaurs, we didn’t do much modeling other than process modeling at the beginning of a project. Then, we set them aside and wrote textual requirements. Once we started doing more modeling, we used to say that models supported written textual documents (e.g. “The system shall. . .”). We would write as many textual requirements as we had elicited, do some modeling, and then add to our requirements lists with what we had found during modeling. We would take deeper and deeper dives, so our requirements list would expand as would our models.
My issue with this has always been that it seemed redundant, especially with use cases. When you have a detailed use case narrative, why rewrite it just to have it on a requirements list—unless organizational standards require it. My recommendation is to document as much as you can in the models, including scope models, which can be used as a list of high-level requirements. If you need to supplement with text, great. Yet, it seems to me that text should support models, not the other way around.
A. Someone asked about the tool Archimate, which apparently is a tool for Strategy (formerly Enterprise) Analysis. You may want to check that out. We do not endorse or recommend any automated tool. Every automated tool supports some kind of process, and we want to be sure people understand the concepts and processes related to the models. Without understanding the fundamental, underlying concepts, the tool will be more or less useless.
Each of the models has at least one associated “scope” model which can (and should) be used during Strategy (formerly Enterprise) Analysis. For example, functional decomposition can be used to break down the scope as well as the detailed deliverables. Use case and context diagrams, as well as value steam-type process models can also be used during Strategy Analysis.
A. All the models I went over during the presentation are suitable for all organizations, large or small, any industry, and can be adapted to almost all life cycles and even methodologies.
A. Rarely is it enough to use only one model—even on small projects in small companies. Even our company uses all four models for our projects involving new or modified software. It does depend on the type of project, as I said in the webinar. However, it’s almost impossible to do just one type these days.
A. I really do not have a favorite. Some are powerful and highly integrated but complex, hard to learn and hard to maintain. Others are easier to learn and use, but require more “manual” interfaces and support.
A. Of course, that depends on your organization/PMO/COE (Center of Excellence). Unless printing is required, I prefer to be as paper-free as possible. Either way, there has to be good version control, because rarely are models static. They need to be easily accessed, modified, and returned, ensuring that what was changed was changed on the most recent version.
A. I addressed this to some extent during the Q&A. I just want to summarize by saying that the development life cycle/methodology/framework does not affect the models themselves, but rather the way models are used (including perhaps different terms) and the timing of the use of the models.
A. You will want to document the current processes, because a new system/software will cause business processes to change. Swim lane process maps are a great way to begin your understanding of what’s happening today and what will change. You can start at a high level and model subsequently lower and lower levels of detail as you learn more.
A. Without going into too much detail, we usually distinguish between functional and non-functional requirements. The process, data, interaction, and interface models are all used to define functional requirements, which describe what are often called the behaviors of the solution/system/software.
A. This is a blog in itself. For now, let’s think of a requirement as describing one aspect of the business need, which will ultimately be developed into a solution. So, it may be helpful to think of a use case as representing one piece of the entire solution. In today’s business analysis field, both requirements and designs are a part of business analysis. It’s quite a bit more complicated than that, but it’s a place to start.
A. Use cases are particularly helpful to business stakeholders, developers, and testers.
A. UML (Unified Modeling Language) is for diagrams only, so it doesn’t apply to narratives. However, the diagram without a narrative is incomplete.
A. They are not part of the process models, so if you include them, you are including things that are related to but separate from the model. If it makes sense to your stakeholders to see the related material, there is no reason not to keep them together.
A. More material for another blog. The short answer is that if you follow the practice of doing these models more or less concurrently, you will do a cross-check to ensure your data model has what is needed to support your process, that your use case narratives make use of the data and processes, and that your user interfaces represent the use cases. It’s always good to do some other cross-checks with state diagrams and with other interaction diagrams, like the old CRUD (create/read/update/delete) matrix.
I know Part I and Part 2 are two long blogs, but that’s because everyone had such fantastic questions! Thank you again to everyone that attended the BA Toolkit webinar and for taking such an active part in this discussion.
How do you define success for your team? Take a moment to think about this…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
Effective leadership has never been more critical. Whether managing a team in a high-pressure corporate…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
The Business Analysis Body of Knowledge (BABOK® Guide v3) is a comprehensive guide to the…
A certified Business Analyst (BA) has successfully passed an International Institute of Business Analysis (IIBA.org)…