Arunkumar Khannur's Software Testing Knowledge Center
   
 

11.16. Challenges and Associated Risks related to Use Cases

Writing effective and meaningful Use Cases is a challenging work demanding unexpected extra work on the part of the analysts and introduced additional risk into the requirements specification:

11.16.1. Inadequate and Less Obvious Context for each Use Case
Context is not always obvious for each use case. Use cases in and of themselves do not always provide an adequate understanding of the interaction that they are intended to describe; this is partially due to the way individual authors write use cases. On numerous

Occasions, we had to refer to other use cases to deepen our contextual understanding. There are various reasons for this.

Firstly, Use Cases require System Thinking in Analysts. While the analysts are very familiar with their domain most of the time they are less competent in other areas like company rules policies and processes, which are termed as underlying business rules. Secondly, the SRS use case overviews did not provide enough contextual information to describe the circumstances under which the use case is relevant. Context makes use cases more meaningful; thus, use case authors should seek to make use cases understandable to all stakeholders including the authors. Lack of contextual information increases the risk that system requirements may be misinterpreted. Context makes use cases more meaningful, and when adequate context is not provided valuable information about the use cases may be lost. We incur the obvious risk of producing an incomplete or erroneous specification.

Use cases are typically utilized to surface requirements early on and yet without the appropriate context the very benefits we expect are reduced, since it is likely that errors will result later in the process from the misinterpretation

11.16.2. Lack of Participation of Intended Users in Advances Phase of Requirements Analysis
Use Cases are written from Users point of view. As such they are to be written in a participatory fashion where authors and intended users contribute. However, practically users are included only in the initial stages of the SRS production and are later unable to contribute additional scenarios or examine the use cases for accuracy and validation. Because of this, the scenarios may be plagued due to assumptions made about typical and/or expected user and system interactions.

The SRS authors were also responsible for designing the GUI. Instead of involving users, in general, the SRS authors rely excessively on the available user interface designs to construct the use cases, producing a collection of use cases that focused more on the system’s GUI rather than the intended functionality of the system. Thus, in this case, use-cases reflect the perspective of those individuals responsible for the GUI production, instead of the perspective of the individuals who use (or will use) the system. This fact that the authors only investigated scenarios from one viewpoint also introduces risk, since exploring multiple viewpoints yields more comprehensive requirements coverage.

11.16.3. Traceability is difficult to manage
Traceability is a measure of quality that reduces the risk of any possible non-consideration of specifications from one phase to following phase across life cycle artifacts. Maintaining traceability information can be quite time consuming. It is much observed problem related to traceability in use case based requirements management that may be because of an excessive focus on GUI in the use cases which demands all GUI references and screen design references. Any inconsistency across such references to available GUIs and screen designs results in corresponding inconsistencies in the derived scenarios. Also, it is very difficult to manage traceability related to multiple use cases to a set of statements pertaining to specific menus and screen navigation.

The use cases in the SRS provide a system scope description of user and system interactions, not a description of interactions between subsystems. The inclusion of design information in use cases that describe subsystem interactions is acceptable but such information should not be recorded in system-level use cases.

11.16.4. Missing and inconsistent naming of use cases
Missing and inconsistent naming of use cases is indicative of an incomplete and flawed Specification. This happens because of many reasons. At times, the list of included and extended use cases often point to un-defined or non-existent use cases. Additionally, some referenced use cases are never defined. The risks associated with missing use cases involve representing missing interaction information and/or suggesting missing requirements. A simple use case name does not sufficiently describe the use case details that affect the derived requirements. Discrepancies between use case names also introduces risk since use cases provide a way to reference a potentially large body of information using just a few words (the use case name) or a unique identifier, such as a number. A use case referenced using the incorrect name also increases the likelihood of conflicts.
 
 
 
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
         
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
STEP-AUTO Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
URL: www.isqtinternational.com
Email: khannur@isqtinternational.com
Skype: arun.isqt