Use Case Diagrams
As we have discussed earlier, a Use Case view explains the behavior of the system to end users, analysts and testers.
Designing a Use Case
With a small example, let us see how we can design a Use Case.
Suppose that we are designing an application which has the login screen functionality for authentication. The login screen is one of the most important in an application and the design for the same should be perfect.
The requirements for the login functionality are like this:
The login screen should have User Name, Password and Connect to fields.
The Connect to field is not mandatory. This field helps the user to connect to a particular database. If the user needs, he can use this option or by default it should connect to the database which we have pre-defined to be default.
Login, Clear and Cancel buttons should be available.
Depending on the login name, the user should be taken to the Administrator page or the normal user page.
We have our requirements clear. Now we need to approach to design use case for this.
As the definition goes, a use case is used to explain the behavior of the system. The UML Specification Document, UML Notation document or the UML Schematic document does not specify that a use case should be structured in a specific way. This leads to a debate of how the use case should be structured and designed. There are many formats and ways in which a use case can be designed and used. Here, I would be depicting the usually way in which I design a use case.
| Use Case Section | Description |
| Name | An appropriate name for the Use Case. |
| Brief Description | A brief description of the use case’s role and purpose. |
| Actors | Persons who are users to the functionality. |
| Flow of Events | A textual representation of what the system does with regard to the use case. Usual notation for the flow of events are: Main Flow Alternative Flow Exceptional Flow |
| Special Requirements | A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation. |
| Pre-Conditions | A textual description that defines any constraints on the system at the time the use case may start. |
| Post-Conditions | A textual description that defines any constraints on the system at the time the use case will terminate. |
After having seen what the use case should typically contain, let us write the use case for the login requirements what we have defined.
RELATED POST
UNIT TESTING PART ONE
UNIT TESTING PART TWO
UNIT TESTING PART THREE
GUI TESTING
WINDOWS COMPLIANCE GUI TESTING PART ONE
WINDOWS COMPLIANCE GUI TESTING PART TWO
WINDOWS COMPLIANCE GUI TESTING PART THREE
WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING
WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING
WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING
CONDITION TESTING
TESTING CONDITIONS PART ONE
TESTING CONDITIONS PART TWO
TESTING CONDITIONS PART THREE
TESTING CONDITIONS PART FOUR
SPECIFIC FIELD TESTING
USABILITY TESTING
INTEGRATION TESTING
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
No comments:
Post a Comment