Functional requirements

This Chapter contains the functional requirements for the implementation of the consistency checking. They are presented by graphical and textual use cases taken from Siv Oma Rogdar’s Master’s Thesis [7]. Some of the use cases have been edited to clearly show their involvement in the implementation of consistency rules.

Before describing the use cases of the system, the actors of the MWCF system are defined.

The actors and their relationships are illustrated in Figure 14 The user actor, who is any user which is not registered in the system, is at the top level, while the characterizer is a

specialisation of the user, denoted by the generalisation relationship. The administrator is at the next level as a specialisation of the characterizer. The actors are described as follows:

User The user represents an anonymous person that is not registered in the MWCF system.

This person has only access to view mobile scenarios previously stored in the system and cannot enter data into the system.

Characterizer This actor represents a person who wants to use the MWCF to create and characterize mobile scenarios. This person is registered in the system and can access the MWCF system with a user name and a password. The characterizer has restricted access to the system. He may view all scenarios stored in the system (like the user actor), and store scenarios and characterize these but only edit scenarios he himself has created previously.

Administrator The administrator represents a person who is responsible for maintaining the MWCF system. The administrator has access rights to every part of the system and

administrator rights to view and edit all data in the system.

Figure 14: The actors of the system and their relationship

The main use cases (as shown in the use case diagram in Figure 15) in the system are:

UC1 User Registration

Any user will be able to register in the system and create a user account provided the user has an e-mail address and has access to the Internet.

UC2 Login

A characterizer will be able to log in to the system using an e-mail address and a private password.

UC3 Edit User Account

The characterizer may edit his user account in the following ways: change the

password, change the e-mail address and change the name that is visible to other users of the system (e-mail address if not specified). The administrator may change all user accounts in the system and may also change the access level of the users.

UC4 Administer Framework

The administrator can make changes to the framework. Groups, characteristics, indicators and consistency rules can be added, edited or removed.

UC5 Administer Scenarios

The characterizer may do several administrative tasks concerning mobile scenarios in the system as creating a new scenario, editing an existing scenario or deleting an existing scenario.

UC6 Administer Tasks

A characterizer may add tasks to a scenario, edit existing tasks in a scenario or remove tasks from a scenario. He may specify the relationship between these tasks as

pre-UC7 Characterize Scenario

After having created a scenario, a characterizer may characterize an existing scenario by assigning each task in the scenario a value for every characteristic in the

framework.

UC8 View Analysis and Interpretations

Any user may view the characterization done on a scenario stored in the system and its complexity indicators.

UC9 Logout

A user of the system that is logged in should log out when the user has finished using the MWCF system. This is to prevent that other persons use the access rights of the person logged in. In case a user forgets to log out, the user should be automatically logged out of the system when the user has been inactive for 1 hour.

Some of the main use cases are further divided into new use cases. These use cases are not shown in the main use case diagram (Figure 15) to keep the diagram clear and easily

understandable, but are shown in the use case diagrams of the respective use cases. The main use case diagram shows the three types of actors involved in the system: the user, the

characterizer and the administrator. As shown also in Figure 14, the relationship between the actors is of type generalisation. This means that a characterizer inherits the behaviour of the user actor, which means e.g. that a characterizer also has an interface to the use case ”View analysis and interpretations”. Since the administrator actor inherits the behaviour of the characterizer, the administrator also has an interface to the use case ”View analysis and interpretations”. For the use cases ”User registration” and ”View analysis and interpretations”

the users of the system do not have to log in. To be able to use any of the other features of the system the users first have to log in. This is shown in the use case diagram by the include relationship to the use case ”Login”. Use case ”Administer scenarios” has an extend

relationship to the use case Administer tasks; i.e. use case ”Administer scenarios” can stand alone as a single use case or its behaviour may be extended by the behaviour of the

Administer tasks use case.

Figure 15: Main use case diagram

In the following sections, the use cases relevant to the consistency checks are described by use case diagrams and textual use cases. The textual use cases include the following items:

brief description, preconditions, actors involved, flow of events, alternative paths if they exist and post-conditions.

The use cases involved in the consistency checks are:

UC4 Administer Framework UC7 Characterize Scenario

Use case 4: Administer framework

Since the MWCF framework probably will evolve, and there might be both minor updates and

framework they involve, hence the use case ”Administer framework” has been divided into four new use cases, namely use case 4a: ”Administer groups”, use case 4b: ”Administer characteristics”, use case 4c: ”Administer indicators” and use case 4d: ”Administer consistency rule” (see Figure 16). “Administer indicators” is not relevant to the implementation of consistency rules and is therefore not further elaborated.

Figure 16: Use case diagram for use case 4: Administer framework

Use case 4a: Administer groups

Use case ”Administer groups” is depicted in Figure 17.

Brief description The administrator may make changes to the groups of the framework. This includes changing the name or description of a group, removing a group from the framework and adding a new group to the framework.

Actor Administrator

Preconditions The administrator is logged in and has chosen to make changes to the groups of the framework.

Path of flow The main flow of events should be:

1. include (Login). The administrator chooses whether he wants to add a new group to the framework, change the name of an existing group, change the description of a group or remove a group from the framework.

2. The administrator makes the changes. If he chooses to delete a group, all characteristics in the group and the consistency rules containing these characteristics will be deleted.

3. The system confirms the changes that have been done to the system.

Postcondition The administration of the groups in the framework results in immediate visible changes to the affected parts of the system.

Figure 17: Use case diagram for use case 4a: Administer groups

Use case 4b: Administer characteristics

Use case ”Administer characteristics” is depicted in Figure 18.

Brief description The administrator may make changes to the characteristics of the

framework. This includes changing the name of a characteristic, changing the description of a characteristic, removing a characteristic from a group (and hence from the framework), adding a new characteristic to the framework and specifying the scale used by a characteristic.

Actor Administrator

Preconditions The administrator is logged in and wants to make changes to the characteristics of the framework.

Path of flow The main flow of events should be:

1. include (Login). The administrator chooses whether he wants to change the name or description of an existing characteristic, remove a characteristic from a group, add a new characteristic to a group or change the scale used by a characteristic.

2. The administrator makes the changes. If he chooses to delete a characteristic, all

Alternative path for any of the steps The administrator chooses not to make any changes to the characteristics of the framework and no updates are done to the system.

Postcondition The administration of the characteristics in the framework results in immediate visible changes to the affected parts of the system.

Figure 18: Use case diagram for use case 4b: Administer characteristics

Use case 4d: Administer consistency rules

Use case ”Administer consistency rules” is depicted in Figure 19.

Brief description The administrator may make changes to the consistency rules. The consistency rules are used by the system to check the consistency when users characterize tasks. The administration of the consistency rules includes creating a new rule, changing an existing rule, or deleting a rule.

Actor Administrator

Preconditions The administrator is logged in and has chosen to make changes to the consistency rules.

Path of flow The main flow of events should be:

1. include (Login). The administrator chooses whether he wants to create a new consistency rule, change an existing rule or delete an existing rule.

Figure 19: Use case diagram for use case 4d: Administer consistency rules

2. The administrator makes the changes.

3. The system confirms the changes that have been done to the system.

Alternative path for any of the steps The administrator chooses not to do any changes to the consistency rules and no updates are done to the system.

Postcondition The administration of the consistency rules results in immediate visible changes to the affected parts of the system.

Use case 7: Characterize scenario

A use case diagram for use case ”Characterize scenario” is depicted in Figure 20.

Brief description After having created a scenario, a characterizer may characterize an existing scenario by assigning each task in the scenario a value for every characteristic in the framework.

Actor Characterizer

Preconditions The user is logged in and has previously created a scenario, which the user now wants to characterize.

Path of flow The main flow of events should be:

1. include (Login). The user chooses the scenario to characterize.

2. The next steps are repeated for each task in the scenario that the user wants to characterize at this point:

(a) The user chooses a task to characterize.

(e) If the user has assigned values that are conflicting, i.e. not in accordance with the rules for data consistency (see Chapter 2.3), the user will be made aware of what the conflicts are and may choose to revise the characterization or leave it as it is.

3. The user finishes the characterization and may view the analysis and interpretations for this scenario if desirable.

Postcondition The characterization is stored in the system, and the calculated complexity indicators may be viewed.

Figure 20: Use case diagram for use case 7: Characterize scenario