Use Cases

I.
Groupon sample Use Case Diagram
Groupon is a popular deal-of-the-day website that feature discounted offers that could be used at local or national companies.

II.

Groupon from Irwin Dayak

III.
1. Groupon can be classified as a TPS or Transaction Processing system

Users can obtain deals daily and Groupon updates their offers often

2. Groupon can also be classified as a DSS or Decision support system

Groupon also handles other business' marketing

IV.
Interview on Eric Lefkosky co-founder of Groupon

I learned from the interview that is important to build a solid base. An entrepreneur can't keep on pursuing bigger and better things if its base keeps crumbling. Another important lesson from the interview is very simple. You must keep firm and stay on course as your business morphs and shifts. Being persistent pays off. As the co-founder of Groupon states that mobile may be the next big thing I also agree to it. Something as small as an object that can fit in you pocket can have enormous potential. In the future more and more things can get integrated into our mobile phones such as mobile purchases. This could introduce the next big thing, the mobile market.


Photo Sources:
www.groupon.com

Use Case Narratives

Identification Summary

Title: Report Project

Summary: By clicking the Report Project a user is attempting to report the project to an admin and await for further decisions.

Actors:

1. User – Reports the project

2. Kickstarter team/staff – evaluates project

3. Kickstarter system – external system that provides info about the project

Creation Date: October 18 2013

Version: v1.0

Person in Charge: Student

Flow of Events

Preconditions:

1. The User must have an account in Kickstarter

Main Success Scenario:

1. User logs in his/her account in Kickstarter.

2. User with his/her account in Kickstarter starts viewing projects by other people.

3. System displays all projects and its respective status.

4. User finds a project that which the user thinks may have violated some rules and regulations.

5. User clicks on Report Project button.

6. User fills out necessary details.

7. System picks up the request and notifies Kickstarter staff to check on it.

8. Kickstarter staff evaluates project if it is going above rules or simply wrong judgment.

9. User waits for further actions or decisions.

Alternative Sequences:

A4. User decides not to report project

1. User does not select any options available on the check box.

2. User closes checkbox.

Error Sequences:

E7. Project is already successfully launched/funded.

7. Kickstarter staff will have a different approach on the project.

8. Use case ends

E4. Project has been taken down or banned.

4. Use case ends

PostConditons:

1. A report for the Kickstarter staff has been created.

UI (User Interface) Requirements:

- Account

Identification Summary

Title: Fund Project

Summary: Fund a Kickstarter project via online payment

Actors:                       

1. User – Funds the project

2. Kickstarter team/staff – Process data concerning pledge amounts

3. Kickstarter system – external system that provides info about the project

4. Amazon payment system – external system that process online payment

Creation Date: October 18 2013

Version: v1.0

Person in Charge: Student

Flow of Events

Preconditions:

1.       The User must have an account in Kickstarter.

2.       The User must have a valid credit card.

Main Success Scenario:

1. User logs in his/her account in Kickstarter.

2. User with his/her account in Kickstarter starts viewing projects by other people.

3. System displays all projects and its respective status.

4. User finds a project that catches user’s attention.

5. User clicks on Back This Project button.

6. User inputs Dollar amount.

7. User selects reward tier.

8. User is satisfied by their choice and proceeds by clicking the Continue to Amazon button.

9. Amazon requests account information.

10. User inputs account information.

11. User proceeds to logging in.

12. User selects mode of payment and which credit card to use.

13. User clicks Confirm to continue.

14. User goes back to project page

Alternative Sequences:

A5. User decides not to fund the project.

1. User does not provide any information on payment and reward tier.

2. Proceeds to step 14

A9. User does not have an account in Amazon, thus creating one.

1. User selects 2^nd option in Amazon page.

2. User fills out necessary information.

3. Proceeds to step 10

A14. User would like to cancel/ change pledge.

1.  User selects Manage Your Pledge.

2. User inputs necessary information.

3. Proceeds to step 14

Error Sequences:

E7. Project is already launched/funded.

7. Button for Backing a project will not appear.

8. Use case ends.

PostConditons:

1. A project in Kickstarter would be funded.

2. User will be able to manage their pledge.

3. User will receive notification about project status.

UI (User Interface) Requirements:

- Account

Identification Summary

Title: Start a Project

Summary: Start a project for people to back.

Actors:                       

1. User – Starts the project.

2. Kickstarter Project Specialist – reviews project.

3. Kickstarter system – external system that provides info about the project.

4. Amazon payment system – external system that process online payment.

Creation Date: October 18 2013

Version: v1.0

Person in Charge: Student

Flow of Events

Preconditions:

1.       The User must have an account in Kickstarter.

2.       The User must have a valid credit card.

3.       The User must have a verified account in Amazon.

Main Success Scenario:

1. User logs in his/her account in Kickstarter.

2. User clicks Start a Project.

3. User fills out basic information.

4. User fills out backer rewards.

                Repeat step 4 until satisfied with multiple reward tiers.

5. User fills out more information.

6. User fills out necessary information about online payments.

7. Amazon Payments verifies account.

6. User submits complete information.

7. Kickstarter system notifies administrators.

8. Kickstarter Project Specialist reviews project.

9. Kickstarter Project Specialist approves project.

10. User launches Project.

Alternative Sequences:

A5. User decides not fill any information yet.

1. User does not provide any information.

2. Proceeds to step 6

A9. Project Specialist disapproves of project and requests change/editing.

1. Project Specialist informs user of problems.

2. User applies changes to better fit regulations.

3. Proceeds to step 8

Error Sequences:

E1. User is not eligible to start a project in Kickstarer due to location.

1. Ends case

PostConditons:

1. A new project in Kickstarter would appear.

UI (User Interface) Requirements:

- Account

User Case Diagram

My 1st attempt at a User Base diagram, the website i used is Kickstarter.com. Kickstarter is a website where people fund other people's projects.

Questions

I would like to tackle a few questions regarding Systems Analysis, certain systems, design processes, interviews and answer it with my own opinions. The first question asks about the technicality of a system analyst or how technical a system analyst must be. Being technical usually involves one being adept or knowledgeable at a specific subject, choosing practical methods over idealistic ones and use of practical tools. For me a system analyst can be both technical and not. It means that a system analyst should be technical but only to some extent but not limited to.

A system analyst has a unique blend of technical knowledge and other skills for it to become effective. Yes, they should be technical and possess technical knowledge but heavy technical jobs should be handled by programmers who are required to be technical throughout. The next question is about how a system analyst is different from the I.T. crowd and how different skills sets are required and what skills fit in both. The first common ground I can think of between I.T. roles and a system analyst is their technical knowledge and understanding of the digital world. Even as the I.T. role has a deeper knowledge about technical issues a system analyst would not fall far behind. A big difference between the I.T. role and System Analysis is the fact that I.T. personnel interact directly to the system analyst while the system analyst connects to different people; from users, to designers and even the decision making higher ups. In short system analysts possess interpersonal people skills, management skills, analytical skills and technical know-how. System analysts are not only good behind a keyboard for they are the people who connect different pieces of the organization to from a working system. Now to a different topic; a topic regarding roles and pyramids. In a large organization different roles are required and they are filled with people with the right skill sets.

The organizational Pyramid

These people depend on one another to keep things running smooth and well organized. An organizational pyramid is a guide to help understand the roles and the people that deal with them. Basically starting from the bottom going to the top different systems are required for they have specific needs and tasks to accomplish. A quick example would be the bottom level; they handle the day-to-day transactions and then record them and send it to someone higher for them to process. They would require a system that would allow them to accomplish this while being able to record and send it to the higher ups for processing. They all belong in different levels each with a different task and requirements and to fully accomplish their goals they require specific and goal-oriented system for them to operate at maximum capability. Now we move on to another question, this time regarding methodologies, documenting and designing software. First we need to consider 2 methodologies that are widely used, namely the Waterfall model then the Agile model. First method we are going to discuss is the Waterfall method, based on the name given to it one can easily assume it involves a process where it follows a stream going down or flows from a start point and an end point, the Waterfall method is a sequential design method. It is a simple and easily understandable.

In the Waterfall method one must complete the step before moving into the next one for completion of the step is a prerequisite for the next. It is a well-planned and rigid process. The Agile model is a flexible and people-oriented process. It is a process where freeform software design occurs. Developers work on small parts at a time while customer/client feedback happens simultaneously with development. As its name suggests it is agile, meaning quick to respond to a change in requirements or a shift in course. Now that we have the understanding of the two models we can compare them. The Waterfall model is best used when there is little chance of change in the customers’ requirements because if the customer does not require something new the Waterfall model could produce software quite quickly. Being a rigid model predictions which are fairly accurate is possible. One can estimate time, costs and other things. Another good thing about the Waterfall model is the fact that it is very secure since it requires a good amount of planning. Now the Agile model, since the agile model is very responsive it could adapt to any changes required by the customer regardless of step. Agile model is best used when the customer/client has not yet fully stated its needs and goals.  The main problem with the Agile model is its requirement for constant communication.  If the included members are not communicating properly it could make the task a lot more difficult. Now let us discuss the cons of the Waterfall model. Being a rigid model one could not easily alter a stage once it was completed because it would cause problems. Another problem is that user feedback is withdrawn till the end which will cause a problem if the customer/client requested something new which would make it difficult to adapt. Now which model is best? I would say either as long as used for best scenarios, like if a client has a plan already I would use Waterfall if not then Agile. Now the last question asks about one of the required skills of a system analyst. Being a good interviewer is required because you can get specific info from the client themselves for your design. A great interview happens when both parties get what they want. If an interviewee properly gets their thoughts and complains across the table properly and the interviewers getting all the info to start their task with ease then that would be a great interview.  A good interviewer usually addresses the right questions and follows the basic steps. One can become a good interviewer through practice.

sources:

http://istqbexamcertification.com/what-is-agile-model-advantages-disadvantages-and-when-to-use-it/

https://www.udemy.com/blog/agile-vs-waterfall/

http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/

http://www.cognitivedesignsolutions.com/Information/PlanningProcess.htm