There are times and cases when a use case using simple text, cannot properly describe a process. In those cases, look to supplement the Use Case to make it easier to understand the process. Activity diagrams can be used to show the workflow of a process the the user/system should take. A Swimlane diagram can…
A successful software product can be measured in many different ways (accuracy, speed, etc) however user satisfaction is often at the top of the list. A use case should properly describe how a user is going to use the system, so that it can be easily modeled and built – so that the users are…
Chapter 9 will focus on scenario bases modeling. Throughout analysis modeling, your focus should be on what, not how. While everything may not be known, we can approach this in an iterative method refining the model until everything is uncovered. The requirements model should have 3 primary objectives: Elements of an analysis modeling: Requirements Analysis…
Each requirement, when modeled, should be examined for: inconsistency, omissions, and ambiguity. You also need to check for: Requirements negotiation is often used to help ensure that requirements are reasonable, and can be met in a reasonable amount of time. You should look to a win-win situation, not a winner takes all contest. Validating Requirements…
We’ve seen the break in a switch statement. It stops running the blocks of code, and simple exits out of the switch. In the same manner, if you use a break in a loop, it exits us from the loop prematurely (not by the loop condition). The continue keyword moves us to the end of…
The for loop is the counting loop of C++. It is usually designed to run a specific number of times, and then end. With it, it keeps a counter, to let you know where in the loop you are – useful when looping through an array which will look at soon enough. The general form…
The intent of the analysis model is to provide a description of the required informational, functional, and behavioral domains for a computer-based system. The model changes dynamically as you learn more about the system to be built. There are many ways to look at how to state a problem. The Use Case we looked at…
The first step is developing a use case is defining a set of actors. While it will normally be a “user”, it might also be “an automated/scheduled system”, “an administrator”, etc. There will likely be different actors in the system, or different roles that the same person might play. When building the use case you…
