Problems with Use Case Modeling
Filed Under Document, UML, Design, Techniques, Model, Issues, Software | Posted on October 22, 2007
There can be many problems in the approach of utilizing the Use Case Approach. You could have limitations of the actual process, or you can have people with not enough expertise in to do it, and messing up the whole thing. So, it is good to get an idea of the limitations of Use Case Modeling.
- Use cases eschew description of user motivations and experiences, and do not address usefulness and usability.
- Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
- Although quality issues are often crucial to the success of a software system, there are no systematic way to handle nonfunctional requirements with use cases.
- Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
- Another drawback exists when trying to document interactions between requirements. Use cases look at each requirement separately and does not document the interaction between the requirements.
- There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
- Many developers often avoid use cases because of the time required to prepare a complete set for an application. Depending on the size of the system in question, it can take a significant amount of time to complete a set of use cases.
- Use cases are criticized for not capturing all the off the wall mishaps and events that can occur.
- Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.
- Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize.
- A use case describes a series of actions that provide value to an actor; it doesn’t describe a collection of features.
Leave a Reply
