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 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…
Ideally everyone from stakeholders to developers would work on the same team and be of the same mind, but that isn’t always the case. In fact, that is rarely the case. Defining the Stakeholders The “Anyone who directly or indirectly benefits from the system being built” is a little too vague in my opinion. Instead,…
If you want a good project, then you need to have good requirements. Having good requirements doesn’t guarantee that you’ll have a good project, but having bad requirements guarantees that you’ll have a bad project. Project Inception There is no one place that a project “comes from”. A new product/project (feature set) can come from…
