This document describes several use cases for a social networking application for insurance agents:
1) Authentication - Allows users to log in by checking username and password against a database.
2) Registering Agents - Administrator registers new users by assigning them a username and randomly generated password.
3) Banning Posts - Administrator can remove irrelevant or obscene posts from the portal.
4) Most Valuable Agent - Administrator determines the highest rated agent based on ratings of their posts.
5) Checking Inactive Agents - Administrator can identify and notify agents who have not posted for a certain time period (e.g. 30 days) and remove their account details from the database.
Ranking fraud in the mobile Apps is nothing but the false or fake activities which are going to be done in Apps
popularity list for bumping up the fraud App . It is very easy for the App developer to use the fake App and fake rating
for commiting the ranking fraud . The research in ranking fraud of the mobile App is limited . For that purpose a
ranking fraud detection system and the App recommendation system is proposed . There are mainly three types of
evidences , Ranking based evidences , Rating based evidences , and Review based evidences . These evidences can be
obtained from Apps ranking , rating and review history .Then proposed an optimization based aggregation method for
integrating all these evidences for the fraud detection .In this way more effectiveness and regularity of the ranking
fraud detection system is obtained and the original App is recommended to the user.
SaaS Application development 70 percent faster at less than ½ the cost.
Requires No Up-Front Capital Expenses.
Minimizes Operational Cost.
Requires no coding and less Technical Resources.
Easy to Integrate and mashup
Ranking fraud in the mobile Apps is nothing but the false or fake activities which are going to be done in Apps
popularity list for bumping up the fraud App . It is very easy for the App developer to use the fake App and fake rating
for commiting the ranking fraud . The research in ranking fraud of the mobile App is limited . For that purpose a
ranking fraud detection system and the App recommendation system is proposed . There are mainly three types of
evidences , Ranking based evidences , Rating based evidences , and Review based evidences . These evidences can be
obtained from Apps ranking , rating and review history .Then proposed an optimization based aggregation method for
integrating all these evidences for the fraud detection .In this way more effectiveness and regularity of the ranking
fraud detection system is obtained and the original App is recommended to the user.
SaaS Application development 70 percent faster at less than ½ the cost.
Requires No Up-Front Capital Expenses.
Minimizes Operational Cost.
Requires no coding and less Technical Resources.
Easy to Integrate and mashup
Application development 70 percent faster at less than ½ the cost.
Requires No Up-Front Capital Expenses.
Minimizes Operational Cost.
Requires no coding and less Technical Resources.
Easy to Integrate and mashup.
Introduction to WOLF Platform As A ServiceCloudComputing
WOLF Frameworks has introduced a path breaking platform which allows business analyst, domain experts to design & deliver all sorts of business applications over the internet without writing a single line of technical code (no scripts).
Presentación utilizada en la Conferencia ICT in Education, celebrada en la Universidad de LIT en Thurles (Irlanda) en la que se habla sobre el proyecto TACCLE 2.
Eating Disorder In Teens M Jacob 2008 Mda TestMelanieJacob
Promising approaches in the treatment of eating disorders.
This presentation was done at the Michigan Dietetics Association meeting to an audience of registered dietitians.
Software Requirements ElicitationRequirements specify a set of f.docxwhitneyleman54422
Software Requirements Elicitation
Requirements specify a set of functions a software development project must deliver. Functional requirements define system capabilities, for example, “The system shall permit users to inquire about Berta’s Pizzeria menu via an email message.” Additionally requirements specify non-functional standards that the system must operate within. Examples of non-functional requirements are performance, quality, safety, security, and interface requirements. An example of a performance requirement is, “The system shall have the ability to process 1MB/sec of input.” An example of a quality requirement is, “The MTBF (mean time between failures) shall be greater than 90 days.”
The iterative and incremental development processes of agile methods permit frequent changes to requirements and documentation. Early requirements analysis is required only for features developed in early iterations. Scrum and XP are agile methods that facilitate requirements gathering flexibility. Agile methods require direct involvement of the end-user though-out the software lifecycle. The requirement elicitation differs depending on the agile methodology used. The Unified Process (UP) creates use cases as requirements. Scrum records initial requirements in the form of a product backlog and prioritises them. Extreme Programming (XP) derives user stories and organizes them on a corkboard, or storyboard into deliverables for each iteration.
Requirements elicitation is considered the most difficult part of a development project. The Importance of identifying correct requirements is valuable to the both software developer and the customer. Systems delivered according to incorrect or inadequate requirements may be disparaging to the development organization and disappointing and wasteful to the client. Difficulties with requirements elicitation and analysis include:
1. lack of domain knowledge by the development team
2. Users are not knowledgeable of software capabilities
3. A communication disconnect between the users and the development team
4. Stakeholders cannot definitively specify the requirements
5. Stakeholders underestimate the importance of requirements gathering
6. Nonfunctional requirements are not addressed
7. Stakeholders alter the requirements during the software lifecycle
Requirements elicitation steps include:
1. collection of application information
2. optionally building analysis models
3. developing requirements and constraints
4. feasibility study
5. requirements specification review
The collection of application information involves inquiries about internal and external influences on the business environment, policies, regulations, business goals, and standards. Analysis models may be constructed to understand the business processes and objectives. The customer or user plays a critical role in driving and prioritizing requirements to satisfy the business needs. When the practicability of implementing particular requirements is in q.
The project “Passport Automation System” is used in the effective dispatch of passport to all of the applicants. This system adopts a comprehensive approach to minimize the manual work and schedule resources, time in a cogent manner. The core of the system is to get the online registration form (with details such as name, address etc.,) filled by the applicant whose testament is verified for its genuineness by the Passport Automation System with respect to the already existing information in the database.
It aims at improving the efficiency in the Issue of Passport and reduces the complexities involved in it to the maximum possible extent.
Application development 70 percent faster at less than ½ the cost.
Requires No Up-Front Capital Expenses.
Minimizes Operational Cost.
Requires no coding and less Technical Resources.
Easy to Integrate and mashup.
Introduction to WOLF Platform As A ServiceCloudComputing
WOLF Frameworks has introduced a path breaking platform which allows business analyst, domain experts to design & deliver all sorts of business applications over the internet without writing a single line of technical code (no scripts).
Presentación utilizada en la Conferencia ICT in Education, celebrada en la Universidad de LIT en Thurles (Irlanda) en la que se habla sobre el proyecto TACCLE 2.
Eating Disorder In Teens M Jacob 2008 Mda TestMelanieJacob
Promising approaches in the treatment of eating disorders.
This presentation was done at the Michigan Dietetics Association meeting to an audience of registered dietitians.
Software Requirements ElicitationRequirements specify a set of f.docxwhitneyleman54422
Software Requirements Elicitation
Requirements specify a set of functions a software development project must deliver. Functional requirements define system capabilities, for example, “The system shall permit users to inquire about Berta’s Pizzeria menu via an email message.” Additionally requirements specify non-functional standards that the system must operate within. Examples of non-functional requirements are performance, quality, safety, security, and interface requirements. An example of a performance requirement is, “The system shall have the ability to process 1MB/sec of input.” An example of a quality requirement is, “The MTBF (mean time between failures) shall be greater than 90 days.”
The iterative and incremental development processes of agile methods permit frequent changes to requirements and documentation. Early requirements analysis is required only for features developed in early iterations. Scrum and XP are agile methods that facilitate requirements gathering flexibility. Agile methods require direct involvement of the end-user though-out the software lifecycle. The requirement elicitation differs depending on the agile methodology used. The Unified Process (UP) creates use cases as requirements. Scrum records initial requirements in the form of a product backlog and prioritises them. Extreme Programming (XP) derives user stories and organizes them on a corkboard, or storyboard into deliverables for each iteration.
Requirements elicitation is considered the most difficult part of a development project. The Importance of identifying correct requirements is valuable to the both software developer and the customer. Systems delivered according to incorrect or inadequate requirements may be disparaging to the development organization and disappointing and wasteful to the client. Difficulties with requirements elicitation and analysis include:
1. lack of domain knowledge by the development team
2. Users are not knowledgeable of software capabilities
3. A communication disconnect between the users and the development team
4. Stakeholders cannot definitively specify the requirements
5. Stakeholders underestimate the importance of requirements gathering
6. Nonfunctional requirements are not addressed
7. Stakeholders alter the requirements during the software lifecycle
Requirements elicitation steps include:
1. collection of application information
2. optionally building analysis models
3. developing requirements and constraints
4. feasibility study
5. requirements specification review
The collection of application information involves inquiries about internal and external influences on the business environment, policies, regulations, business goals, and standards. Analysis models may be constructed to understand the business processes and objectives. The customer or user plays a critical role in driving and prioritizing requirements to satisfy the business needs. When the practicability of implementing particular requirements is in q.
The project “Passport Automation System” is used in the effective dispatch of passport to all of the applicants. This system adopts a comprehensive approach to minimize the manual work and schedule resources, time in a cogent manner. The core of the system is to get the online registration form (with details such as name, address etc.,) filled by the applicant whose testament is verified for its genuineness by the Passport Automation System with respect to the already existing information in the database.
It aims at improving the efficiency in the Issue of Passport and reduces the complexities involved in it to the maximum possible extent.
cuACS Requirements Analysis Document Nicholas Aubé.docxdorishigh
cuACS
Requirements Analysis Document
Nicholas Aubé 101032093
Ibiduneyitayo, 101018199
Peter MacDonald, 100683150
Submitted to:
Dr. Christine Laurendeau
COMP 3004 Object-Oriented Software Engineering
School of Computer Science
Carleton University
1
Table of Contents
Introduction + Overview of Document…………………………………………………………………………….1
Functional Requirements…………..……………………………………………………..……………………………..2
Non-functional Requirements………………………………………………………………………………………2-4
Use Case Model…………………………………………………………………………………………….……………4-15
Object Model……………………………………………………………………………………………………………...…16
Introduction
The cuACS program is designed to find the best possible matches between a variety
of different animals and clients that are looking for a new pet. The Carleton University
Animal Case System will revolutionize the way that we adopt animals. The main advantage
of the cuACS system is the dynamic algorithm that matches shelter animals and human
clients based on compatibility factors such as habitat, size, and temperament. The
algorithm is optimized to create the largest number of sufficient matches, not just one or
two perfect ones. The cuACS program will allow clients to look at animal profiles and edit
their own detailed profiles. There will also be functionality to manage client profiles and
animal preferences. There are even multiple types of users that can access the system, staff
and clients. Both types of users have different permissions, which will be managed by the
system.
This report will cover many different aspects of the cuACS system, including an
overview of the program, functional and non-functional requirements, the user case model
and the object model.
2
Functional requirements
Traceability: functional requirements are preceded by the letter F when referred to in
other sections of the requirements analysis. E.g. F-1.1 refers to the staff interaction 1.1
functional requirement.
1. Staff interactions
1.1. Staff should be able to add new animals and clients
1.2. Staff should be able to view client and animal information
1.3. Staff should be able to edit animal and client profiles
1.4. Staff should be able to start the Matching algorithm process
1.5. Staff should be able to view a summary of matches made by the Matching algorithm
1.6. Staff should be able to view the details of a specific match made by the algorithm
2. Client interactions
2.1. Clients can view and edit their profile
2.2. Clients can view animal profiles
3. Algorithm
3.1. There should be an algorithm that can create optimal matches between clients and
animals
3.2. The algorithm should look at client preferences and match them with animal traits
3.3. The algorithm should attempt to create the largest number of acceptable matches
possible rather than a small number of extremely compatible matches.
3.4. The algorithm should provide output in a for.
Design Implementation Proposal
Design Implementation Proposal
***Some of the Material in this paper has been repurposed from IT with Professor Stewart and CS455 with Professor Lemaster, and IT251 with Professor Noffsinger ***
CS377-1503-A-01 Software Design
Phase 1 Individual Project
Design Implementation Proposal
Damon Tholson
July 18th, 2015
Design Implementation ProposalFor<Legacy Equipment Corporation>
Version 1.2 approved
Prepared by <Damon Tholson>
<Ethical Company Finder>
<July 21st, 2015,>
Revision History
Name
Date
Reason For Change(s)
Version
Damon Tholson
July 18, 2015
Original Document
1.0
Damon Tholson
July 21, 2015
Phase Two Class Diagram Implementation
1.1
1.2
1.3
1.4
Table of Contents
Revision History 3
1.0 Project description 4
1.1 Use Case Diagram 6
Introduction 6
Use Case Model Actor Description and intended interactive role 6
Relationships between the actors and the use case 7
1.2 Use Cases 9
2.0 Class Diagram 13
3.0 Sequence and Collaboration Diagram 15
4.0 State Transition and Activity Diagram 16
5.0 Follow-Up Discussion on Use of Object-Oriented and Recap of Design Changes 19
References: 20
1.0 Project description
The Ethical Company Finder application will allow the US government to sell otherwise wasted byproducts of the chemical munitions process to companies which operate ethically and set a standard for honest business practices. Thiodiglycol is most commonly used as a common solvent in the paint and coatings industry however, it can also be used for more devious purposes (i.e., the reproduction of mustard gas) and a system is needed to identify industrial companies who will purchase and use the chemical in a safe and ethical manner. Therefore, in order to sell this chemical for a profit, a software service must be developed which will create a “whitelist” (list of allowed, rather than prohibited) companies which meet a given set of conditions set forth by the US government. Companies which meet the minimum criteria, to include such things as good credit, a reputation of honest business practices, and no lawsuits regarding company behavior within the past ten years, will be considered for the whitelist service. Once companies are whitelisted they will be allowed to bid on the chemical with the software service calculating factors such as quantity of selected product, cost and distance of shipping, location of the product destination, the required route for the product to reach the customers destination, and the price the customer is willing to pay to determine which company to sell the product to and how much to sell them.
1.1 Use Case Diagram1.2 Introduction
Within every individual use case there are specified actors and roles which those actors play. In the following paper the names of those actors will be specified and a description of how they interact with the software service will be provided. It should be noted that only current customers are within scope with current customers bei.
Scenario OverviewAn airline company is looking for a PRP.docxanhlodge
Scenario Overview
An airline company is looking for a PRPC implementation to administer their Frequent Flyer Program called Sky-Kilometers.
Actors
1. Frequent Flyer Member – Can access and administer their account online, is able to use services such as request missing kilometers, file complaints, etc.
2. Customer Service Representative (CSR) – Acts on the requests from Frequent Flyer Members
3. Benefits Manager – Manages benefits and rules associated with the benefits. They can also run reports and handle all escalations by CSR’s
4. Customer Service Manager – Decides on disciplinary actions for complaints. They can also run reports
Process Overview
Frequent Flyer members should be able to:
View their flight history
Update their contact and personal information File a complaint request
Request missing kilometers
Detailed Requirements
Members of the Sky Kilometers program login to Sky Kilometers’ PRPC application where they can view their member ID, membership status, and total kilometers.
The system assigns the membership status: Silver, Gold or Platinum based on kilometers accumulated.
View recent account activity
The recent account activity view displays the flights flown by the member with the number of kilometers flown as well as the number of kilometers awarded for each flight.
1
Update contact information
The users can update their contact information such as their home and cell phone numbers and email. They can also update their payment information such as their credit card number, expiration date and CVV number.
Enter a missing kilometers request
Enter a request for missing kilometers consisting of origin and destination, and the date. Requests for missing kilometers are sent to a work basket. The Get Next Work functionality is used to retrieve work from the work basket. Requests are prioritized after member status and request date (oldest first).
The requests for missing kilometers are sent to a CSR who either approves or rejects it. The member is notified of the result by email.
Enter a Complaint
Enter a complaint consists of a category and a description. Complaints are categorized in: Crew behavior, cleanliness, flight delays, and other. A complaint is assigned to a CSR who can escalate it to the Benefits Manager, or reject it. The Benefits Manager can reward bonus kilometers for complaints. The Frequent Flyer Member receives an email response to his complaint, unless it was rejected. If the complaint is related to crew behavior an additional process is started in parallel allowing a Customer Service Manager to review the complaint and take disciplinary actions if necessary. The claim is closed when both processes are complete.
2
Complaints submitted are sent to the CSR with least amount of work in the work list for review. In addition, complaints for crew behavior are routed to the Customer Service Manager for.
2. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-AUTHENTICATION
BREIF DESCRIPTION:-
This use case is to provide a secure mechanism of users logging in into the portal; it will
allow only the registered users to sign in into the portal by checking in their details with
the requisite database.
ACTORS INVOLVED:-
1. Questioner
2. Answerer
3. Administrator
PRE CONDITION:-
1. The particular ACTOR must have a user name and password.
BASIC FLOW OF EVENTS:-
1. The use case begins when the actor selects the login screen from the home page.
2. The actor enters the details i.e. username and password.
3. The application checks for the correctness of username and password from the
requisite database.
4. The use case ends.
ALTERNATE FLOW OF EVENTS:-
1. If in step3 of the basic flow the application confirms a valid actor.
Then allows the actor to navigate to the next page.
Or
The application responds with a error message to the actor.
PRE CONDITION:-
3. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-REGISTRING AGENTS
BREIF DESCRIPTION:-
This use case is to provide a mechanism for the administrator to provide authentication
for new users who wants to register to the web portal. Administrator provides a password
with a particular username the new user has desired.
ACTORS INVOLVED:-
1. New User
2. Administrator
PRE CONDITION:-
1. The Administrator must be complete the authentication use case.
2. The new user must provide all the details
BASIC FLOW OF EVENTS:-
1. The use case begins when the new user selects the register button from the login
screen.
2. The new user fills in all the details.
3. The application checks in all the details
4. The use case ends.
ALTERNATE FLOW OF EVENTS:-
1. If in step3 of the basic flow the application checks all the details of the New user
if found valid then.
Application generates a password and the new user is alerted with the
confirmation through the administrator.
Or
The application responds with a error message to the administrator and
new user is not registered.
POST CONDITION:-
1. The application adds a new user to the portal
4. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-BANNING POST
BREIF DESCRIPTION:-
This use case is to provide a mechanism for the administrator to remove a particular
irrelevant or obscene post(question or answers) from the poartal
ACTORS INVOLVED:-
2. Administrator
PRE CONDITION:-
1. The Administrator must be complete the authentication use case.
2. There must be an actor completing the post use case
BASIC FLOW OF EVENTS:-
1. The use case begins when the administrator checking for the relevance of the post
manually.
2. If found irrelevant the administrator select the BAN option along the post.
3. The particular post is removed
4. The use case ends
ALTERNATE FLOW OF EVENTS:-
Not Applicable
POST CONDITION:-
1. The application generates a warning to the initiator of the post.
5. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-MOST VALUABLE AGENT
BREIF DESCRIPTION:-
This use case is to provide a mechanism for the administrator to judge the most valuable
agent among all the registered agents. The process is carried forward on the basis of the
ratings of post given to the all the agent’s posts.
ACTORS INVOLVED:-
1. Administrator
PRE CONDITION:-
1. The Administrator must be complete the authentication use case.
BASIC FLOW OF EVENTS:-
2. The use case begins when the administrator selects the option for the best agent.
3. The application sums up the rating of all the posts for all the agents
4. The application selects the agents with the highest rating value.
5. The particular agent is addressed by the administrator.
ALTERNATE FLOW OF EVENTS:-
NOT APPLICABLE
POST CONDITION:-
1. The application generates congratulatory message to the best agent adjudjed.
6. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-CHECK FOR INACTIVE AGENTS
BREIF DESCRIPTION:-
This use case is to provide a mechanism for the administrator to check for agents who
have not posted anything for particular time span and disallow them from taking any
further part in the portal activity.
ACTORS INVOLVED:-
1. Administrator
PRE CONDITION:-
1. The Administrator must be complete the authentication use case.
2. The agents in check should be at least 30 days old subscriber.
BASIC FLOW OF EVENTS:-
1. The use case begins when the new administrator selects the inactive agent button
2. The application checks the last posted dated for all the registered users who are 30
days old subscriber.
3. The application generates the list of all the users who have not posted for the
particular time span.
4. The particular agents are notified by the administrator.
5. The use case ends.
ALTERNATE FLOW OF EVENTS:-
NOT APPLICABLE
POST CONDITION:-
1. The application removes all the details of the inactive agents from the database.
2. The agents creditability as a valid user is removed.
7. SOCIAL NETWORKING APPLICATION FOR
INSURANCE AGENTS
USE CASE:-CHECK FOR INACTIVE AGENTS
BREIF DESCRIPTION:-
This use case is to provide a mechanism for the administrator to check for agents who
have not posted anything for particular time span and disallow them from taking any
further part in the portal activity.
ACTORS INVOLVED:-
1. Administrator
PRE CONDITION:-
1. The Administrator must be complete the authentication use case.
2. The agents in check should be at least 30 days old subscriber.
BASIC FLOW OF EVENTS:-
1. The use case begins when the new administrator selects the inactive agent button
2. The application checks the last posted dated for all the registered users who are 30
days old subscriber.
3. The application generates the list of all the users who have not posted for the
particular time span.
4. The particular agents are notified by the administrator.
5. The use case ends.
ALTERNATE FLOW OF EVENTS:-
NOT APPLICABLE
POST CONDITION:-
1. The application removes all the details of the inactive agents from the database.
2. The agents creditability as a valid user is removed.