Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


What are some of the limitations of use cases and use case specifications?

Posted by Vineet Banwet

Article Rating // 14864 Views // 2 Additional Answers & Comments

Categories: Business Analysis, Systems Analysis, Use Cases


Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system or business, however they do have limitations.

  • Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability, reliability of a system). While use case specification templates have been extended by some in an ad-hoc fashion to list non-functional requirements, this strays from the intended purpose of a use case.  Use cases are functional in nature.  It is this very organization by function that give use cases their many benefits.  Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the cohesiveness and benefits of the use case specification.
  • The non-sequential nature of a use case diagram is often difficult for some audiences to understand.  When one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion that the use case diagram is showing a sequence where the first use case is completed before the other begins.  Those who are familiar with use case diagrams know that an included or extended use case can occur or be initiated at any point within the including or extending use case.
  • Learning how to write use cases takes time.  Many consider it to be more of an art than a science.  This is because there is no fully defined set of standards for how to write use cases, or what should be included within a use cases specification. And while there have been many different views espoused by authors, still a great deal of commonality has emerged among them. Where this commonality exists there is little disagreement among use case writers and those who consume or read use cases.  However, in some areas there are still a number of differing opinions creating confusion for new use case authors.  Because of this, the learning curve for use cases and use cases specifications is elongated.  Still, over time, use case authors and readers develop a more sophisticated understanding of those areas that are more ambiguous and open for interpretation, such as the “extends” relationship. 
  • Use case specifications are not an appropriate tool for describing the user interface of the application.  Use cases should be left as UI independent as possible.  Remember that a use case specification it intended to capture the functional requirements of the system, or in other words, WHAT the system should do in response to a user action.  This is very different than HOW the system should do something.  Any time an analyst captures requirements, the focus should be on the WHAT not the HOW.  This gives the system and UI designer the freedom to develop the best solution possible.  It also makes our use case specifications much more maintainable since a change in screen design doesn’t impact the user-system interaction previously defined.



amit aswani posted on Thursday, September 10, 2009 1:06 PM
The last point is very important in terms of understanding how use cases can be realized to create high level design or software requirement specifications. Use cases essentially verbs will work on entities essentially nouns. So it becomes imperative to identify both to draw a feasible system solution.

For example, registering a user shall be a use case(Verb - Add). Now the 'user' is a noun and shall have some attributes like name, age, sex, address. To realize the use case 'Register User', the user interface should provide the capability to capture all the attributes, be it mandatory/non-mandatory and should be able to add the user to the system.
The pre-conditions mentioned for the use case are constraints or validations applicable on the user interface. For example one of the pre-conditions could be users aged between 18-40 can only be registered in the system. The user interface shall restrict users aged below 18 and above 40 from registering in the system.

The post conditions of the use case are the desired results.For example appropriate message on successfully registering a user in the system.
amit aswani
jmcguire posted on Sunday, November 29, 2009 2:14 PM
Use cases also do not show:

- data requirements: data entities, attributes, relationships, formats, etc.
- data flows between processes
- process flows (sequence), and
- the relationship between actors and processes (ex: a student may register for zero or more courses)
Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC