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…
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…
Constructions (the Software Coding or Development Phase) can be broken down into several small phases. While Coding is only one part of Software Engineering, it is a large part, and part of being an engineer is being able to write good code! Preparation Make sure you understand the problem. Understand the basic design principles and…
The primary goal is to build software not models. Building models is great, but if it doesn’t get you to software being built, it’s not helping. “Travel Light” – Don’t build more models than you need. By working only on the models you are about to write software for, you minimize unnecessary work. Build it…
