BA Toolkit: Top Models for Complete Requirements Analysis Webinar Q&A – Part 2

Thank you to everyone who attended the “BA Toolkit: Top Models for Complete Requirements” webinar, hosted by Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA. If you missed it or would like to review, check out the recording.

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.

Q. Do you offer a class that covers all of these models? I’d like a step deeper, but not intensive on a single model.

A. Yes, our Visual Modeling Essentials class covers all the models. In fact, this webinar is a summary of that class.

Q: Should use cases be detailed enough to understand to add business rules related topics?

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.

Q. If you are compiling written requirements, how far down the modeling path do you go before writing requirements?

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.

Q. Is there a model that we can leverage for enterprise analysis (capturing the different systems/processes in the organization)?

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.

Q. What no-fail BA model is able to be utilized for just about any organization?

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.

Q. Can it be enough to use only 1 model for a not very big project? What is the basic model that is necessary?

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.

Q. What is your favorite modeling software?

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.

Q. How do you store your models? Is it printed out or is everything stored only electronically?

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.

Q. How much does the style of development, such as Waterfall, Agile etc, influence modeling?

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.

Q. What is the best model to start with when the business is in the process of looking for a new system? Will the swim lane model help me to start with?

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.

Q. Define functional requirement.

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.

Q. What is the difference between a use case and a requirement?

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.

Q. Who is the primary audience for use cases?

A. Use cases are particularly helpful to business stakeholders, developers, and testers.

Q. While UML use cases can’t show sequence, narrative can, right?

A. UML (Unified Modeling Language) is for diagrams only, so it doesn’t apply to narratives. However, the diagram without a narrative is incomplete.

Q. Should an AS-IS process model include technical elements (e.g. spreadsheets, system actions) or should it be more abstract?

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.

Q. How do you validate models against each other for consistency?

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.