Use cases are simple representations of a person\'s understanding of a process t
ID: 3889673 • Letter: U
Question
Use cases are simple representations of a person's understanding of a process to be modeled by the system. In relation to this statement, answer the following questions:
An overly simplified set of documents can cause some problems. Evaluate this statement and explain your stand.
Discuss at least three ways in which you think use cases may hinder the development process.
Use cases are not the best approach as a method of representing processes.
Can you state any situations?
What aspect of the situation would make use cases not the perfect solution?
Please give enough information in your answer to set the stage for your example. Also state any assumptions that you are making. Use cases are a means of communication to nontechnical stakeholders.
We analyzed different ways of eliciting requirements as well as several types of people who may be involved with the development of the new system.
Do you think that use cases should reach anyone who was involved in the requirements elicitation process (such as employees you interviewed) or just key stakeholders? Discuss your opinion, justifying your answer.
Part 2
UML is a tool that enables people to easily exchange information, but it is not necessarily the only tool.
Discuss at least three reasons you think are significant enough to let a company choose a solution other than UML for their needs. Justify your answers.
Explanation / Answer
CONCLUSION
What then should developers do? Use cases clearly offer many important benefits and are powerful weapons that probably should be in the arsenal of all software analysts, designers, and testers. Unfortunately however, they are functional rather than object-oriented and can significantly compromise the benefits of object technology if blindly added at to the object-oriented development process. Fortunately, the risks associated with use case modeling can be mitigated through knowledge, training, and avoiding an over enthusiastic acceptance.
Use cases should be only one of several ways of capturing user requirements. The model of objects, classes, and their semantic relationships should be consistent with, but not totally driven by, the use cases. Designers should beware of and minimize scattering the features of a use case's objects and classes, and they should exercise great care to avoid the creation of partial, redundant variants of classes, especially on large projects involving multiple builds and releases.
The architectural guidelines of Rebecca Wirfs-Brock [9] should be followed to avoid creating excessive functional controller objects that dictate the behavior of dumb entity objects. Most importantly, use cases should not be used as an excuse to revert back to the bad old days of functional decomposition and functionally decomposed requirements
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.