Some things are easy to identify as a class. For example, if you look around the room, you can find lots of physical objects which can be made into classes. However, in a software environment, this may not always be as easy to identify. So look at the following questions to start to identify what…
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…
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…
The book calls this Eliciting Requirements. They should be done in a collaborative environment. Generally either face to face meetings and/or virtual meetings. Being done in real time allows for faster feedback than over an email/text/phone calls, etc. The meetings should include developers as well as other stakeholders. Rules and an Agenda for the meeting…
