REQUIREMENTS ANALYSIS SYSTEM UTILIZING USE CASE MODELING
Shweta Karnik
B.E., Pune University, India, 2003
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
FALL
2010
REQUIREMENTS ANALYSIS SYSTEM UTILIZING USE CASE MODELING
A Project
by
Shweta Karnik
Approved by:
__________________________________, Committee Chair
Ahmed Salem, Ph.D.
__________________________________, Second Reader
Meiliu Lu, Ph.D.
____________________________
Date
ii
Student: Shweta Karnik
I certify that this student has met the requirements for format contained in the University format
manual, and that this project is suitable for shelving in the Library and credit is to be awarded for
the Project.
__________________________, Graduate Coordinator
Nikrouz Faroughi, Ph.D.
Department of Computer Science
iii
________________
Date
Abstract
of
REQUIREMENTS ANALYSIS SYSTEM UTILIZING USE CASE MODELING
by
Shweta Karnik
Requirements Analysis is a critical task in the software development lifecycle. System
requirements must be accurately interpreted, captured and documented to ensure
successful software product development and delivery. The aim of this project is to
design a web-based tool to capture, document, track and analyze requirements using
UML Use Case models. This system is designed to be intuitive, robust and is
implemented in Ruby on Rails and MySQL database.
_______________________, Committee Chair
Ahmed Salem, Ph.D.
_______________________
Date
iv
ACKNOWLEDGMENTS
I would like to thank my Master project advisor, Dr. Ahmed Salem for his valuable
guidance throughout my project. It was his unwavering support and constant
encouragement at each step that helped me complete my project on time. I am thankful to
my second reader Dr. Meiliu Lu who helped me in reviewing my project.
My parents and my brother have always been very supportive and a constant source of
inspiration for me. I would like to dedicate my Master project to my husband who has
always stood by me in times of difficulty and motivated me to achieve my goal.
v
TABLE OF CONTENTS
Page
Acknowledgments ……………………………………………………………………………..v
List of Tables…………………………………………………………………………………viii
List of Figures …………………………………………………………………………………ix
Chapter
1. INTRODUCTION ………………………………………………………………………...1
1.1 Background ………………………………………………………………………. . ..2
1.2 Overview…………………………………………………………………………......3
2. SYSTEM REQUIREMENTS ……………………………………………………………..5
2.1 Interface Requirements ………………………………………………………………5
2.1.1 User Interface …………………………………………………………….......5
2.1.2 Software Interface ……………………………………………………………5
2.1.3 Hardware and Operating System …………………………………………… 6
2.1.4 System Perspective …………………………………………………………..6
2.2 Functional Requirements ……………………………………………………………7
2.3 Use Case Diagram …………………………………………………………………..8
2.3.1 Use Case’s Basic Flow ……………………………………………………. 11
2.3.2 Use Case’s Alternate Flow …………………………………………………11
2.4 Users of the System …….………………………………………………………….12
2.5 System Constraints ………………………………………………………………...13
3. SYSTEM ARCHITECTURE AND DESIGN …………………………………………..14
3.1 Architecture ………………………………………………………………………..14
vi
3.2 Database Design …………………………………………………………………....16
3.3 System Flow Diagram ……………………………………………………………...24
3.4 Modules …………………………………………………………………………….26
3.4.1 Projects ……………………………………………………………………...26
3.4.2 Requirements ……………………………………………………………......27
3.4.3 Use Cases …………………………………………………………………...28
4. IMPLEMENTATION ……………………………………………………………………29
4.1 Overview of Technologies ………………………………………………………….29
4.2 User Interface ……………………………………………………………………....33
5. CONCLUSION …………………………………………………………………………..44
References ……………………………………………………………………………………46
vii
LIST OF TABLES
Page
Table 3.1 Projects …………………….……………………………………….18
Table 3.2 Requirements ……. …………….……………………………......... 19
Table 3.3 UpdateLogs …………….………………………..............................19
Table 3.4 DeleteLogs …………….…………………………………………...20
Table 3.5 Use Cases ….………….…………………………………………....21
Table 3.6 Basic Flow ….………….…………………………………………...21
Table 3.7 Alternate Flow ……….……….…………………………………… 22
Table 3.8 Issues ………….…………………………………………………... 23
Table 3.9 Actors ….……….…………………………………………............. 23
viii
LIST OF FIGURES
Page
Figure 2.1 Overview of System …….………………………………………….6
Figure 2.2 Use Case Diagram ……….………………………………………..10
Figure 2.3 Basic Flow ……….………………………………………………..11
Figure 2.4 Alternate Flow ………….…………………………………………12
Figure 3.1 Architecture ………………………………………………………15
Figure 3.2 Database Design ….……………………………………………….17
Figure 3.3 System Flow Diagram… ………………………………………….25
Figure 3.4 Projects Data Flow Diagram….…………………….……………..26
Figure 3.5 Requirements Data Flow Diagram……………….………………..27
Figure 3.6 Use Cases Data Flow Diagram…………..….…………………... ..28
Figure 4.1 Rails MVC Architecture Framework …………………………..…30
Figure 4.2 Projects List …………………………..…………………………...33
Figure 4.3 Create New Requirement …..……………………………………..34
Figure 4.4 Project Requirements …………………..…………………………35
Figure 4.5 Requirements Update Logs ………………….…………………...36
Figure 4.6 Requirements Delete Logs ………………………………………..37
Figure 4.7 Create New Use Case …………………………………………….38
Figure 4.8 List all Use Cases ………………………………………………...39
Figure 4.9 Add New Basic Flow ………………………………….................40
Figure 4.10 List Requirements Issues ………………………………………..41
ix
Figure 4.11 Reports ………………………………………………………….42
Figure 4.12 Requirements Update Logs Report …………………………….42
x
1
Chapter 1
INTRODUCTION
“ No part of the delivery process is as critical, nor as difficult because requirements map the human world to the technological world.’’
- Jim Highsmith
The software development lifecycle spans over many stages in the process of
developing the final product. Jim Highsmith, an author and contributor of “Agile
Project Management” correctly states in the phrase that the most crucial and
intriguing part in any software development route is the requirements phase [1].
Requirements answer the question ‘What is to be achieved or produced?’ The
challenging task of delivering software on time and on budget depends on the
precise recognition, implementation and processing of requirements. The effective
interpretation of user’s needs into technical jargon has never been a trivial process
and has lead to project delays, expensive reworks and sometimes even a complete
fiasco. As the efficient analysis and management of requirements becomes
imperative, the techniques which can help drive this complex process also gain
prominence. Use Cases is one such popular method used for describing interactions
between users (actors) and the system [2]. Capturing requirements with Use Cases
guarantees a seamless transition from problem to solution. Requirements and Use
2
Cases qualify as a great combination to identify and analyze the stakeholder’s
needs in the path of software development lifecycle [3].
1.1 Background
Developing a software product without comprehending user needs will cause a
project to fail. Gathering requirements from users and stakeholders always marks the
beginning of any software project development. To make a project successful in
achieving it’s objectives, these requirements need to be carefully interpreted,
analyzed and managed. A Use Case driven modeling approach helps communicate
requirements in a way that is understandable for technical as well as non-technical
members using a single, common format. A Use Case defines a requirement, provides an
introduction, and lists the different actors for a given scenario [4]. Use Case modeling
reduces mistakes that can occur in translating user requirements for non-technical
members into system requirements (for technical members). This approach also ensures
that any miscommunications or misunderstandings between the stakeholders and
the software group are resolved well before the development starts, avoiding
expensive modifications later in the development lifecycle [5]. There are commercial
tools available today like Requisite Pro, Analyst Pro, GatherSpace the benefits of
which are web based access, customized reporting, user interfaces, integration with
Microsoft Office Programs [6]. Usually these tools have complex features and users
may need to spend a considerable amount of time to study the various aspects. Moreover,
3
these tools may or may not take Use Case relationships like include, extend,
generalization into consideration. They offer a limited trial period which is insufficient to
scrutinize and evaluate all of their features. These tools also come with an expensive
price tag and are unaffordable for small projects [7]. The purpose here is to develop a
affordable tool which minimizes or eliminates most of the shortcomings of other tools
like cost, complexity and learning curve.
1.2 Overview
Requirements Analysis System Utilizing Use Case Modeling a.k.a. RASUM is a
web based open source tool to capture and analyze requirements using Use Case
Modeling. RASUM aims at providing functionalities to gather, track and document
requirements through a simple and intuitive user interface. RASUM makes the critical
task of analyzing requirements much more simple and interactive.
The key components of RASUM are:

Project Management

Capture and Analyze Requirements

Use Cases Module

Requirements Logs

Requirements Issues

Reports Generation
4
The Projects Management component deals with creating, updating or deleting projects.
The Capture and Analyze Requirements component is associated with gathering and
documenting requirements. Use Case module enables creation of Use Cases, Basic and
Alternate flows. The details of changed or deleted requirements are recorded in the
Requirements Logs component. The issues regarding any requirement can be added in
the Requirements Issues module. RASUM allows report generation for the components
described above in the Reports Generation module.
RASUM adopts a systematic approach of modeling requirements with Use Cases
with an objective to improve software quality thus resulting a better product. As
Use Cases work in perfect harmony with requirements, RASUM utilizes Use Cases
to explore the intricate details embedded in the requirements.
Chapter 2 details the requirements of this project which will help to clearly understand
the objectives of this application.
5
Chapter 2
SYSTEM REQUIREMENTS
The software development cycle of any product begins with requirements. Requirements
are the tasks or services that a system should perform to accomplish the desired goals
during the estimated time frame. Analyzing client requirements is a critical task and is the
key to project success. RASUM is a robust tool to gather, track and analyze requirements
using Use Case Modeling.
2.1 Interface Requirements
This section lists the user, software and hardware interface requirements.
2.1.1 User Interface
RASUM is a web based project which will have friendly user interface views. The views
displayed to the user will have simple forms which the user can fill and update data. The
user will be able to create new values that will be saved to the database. The user
interface screens will be simple to navigate through and will contain tutorials about
using this system along with other tutorials.
2.1.2 Software Interface
Various software technologies will be used to develop an interface where the user can get
information from the web server and can store updated or new data in the database. This
6
project will be a three tier web application. The software interface which will
communicate between the three tiers will use the Ruby on Rails framework which will be
based on Ruby programming language.
2.1.3 Hardware and Operating System
This web based application will run on Windows platform with Webrick server.
2.1.4 System Perspective
The figure 2.1 shows the general overview of this system. The different modules network
with RASUM to establish the flow of data. When the user creates or updates data values
through the user interface, the values are saved in the database. The application serves
user requests as data is passed from database to the user views.
Figure 2.1 Overview of System
7
2.2 Functional Requirements
Functional requirements depict the main functionality of the system.
This application should enable the user to do the following tasks:

Create new projects by entering relevant project information. Validate user input
data. Generate error messages if the data is invalid.

Edit or delete existing projects.

Upload requirements documents stored at an external location.

Create new requirements for an existing project. Upload an external file if needed.

Validate user input data. Since requirements are part of a project, verify whether
the project for which the requirements are being added exists. If not generate an
exception.

Edit or delete the requirements.

Record changed and deleted requirements

Create new Use Cases for requirements. Add actors, preconditions and post
conditions for the Use Cases. Validate user input data. Display error messages if
data is invalid. Edit or delete any Use Case as required.

Add Basic and Alternate flows to Use Cases.

Export data to Excel Spreadsheet.

Allow users to add requirements issues.

Generate reports.
8
2.3 Use Case Diagram
Figure 2.2 displays the Use Case model for RASUM. The description is as follows:
UC1: Manage Projects
This Use Case is associated with the projects module. It enables user to add, edit or delete
projects, view requirements, validate data.
UC2: Manage Requirements
This Use Case manages client requirements providing functionalities for adding and
updating requirements and listing requirements logs.
UC3: Import Requirements
User can import requirements from external files like MS-Word, Excel, CSV and PDF.
UC4: Generate Requirements Logs
When requirements are changed, the details are recorded in the requirements update logs.
The delete logs store the details of the deleted requirements.
UC5: Manage Use Cases
User creates Use Cases and links them to the requirements.
9
UC6: Create Basic, Alternate Flows
This Use Case describes the Basic and Alternate flows. A single Use Case can have more
than one alternate flow.
UC7: Add requirements issues
Users are allowed to select a requirement and add requirements issues. The issues will
contain the description for the issue, the person to whom the issue is assigned and the
date by which the issue needs to be resolved.
UC8: Export to Excel
For convenience of the user, the data can be exported to an Excel Spreadsheet.
10
System Boundary
UC1: Manage Projects
UC2: Manage
Requirements
UC3: Import
Requirements
UC4: Generate
Requirements Logs
User
UC5: Manage Use
Cases
UC6: Create Basic
,Alternate Flows
UC7: Add
requirements issues
UC8: Export To Excel
Figure 2.2 Use Case Diagram
11
2.3.1 Use Case’s Basic Flow
Figure 2.3 shows the flow of data under normal situations. This assumes that there are no
error conditions. The user input data is validated and then stored in the database. Such a
flow is also called as ‘Basic Flow’ which describes how a system should perform under
normal conditions.
Figure 2.3 Basic Flow
2.3.2 Use Case’s Alternate Flow
Figure 2.4 shows the flow of data in case of error conditions. The user enters data which
is validated. Invalid data is not stored in the database and an error message is displayed to
the user. The error conditions here may be of different types and may occur at any time
12
until the data is saved in the database. This is known as ‘Alternate Flow’ and it describes
how a system reacts in erroneous situations.
Figure 2.4 Alternate Flow
2.4 Users of the System
The users of this tool are business analysts, software developers, stakeholders, system
engineers, project managers, quality assurance engineers, software testers. For example a
business analyst would find RASUM very useful for creating Use Cases to analyze
requirements, a client would like to add new requirements or upload requirements files to
a project, developers would want to view the Use Case flows to have a clear view of the
requirements or add issues for a specific requirement, a project manager would like to
know issues associated with requirements. RASUM aims to meet their requirements and
provide support to users at various stages of development.
13
2.5 System Constraints

RASUM does not adopt special methods to test the performance of this system
especially on other operating systems.

JavaScript needs to be enabled on the client machine to utilize all the features of
this application.
Chapter 3 describes the design phase of this project. It includes database design, different
modules used by RASUM along with data flow diagrams for each module.
14
Chapter 3
SYSTEM ARCHITECTURE AND DESIGN
The design phase emphasizes on the question, “How to accomplish the requirements”.
Transition from requirements to design is no trivial task and involves meticulously
designing the database and other aspects to make the design plan feasible. This chapter
describes the design architecture of this system including the various modules used in this
application.
3.1 Architecture
This project is a web based application which uses Model-View-Controller (MVC)
framework. Figure 3.1 shows MVC software architectural design structure. One of the
main benefits of this technique is that the presentation layer logic is isolated from the
business logic. The web browser is the user who sends request which is sent to the MVC
layers and is processed. MVC segregates the application into three main elements,
Model, View, Controller [8]. The Model basically represents the data and can also be
connected with the business logic. It has the capability to interact directly with the
database and retrieve data. The controller is more focused on processing the data obtained
from the model before it can send it to the view. Controller networks with the model and
the view and centralizes the access to data. The view is the presentation layer whose
15
primary task is to display the data to the user. It has minimal logic code which is
concerned with the format of the output data.
Figure 3.1 Architecture
These are the sequence of steps beginning with user request to the final data output
delivery through the MVC layers in RASUM:
1. When the browser requests data, the request is received by the web server
Webrick
2. Webrick routes the data to the appropriate controller for further processing.
3. The controller parses user request and may contact the Model if data needs to be
fetched from the database.
4. Model will retrieve the data from or save the data in the database, perform
business logic and validate data. The records are then passed back to the
controller
5. The controller gives the data to the view to be displayed as output.
6. The view has the code to display the information in the specified format. It is
usually includes HTML, CSS, XML, JavaScript.
16
3.2 Database Design
This section shows the database design structure for RASUM. The database structure in
figure 3.2 displays the tables used in RASUM application. The project table is the parent
table and is linked to the Requirements and Use Case table with a one to many
relationship. Use Case is connected to the Basic Flow table indicating that one Use Case
can have one or more Basic flows. Similarly Use Case is related to the Alternate Flow
table which signifies that one Use Case may have zero, one or more Alternate flows. Use
Case also connects the Actors table. The Requirements table is bonded to the Issues,
UpdateLogs and DeleteLogs tables with a one to may relationship.
17
Figure 3.2 Database Design
Given below is the detailed description of all the tables in the database:
1. Projects
Table 3.1 stores information about projects. Id is the unique number value for the project.
The field name gives the name of the column in the table like Id, Name, Owner, Start
date, End date. The fields Photo_file_name, Photo_content_type, Photo_file_size are the
attributes of the uploaded file where file_name indicate the name of the file, content_type
18
indicates the type of file and file_size gives the file size. The constraints column shows
that Id is the primary key constraint for the table.
Field Name
Description
Id
Gives the unique id of the
project
Gives the name of the project
Gives the owner of the project
Gives the start date of the
project
Gives the end date of the
project
Gives the description of the
project
Name of the attached file
Name of content type
Size of the attached file
Name
Owner
Start_date
End_date
Description
Photo_file_name
Photo_content_type
Photo_file_size
Data
Type
Int
Constraints
Primary Key
Varchar
Varchar
Date
Date
Text
Varchar
Varchar
Int
Table 3.1 Projects
2. Requirements
The 3.2 table stores information about all the software requirements. Id is the unique
number value for the requirement. The field name gives the name of the table columns
like Id, Name, Priority, Status, Description. Project_Id is the foreign key which connects
with the Projects table. The Constraint table indicates the primary key and foreign key
constraints. This table has various data types like int, varchar and text.
19
Field
Name
Id
Name
Priority
Status
Project_Id
Description
Description
DataType
Constraints
Gives the unique id of the software
requirement
Gives the name of the software
requirement
Gives the priority of the
requirement
Gives the status of the requirement
Gives Id of the project
Describes the software requirement
Int
Primary Key
Varchar
Varchar
Varchar
Int
Text
Foreign Key
Table 3.2 Requirements
3. UpdateLogs Table
Table 3.3 stores the logs of the requirements when they are updated. Id is the primary key
for this table. The description field explains which specific requirement attribute is
changed along with the old and new values. It also gives the date when the requirement
was updated.
Field Name
Id
Name
Date
Req_Id
Req_Owner
Description
Description
Gives the unique id of the
changed record
Name of the changed requirement
Date of change
Gives Id of the software
requirement
To which owner the requirement
belongs to
Details
Table 3.3 UpdateLogs
DataType
Int
Constraints
Primary Key
Varchar
Date
Int
Foreign Key
Varchar
Text
20
4. DeleteLogs Table
This table stores the information about all the requirements that were deleted. Id is the
primary key constraint. It also gives the date when that specific requirement was deleted.
The req_id serves as the foreign key connecting to the requirements table. The req_owner
is the name of the owner to whom the requirement belongs.
Field Name
Id
Name
Date
Req_Owner
Req_Id
Description
Description
Gives the unique id of the deleted
record
Name of the deleted requirement
Date when requirement deleted
To which owner the requirement
belongs to
Gives Id of the software
requirement
Details
DataType
Int
Constraints
Primary Key
Varchar
Date
Varchar
Int
Foreign Key
Text
Table 3.4 DeleteLogs
5. Use Cases Table
Table 3.5 stores all the data related to Use Cases. It has Id as the primary key. The field
name is the column name of the table like Id, Name, Actors, Description, Precondition,
Post condition. The Use Case table accepts uploaded files as attachments. The
photo_file_name indicates the name of the file, photo_content_type indicates the type of
file and photo_file_size is the file size. Project_Id and Req_Id are the foreign keys which
connect to the parent tables Projects and Requirements.
21
Field Name
Id
DataType
Int
Project_Id
Description
Gives the unique id of the use
case
Gives the name of the use
case
Gives Id of the project
Req_Id
Id of the requirement
Int
Description
Precondition
Postcondition
Actors
Describes the use case
Precondition
Postcondition
Gives the actors in the use
case
Name of the attached file
Name of content type
Size of the attached file
Text
Varchar
Varchar
Varchar
Name
Photo_file_name
Photo_content_type
Photo_file_size
Constraints
Primary
Key
Varchar
Int
Foreign
Key
Foreign
Key
Varchar
Varchar
Int
Table 3.5 Use Cases
6. Basic Flow Table
This table has all the Use Case Basic Flow data. Id is the primary key. Name is the name
of the Basic Flow. Usecase_Id is the foreign key. The flow field gives the description of
the entire flow. SystemResponse denotes the post condition.
Field Name
Id
Name
Usecase_Id
Flow
SystemResponse
Description
Gives the unique id of the basic
flow
Gives the name of the basic
flow
Id of use case to which it
belongs
Actual Flow
System Response
Table 3.6 Basic Flow
DataType
Int
Constraints
Primary Key
Varchar
Int
Text
Varchar
Foreign Key
22
7. Alternate Flow Table
This table has all the use case alternate flow data. Id is the unique id for the Alternate
Flow. The flow field is the description of the entire alternate flow. SystemResponse is the
post condition.
Field Name
Id
Name
Usecase_Id
Flow
SystemResponse
Description
Gives the unique id of the
alternate flow
Gives the name of the
alternate flow
Id of use case to which it
belongs
Actual Flow
System Response
DataType
Int
Constraints
Primary Key
Varchar
Int
Foreign Key
Text
Varchar
Table 3.7 Alternate Flow
8. Issues Table
Table 3.8 stores all the issues related to the requirements. Id is the primary key for this
table. The Description field gives the details of the issue. The Assigned_to is the name of
the person to whom the issue has been assigned. The Resolve_by is the date by which the
issue needs to be resolved. The Req_Id serves as the foreign key connecting to the
Requirements table.
23
Field Name
Description
DataType
Id
Gives the unique id of the issue
Int
Description
Req_Id
Describes the issue
Id of requirement to which it belongs
Varchar
Int
Assigned_to
Name of the person assigned to solve
it
Date by which it needs to be solved
Varchar
Resolve_by
Constrai
nts
Primary
Key
Foreign
Key
Date
Table 3.8 Issues
9. Actors Table
Table 3.9 stores all the information about the actors of the use case. Id is the primary key.
Name is the name of the actor like student, cashier, engineer. Description field specifies
the details and goals of the actor.
Field
Name
Id
Name
Usecase_Id
Description
Description
DataType
Constraints
Gives the unique id of the actor
Name of the actor
Id of use case to which it belongs
Description about the actor
Int
Varchar
Int
Text
Primary Key
Table 3.9 Actors
Foreign Key
24
3.3 System Flow Diagram
Figure 3.3 shows the system flow diagram. This is level 1 data flow diagram and
illustrates
the flow of data through the various modules of RASUM. The circles
represent the process and have inputs and outputs. The arrows depict the flow of data.
The user is the entity who interacts with the modules at a point in time. The parallel lines
signify the data store where data is saved to and retrieved from. In a typical scenario, the
user creates a project, adds requirements to it, adds Use Case Actors, creates Use Cases,
adds Basic and Alternate flows to the Use Cases. Any issues regarding a requirement are
added by the user. All the new and updated data is validated before it can be saved in the
data store. Data is fetched from the store as needed especially while generating reports.
User selects the report to view and the report is displayed.
The advantage of a data flow diagram is that it helps to visualize the system as whole and
in individual parts during the initial stage of system design. It divides the entire system
into different sub-systems which can be easily understood by all team members. These
diagrams show the high level aspects of the system and also display an in-depth analysis
of the system components.
25
Figure 3.3 System Flow Diagram
26
3.4 Modules
This section describes the main modules of RASUM using data flow diagrams.
3.4.1 Projects
This module handles the project management feature of RASUM. As seen in the data
flow diagram below, the user can create new project, edit or delete existing projects.
Project DB is the database in which the project data is stored. The new project details are
first validated and then stored in the database. Similarly, the updated project data is
validated and stored in the database. The user can import a requirements file which is
stored at an external location. This can be done when the project is created or during the
update phase.
Error Message
Project ID
Project data
Create new
project
User
Project
details
Verify data
Project data
fields
Edit project
details
Project
ID &
name
Project
name
Delete
project
Updated project data
Figure 3.4 Projects Data Flow Diagram
Project DB
27
3.4.2 Requirements
The requirements module deals with all the requirements for the projects. The user can
add new requirements by providing all the details. Any attribute of the requirement can
be updated, validated and stored in the database. The details of this changed data is
recorded in the UpdateLogs database. This feature is helpful as it helps to keep track of
all the changes made to the requirements.
Error message
SR ID
SR
details
Create new
SR
User
SR Data
SR data
fields
Edit SR
details
SR ID &
name
Import file
interface
Error Message
Verify data
SR details
Enter iteration
number
Delete SR
Import SR file
Updated SR data
SR ID & name
Updated SR data
Record
updated SR
data fields
SR ID,name and updated
fields data
SR Log DB
Figure 3.5 Requirements Data Flow Diagram
SR DB
28
3.4.3 Use Cases
This module handles use case management related tasks. The user can manage use cases.
The basic flow or alternate flow can be added to the use case either at the time when the
use case is created or during the use case update stage. This gives flexibility to the user as
the flows need not be added as soon as the use case is created but can be added at any
point of time. All the user data is validated and in case of any error, a message is
displayed.
Create Basic
Flow
Use Case details
Use Case
ID & name
Use Case
ID & name
Us
User
eC
as
Create
Alternate Flow
eI
D
Use case data
fields
Edit use case
details
Use case
ID & name
Create new
use case
Delete use
case
Use Case Data
Verify data
Use Case DB
Use case
details
Associate use
case with SR
Use Case ID & name
Updated use case data
Error message
Figure 3.6 Use Cases Data Flow Diagram
Chapter 4 describes the implementation phase and the technology used for this system.
29
Chapter 4
IMPLEMENTATION
The implementation phase of any project is an important step towards achieving the
desired goals. It actually involves bringing the system design into action and making it
work. This chapter describes the implementation details of RASUM
including the
various technologies used. RASUM uses Ruby on Rails framework, MySQL database,
HTML, JavaScript, Cascading Style Sheets to develop the user interfaces, business logic
and backend database.
4.1 Overview of Technologies
Ruby on Rails
Ruby is an object oriented language where everything is considered as an object. Rails is
a framework for developing web applications. It is an open source technology utilized by
web developers for quick implementation of web projects in an agile development
methodology. Ruby on Rails is based on Ruby programming language which makes it
simple and flexible to use, making the development easier with remarkable productivity.
Rails emphasizes on the concept of convention over configuration. This means that Rails
has certain defaults when developing web projects and if those rules are followed
meticulously then it would prove effective to accomplish the tasks with fewer lines of
30
code. Ruby on Rails framework follows the Model-View-Controller (MVC) approach
which segregates the application into three closely knit layers.
Model (Active Record ) :
Model ties the data objects and database data forming the object-relational-mapping
pattern. It interacts directly with the database and is designed to support the application
tasks that are concerned with the database which includes retrieving data records and
saving new or updated records.
Figure 4.1 Rails MVC Architecture Framework
Controller (Active Controller ) :
Rails controller handles user request and decides what output has to be displayed. The
controller can interact with the model to get data from database and send it back to the
31
view as output. It acts as a medium between the model and the view and also saves and
updates user data to the model.
View (ActionView) :
View acts as the presentation layer and displays data to the user. It contains a mixture of
Ruby and HTML code. The ActionView package encloses the functionality of View
module. View has three main parts: Template, Layout and Pagination. Template is a file
which specifies a fixed format and can easily used in other pages. This eliminates the
need to recreate the format each time. Layout is concerned with the display of graphic
elements like buttons, text boxes, radio buttons, checkboxes on the page. The layout can
be placed horizontally, vertically or both. With pagination, the page can be divided into
several pages. This is useful when amount of data is very large to be fitted on one page.
MySQL Database:
MySQL is an open source multi threaded SQL database management system. It is one of
the most used databases in the industry today because of its simplicity, good transactional
support, robust security features and fast performance. It displays strong scalability with a
capacity to store massive amounts of data. MySQL is also compatible with most of the
operating systems and can be obtained free of cost under the GNU license.
32
Hypertext Markup Language (HTML):
It is the common computer language used for web design and development. HTML
document is identified by the HTML tag. The HTML page can be divided into two main
sections: HEAD and BODY. The page starts with the <HTML> tag and end with
</HTML> tag. All web pages in RASUM require HTML tags for display on an internet
browser.
JavaScript:
JavaScript is a scripting language which is used mostly for web development. This object
oriented programming language adds extra functionality to the web pages making them
more dynamic. All web browsers have built-in support for JavaScript, however to be able
to run it, this feature must be enabled on the browser. JavaScript code and HTML can be
in one file but usually it is better to have it in a separate file and referenced in the HTML
code. The same JavaScript code can be reused in other pages by adding the tag into each
of the pages. JavaScript is a powerful designed to handle dynamic tasks.
33
4.2 User Interface
This section displays the user interface screens of RASUM.
Figure 4.2 Projects List
Projects Screen
This is the Projects interface. When the user clicks on the ‘Projects’ tab, the user can
view a list of all the projects. When a new project is to be added, user can enter the
project name on the left sidebar under ‘Add new project name’. The search option helps
to search any project by name or owner. A file of requirements can be attached to any
projects and can be viewed with the ‘View Attachments’ link. By clicking on the project
34
name or id on the screen, the project edit page opens where user can update the project
data.
Figure 4.3 Create New Requirement
Create New Requirement Screen
Once the projects are created, requirements can added. User need to enter the name,
priority, status, owner and description for the requirement. The project drop down list
contains the names of all the projects. The user must select one project for which this
requirement is being created.
35
A search feature is provided on the left side bar of the page. Here user can search any
requirement by name, owner, status or priority.
Figure 4.4 Project Requirements
Project Requirements Screen
One or more requirements can be added to a project. The 4.4 shows all the requirements
for a project. The name of the project to which the requirements belong is displayed on
the top. The ‘Edit’ link will display the page where user can update the requirement. The
requirement can be deleted by clicking the ‘Destroy’ link. If the user wants to view the
relevant logs for any requirement, the ‘View Logs’ link can be clicked.
36
Figure 4.5 Requirements Update Logs
Requirements Update Logs Screen
The figure 4.5 display all the update logs for requirements. When any field of a
requirement is edited, the change made is recorded in the update log. The ‘Log Date’
column indicates the date when the requirement was updated.
37
Figure 4.6 Requirements Delete Logs
Requirements Delete Logs Screen
When a requirement is deleted, it can no longer be seen in the list of requirements.
However sometimes it becomes necessary to keep a track of all the deleted requirements
for future reference. The 4.6 shows a list of all the deleted requirements. If the user wants
to view all the deleted requirements which belong to a specific user, the owner name can
be entered in the search box.
38
Figure 4.7 Create New Use Case
Create New Use Case Screen
New Use Case can be created by entering all the relevant details like Use Case name, the
requirement to which the Use Case belongs, actors, pre-conditions and post-conditions
and description. A Use Case diagram can be attached to the record. The ‘Browse’ button
will help the user to select the location where the file is located. The search box provides
search functionality for the Use Case records.
39
Figure 4.8 List all Use Cases
Use Cases List
Figure 4.8 displays the list of Use Cases. The ‘Requirement Id’ and ‘Project Id’ indicates
the requirement and project to which the Use Case belongs. The ‘View Flows’ link
displays the Basic and Alternate Flows for that specific Use Case. The attached Use Case
diagram can be viewed by clicking the ‘Attached Diagram’ link.
40
Figure 4.9 Add New Basic Flow
Add New Basic Flow Screen
This screen allows the user to add a new Basic Flow for a Use Case by filling the details
like the flow name, the Use Case to which the flow belongs and description of the flow.
The ‘Systemresponse’ field indicates the post-condition. The Basic Flows can be
searched by name by using the search box.
41
Figure 4.10 List Requirements Issues
List Requirements Issues Screen
Users may have some problems regarding any requirement. In this case, they can add the
issues for any specific requirement by utilizing the ‘Issues’ page. The figure 4.10 shows
the list of issues for a requirement. The issue includes the issue name, the person to
whom this issue is assigned and the date by which this issue is required to be solved.
42
Figure 4.11 Reports
Figure 4.12 Requirements Update Logs Report
43
Reports
Figure 4.11 shows the Reports page where user can select the report to view. Figure 4.12
displays the requirements update logs report.
44
Chapter 5
CONCLUSION
RASUM is a web based open source tool which captures and analyzes requirements
utilizing Use Case modeling. Analysis is done with the help of Use Case flows where
the Basic Flow examines the flow of data under normal situations and the Alternate Flow
evaluates flow of data with error conditions. RASUM has the capability to upload Use
Case diagrams from external files which provides a visual perspective of Use Cases.
RASUM can export data to Excel to be further scrutinized. In addition to requirements
analysis, RASUM also provides effective tracking of requirements by recording the
details of changed or deleted requirements. It also allows users to add issues regarding
requirements. Through it’s Project Management feature, users can upload initial or
intermediate requirements from external file formats such as MS-Word, Excel, PDF,
CSV. RASUM generates dynamic reports for various components like projects,
requirements, Use Cases, issues and requirements logs.
RASUM is better suited for small to medium scale projects but does not perform well for
large or complex projects. RASUM does not provide an internal communication system
between the users.
Further work can be done on RASUM which can eliminate the above shortcomings.
RASUM can use other UML diagrams like sequence diagrams, activity diagrams,
45
collaboration diagrams for further analysis of requirements. Another feature that might
be added to enhance the tool is the ability to design test cases based on the Use Case
Models. A requirements issues tracking feature can be included in RASUM which can
track all the resolved issues and can display alert messages if issues are not solved by
due date. Additional features such as automatic Use Case diagrams generation can be also
added to RASUM.
46
REFERENCES
1] “Requirements Proverbs” . [Online]. Available
http://easyweb.easynet.co.uk/~iany/consultancy/papers.htm
2] “Using Use Cases for Requirements Capture” . [Online]. Available
http://www.mcbreen.ab.ca/papers/UseCaseNotes.pdf3
3] “Effective Requirement & Use Case Management For Software Development”.
[Online]. Available
http://www.bredmeyer.com/use_cases.htm
4] “Defining Use Cases”. [Online]. Available
http://publib.boulder.ibm.com/infocenter/pim/v6r0m0/index.jsp?topic=/com.ibm.wp
c.sar.doc/wpc_tsk_arc_definingusecases.html
5] “Essentials of Software Engineering” by Frank Tsui
Publisher: Jones & Bartlett Learning, Publishing Date: December 15, 2009
Print ISBN-13: 978-0-7637-8534-5
6] “Requirements Management Tool”. [Online]. Available
http://www.jiludwig.com/Requirements_Management_Tools.html
7] “Automating Requirements Management”. [Online]. Available
http://www.processimpact.com/articles/rm_tools.pdf
8] “ Rails MVC Architecture”. [Online]. Available
http://rorrocket.com/2010/04/17/the-rails-mvc-architecture-explained-the-easy-way/