Normally you gather requirements through interviews and reviews with stakeholders. From these interviews and reviews you gain an understanding of what the software needs to do. Then you clearly, unambiguously document it in a requirements format. It is a little hard in a classroom setting to provide stakeholders. So in this exercise you will be provided a finished software product. You can learn how the software works. This will allow you to gain an understanding of what the software does. From this you will document the requirements using Use Case Diagrams and Textural Use Cases.
The purpose of this exercise is to get you accustomed to the various Use Case Diagrams and techniques. You may pick any software that you like, as long as you can show your excellence and command using features of that software. You don’t have to document all the features of that software, but you must have one type of Use Case Diagram describing the feature.
Due to time limits you will not be able to create a full requirement document for the software. Doing so would take years to complete. Pick a subset of features; hopefully you can pick a subset that has something in common. Your requirement document must have at least 8 Textual Use Cases and a Use Case diagram that includes the Use Cases.
We suggest picking feature-rich software that is also readily available to others. Examples include MS Word, MS Excel, Open Office, Google Web Search, Google Maps, GMail, Uber, Facebook, GnuCash, or a web browser. Of course, you may pick something not on this list. In order to best prepare you for what’s coming, I suggest that you use a product with more than one user involved (underlined in the list).
You may use screenshots of the software to help me understand the feature you are describing.
There is a template attached that you may wish to use for this exercise.
