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…
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…
