Chapter 3

2. Requirements Specification and Analysis

The emphasis of this chapter is on getting an idea of what the requirements are for the
intended software. Students who are doing a research related project would provide literature
survey for their problems. They are expected to understand the relevant papers and provide
summary of the existing work presented in each research paper. Such students should consult
their project supervisor for the detailed instructions related to this chapter.

You should write SRS in precise, clear and plain language so that it can be reviewed by a
business analyst or customer representative with minimal technical expertise. However it also
contains analytical models (use case diagrams, entity relationship diagrams, data dictionary
etc.), which can be used for the detailed design and the development of the software system.

Requirements specification involves frequent communication with system users to determine

specific feature expectations, resolution of conflict or ambiguity in requirements as demanded
by the various users or groups of users and documentation of all aspects of the project
development process from start to finish. Requirements are a description of how a system
should behave or a description of system properties or attributes. It can alternatively be a
statement of 'what' an application is expected to do.

3.1. Functional Requirements

The Functional Requirements Specification documents the operations and activities that a
system must be able to perform. The Functional Requirements Specification is described in
such a way that anyone from non-technical audience can understand. Readers should
understand the system, but no particular technical knowledge should be required to
understand the document.

Functional Requirements should include:

 Descriptions of data to be entered into the system

 Descriptions of operations performed by each screen
 Descriptions of work-flows performed by the system
 Descriptions of system reports or other outputs
  Who can enter the data into the system
 How the system meets applicable regulatory requirements

Table 3-1 Functional Requirements

S. No. Functional Requirement Type Status

1 User can upload the data set Core Pending

2 User can apply preprocessing Core Pending

operations before initiating
machine learning task
3 User can train machine learning Core Pending
model on their dataset enabling
creation of predictive model
4 User can apply their trained model Core Pending
to make prediction on new or test
dataset
5 User can save their preprocessed Core Pending
dataset, trained machine learning
model and predictive results for
future use
6 User can load previously saved Core Pending
dataset, models, and predictions
into the platform for further
analysis
7 When the dataset is uploaded the Core Pending
system will automatically
preprocess the dataset
8 After the model is trained on Pending
preprocessed data the user can save
the trained model

3.2. Non-Functional Requirements

Non-functional requirements cover all the remaining requirements, which are not covered by
the functional requirements. They specify criteria that judge the operation of a system, rather
than specific behaviors, for example: “Modified data in a database should be updated for all
users accessing it within 2 seconds”. Some typical non-functional requirements include
performance, scalability, availability, reliability, maintainability, usability and security.
Functional requirements describe what the system should do while non-functional
requirements describe how the system works. The Format for presenting these requirements
is given in Table 3-1 and Table 3-2.
 Table 3-2 Non-Functional Requirement

S. No. Non Functional Requirements Category

1
2
3…

3.3. System Use Case Modeling

A use case defines a set of use-case instances, where each instance is a sequence of actions a
system performs that yields an observable result of value to a particular actor. The
functionality of a system is defined by different use cases, each of which represents a specific
goal (to obtain the observable result of value) for a particular actor.

You should develop fully dressed use cases. One way of conceptualize correct use case is by
imaging the user interface of all the features of your project. This will help you to improve
your project well in time.

Figure 3-1 Use-case Diagram

3.3.1. Use Case1 Title
Describe the use case (expected behavior of the software) in the form of steps and sub steps
in the format given below. You should also proved a brief description of user interface that
will satisfy the requirement of each use case.

Table 3-3 Use-case Title

Use Case ID: UC-01

Use Case Name: Preprocess Dataset
Created By: Fiza Ali Last Updated
By:
Date Created: Oct 31th, 2023 Last Revision
Date:
Actors: User
Description: This use case is used for preprocessing of dataset uploaded by user.
Trigger: User initiate the preprocessing after uploading dataset
Preconditions: The user must upload the dataset.
Post conditions: The uploaded dataset is processed and used for training the data
model to address anaphoric ambiguity.
Normal Flow: User System

1. User uploads dataset by 2. The system notifies the user once

the dataset is uploaded.
selecting chose file option.
3. User select preprocessing 4. The system show the start
technique to be applied on data preprocessing button when the user
set select confirm for the upload dataset
5. Users start preprocessing
after the dataset is successfully 6. The system show preprocessing
uploaded by pressing start techniques once the user starts
preprocessing button. preprocessing

7. The system notifies the user once

the dataset is preprocessed

8. The system shows a brief report of

data preprocessing.
Alternative Flows: NA
Exceptions:
If wrong file with another type of extension system will show error
message to the user and notifies to select correct file.
Use Case ID: UC-04
Use Case Name: Train ML Model
Created By: Tayyab Asghar Last Updated
By:
Date Created: Nov 1st, 2023 Last Revision
Date:
Actors: User
Description: In this use case the user will select a technique to train Dataset for
detection of anaphoric ambiguity.
Trigger: Users select train model option to select technique that can be applied
from given options.
Preconditions: Users have to select dataset after technique drop down menu will be
available.
Post conditions: Technique is being selected that can be applied on selected dataset to
be trained to detect anaphoric ambiguity.
Normal Flow: User System

1. Users Press Train model 2. The system will show new

interface where select ML technique
option.
and start training buttons are present.

4. The system will show different

3. User selects ML training Training techniques by pressing drop
model through drop down down menu button.
menu.
5. User press starts training 6. The system notifies the user that
button to train the model. selected option is being selected.

7. The system will notify when the

data model is trained.

8. The system show brief report of

trained model.
Alternative Flows: NA
Exceptions:
NA
Use Case ID: UC-02
Use Case Name: Save Model
Created By: Ali Haider Last Updated
By:
Date Created: Oct 31th, 2023 Last Revision
Date:
Actors: User
Description: This use case is used for saving the model that has been trained
already
Trigger: Users initiate the model saving process after successfully training the
model
Preconditions: The user must train the model
Post conditions: The trained data model to address anaphoric ambiguity is saved for
future use
Normal Flow: User System

1. User press save model 2. The system will show new

interface where select data model
button.
and save buttons are present.

4. The system will show directory

3. User select the trained Model option where user can save the
model.

6. The system notifies the user once

5. User select the location to trained model is selected
save the trained model
8. The system notifies the user once
model is saved
7. User press save button to
save trained model
Alternative Flows: NA
Exceptions:
If trained model name already exist user should change the name
Use Case ID: UC-03
Use Case Name: Load Model
Created By: Ali Haider Last Updated
By:
Date Created: Nov 1st, 2023 Last Revision
Date:
Actors: User
Description: In this use case, users retrieve a previously saved trained model to
utilize for resolving anaphoric ambiguity.
Trigger: Users initiate the model Load process after selecting the Previously
trained model
Preconditions: A trained data model has been saved and is available for retrieval.
Post conditions: The saved trained model is successfully loaded and is ready for use
in addressing anaphoric ambiguity.
Normal Flow: User System

1. User select load model 2. The system will show new

interface where Load Model button
button
is present.
3. Users select the trained 4. The system show the directory
model from directory after where trained model is saved
pressing chose button
6. The system shows chose option to
5. Users pressed load button to user
load the trained model
7. The system notify the user when
user press chose button

8. The system notifies user when

trained model is loaded
Alternative Flows: NA
Exceptions:
If multiple dataset are saved in directory the user should select one
trained model that need to be loaded.
Use Case ID: UC-06
Use Case Name: Detect Ambiguity
Created By: Last Updated
By:
Date Created: Oct 31th, 2023 Last Revision
Date:
Actors: User
Description:
Trigger:
Preconditions:
Post conditions:
Normal Flow: User System

Alternative Flows: NA
Exceptions:

3.4. System Sequence diagrams

Sequence diagrams are created to show the sequence of events among user and the system to
complete an action / use case. A sample is presented in Fig 3.2.

You are required to provide SSD of all the uses cases that you have provided above.
 Figure 3-2 Sample SDD

3.5. Domain Model

Part of your initial architectural modeling efforts, particularly for a business application, will
likely include the development of high-level domain model as you see in Fig. 3.3. This model
should be very slim, capturing the main business entities and the relationships between them.
Some people consider this type of model to be an initial requirements model instead of an
initial architecture model.

Figure 3-3 sample Domain Model

3.6. User Interface Design (Prototypes)

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring
that the interface has elements that are easy to access, understand, and use to facilitate those
actions. UI brings together concepts from interaction design, visual design, and information
architecture.

You should describe the UI design in such a way that it remains simple and consistent along
different views. Common GUI elements are shown in the Fig. 3.4. You should describe the
UI design of each page.
Figure 3-6 Example Login Page UI Design