Use Case Diagram

A Use Case Diagram (UCD) is used to describe the functionality of a system or describe a set of actions that some system can perform with one or more external users of the system. That is, rather than representing the details of individual features of your system, UCDs depicts pictorially all the available functionality. Each action provides some observable and valuable result to the actors of the system.

However the UCDs cannot replace sequence diagrams or flow charts because they are fundamentally different. UCD cannot be used

-          When you wish to represent a sequence of steps needed to complete a task or when a error occurs. Use Sequence diagrams.

-          When flow should be depicted in a linear time based way. Use Flow charts.

Use case diagrams are used to specify:

-          External requirements on a subject, required usages of a system - to capture what a system under construction is supposed to do;

-          the functionality offered by a subject – what system can do;

-          Requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services.

UCDs have only 4 major elements

1. The actor - specifies a role played by an external entity that interacts with the system, a human user of the designed system. All actors must have names according to the assumed role. Customer, Student, Passenger etc are sample actor names


2. The system – Describe a system/subject that does some business process. Examples of systems:  Web Site, Payment System etc


3. The use cases - Specifies behavior of a system by describing a set of sequences of actions performed by the system to yield an observable result of some value to actors of the system. Examples of use case names are Place Order, Update Subscription, Transfer Funds etc


4. The lines - Represent relationships between different elements of UCD.

Pictorial representation of Major elements of the use case diagram is:

Image Credit : Google

Once you have studied the main components of UCD, now it is time to build one UCD. The initial step is to identify all of the high-level behavior of the system you wish to depict through the UCD. Once you have described details in a high-level way you should get an idea of how to draw UCD. At every stage of development, the UCD will depict a complete description of the system's functionality. It may lack some detail, but it should cover most features of system. And if functionality or behavior is added or deleted over the life of your project, the scope of the change you need to make is proportional to both the scope of the change in the system itself, and the maturity of your model. You can continue to add detail by decomposing your use cases into more use cases which are used by the top-level use cases. Below is how a sample Use Case and Flow Chart will look for driving a car.

Image Credit : Google

Image Credit : Google

To Conclude UCD are best diagrams when you wish to depicts behavior of the system or structural relationships.





Reference

http://www.uml-diagrams.org/use-case-diagrams.html

http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html

SIPOC stands for suppliers, inputs, process, outputs, and customers

A SIPOC (sometimes COPIS) is a tool or template that summarizes the inputs and outputs of one or more processes in a tablular form. In other words it can be used to define a process before we begin to measure or improve it. The acronym SIPOC stands for suppliers, inputs, process, outputs, and customers which form the columns of the table.

This tool is used whenever some process management or improvement activity is planned because this tool helpsto get a high level understanding of the proces scope.  Mostly Kaizen events or "define" phase of the DMAIC process use SIPOC tool to define and understand the boundaries of process being worked on.

SIPOC use can be categorized base on the audience:

• To give high level overview for people unfamiliar with a process or act as a ready reckoner for refreshing the overview of system.


• To help define a brand new process

Before creating a SIPOC process, do the following:

1. Finalize the name of the process. Use a Verb + Noun format (e.g. Recruit Staff).


2. Identify the Outputs of the process. These are the tangible things that the process produces (e.g. a report, or letter).


3. Identify the Customers of the process. These are the people who receive the Outputs. Every Output should have a Customer.


4. Define the Inputs to the process. These are the things that trigger the process. They will often be tangible (e.g. a customer request)


5. Define the Suppliers to the process. These are the people who supply the inputs. Every input should have a Supplier. In some “end-to-end” processes, the supplier and the customer may be the same person.


6. Define the sub-processes that make up the process. These are the activities that are carried out to convert the inputs into outputs. They will form the basis of a process map.

Image Credit : Google

Some examples of SIPOCmodel are

Onsite – Offshore Coordination: The client (Supplier) sends the specification document. The documents are received by the onsite coordinator which serves as the input (Input). The inputs may be in the form of PPT, Un-standardized Flows, Process Narratives, etc. If any clarification is required to understand the business for drafting the flows, then a brain storming session is arranged with the coordinator to get the doubts clarified. Once the doubts are clarified then the business flows are drafted according to the methodology agreed by the team (Process). Then the finalized Business process flows are reviewed and sent to the Onsite coordinator (Output). The final report is sent to the Clients (Customer).

Account Activation in a Bank: Suppliers involved in account activation are Customers, New account activation system. So the suppliers send input information to the Customer Service Representative. The customer service representative gathers the Inputs in the form of Customer Account Number, Customer Identity details and Customer Relationship Type (Joint, Merchant, and Third Party etc), etc. So with the gathered information various processes are performed which form the core of account activation. After the processing is complete the Outputs in the form of Customer Notification, Card Activation status, Sales eligibility details, Account Activation status are sent to the Customers.

A SIPOC example in tabular form is

Process : Car Dealer Example
Suppliers	Inputs	Process	Output	Customers
Manufacture Gas Supplier Cars Fuels for Car Car Cleaners Meet Client Map their requirements to the car Present Options Identify Financing Options New Client Legal Contract				1.Car buyer2.Car Renter

Above is a simplified example of a SIPOC. In practice, you may need to include several other suppliers (e.g. Shops to supply spare parts, Credit Rating Agency to assess old cars) and other customers (Company, Government Departments).

Test Case Development

Today’s organizations rely heavily on information technology (IT) systems and are exposed to every kind of information flooding into the business world. Besides, there are reports of faulty systems and their associated problems, resulting in inconvenience, misinformation, loss of information etc. Like any other service or commodity used by us, the importance of quality is beyond question and software quality is no exception and needs to be addressed seriously. Software failures can be dangerous, costly and sometimes even result in loss of lives. Therefore, software development should always be accompanied by comprehensive & thorough testing to detect software failures and prevent faults from flowing through the final production system. In order to do an effective testing, an effective test case lays a very good foundation

Image Credit : Google

A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test result. A test case is usually a single step, or occasionally a sequence of steps, to test the correct behavior/functionalities, features of an application. An expected result or expected outcome is usually given.

A test case is developed at a minimum for each business case from a functional viewpoint. There may be one or more uses cases per requirement.  There may be a need to write test cases for non-functional requirements. In effect one requirement may have many test cases, which map to it. A top down approach will be used in the development of test cases.

Additional information that may be included in while creating a test case document are:

• Test Case Identifier


• Test Case Name


• Priority


• Creator


• Date of creation


• Mapping to Requirement Number


• Test Type (Regression / BVT/ Deployment / Installation etc)


• Automation Flag


• Test Script ID


• Overview, Scope and Objective of Test Case


• Pre-requisites


• Test Case Steps


• Input Specifications


• Expected Result and Actual Result.


• Pass/fail


• Remarks

These steps can be stored in a word document, excel spreadsheet, database or tools such as Quality Center etc. A Important and commonly missed test cases are the conditions of negative testing. This is to determine that end users, cannot compromise applications and data that are created and handled by the applications. Functionality testing is designed to ensure that  applications do what they are supposed  to  do,  whereas  the  purpose  of  negative  testing  is  to  check  that applications do not do what they are not supposed to do.

To conclude, a test Case documents the functionality to be tested. The most time consuming part in the test case is creating the test data to test the case and modifying the cases when the system changes. Once the tests are done by testers, end-users or clients of the system test their own test case to ensure the developed system meets the requirements specified in the contract. The testers understanding of the system/business and proper documentation/testing of positive/negative test cases will result in a WIN WIN situation for all the stakeholders. .