S oftw ar e R e q u i r e me n ts S p e c i fi c ati on

Software Requirements Specification for “PLANy” Page 1

Software Requirements Specification

for

PLANy

Version 4.0 approved

Prepared by Gultac Ibrahimova, Mubashar Iqbal, Musa Guliev, Stanislav

Sochynskyi, Veronika Vlasova

Tartu University

12.16.2018


Table of Contents

1. Introduction 6 1.1 Purpose 6 1.2 Intended Audience and Reading Suggestions 6 1.3 Product Scope 6 1.4 Definitions, acronyms, and abbreviations 7 1.5 Overview of the specification document 9 1.6 References 10

2. Overall Description 11 2.1 Product Perspective 11 2.2 Product Functions 12 2.3 User Classes and Characteristics 12

2.3.1 Actors dependencies in a traditional approach 12 2.3.3 Actors dependencies in the software-intensive system 13

2.4 Goal modelling 14 2.5 Design and Implementation Constraints 16 2.6 Assumptions and Dependencies 17

3. System Features 18 3.1 Functional Requirements 18 3.3 Use cases 27

3.3.1 Use case Diagrams 27 3.3.2 Use Case Summary 28

s3.4 Solution oriented requirements modelling 35 3.4.1 Class diagram 35 3.4.2 State diagrams 37 3.4.3 Sequence diagram 42

3.5 Traceability model 43 3.5.1 Traceability matrix for features and functional requirement 44 3.5.2 Traceability matrix for goals and use cases 47 3.5.3 Traceability matrix for use cases and solution-oriented requirements 47

3.5 Non-functional requirements 49

4. Prioritization 53 Estimate the eigenvalues 53 4.1 Cost matrix 53 4.2 Value matrix 54


4.3 Results 55

5. Prototyping 58

Appendix A: Requirements dependency shell 64

Appendix B: Document of the change request 66


Revision History Date Reason For Changes Version

10/12/2018 Prepared initial draft including: Introduction, purpose and scope of the system

1.0

10/13/2018 Included functional requirements, requirements prioritisation and traceability

1.1

10/14/2018 Included prioritization matrices Plots the priority of features on ROI graph Included use cases and their dependencies

1.2

10/22/2018 Added traceability matrix Added the traceability model and attributes Improved features prioritization attributes Improved the documentation glossary Features change management

1.3

11/06/2018 Defined major actors Updated glossary

2.0

11/07/2018 Defined Non-Functional Requirements (NFR) Stakeholder/actors dependency model

2.1

11/09/2018 Refined Non-functional Requirements Software-intensive dependency model Refined use case diagrams Refined use case summary Updated traceability model Updated glossary Updated versioning of functional requirements

2.2

11/11/2018 Updated description of actors dependency model in a traditional system Updated description of the software-intensive dependency model

2.3

11/16/2018 Updated the non-functional requirements description Update the PLANy user login use case

2.4

11/18/2018 Reviewed the document Updated the goals IDs

2.5

11/28/2018 Scope the problem for requirements Created a class diagram Created state diagrams Created sequence diagram Updated glossary

3.0


12/02/2018 Derived 4 new solution-oriented requirements from a class diagram Derived 10 new solution-oriented requirements from state diagrams Derived 4 new solution-oriented requirements from a sequence diagram Updated traceability model Update document versioning Update glossary

3.1

12/07/2018 Updated the scope of the class diagram Updated the scope of the sequence diagram Updated the class diagram Updated state diagram Updated sequence diagram

3.2

12/16/2018 Prototyping Updated glossary

4.0


1. Introduction This section provides the purpose of this document, details related to the scope that is covered by this SRS and listing the definitions, acronyms, and abbreviations.

1.1 Purpose

The purpose of this document is to create a detailed list of requirements of the skill called “PLANy” for the voice virtual assistant - Google Assistant. This document will capture different interactions with external applications and environment scenarios of usage, hardware requirements, different constraints, and Voice User Interface (VUI) prototype.

1.2 Intended Audience and Reading Suggestions

This document will be used to capture all stakeholders preferences as well as different conflicts and their resolution. It could be used in the development process by developers, conversation designers, testers, project managers, etc. This document could be used to create user documentation. It would be proposed to a customer and other stakeholders for its approval, that would be work as a reference guide of the system for the development of the system on different phases.

1.3 Product Scope

The “PLANy” is a Google Assistant skill which helps users in their day-to-day life to organize, plan and manage their time. The skill would work along with Google assistant to plan and manage the meetings by using the voice commands from the user and schedule it in a Google calendar. This skill is integrated within in Google Assistant and it is free of charge. With this application, it will be possible for users to plan, manage, revisit, set reminders when hands are not available. The skill will gather information about user preferences and store it at the server. For example, the preferred time of the meeting or work hours and learn to provide better service. The security of personal data and its transfer is guaranteed. As our application is using a Google assistant so Google assistant privacy policy and terms and conditions should be followed to make it compliance with it. This skill will be available across devices such as mobile phones, smart watches, smart speakers, TV, cars if Google Assistant is installed and access to the Internet is provided. The objects of PLANy that are relevant to the system include Google Assistant, Google Calendar, Gmail, and the users of PLANy.


The interaction with PLANy will not only happen by the users, but also the previously mentioned systems such as Google assistant, Gmail, and Google calendar. When the required voice or text command is given, the programs will complete it. The commands, which is given in accordance with the usage goals, will help the user to create and edit the daily plans. Upon receiving the command, Google Assistant will activate PLANy, and PLANy will modify the user’s calendar accordingly. In addition, due to private data protection laws, the systems will not share any of the information without the consent of the user. As per the design of our skill, neither the mobile nor the web or the desktop version required any designated hardware, and it does not have any direct hardware interfaces as the Google assistant application will run on the designated devices which would fulfil the requirement for the PLANy skill and underlying functions. Google Actions, which is a web-based Google assistant skill development tool, will be used for developing PLANy. Development, test, and publishing will be done on Actions Console, while the project is saved in Actions Project, which is maintained by Google in Actions project in a cloud backend. For the quality assurance, the initial method is ISO 9000 standard (it may be subject to change if there are shortcomings). Our application is using a Google assistant and is expected to acquire, analyze and store the private data of millions of people. Therefore, Google assistant privacy policy and terms and conditions should be followed to make it compliance with it.

1.4 Definitions, acronyms, and abbreviations

Term Definition

Google assistant Artificial intelligence based virtual assistant developed by Google

Skill/System An application which provides a separate feature for Google Assistant

PLANy A skill for the Google Assistant integrated with different Google products, which allows the users to manage and track their time

User A person which interact with the PLANy

Adventure An event/meeting in Google Calendar which have purpose, time, date, location and list of invited people

Notification Push alert related to different adventures

Contact Contact of the user in Google account

Template A pattern for invitation message


VUI Voice User Interface

SRS Software Requirements Specification

DEP Dependency

User phrase The sentence which user tell to the PLANy skill by voice command

User Request A request which user send by voice command to PLANy cloud

Time of the adventure A start and end time of the adventure

Date of the adventure A start and end date of the adventure

Type of the adventure It is a categorization of the different adventures like meeting, workshop, shopping, doctor visit and other personalized categories which use will set

Adventure participants These are those people who will be invited to the meeting

User preferences These are the user personalized settings like time of notification, enable not to disturb time, disable not to disturb time

Notification timing It is time of notification alert which user will set by their own preferences

Not to disturb mode Mode during the period of time when the user does not want to receive notifications

PLANy cloud It is a backend server which stores the data about PLANy customers and available features

Google ML cloud It is a set of machine learning tools to interpret the voice command of a user and generate a reply

User inactivity When the user does not perform any action to interact with the skill

Personalised permissions

Individual permission granted to adventure attendees for changing the details of the

Access control Ability to grant access to other users to see personal info

Confidentiality Privately keeping the personal information of the user

Audit trail a subsystem that tracks and records logs

Security alert alert notification sent to the user


V1.3.F1.V1.1 This scheme presents the version of functional requirements. The first part of this scheme (i.e. V1.3) presents the SRS document version and the second part (i.e. F1.V1.1) presents the functional requirement id (i.e. F1) and version (i.e. V1.1).

V2.NFR1.V2.1 This scheme presents the version of non-functional requirements. The first part of this scheme (i.e. V2) presents the SRS document version and the second part (i.e. NFR1.V2.1) presents the non-functional requirement id (i.e. NFR1) and version (i.e. V2.1).

Relationship Defines a relationship between functional requirements and non-functional requirements

Attendee Participant of the adventure who receives notification on the adventure details and given a choice to confirm or not. One role of the user.

Attacker A person who attacks the system to disable it

Misuse case Misuse case is an inverse of use case, and it represents an attacker actions

TBD To be determined

G Goal

GSI The goal indicates a software-intensive system

GSD The goal indicates a stakeholder dependency

SOR Solution oriented requirements

F2-SOR1 This is a unique id of our feature 2 solution oriented requirements. F2 indicate feature and SOR1 indicate solution oriented requirement.

Table 1. Definitions, acronyms, and abbreviations

1.5 Overview of the specification document

The rest of this SRS document is organized as follows.


The second chapter is an overall description of the system, including the product perspective, product functions, user classes, constraints, and assumptions. The third chapter is illustrating the features of the system including functional requirements and traceability, also includes solution-oriented requirements and non-functional requirements. The fourth chapter is about the prioritization. The fifth chapter includes the prototyping and the last chapter includes the appendix.

1.6 References

1. Ali, N., & Lai, R. (2017). A method of software requirements specification and validation for global software development. Requirements Engineering, 22(2), 191–214.: https://doi.org/10.1007/s00766-015-0240-4

2. Google Assistant official web page: https://assistant.google.com/#?modal_active=none 3. “Cost & value calculation.xls”:

https://docs.google.com/spreadsheets/d/1d-w1loQk8EBZYEtgEukh_aWUlToPLGzqn1xZbX0-2KM/edit#gid=1098345589

4. Oachim Karlsson Focal Point AB & Kevin Ryan University of Limerick (1997): http://www.cse.msu.edu/~chengb/RE-491/Papers/cost-value-prioritizing-reqts.pdf

https://doi.org/10.1007/s00766-015-0240-4

https://assistant.google.com/#?modal_active=none



http://www.cse.msu.edu/~chengb/RE-491/Papers/cost-value-prioritizing-reqts.pdf


2. Overall Description This section would provide an overview of the overall system, it also details how the system interacts with other systems or sub-systems and associated product functionality. It will also describe the user classes and characteristics, operating environment, a different type of constraints and in the last, the assumptions and dependencies.

2.1 Product Perspective

The main goal of this skill gives Google calendar user is to provide another way to plan and manage their schedule by voice or text command suggested by PLANy. Skill should be activated by Google assistant after the user voice request with the keyword “PLANY”. PLANY as a chatroom tracks audio request of the user into PLANy Cloud.

Figure 2.1 General description of the process flow


The skill functions have rather a similar process described by “Figure 1. General description of the process flow”. Skill interacts with Google Calendar Database, but for the additional functions such as Notification, it can also use Gmail. All the data transformation from voice to text, text to voice and PLANy learning will be processed by Google Machine Learning Cloud as integration with other platforms will be much more difficult and currently not capable to develop own tools. PLANy Cloud will be the backend of our skill. It will store information about customers (their preferences) and will have functions to communicate with other systems: Google Cloud, Gmail, Google Calendar database.

2.2 Product Functions

With that Google assistant skill, the users can manage meetings and to-do lists in their calendar by voice using special keywords. A core list of functions is: customize skill, create an adventure, add an adventure, delete adventure, edit an adventure, confirm the adventure, set reminder, notify invited people. Adventures are created based on the voice or tapped info received from the user. Every adventure has his own template which was chosen by the user or assigned by default. The user has a choice either notify invited people or not, set a reminder about the adventure or not.

2.3 User Classes and Characteristics

There is only one type of users for our system as they have the same functionalities. The user has the possibility to customize the system according to his need and preferences. The user can interact with the system with mobile application, web or desktop version. So far as the system is integrated with Google assistant which means that user should have a Google account. The main interests of the users are to plan and manage their schedule by voice command to facilitate their day-to-day life to organize, plan and manage their time when they are busy. The user sets the different preferences and settings, for example, preferred time of the meeting, work hours, reminders or not to disturb time.

2.3.1 Actors dependencies in a traditional approach

Figure 2.2 illustrates the actor dependencies model in a traditional approach. User: A person who wants to arrange a meeting Attendee: Participant of the meeting. One of the possible roles of the User. Calendar: paper calendar of the user where user plans her/his schedule. In the picture below (Figure 2.2) The main goal of the user is to plan and manage schedule in a more effective way. The user wants to arrange a meeting with certain attendees. He notifies attendees about a meeting.


Attendees reply about meeting in any form (phone, mail, pigeon post etc.). After negotiation about time, date, all attendees and user add the adventure/meeting to their calendar on their own.

Figure 2.2 Stakeholder dependency model

Goal ID Description

GSD1 Manage meeting

GSD2 Arrange meeting with attendee

Table 2.1 Goal table of stakeholders

2.3.3 Actors dependencies in the software-intensive system

The following model (Figure 2.3) indicating the actor's dependencies in a software-intensive system. Our model has four different actors: User: A person which interact with the PLANy Attendee: Participant of the adventure who receives notification on the adventure details and given a choice to confirm or not. One role of the user. PLANy skill: A skill for the Google Assistant integrated with different Google products, which allows the users to manage and track their time Google assistant: Artificial intelligence based virtual assistant developed by Google


In this system, the main interests of the users are to plan and manage their meetings/adventures. In PLANy, the user can manage their adventures, notify attendee and schedule a meeting. PLANy skill interacts with Google assistant which exist in this system as an agent for PLANy skill.

Figure 2.3 Software-intensive system dependency model

Goal ID Description Relationship Equivalent

GSI1 Adventure management by voice

recognition F2, F4, F5, F9, F10 Main goal

GSI2 Request for participant F8 G1.3

GSI3 To get the notification F3 G3

GSI4 User authentication F1 -

GSI5 Information request F6 -

Table 2.2 Goal table of software-intensive system

2.4 Goal modelling

For the goal modelling and subgoals defining the KAOS modelling construction is used. We start the modelling process with a goal “Schedule be managed” on the top. Questions how else and how to help us to find subgoals. For example, for “Schedule be managed” the alternative “Schedule be managed by hands” and “Schedule be managed by voice recognition” (G1) We


stop our goal refining process when the goal will be assigned for a single agent “Skill” or “User” given in pink shapes.

Figure 2.4 System goal model

Goal ID Description Relationship

Main goal Adventure be managed by voice recognition F9, F10

G1 Adventure be created F2

G2 Schedule be changed F4, F5

G3 Adventure be received F8

G4 User be reminded about adventure F7

G1.1 Information about adventure be defined F2

G1.2 Reminder be set F7

G1.3 Participants invited F8

G1.4 Information about adventure be set F2

G2.1 Change request set F4

G2.2 Delete request be set F5

G2.3 Changes are handled F4

G2.4 Adventure be deleted F5


G3.1 The decision about adventure be set F8

G3.2 The decision is sent to the initiator F8

Table 2.3 Goal table of the system

2.5 Design and Implementation Constraints

First, the internet connection is a constraint for the application, because the google assistant application communicates with the external system to retrieve the response data over the internet, and it is essential that internet connection would be available all the time. Secondly, as PLANy is the skill and it is available only for users who have Google assistant, if some user doesn't have a Google assistant then they cannot use PLANy, and similarly, the user needs Google calendar to use PLANy. Below is the identified list of supported devices and operating systems for Google assistant, the list is taken for official Google assistant site. Available devices:

● Android 6.0+ TVs ● Google Home ● Android 5.0+ phones ● iOS 10.0+ devices ● Headphones

Usage of the skill available only in English. Also to use the mobile version the users should have a phone with the next hardware requirements:

● Android 5.0 or higher ● Google app 6.13 or higher ● Google Play services ● 1 GB of memory ● Device's language set to a language listed above


2.6 Assumptions and Dependencies

It assumes that the users who will use PLANy would have a Google assistant and Google calendar, also the additional functionality requires the Gmail. Figure 2. mapped all the feature connections and Table 2 (in Appendix A) presents the dependency shell and traces of different attributes. Probably, most of the features depend on PLANy activation. In another case, any of the features could not be used. The second the most important feature which a few features rely on is skill communication with the user as it used to listen to, to understand and reply to our user. All other features are dependent on two mentioned above, but feature 6 - tell the list is one that distinguishes our skill from an average calendar application.

Figure 2.5 Feature dependency map


3. System Features This section illustrates the functional requirements which are organized based on the features. Each functional requirement has its own unique id, title, description and priority.

Figure 3.1 Requirement shell Priority can be divided into 3 parts: Mandatory, Nice to be (Low, Medium, High) or Should not be. In the Functional Requirement of the current version of the document, we do not have “Should not be” features.

3.1 Functional Requirements

This section is organised based on the available system features: Feature 1 - Set up with Google account ID: F1 Description: A user should be able to login to PLANy with Google Account. Depend: None Relationship: NFR5, NFR6, NFR7, NFR8, UC#1 Priority: Mandatory Version: V2.2.F1.V1.2 ID: F1-REQ1 Title: Login on Google account Description: A user should be logged in from his/her Google account.


ID: F1-REQ2 Title: Enable Not to disturb Description: System should allow the user to enable the “not to disturb” option. ID: F1-REQ3 Title: Disable Not to disturb Description: System should allow the user to disable the “not to disturb” option. ID: F1-REQ4 Title: Configure adventures notification time Description: A user would be able to configure adventures notification time in the “not to disturb” option. ID: F1-REQ5 Title: Another account Description: The skill should not allow login using an account from non-Gmail accounts. Feature 2 - Add adventure ID: F2 Description: The user should have the ability to add a new adventure. Depend: F9, F10 Priority: High Relationship: NFR1, UC#2, G1, G1.1, G1.4 Version: V2.2.F2.V1.2 ID: F2-REQ1 Title: Keywords for the function activation Description: The keywords below should make the system start the arrangement process.

- add (For example, “Add meeting with the boss to my calendar”) - create (For example, “I want to create an adventure”) - plan (For example, “I need to plan my adventures”) - arrange (For example, “I want to arrange the meeting with colleges”) - put (For example, “Put to my calendar meeting with the doctor”) - organize (For example, “I want to organize Birthday Party”)

ID: F2-REQ2 Title: Time extraction Description: System should extract from user phrase the time of the adventure.


ID: F2-REQ3 Title: Date extraction Description: System should extract from the user phrase the date of the adventure. ID: F2-REQ4 Title: Purpose extraction Description: System should extract from the user phrase the purpose of the adventure. ID: F2-REQ5 Title: Place extraction Description: System should extract from the user phrase the place of the adventure. ID: F2-REQ6 Title: Time limitation Description: System can create an adventure in a certain moment. ID: F2-REQ7 Title: Current time selection Description: System should identify a current time. ID: F2-REQ8 Title: Type of the adventure Description: System should recognize from the phrase the type of adventure. ID: F2-REQ9 Title: Emails identification Description: System should identify the given emails of the adventure participants. ID: F2-REQ10 Title: Invitation text Description: System should write down text said by the user. ID: F2-REQ11 Title: Sending text Description: System should send a message to the list of emails.


Feature 3 - Adventure confirmation ID: F3 Description: A user would get a new adventure confirmation from other users. Depend: F8, F9, F10 Priority: Medium Relationship: Version: V2.2.F3.V1.2 ID: F3-REQ1 Title: Confirmation of a new adventures Description: System should receive an adventure notification. ID: F3-REQ2 Title: Purpose extraction Description: System should get information about the purpose of a new adventure. ID: F3-REQ3 Title: Time extraction Description: System should get information about the time of a new adventure. ID: F3-REQ4 Title: Place extraction Description: System should get information about the place of a new adventure. ID: F3-REQ5 Title: Defining of suitability Description: System should define suitability between new and current adventures. ID: F3-REQ6 Title: Agreement of new adventure Description: System should agree with new adventures. ID: F3-REQ7 Title: Disagreement with a new adventure Description: System should disagree with new adventures. ID: F3-REQ8 Title: Confirming a new adventure Description: System should confirm a new adventure.


Feature 4 - Adventure Editing ID: F4 Description: A user would be able to edit the already created adventure by voice command Depend: F9, F10 Priority: Low Relationship: G2, G2.1, G2.2 Version: V2.2.F4.V1.2 ID: F4-REQ1 Title: Editing of the meeting/reschedule Description: A user would be able to reschedule the adventure time by voice command. ID: F4-REQ2 Title: Updating of the calendar timing Description: System should update the calendar timings according to user reschedules of the adventure. ID: F4-REQ3 Title: Updating the notification timing Description: System should update the notification timings according to user reschedules of the adventure. Feature 5 - Delete adventure ID: F5 Description: A user would be able to delete the already created adventure by voice command. Depend: F9, F10 Relationship: UC#3, G2, G2.2, G2.4, Priority: High Version: V2.2.F5.V1.2 ID: F5-REQ1 Title: Delete the meeting Description: A user would be able to delete the scheduled adventure by voice command. ID: F5-REQ2 Title: Deleting meeting timing from the calendar Description: Delete order given by the user should remove the scheduled adventure from the calendar.


ID: F5-REQ3 Title: Deleting of the notification timing Description: Delete order given by the user should remove the notification times of the scheduled adventure from the calendar. Feature 6 - Tell the list of adventures ID: F6 Description: A users should get information about existing adventures. Depend: F9, F10 Relationship: NFR2, NFR3 Priority: Medium Version: V2.2.F6.V1.2 ID: F6-REQ1 Title: Ordering of telling schedule from the user Description: System should get an order to tell the schedule to the user. ID: F6-REQ2 Title: Defining of schedule Description: System should define all schedules. ID: F6-REQ3 Title: Telling of schedule Description: System should tell the schedule to the user. ID: F6-REQ3 Title: Telling of schedule Description: System should not miss scheduled adventures. Feature 7 - Reminder ID: F7 Description: The skill should remind the user about planned adventure in time set by the user. Depend: F9, F10 Relationship: TBD, G1.2, G4 Priority: Low Version: V2.2.F7.V1.1


ID: F7-REQ1 Title: Ordering of a reminder from the user Description: System should receive an order to set-up a reminder from the user. ID: F7-REQ2 Title: Time extract Description: System should receive information about the exact reminder time. ID: F7-REQ3 Title: Setting-up reminder Description: System should set-up reminder. ID: F7-REQ4 Title: Reminding of users Description: System should remind the users in needed time. Feature 8 - Notification ID: F8 Description: A users get a notification about the adventures set by others. Depend: F2, F10 Priority: Medium Relationship: NFR3, G1.3, G3, G3.1, G3.2 Version: V2.2.F8.V1.2 ID: F8-REQ1 Title: Ordering of notification. Description: System should get an order to send a notification to users. ID: F8-REQ2 Title: Information about notification Description: System should present detailed information about a notification. ID: F8-REQ3 Title: Time extraction Description: System should extract from user phrase the time of the adventure. ID: F8-REQ4 Title: Purpose extraction Description: System should extract from user phrase the purpose of the adventure.


ID: F8-REQ5 Title: Place extraction Description: System should extract from user phrase the place of the adventure. ID: F8-REQ6 Title: Recipient extraction Description: System should extract from user phrase the recipient of the notification. ID: F8-REQ7 Title: Sending notification Description: System should send a notification to users. Feature 9 - Skill communication with the user ID: F9 Description: The system should be able to communicate with the user. Depend: F10 Priority: Mandatory Relationship: NFR2, NFR4, NRF12, NRF13, NFR15, NFR16, UC#4, Main goal Version: V2.2.F9.V1.2 ID: F9-REQ1 Title: Voice recognition Description: System should recognize user voice input. ID: F9-REQ2 Title: Voice transformation Description: System should transform input into the text. ID: F9-REQ3 Title: Data understanding Description: System should extract information from the given text. ID: F9-REQ4 Title: Text generation Description: System should generate a reply to the text input. ID: F9-REQ5 Title: Voice generation


Description: System should transform reply text to voice. ID: F9-REQ6 Title: Insults Description: The skill should not insult a user Feature 10 - PLANy skill activation ID: F10 Description: Google assistant must activate the PLANy skill. Depend: F1 Relationship: NFR11, UC#5, Main goal Priority: Mandatory Version: V2.2.F10.V1.2 ID: F10-REQ1 Title: Keyphrases for the activation Description: Activation phrase said by the user should include word “PLANy”: Example:

- “Ok Google, PLANy work started” - “Ok Google, open PLANy” - “Ok Google, what’s on my PLANy”

ID: F10-REQ2 Title: Time of the activation Description: System should start work in 2 seconds after one of the key phrases were said by the user. ID: F10-REQ3 Title: 10 seconds no-reply Description: System should ask the user “Hello. what do you want to do?” in 10 seconds of user inactivity. ID: F10-REQ4 Title: 20 seconds no-reply Description: System should deactivate in 20 seconds of user inactivity. ID: F-REQ Title: Interaction limitation Description: The skill should not store information about user conversation.


3.3 Use cases As the goal is to provide an information about schedule and not to talk much to people those are not interested in the scope of use cases that involved chatting with our user.

Our customers will use PLANy as he is in hurry or it is difficult for him to check it manually. For example, in “Walking” example, it is clear that there should be a requirement that will allow separating user voice from other noises in the environment (vehicle horn sounds, roadworks, a voice of people that walking by etc.). In a further version of the documentation it is possible to extract an information from these use cases but only after when will prioritize existing features.

3.3.1 Use case Diagrams

The following diagram presenting all the goals which different actors perform or involve to achieve some other goals. The use case introduced four different actors: User, skill, attendee and Google assistant.

Figure 3.3 Use cases of software-intensive system


The following diagram (Figure 3.4) presenting the breakdown of ‘user account setup on PLANy’ use case that indicating different user flow. It also introduced misuse case where the attacker actor can possibly attack the system and threatens the user personalized settings.

Figure 3.4 Use case for user setup of PLANy

3.3.2 Use Case Summary

Use case #1: User login to PLANy

Use Case ID UC#1

Use Case Name User login to PLANy

Created By Mubashar

Date Created 04-Nov-2018

Actors User, Attacker

Description Before browsing the PLANy skill a user should be able to login into the PLANy with Google Account

Relationship F1


Trigger The user gives details to login into the PLANy skill

Preconditions A user opens the PLANy skill

Postconditions A user is authenticated

Normal Flow 1. A user opens the PLANy skill 2. The PLANy skill receives details from the user to authenticate 3. A user is successfully authenticated into the PLANy skill 4. A user redirects to their PLANy skill account

Alternative Flow 1. A user opens a PLANy skill 2. The PLANy skill receives details from user to authenticate 3. A user is notified by an error message if the user authentication fails

Exceptions EXC#1: User fails during login A user is notified with an error message If the user authentication fails

Includes Account settings

Priority Mandatory

Frequency of Use N/A

Assumptions A PLANy user has a GMAIL account to set up Google Assistant based PLANy skill

Notes and Issues N/A

Use case #2: Add adventure

Use Case ID UC#2

Use Case Name Add adventure

Created By Musa


Actors User and Attendees

Description The user should be able to add an adventure to the calendar

Relationship F2


Trigger The user says the keywords to activate the system and add adventure

Preconditions The user should be logged in

Postconditions A new adventure adds to the calendar

Normal Flow NF#2.1: User adds individual adventure 1.1 User says the keyword to activate PLANy 1.2 User gives the details of the adventure 1.3 System adds adventure to the calendar NF#2.2: User adds group adventure 2.1 User says the user phrase to activate PLANy 2.2 User gives the details of the adventure 2.3 User includes the attendees 2.4 The system sends a notification to the attendees 2.5 The attendees confirm the adventure 2.6 System adds adventure to the calendar

Alternative Flow AC#2.1: Attendees do not confirm adventure 1. The user says the user phrase to activate PLANy 2. The user gives the details of the adventure 3. The user includes the attendees 4. The system sends a notification to the attendees 5. Not all attendees agree on the details 6. Adventure is not confirmed

Exceptions EXC#2.1: Attendees do not confirm the adventure 1. The user receives a notification about the disagreement 2. The user updates the adventure details EXC#2.2: Internet connection failure 1. The user receives a message regarding internet connection failure 2. The system tries to reconnect 3. The system notifies the user about reconnection

Includes PLANy skill activation and Skill communication with the user

Priority High

Frequency of Use Always

Assumptions N/A



Use case #3: Delete adventure

Use Case ID UC#3

Use Case Name Delete Adventure

Created By 11/05/2018

Date Created Gultaj

Actors Users

Description After adding adventure a user would be able to delete the adventure by voice command

Relationship F5

Trigger The user gives a voice command to PLANy skill

Preconditions A user has a list of already added adventure(s)

Postconditions An adventure deletes from the list

Normal Flow 1. A user opens the PLANy skill 2. The PLANy skill receives a voice command from a user to authenticate and delete an adventure with PlANy skill 3. A user is successfully authenticated into the PLANy skill 4. A user deletes an adventure from their PLANy skill account

Alternative Flow 1. A user opens a PLANy skill 2. The PLANy skill receives a voice command from a user to authenticate and delete an adventure with PlANy skill 3. A user is successfully authenticated into the PLANy skill 4. A user is notified by an error message If the user authentication fails


Exceptions EXC#1: User fails during deleting A user is notified by an error message If the user authentication fails EXC#2: User fails during deleting A user is notified with an error message if the user voice authentication fails

Includes View & Change personalized settings

Priority High


Assumptions A PLANy user would have a meeting to delete it from the calendar


Use case #4: Skill communication with the user

Use Case ID UC#4

Use Case Name Skill communication with the user

Created By Stanislav


Actors System, User

Description The system should be able to communicate with the user

Relationship F9

Trigger The user says a phrase

Preconditions PLANy skill is activated. User input should be up to 3 sentences.

Postconditions User’s goal should be fulfilled. The skill must provide an answer based on user input-phrase

Normal Flow NF#1 User says input phrase


1. System transform user input phrase from voice into a text representation 2. The system analyzes text representation 3. System extract command forms from the text representation. 4. Systems activate a function based on the extracted command. 5. The system completes the user task 6. The system generates text reply for user 7. The system transforms text into voice representation 8. The system produces the voice reply

Alternative Flow AC#1: Reply does not fulfil the user’s goal. 1. The system should generate a question to the user based on his first input. 2. User changes her/his input. 3. The system starts NF#1

Exceptions EXC#1: User said more than 4 sentences. 1. The system transforms the user input phrase from voice into the text representation 2. The system analyzes text representation 3. System produces voice message about the sentences excess. 4. The system suggests possible options about user input.

Includes N/A

Priority Mandatory

Frequency of Use Always

Assumptions User-aware that PLANy is not the same as human-being so PLANy could make mistakes in understanding user’s input.


Use case #5: PLANy skill activation

Use Case ID UC#5

Use Case Name PLANy skill activation

Created By Veronika

Date Created 11/05/2018

Actors User, Skill, Google Assistant

Description Google assistant activates a PLANy skill


Relationship F10

Trigger The user gives details to login into PLANy skill

Preconditions The user says keywords for activation a PLANy skill

Postconditions A PLANy skill activates

Normal Flow 1. A user says one of the keywords for the skill activation - “Ok Google, PLANy work started” - “Ok Google, open PLANy” - “Ok Google, what’s on my PLANy” 2. The Google Assistant opens a PLANy skill 3. PLANy skill starts communication with a user

Alternative Flow 1. A user says one of them for the skill activation - “Ok Google, PLANy work started” - “Ok Google, open PLANy” - “Ok Google, what’s on my PLANy” 2. The Google Assistant opens a PLANy skill 3. PLANy skill do not start communication if there is no Internet connection

Exceptions EXC#1: No Internet A user need an Internet connection to open the PLANy skill

Includes Skill communication with a user

Priority Mandatory


Assumptions A Google Assistant can recognise keywords for the PLANy skill



s3.4 Solution oriented requirements modelling In order to discover specify the requirements about the Feature 2: Add adventure at the required level of detail we are going to look at the perspectives of the solution: data perspective, behavioural perspective and functional perspective. Hence we performed the modelling and built class diagrams, states models and sequence models accordingly, also created 18 new solutions-oriented requirements which are presented along with the models. The solution-oriented requirements shell is presented below where each requirement has its own unique id, title and description.

Figure 3.4.1 Solution-oriented requirements shell

3.4.1 Class diagram

Since we have focused on Feature 2: Add adventure we discarded all the classes which should be in the system by at the current moment are beyond the scope of the analyses. So our main classes are User, Adventure, Notification, PLANy, Google Calendar. We use 2 types of the relationship between classes: association and aggregation. For example, User created adventure (association). And the Notification is a part of the whole Adventure is shown on the example of User and Adventure (aggregation).


Figure 3.4.1.1 Class diagram for the Feature 2: Add adventure

Solution oriented requirements During the requirements modelling new requirements are elicited, 4 new solution-oriented requirements are derived from the class diagram which are listed below: ID: F2-SOR1 Title: One google calendar Description: The user can work only with the one Google calendar that is assigned to user Gmail account Relationship: UC1 Priority: High Version: V3.SOR1.V1


ID: F2-SOR2 Title: Allowed to add adventures Description: User should be authenticated by their Gmail account credentials to add new adventure Relationship: TBD Priority: High Version: V3.SOR2.V1 ID: F2-SOR3 Title: Not only voice Description: User can create an adventure by tapping with fingers on the mobile screen Relationship: UC2 Priority: Low Version: V3.SOR3.V1 ID: F2-SOR4 Title: Whom to invite Description: User can add emails from his address book of those people who would be invited in the adventure Relationship: TBD Priority: Medium Version: V3.SOR4.V1

3.4.2 State diagrams For some entities which were described in the class diagram, we have created 5 different state diagrams to present the state of different objects from the associated classes. Each diagram represents the state of different objects. Solution oriented requirements From the below state diagrams 10 new solution-oriented requirements are derived which are listed below: I. Adventure time state diagram


Figure: 3.5 State diagram to represent the state of time attribute in adventure class ID: F2-SOR5 Title: Adventure time Description: Adventure time should fulfil the valid adventure time requirements such as:

a. Adventure time should be in the future b. Adventure time should be in a unique format hh:mm:ss (h=hour, m=minutes and

s=seconds) Relationship: TBD Priority: High Version: V3.SOR5.V1 II. User future adventures state diagram

Figure: 3.6 State diagram to represent the state of future adventures attribute in user class

ID: F2-SOR6 Title: Markup for future adventures


Description: System should explicitly mark the future adventures to present them separately from already completed adventures Relationship: TBD Priority: High Version: V3.SOR6.V1 III. Adventure completed state diagram

Figure: 3.7 State diagram to represent the state of adventure completed attribute in adventure class ID: F2-SOR7 Title: Adventure completed Description: System should mark the completed adventures to present them separately from future adventures Relationship: UC2 Priority: High Version: V3.SOR7.V1 IV. Notification letter send state diagram

https://docs.google.com/document/d/1ZQFbXYb7WADw5umHWDOUOgmVlsH2hDBJKT56ecTlFb4/edit#bookmark=id.creugzysmak2


Figure: 3.8 State diagram to represent the state of letterSend attribute in notification class ID: F2-SOR8 Title: Letter send as notification Description: System provides the functionality to create a letter for notifying attendees of the adventure Relationship: UC2, UC4 Priority: Medium Version: V3.SOR8.V1 ID: F2-SOR9 Title: Letter template Description: System should check the letter template which is pre-compiled for notification standardisation Relationship: TBD Priority: Low Version: V3.SOR9.V1 ID: F2-SOR10 Title: Letter template Description: System should not exceed the letter character length which is more than 250 characters Relationship: TBD Priority: Medium Version: V3.SOR10.V1 V. User username state diagram

https://docs.google.com/document/d/1ZQFbXYb7WADw5umHWDOUOgmVlsH2hDBJKT56ecTlFb4/edit#bookmark=id.creugzysmak2

https://docs.google.com/document/d/1ZQFbXYb7WADw5umHWDOUOgmVlsH2hDBJKT56ecTlFb4/edit#bookmark=id.mfoc5kncwosc


Figure: 3.9 State diagram to represent the state of username attribute in user class ID: F2-SOR11 Title: No special characters in the username Description: The system should not accept any special characters in the username of the user Relationship: UC1 Priority: Medium Version: V3.SOR11.V1 ID: F2-SOR12 Title: Username maximum characters length Description: The system should check the username should not exceed from the maximum characters length which is 15 characters Relationship: TBD Priority: Low Version: V3.SQR12.V1. ID: F2-SOR13 Title: Username minimum characters length Description: The system should check the username should not be under the minimum characters length which is 3 characters Relationship: UC1 Priority: Medium Version: V3.SOR13.V1

https://docs.google.com/document/d/1ZQFbXYb7WADw5umHWDOUOgmVlsH2hDBJKT56ecTlFb4/edit#bookmark=id.mgbsmlqmntem

https://docs.google.com/document/d/1ZQFbXYb7WADw5umHWDOUOgmVlsH2hDBJKT56ecTlFb4/edit#bookmark=id.mgbsmlqmntem


ID: F2-SOR14 Title: Unique username Description: The system should accept the unique username Relationship: TBD Priority: High Version: V3.SOR14.V1.

3.4.3 Sequence diagram To define how objects of classes interact with each other and which events happening during this interaction the sequence model was created which is presented below:

Figure 3.10 Sequence diagram for the add adventure

● SetInformationAboutAdventure() is a generalization of set methods from class

“Adventure”: setTime(), setDate(), setPlace(), setPurpose(), setAttendees().

● getInformationAboutAdventure() is a generalization of get methods from class “Adventure”: getTime(), getDate(), getPlace(), getPurpose(), getAttendees().


Solution oriented requirements From the above sequence diagram 4 new solution-oriented requirements are derived which are listed below: ID: F2-SOR15 Title: Check field Description: System should check whether all fields specified in glossary are filled Relationship: UC2 Priority: High Version: V3.SQR15.V1. ID: F2-SOR16 Title: Sending text Description: PLANy creates an adventure only when all fields specified in glossary of Adventure are filled Relationship: TBD Priority: High Version: V3.SQR16.V1. ID: F2-SOR17 Title: Undefined field Description: User can mark a field about adventure undefined Relationship: UC2, UC4 Priority: High Version: V3.SQR17.V1. ID: F2-SOR18 Title: Define later Description: User can ask PLANy to define the Undefined field in a set by user time Relationship: TBD Priority: Low Version: V3.SQR18.V1.

3.5 Traceability model In this section, the general traceability model is described.


Figure 5 Traceability model For the moment, traceability artefact consists of feature and its functional requirement, goals and use cases, solution-oriented requirements. Traceability relationship should include the next description items: satisfied, conflict, based on and make it happen.

3.5.1 Traceability matrix for features and functional requirement

We have chosen 12 requirements and compared them with 10 features we have. The result of the comparison is presented in a matrix provided below in 4 parts. Legend

conflict feature and requirement contradict each other and cannot be used at the same time

satisfied feature and requirement can be implemented at the same time

make it happened feature include a certain requirement

depend feature use other features with that requirement

Table 3.2 Legend of the traceability matrix


Figure 6.1 Traceability matrix (part 1)






3.5.2 Traceability matrix for goals and use cases

We have chosen 5 goals and compared them with 5 use cases. The result of the comparison is presented in a matrix provided below.

PLANy setup

Add adventure

Delete adventure

User communication

PLANy activation

UC1 UC2 UC3 UC4 UC5

Adventure be managed by voice recognition Main goal depend depend depend

make it happened depend

Adventure be created G1 depend make it happened satisfied depend

Schedule be changed G2 depend satisfied satisfied depend

Adventure be received G3 depend satisfied depend

User be reminded about adventure G4 depend satisfied depend

Figure 6.5 Traceability matrix for goals and use cases

Legend

conflict use case and goal contradict each other and cannot be used at the same time

satisfied use case partly satisfies the goal

make it happened particular use case fulfil the goal

depend use case use that goal

Table 6.6 Legend of the traceability matrix for goals and use cases

3.5.3 Traceability matrix for use cases and solution-oriented requirements

We have chosen 7 requirements and compared them with 5 use cases we have. The result of the comparison is presented in a matrix provided below. Legend

conflict use case and solution oriented requirement contradict each other and cannot be used at the same time

satisfied the requirement is used by the use case

Table 3.8 Legend of the traceability matrix for solution-oriented requirements and use cases

PLANy Add Delete User PLANy


setup adventure adventure communication

activation

UC1 UC2 UC3 UC4 UC5

The user can work only with the one Google calendar that is assigned to users Gmail account F2-SOR1 satisifed

User can create an adventure by tapping with fingers on the mobile screen F2-SOR3 satisifed

System should mark all the completed adventures to separate from future adventures F2-SOR7 satisifed

System provides the functionality to create a letter for notifying attendees of the adventure F2-SOR8 satisifed satisifed

The system should not accept any special characters in the username of the user

F2-SOR11 satisifed

The system should check the username should not be under the minimum characters length which is 3 characters

F2-SOR13 satisifed

System should check whether all fields are filled

F2-SOR15 satisifed

User can mark a field about adventure undefined

F2-SOR17 satisifed satisifed

Figure 6.7 Traceability matrix for solution-oriented requirements and use cases


3.5 Non-functional requirements

Figure 7. Non-functional shell ID: NFR1 Category: Performance Description: A system should not take more than 30 seconds to add a new adventure Relationship: F2 Priority: High Version: V2.NFR1.V2.1 ID: NFR2 Category: Performance Description: The system should process request about creating a new adventure in 3 seconds Relationship: F6, F9 Priority: High Version: V2.NFR2.V2.4 ID: NFR3 Category: Reliability Description: The system should launch appropriate functions according to user input 95% of time Relationship: F8, F7, F6 Priority: Mandatory Version: V2.NFR3.V2.4 ID: NFR4


Category: Reliability Description: Transmission of information should be end-to-end encrypted Relationship: F9 Priority: Medium Version: V2.NFR4.V2.1 ID: NFR5 Category: Security Description: People invited to the meeting can not change the meeting time without personalised permissions Relationship: F1 Priority: Medium Version: V2.NFR5.V2.1 ID: NFR6 Category: Security Description: Confidentiality of the user should be protected by the access control Relationship: TBD Priority: Low Version: V2.NFR6.V2.1 ID: NFR7 Category: Security Description: Each unsuccessful attempt to access the information should be recorded in an audit trail Relationship: F1 Priority: Low Version: V2.NFR7.V2.1 ID: NFR8 Category: Security Description: The password should not be viewable to anyone at any time Relationship: F1 Priority: Medium Version: V2.NFR8.V2.1 ID: NFR9 Category: Security Description: The user will be notified by security alert when user will do log in from another device


Relationship: F1 Priority: High Version: V2.NFR9.V2.1 ID: NFR10 Category: Efficiency Description: The system should handle 1000 concurrent users in 1 second Relationship: TBD Priority: Medium Version: V2.NFR10.V2.1 ID: NFR11 Category: Efficiency Description: The system should not exceed 2 mistakes when the new user is performing tasks Relationship: F10 Priority: Mandatory Version: V2.NFR11.V2.1 ID: NFR12 Category: Maintainability Description: The system should be consistent in their interaction with the user Relationship: F9 Priority: Medium Version: V2.NFR12.V2.1 ID: NFR13 Category: Maintainability Description: The system should be consistent in their success and error responses to a user Relationship: F9 Priority: Medium Version: V2.NFR13.V2.1 ID: NFR14 Category: Maintainability Description: The system should be easy to scale for adding new functionality Relationship: TBD Priority: Mandatory Version: V2.NFR14.V2.1 ID: NFR15


Category: Portability Description: The system should work on specified smart devices (see section 2.4) Relationship: F1, F9 Priority: High Version: V2.NFR15.V2.1 ID: NFR16 Category: Portability Description: The system should work on specified operating systems (see section 2.4) Relationship: F1, F9 Priority: High Version: V2.NFR16.V2.1


4. Prioritization In order to define which features will do first or to divide them into different releases or budgets, the prioritization activity is performed. For the prioritization, the matrix approach is used. Based on the results of stakeholder meeting there is a feature matrix 10*10 for cost and value created. Fill the cell (x, y) with a value:

● 1 - if x and y are of equal value, ● 3 - if x is slightly more preferred than y, ● 5 - if x is strongly more preferred than y, ● 7 - if x is very strongly more preferred than y, ● 9 - if x is extremely more preferred than y, and 2,4,6,8 if stakeholders couldn't agree on

some concrete value). Otherwise, for every cell (y,x) the value reciprocal value was used. With a simple calculation, normalize the rows and find the importance of every feature in percentages. The results of value and cost matrices are provided below.

Estimate the eigenvalues ● Calculate the sum of each column ● Divide each element in the matrix by the sum of its column ● Calculate the sum of each row ● Divide each row sum by the number of rows

4.1 Cost matrix Cost matrix maps the cost of features from different stakeholders.

COST F2 F3 F4 F5 F6 F7 F8

F2 1,00 0,33 2,00 2,00 0,33 0,25 3,00

F3 3,00 1,00 0,50 4,00 0,50 0,50 2,00

F4 0,50 2,00 1,00 5,00 0,25 0,33 5,00

F5 0,50 0,25 0,20 1,00 0,25 0,16 0,50

F6 3,00 2,00 5,00 4,00 1,00 0,25 5,00

F7 4,00 2,00 3,00 6,00 4,00 1,00 7,00

F8 0,33 0,50 0,20 2,00 0,20 0,14 1,00

Sum of each column 12,33 8,08 11,90 24,00 6,53 2,63 23,50

Table 4.1 Cost matrix


Normalised columns and sum of the rows of cost matrix

This matrix (Table 4) presents the normalised cost from (Table 3) those are calculated by using the above mentioned “estimate the eigenvalues” criteria. COST F2 F3 F4 F5 F6 F7 F8 Sum %

F2 0,08 0,04 0,17 0,08 0,05 0,10 0,13 0,65 0,09

F3 0,24 0,12 0,04 0,17 0,08 0,19 0,09 0,93 0,13

F4 0,04 0,25 0,08 0,21 0,04 0,13 0,21 0,96 0,14

F5 0,04 0,03 0,02 0,04 0,04 0,06 0,02 0,25 0,04

F6 0,24 0,25 0,42 0,17 0,15 0,10 0,21 1,54 0,22

F7 0,32 0,25 0,25 0,25 0,61 0,38 0,30 2,36 0,34

F8 0,03 0,06 0,02 0,08 0,03 0,05 0,04 0,32 0,05

1,00

Table 4.2 Normalised columns and sum of the rows of cost matrix

4.2 Value matrix Value matrix maps the value of each feature from different stakeholders. VALUE F2 F3 F4 F5 F6 F7 F8

F2 1,00 0,20 6,00 8,00 9,00 0,50 9,00

F3 3,00 1,00 0,20 0,50 0,25 0,33 0,50

F4 0,16 5,00 1,00 0,25 0,25 0,50 0,00

F5 0,12 2,00 4,00 1,00 5,00 5,00 8,00

F6 0,11 4,00 4,00 5,00 1,00 5,00 6,00

F7 2,00 3,00 2,00 0,20 0,20 1,00 1,00

F8 0,11 2,00 1,00 0,12 0,16 0,50 1,00

Sum of each column 6,50 17,20 18,20 15,07 15,86 12,83 25,50

Table 4.3 Value matrix


Normalised columns and sum of the rows of value matrix

This matrix (Table 6) presents the normalised value from (Table 5) those are calculated by using the above mentioned “estimate the eigenvalues” criteria. VALUE F2 F3 F4 F5 F6 F7 F8 Sum %

F2 0,15 0,01 0,33 0,53 0,57 0,04 0,35 1,99 0,28

F3 0,46 0,06 0,01 0,03 0,02 0,03 0,02 0,62 0,09

F4 0,02 0,29 0,05 0,02 0,02 0,04 0,00 0,44 0,06

F5 0,02 0,12 0,22 0,07 0,32 0,39 0,31 1,44 0,21

F6 0,02 0,23 0,22 0,33 0,06 0,39 0,24 1,49 0,21

F7 0,31 0,17 0,11 0,01 0,01 0,08 0,04 0,74 0,11

F8 0,02 0,12 0,05 0,01 0,01 0,04 0,04 0,28 0,04

1,00

Table 4.4 Normalised columns and sum of the rows of value matrix

4.3 Results Based on the calculation that was written the percentage distribution for every feature regarding value and cost dimensions and described them. Cost Value Description

F2 0.09 0.28 Feature-2 has 9% cost and 28% value distribution







Table 4.5 Results of cost and value distribution


To visualize the results obtained, a scatter plot is constructed where every dot is a Feature with cost as dimension x and value as dimension y. The area of the plot is divided into 3 part: “High priority”, “Medium priority” and “Low priority”:

Figure 8 ROI graph Following priority division from the plot that led to features priority results: Priority

F2 High

F3 Medium

F4 Low

F5 High

F6 Medium

F7 Low

F8 Medium

Table 4.6 Features priority


Figure 9 Value and cost distribution Figure 4.1, Figure 4.2 and Table 4.6 show that Feature 9 is the most important feature in PLANy to deliver for the stakeholder in terms of cost and value.


5. Prototyping

The following prototype is built to test the process and flow of the system feature 2 (F2: Add Adventure ), as well as, the feasibility and validity of the requirements. The prototype shows the different interfaces which are bond with the main functions of F2 and various interactions with the user, PLANy skill and calendar.

Figure P1: Shows the login screen from where the user would authenticate

Figure P2: It is the screen which would be visible after user login to perform the action


Figure P3: User would send the voice message as instructions which PLANy would analyze and reply back

Figure P4: User would provide additional information which requires to complete the one particular task


Figure P5: PLANy would ask if the user wants to perform some other actions

Figure P6: If yes, the user will provide further instructions by voice


Figure P7: PLANy will use the invitation template and would compose the letter

Figure P8: If everything fine with the composed message, then PLANy will send an invitation


Figure P9: PLANy will add the adventure to the calendar and will notify the user

Figure P10: A polite message to end the conversion with the PLANy skill


Figure P11: PLANy is too smart with their responses


Appendix A: Requirements dependency shell

Feature Traceability Description Version

F1 DEP: None SAT: CON: None CLA:

Every other feature could be activated only after Feature 1 was successfully complete and our user is logged in Google Account. Any other features and also all system features only can start to be active after F1

V1.3

F2 DEP: F9 SAT: CON: None CLA:

Adventure adding could be activated only after getting a new order from Feature 9 for adding.

V1.3

F3 DEP: F8, F9, F10 SAT: CON: None CLA:

Adventure Confirmation could be activated only after getting notification from Feature 8, receiving an order from F9 and also after activating of Feature 10 for starting. Any other features and also all system features do not depend on Feature 3.

V1.3

F4 DEP: F9, F10 SAT: CON: None CLA:

Adventure editing could be activated only after activating of Feature 10 and receiving an order from F9 for starting. Any other features and also all system features do not depend on Feature 4.

V1.3


Adventure deleting could be activated only after activating of Feature 10 and receiving an order from F9 for starting. Any other features and also all system features do not depend on Feature 5.

V1.3


Telling of adventure lists could be activated only after activating of Feature 10 and receiving an order from F9 for starting. Any other features and also all system features do not depend on Feature 6.

V1.3


Reminder could be activated only after activating of Feature 10 and receiving an order from F9 for starting. Any other features and also all system features do not depend on Feature 7.

V1.2


The notification could be activated only after adding a new adventure in Feature 2 and activation of Feature 10.

V1.3



Communication skills with users could be activated only after activation of Feature 10.

V1.3


PLANy Activation could be activated only after Feature 1 was successfully complete and our user is logged in Google Account. Any other features except Feature 1 also can start to be active after Feature 10.

V1.3

Table 2. Feature dependencies


Appendix B: Document of the change request

Content Description

Project name PLANy

Request no. 1

Title PLANy skill does not insult a user

Date 10/20/2018

Originator Stanislav

Origin Development

Status Finalised

Originator’s priority TBD

Priority of realisation TBD

Verifier of the change Mubashar

Date of the last update N/A

Release N/A

Integration effort N/A

Description of the change request

All PLANy user should not be insulted by the skill. Like, skill should not respond to any racial or sexual replies or comments in a response.

Comments N/A

Table 3. Document of change request

Documents

S oftw ar e R e q u i r e me n ts S p e c i fi c ati on