Vision and Scope

The vision and scope document”collects the business requirements into a single deliver-able that sets the stage for the subsequent development work” [30]. In this section, the project scope is defined at high level, then stakeholders are identified, thus clarifying the business benefits of this system.

In the first place, the system attempts to innovate the teamwork synergy of the case soft-ware company. The result is a transformation from old-fashioned manual to softsoft-ware utilization, which is both modern and helpful. It will enhance customer service, keep the information in synchronization among members of organization, allow customer service agents to keep track of their customer interactions, improve work efficiency, and build some foundation to measure the productivity. Furthermore, the system can be generalized to adapt other types of company that requires customer support, rather than only software ones. The table below elaborates the as-is work process and to-be one that this system targets to achieve upon completion.

Table 3.The as-is and to-be characteristics

As-is To-be

Lack of ubiquitous and organized channel of communication, causing loss of infor-mation

Establishment of formal communication mechanism, keeping knowledge stream-lined

Customer interactions go through with manual tracking, which consumes consid-erable amount of time

Detailed history of customer feedback and interactions with company staff Same or similar problems occur again

and again without awareness, underlying technical debts stay unnoticed

Detailed history, custom categorization of recurring issues

High turnover rate leads to additional cost of training new CS agent

Custom categorization of recurring issues can be utilized as an effective method of documentation

Tasks may pass through unmonitored, or staff may simply forget some periodical tasks. For example, CS agent usually asks for customer feedback and contract re-newal as the contract is expiring

Task management and reminder function-alities

This research utilizes Activity Theory to analyze requirements by understanding the con-textualized human activities. Activity Theory is defined by Kuutti as ”a philosophical and cross-disciplinary framework for studying different forms of human practices as de-velopment processes, both individual and social levels interlinked at the same time”[31].

The triangular figure below is an example of the structure of the most basic activity in this system: a customer submit a ticket of bug report or feature request. A key principle of ac-tivity theory is that a human acac-tivity is the basic unit of analysis. An acac-tivity indicates that a subject (individually or collectively) transforms an object into an outcome. Tools play the role of mediating the transformation process. The subject does not exist in isolation but have ones who share the same object (community). The relationship between subject and community is mediated by rules - which are conventions and policies that regulate ac-tivities in the system. Finally, the relationship between object and community is mediated by division of labour, which means the role of each individual in the community [31].

Figure 4.Activity of customer submitting a ticket

The figure below illustrates how to perform an activity from the root. The dashed line depicts the breakdown of a complex activity into small sub-activities, while the arrow line represents the sequence relationship that one action must be performed after another. This figure reflects how the case company deals with a customer issue explicitly step-by-step.

Figure 5. Hierarchical decomposition of resolving a customer ticket

For better clarification purpose, since this chapter, the meanings of several terms in system context are explained in the table below, to avoid any misunderstanding:

Table 4.Glossary of terms used in system

Term Meaning Value

Ticket An encompassment of a particular prob-lem or request reported by customer. For example: Button X does not work as ex-pected and yields unknown error

Aid CS agent to quickly lo-cate and communilo-cate with customer about their problem or request, call out for solu-tion in background

Ticket sector The categorization of ticket that regards the component involved to resolve the re-ported ticket. Examples of ticket sector:

back-end error, system fault, integration error

Easy determinant of account-ability of matter

Issue A template describes the classification of tickets. Every issue is already drawn with a systematic internal process to deal with.

An issue is driven by solving particular problems for customer empirically. For example: recurring defect X is repro-duced by specified steps, then assigned with a member from department Y, get-ting solved by following specified steps

Easy determinant of what to do with a ticket thanks to shared knowledge

Workgroup A collection of system users and their cooperative activities for internal shared goals. These activities include conversa-tions, comments, and tasks

High participation review, knowledge sharing, informa-tion closure from others

The table below briefly explains the intended major features that will be included in sys-tem upon completeness of this iteration.

Table 5.List of features

Feature name Benefits

Create, view, modify, and delete customer information

Keep track of customer information and collaboration activities with them

Create, view, modify, and delete ticket sector catego-rization of ticket

Classify customer problem or request to easily iden-tify the location of interest in software system

Create, view, modify, and delete issue categorization of ticket

Make a set of recurring customer inquiries that have been standardized to systematic response process Create, view, modify, and

comment ticket

Keep track of collaborative interactions with cus-tomers, provide communication between the software company and reporting customers

Report problem/request through ticket

Make a statement about a particular problem with company’s software

Create, view, and modify workgroup

Group members into a team to easily keep relevant information shared and well-structured

Create and comment on con-versation within workgroup

Make an announcement content about a certain topic relevant to workgroup, exchange information, express an opinion or reaction about the topic

Create, view, modify, and delete task

Keep track of what has been done and needs to be done, essentially in one place to follow and decide what to do next

Update profile Modify one’s own user profile

Grant employee account Provide an employee with an account with access to resources and usage of the system functionalities Authentication and

authoriza-tion

Confirm identity of employee through their creden-tials, verify whether they have access to particular re-sources and functionalities

Essentially, requirements engineering seeks to compromise rough and conflicting wishes of many stakeholders to a complete set of requirements. A stakeholder is defined as ”a person or organization who influences a system’s requirements or who is impacted by that system”[32]. The table below enumerates stakeholder profiles of the system, referencing template by Wiegers and Beatty [30].

Table 6.Stakeholder profiles

Stakeholder Major concerns Major values

Customer Effective and instant feed-back response goals, staying aware of cru-cial information and goals, staying aware of cru-cial information and objec-tives

Sharing opinions, controlling tasks, reminding others and themselves

A context diagram is used to define the system as a whole and its input and output. The system lies in the center of the diagram, surrounded by all its interacting systems, envi-ronments and activities. The objective of context diagram is to figure out boundary of the system with its external factors in order to develop a complete set of system requirements and constraints [33]. Basically, the context diagram is very high-level, determining the software system to-be-built and entities around without any internal details itself [34].

Figure 6. System context

The figure above pictures the context view of the system. There are three types of users who interact with the system, and no external systems at the moment.

Although business risks can be mitigated by comprehensive planning and timely execu-tion, nevertheless, the following risks are taken into consideration regarding the vision of the system:

• Employees resist to changes.

• Development and deployment of the system consumes time, causing delays as a consequence.

• Insufficient number of employees using the system will reduce the return on invest-ment from system developinvest-ment.