RENG Assignment Template

Module Code
Intake Code
Lecturer Name
Hand in Date
Tutorial No.
Group No.
Student ID
:
:
:
:
:
:
CT056-3.5-2 Requirements Engineering

UC2F1402SE
SIVANATHAN CHELLIAH
10th November,2014
Student Name
Requirements Engineering
Group Assignment
UC2F1301SE
TABLE OF CONTENTS
2
Introduction........................................................................................................................4
2.1
Project Background.....................................................................................................4
2.2
Current flow of operations...........................................................................................5
2.3
Project Assumptions....................................................................................................5
2.4
Problem Analysis.........................................................................................................6
2.4.1
Performance Problems.........................................................................................6
2.4.2
Information Problems...........................................................................................7
2.4.3
Economics Problems............................................................................................7
2.4.4
Control and Security Problems............................................................................8
2.4.5
Efficiency Problems.............................................................................................8
2.4.6
Service Problems..................................................................................................9
2.5
Problem Solutions.....................................................................................................10
2.6
Project Scope.............................................................................................................12
2.7
Project Aims and Objectives.....................................................................................12
Schedule Planning............................................................................................................13
3.1
Gantt Chart................................................................................................................13
3.2
Workload Matrix........................................................................................................14
Requirements Development Processes............................................................................15

4.1
Elicitation..................................................................................................................15
4.1.1
Customers...........................................................................................................15
4.1.2
Owners...............................................................................................................16
4.1.3
Restaurants.........................................................................................................16
4.1.4
Drivers................................................................................................................17
4.1.5
Telephone Operators..........................................................................................17
4.2
Analysis.....................................................................................................................18
2
Class Diagram....................................................................................................18
4.2.2
Use Case Diagram..............................................................................................18
4.2.3
Data Flow Diagram............................................................................................23
Requirements Specification.......................................................................................27
4.3.1
4.4
Description of template items............................................................................28
Validation & Verification...........................................................................................30
4.4.1
Validation Techniques........................................................................................30
4.4.2
Requirements Inspection and Checklist.............................................................31
Requirements Management..............................................................................................35
5.1
UC2F1301SE
4.2.1
4.3
Group Assignment
Requirements Management Planning........................................................................35
5.1.1
Requirement Identification.................................................................................35
5.1.2
Change Management Process............................................................................36
5.2
Traceability................................................................................................................37
5.3
Requirement Management Tool Support...................................................................38
Weekly Reports................................................................................................................39
6.1
Project Progress Report 1..........................................................................................39
6.2
6.3
6.4
References........................................................................................................................43
Appendix : SRS Documentation......................................................................................44
Group Assignment
1 INTRODUCTION
1.1 PROJECT BACKGROUND
1.2 PROJECT ASSUMPTIONS

1.3 PROBLEM ANALYSIS
1.3.1 Performance Problems
Problem
Consequences
UC2F1301SE
Group Assignment
1.3.2 Information Problems

Problem
Consequences
1.3.3 Economics Problems

Problem
Consequences
UC2F1301SE
Group Assignment
UC2F1301SE
1.3.4 Control and Security Problems

Problem
Consequences
No control over manipulation of records
Too little control Input data is not
adequately edited
Possible to modify amount on records to Too little security Crimes can be
show incorrect totals.
committed against data
No control over who has access to what Too little security Ethics are breached on
kind of information
data or information
Changes to records may not be reflected Too little control Redundantly stored data
across the system
Chance of human error in creating records
is inconsistent in different files

Too little control Processing errors are
occurring
1.3.5 Efficiency Problems

Problem
Consequences
Details of return customers are recorded in Waste of Time Data is redundantly input
every new transaction
Every record is written on paper
Materials required for tasks is excessive
Changes to existing orders means discarding Waste of materials and supplies
existing order and writing a new one
Calculation of totals, creation of reports are Effort required for tasks is excessive
all done manually.
Group Assignment
UC2F1301SE
1.3.6 Service Problems

Problem
Consequences
Chance of human error in producing reports The system produces inconsistent results
Availability of drivers is unknown until they The system produces unreliable results
call in or are called
High learning curve for new employees due The system is not easy to learn
to complicated operations.
Manual work based system consumes time The system not easy to use
and effort
Sudden changes such as employee absence The system is inflexible to new or
can disrupt operation efficiency
exceptional situations
Additional customers or new restaurants The system is inflexible to change
means extra workload on employees
Changes in food selection, prices and The system is not coordinated with other
availability in restaurants is not known to systems.
company.
Group Assignment
UC2F1301SE
1.4 PROBLEM SOLUTIONS

Problem
Proposed Solution
No knowledge of drivers availability unless System to track deliveries and driver

they call in or are called
availability
Manually written records
Computers to enter records
Telephone operators can only handle limited Website to take orders with telephone
number of customers at any one time.
operators as backup
Individual records and receipts are all Database to store records and receipts
separate
Records are stored by telephone operators Database to store records and receipts
while receipts are stored by drivers
Record and receipts are on paper.
Computers to produce digital records
Record details are obtained from customer Customer enters their own details through
through voice calls
website
Details of return customers are recorded in Account on database for each customer to
every new transaction
Chance of human error in writing orders
store their details

Database with on demand information
reduces chance of inputting wrong data

Unknown knowledge of restaurant food Client system for restaurants to keep track
selections or prices
of their menu
Restaurant food selection availability is Client system for restaurants to keep track
unknown
of their menu
Creating reports to monitor performance is Reporting function
in
website
very difficult
automatically generate reports
Cost of delivery from restaurant to customer Integration with mapping
address is unknown
to
determine distance between restaurant and

customer
Fuel costs for drivers cannot be traced
system
to
residence
for
calculation
of
delivery costs
Function to compare delivery distance
against fuel consumption of drivers.

Additional telephone operators required on Website able to handle increasing customers
hand to handle increasing customer base.
at the same time
No control over manipulation of records
Changes to records are logged
Possible to modify amount on records to System automatically calculates amount and
show incorrect totals.
restricts changes to menu prices.
No control over who has access to what Login system to restrict access to data to
kind of information
relevant employees
Changes to records may not be reflected Centralized database ensures any changes
8
Group Assignment
across the system
UC2F1301SE
are reflected equally across the entire
system
Changes to existing orders means discarding Digital records which can be modified if
existing order and writing a new one
necessary
Calculation of totals, creation of reports are System functions to take care of calculation
all done manually.
Chance of human error in producing reports
and report generation

Automate generation of reports renders
problem obsolete
High learning curve for new employees due User manual and training for system to
to complicated operations.
lower learning curve
Manual work based system consumes time Automated system reduces employee effort
and effort
and increases throughput
Sudden changes such as employee absence Backup systems to ensure consistent system
can disrupt operation efficiency
availability and performance
Additional customers or new restaurants Processing capability of system can be
means extra workload on employees
upgraded if necessary to handle extra
workload
Changes in food selection, prices and Synchronized restaurant client database and
availability in restaurants is not known to main database ensures changes are known
company.
to the company
Group Assignment
UC2F1301SE
1.5 PROJECT SCOPE

This project encompasses the process of creating a Software Requirements Specification
Documentation identifying the problems and requirements that Sue and Tom Bickford are
facing in their current business which is Waiters on Wheels.
1.6 PROJECT AIMS AND OBJECTIVES

To create a Software Requirements Specification documentation that will serve as a guideline
for the development of a system that will meet the needs of Sue and Tom Bickford in their
line of operations.
-
Identify and propose solutions using the PIECES framework

Using the Requirements Development Processes which include Elicitation, Analysis,
Specification and finally Validation of requirements to ascertain that the requirements
proposed are valid solutions.

Manage requirements by using tools to plan and monitor changes for traceability.
10
Group Assignment
UC2F1301SE
2 SCHEDULE PLANNING
2.1 GANTT CHART
2.2
MATRIX
Task
Alexander Ho
YingHan
11
Lau Chun Khye
Group Assignment
UC2F1301SE
Introduction
50%
50%
Schedule Planning
50%
50%
Requirements Development Processes
50%
50%
Requirements Management
50%
50%
Weekly Reports
50%
50%
Appendix: SRS documentation
50%
50%
Signatures
12
Group Assignment
UC2F1301SE
3 REQUIREMENTS DEVELOPMENT PROCESSES

3.1 ELICITATION
3.1.1 Customers
For customers, the method of elicitation involves distributing questionnaires to a relevant
demographic, primarily existing customers that have ordered one or more times with the
company in order to learn about their current ordering experience as well as any
improvements they may be able to suggest for the system.
Through the questionnaires, it is found that the customers constantly face difficulty
contacting the company due to the limited amount of operators on hand during lunch and
dinner times. They find the process of having to inform the operator about their details such
as full name, address, number to be very cumbersome as some of them are frequent
customers and thus feel the company should have some sort of system to store their details
and focus on getting straight to the ordering process. When there is a need to change orders,
the process also takes some time over the phone since the operator needs to call the restaurant
to verify whether the order has been prepared.
13
Group Assignment
UC2F1301SE
3.1.2 Owners
For the owners, the method of elicitation involves interviewing Tom and Sue individually, in
order to gain some insight into the difficulties that they face while working with the system.
In addition to this, due to the fact that the owners are primary stakeholders of the system,
their needs will be considered as top priority and thus interviewing them will help to provide
a clearer picture of their business requirements.
Through the interviews, the main issue the owners are facing is the information that they are
getting from the system, or rather the lack of it. Due to the fact that reports involve sorting
through a lot of paperwork in order to obtain any useful information, it is very difficult to
judge whether they are operating the business efficiently. As of the time of the interview, the
only information they are able to gain from the reports are gross profits calculated from
weekly earnings after deducting the amount owed to restaurants. As such, the owners require
a reporting system that is both timely and accurate, as well as being flexible so that they can
request varied reports from the system according to their business needs.
3.1.3 Restaurants
For the restaurants, the methods of elicitation involves observing the flow of operations at the
restaurants from the moment they receive a call from Waiters on Wheels to accept an order.
Whenever necessary, questions are asked so that everything remains clear-cut.
Through observations, the restaurants are each using very different systems of accepting and
preparing the orders that they receive from Waiters on Wheels. Due to the absence of any
guidelines for processing the order, some restaurants choose to process the order in the same
style as their ordering system, which presents a problem since payments to them are not made
daily but rather weekly to them, and doing such means additional workload for them since
they need to work out which receipt belongs to Waiters on Wheels at the end of the day and
how much amount is due. Other restaurants have a log book where the delivery orders are
noted and have a much better experience than the former restaurants who go through much
trouble to sort out their orders at the end of the day, yet this method still requires the workers
of the restaurant to set aside valuable time to do the calculations at the end of every day.
Human errors are prone in both scenarios when sometimes a particular order detail is missed
or misunderstood, which leads to delays and customer dissatisfaction when their orders are
not up to par with their expectations.
14
Group Assignment
UC2F1301SE
3.1.4 Drivers
For the delivery drivers, the method of elicitation involves interviewing the drivers. These
interviews serve to garner information from them such as their experiences handling the
delivery orders provided to them, their ability to maintain communication with the company
as well as any improvements that they wish could be implemented for them.
Through the interviews, one of the major problems that the drivers constantly face is updating
the company about their status, since the company has no active system to track delivery
progress, any updates to their delivery progress must be relayed to the company by calling the
operators. This method of relaying information is highly inaccurate and untimely as the
operator they call may not be the one who is handling their delivery order and thus they may
have to wait as they are passed to the proper operator, which can take some time during lunch
or dinner hours due to the increased workload on the operators. When asked whether they
wish for any improvements to the system that applies to them, most have expressed their
desire for a digital tracking system that they can update with a push of a few buttons, rather
than wasting time calling the company again and again during the course of their work.
3.1.5 Telephone Operators

For the telephone operators, the method of elicitation involves observing their flow of
operations as well as interviewing them to gather their opinions on the current flow of
operations as well as any suggested improvements that they may have in mind.
Through the observations, it is obvious that the operators experienced delays in numerous
phases of their operations of handling calls from customers and coordinating the drivers. This
is because much of the information they need is not available to them on demand. Such
delays happen when they spend time writing down the details of repeat customers, trying to
contact a driver that is available to take a delivery order as well as locating an order receipt to
make changes to an ongoing order. All these delays are a major source of headache and
represents a workload with a high learning curve, making it difficult for newcomers to the job
to handle such an enormous amount of responsibilities in one go which is highlighted in
interviews with them. Most have expressed their desire for system features that will provide
them information right away instead of having to manually look for it, as well as features that
take some of the order processing workload off of them such as a method of retaining the
information of repeat customers so they can quickly get to the items that the customer wishes
to order.
15
Group Assignment
3.2 ANALYSIS
1.1.1 Class Diagram
1.1.2 Use Case Diagram
16
UC2F1301SE
1.1.2.1
Group Assignment
UC2F1301SE
Use Case Specification

Case ID UC01
Name User Access & Management
Actor: Telephone
Operator,
Customer,
System
Administrator,
Restaurant, Driver, Owner

Description: This case is further divided into 2 parts:
User Login (refer UC02)

Personal Information Management (PIM) (refer
UC03)
Case ID UC02
Name User Login
Actor: Telephone
Operator,
Customer,
System
Administrator,

Description: User logs into the system
Preconditions: Valid username and password
Post conditions: User are logged into the system
Frequency of Use: Every time user use the system
Normal Course of LG.NC.01: User entered correct username and password in
Events: the corresponding field.
LG.NC.02: Submit button is clicked
Alternative Courses: -
17
Group Assignment
UC2F1301SE
Case ID UC03
Name Personal Information Management (PIM)
Actor: Telephone
Operator,
Customer,
System
Administrator,

Description: Management of user information in the system
Preconditions: User must login first
Post conditions: Personal information is being updated
Frequency of Use: Only when users wish to update their information
Normal Course of PIM.NC.01: About Me button is clicked
Events:
PIM.NC.02: All the details of the user id shown

PIM.NC.03: User updated the data in the field with no errors
PIM.NC.04: Update successful.
Alternative Courses: PIM.AC.01: Forget Password is clicked before the user

login.
PIM.AC.02: A verification email will sent to user email that
given during user registration.
PIM.AC.03: User click on the link in the email.
PIM.AC.04: User are redirect to the change password page to
setup new password.
18
Group Assignment
Case ID UC04
Name Customer Management
Actor: Telephone Operator
Description: This case is further divided into 3 parts:
Add New Customer (refer to UC05)

Search Customer (refer to UC06)
Update Customer Details (refer to UC07)
Case ID UC05
Name Add New Customer
Description: Adding of new customers to the system
Preconditions: Actor must login to the system
Post conditions: New customer is added
Frequency of Use: Only when new customer called to the operator
Normal Course of AC.NC.01: Customer Registration is clicked
Events:
AC.NC.02: All field is filled with no errors

AC.NC.03: Submit button is clicked.
19
UC2F1301SE
Group Assignment
UC2F1301SE
Case ID UC06
Name Search Customer Details
Description: Searching of customer details
Valid customer ID must be given
Post conditions: Customer details with the correspondence ID is shown
Frequency of Use: When operator want to add new order with customer that
forgot their id
and when customer want to update their
information
Normal Course of SC.NC.01: Valid customer ID is entered
Events:
SC.NC.02: Submit button is clicked.
Case ID UC07
Name Update Customer Details
Description: Updating of customer details
Search customer record before update can be done
Post conditions: Customer information is being updated
Frequency of Use: Only when customer want to update their details
Normal Course of UC.NC.01: All field is filled with no errors
Events:
UC.NC.02: Submit button is clicked.
20
Group Assignment
3.2.1 Data Flow Diagram

1.1.2.2
Level 0
1.1.2.3
Level 1
21
UC2F1301SE
1.1.2.4
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Group Assignment
Data Dictionary
1.0
User Access & Management
This is the process that allow users to login and
update their information.
User Details
User Information
2.0
Account Registration
This is the process that allow customer to
register themselves at the website.
Customer Details
Customer Information
3.0
View Menu
This is the process that allow customer to view
the existing menu item on the website
Item Details
Menu Item Information
4.1
Make New Order
This is the process that allow customer and
telephone operator to make new order.
Order Details
Order
22
UC2F1301SE
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Group Assignment
4.2
Calculate Price
This is the process that calculate the total price
of the order by adding the item price with the
delivery fees.
Order
Order price
4.3
Assign Order
This is the process that assign the order to free
driver.
Order Detail
Order
4.4
Update order status
This is the process that allow restaurant to
update the order while the order is ready to be
picked and allow driver to update the delivery
status of the order
Order Status
Order Detail
4.5
Modify Order
This is the process that allow users to modify
their order.
Old Order Detail
New Order Information
23
UC2F1301SE
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Number
Name
Description
Input Data
Flow
Output Data
Flow
Group Assignment
5.0
Menu Item Management
This is the process that allow restaurant to
manage the menu item that they are selling
Item Details
Item Information
6.0
Staff Management
This is the process that allow the system
administrator to add, update and delete staff of
the system
Staff Details
Staff Information
7.0
Report Generation
This is the process that allow Tom and Sue
view the report
Order Information
Report
24
UC2F1301SE
Group Assignment
UC2F1301SE
3.3 REQUIREMENTS SPECIFICATION

To facilitate the process of creating a requirements documentation, a template has been
created which will serve to guide the creation of software requirements specification
documents as a deliverable in the subsequent phase of the software development life cycle.
Introduction
o Purpose
o Scope
General Description
o Product Perspective
o Product Functions
o User Classes and Characteristics
o Assumptions and Dependencies
Specific Requirements
o Functional Requirements
o Non-Functional Requirements
Performance
Security
Analysis Models
o Class Diagram
o Use Case Diagram
o Data Flow Diagrams (DFD)
Change Management Process
o Process flow
25
Group Assignment
UC2F1301SE
3.3.1 Description of template items

3.3.1.1
Introduction Purpose
What is the purpose of this SRS and the (intended) audience for which it is written?
3.3.1.2
Introduction Scope
This subsection should:

(1)
Identify the software product(s) to be produced by name; for example, Host DBMS,
Report Generator, etc.

(2)
Explain what the software product(s) will, and, if necessary, will not do
(3)
Describe the application of the software being specified. As a portion of this, it
should:
(a) Describe all relevant benefits, objectives, and goals as precisely as possible. For example,
to say that one goal is to provide effective reporting capabilities is not as good as saying
parameter-driven, user-definable reports with a 2 h turnaround and on-line entry of user
parameters.
(b) Be consistent with similar statements in higher-level specifications (for example, the
System Requirement Specification), if they exist. What is the scope of this software product?
3.3.1.3
General Description Product Perspective
This subsection of the SRS puts the product into perspective with other related products or
Projects.
3.3.1.4
General Description User Classes and Characteristics
This subsection of the SRS should describe those general characteristics of the eventual users
of the product that will affect the specific requirements. (See the IEEE Guide to SRS for
more details).
3.3.1.5
General Description Assumptions and Dependencies
This subsection of the SRS should list each of the factors that affect the requirements stated
in the SRS. These factors are not design constraints on the software but are, rather, any
changes to them that can affect the requirements in the SRS. For example, an assumption
might be that a specific operating system will be available on the hardware designated for the
26
Group Assignment
UC2F1301SE
software product. If, in fact, the operating system is not available, the SRS would then have
to change accordingly.
3.3.1.6
Specific Requirements Functional Requirements
This section describes specific features of the software project. If desired, some requirements
may be specified in the use-case format and listed in the Use Cases Section.
3.3.1.7
Specific Requirements Non-Functional Requirements
Performance
Non-functional requirements may exist for the following attributes. Often these requirements
must be achieved at a system-wide level rather than at a unit level. State the requirements in
the following sections in measurable terms (e.g., 95% of transaction shall be processed in less
than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value,
etc).
3.3.1.8
Specific Requirements Non-Functional Requirements
Security
Non-functional requirements may exist for the following attributes. Often these requirements
must be achieved at a system-wide level rather than at a unit level. State the requirements in
the following sections in measurable terms (e.g., 95% of transaction shall be processed in less
than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value,
etc).
3.3.1.9
Analysis Models Class Diagram
This section should be used to analyse the requirements based on a class diagram. The
diagram should include every user class that has been specified and have attributes that will
be associated with each class.
3.3.1.10
Analysis Models Use Case Diagram
This section should be used to analyse the requirements based on a use case diagram. The
diagram should include all users that have been specified, the high-level system features that
are specified, as well as the connections showing the relationship of the users to these
features.
27
3.3.1.11
Group Assignment
UC2F1301SE
Analysis Models Data-Flow-Diagrams (DFD)
This section should be used to analyse the requirements based on data flow diagrams. The
diagrams can be as elaborate as possible within each increasingly detailed level of the system
as long as the purpose of showing the flow of data in each feature is properly described.
3.3.1.12
Change Management Process
This section should be used to establish a proper procedure to track the submission,
coordination, review, evaluation, categorization and approval for release of all changes done.
28
Group Assignment
UC2F1301SE
3.4 VALIDATION & VERIFICATION

3.4.1 Validation Techniques
3.4.1.1
Requirements Review
As described by (Saqi, 2008), requirements review represents a techniques where a group of

people comes together to validate requirements. The formal process includes readers from
both client and developer sides and helps them to resolve problems at the early stages of
SDLC. Shown below are the steps that will be undertaken during the review of the
requirements that have been specified.
Plan
Review
Distribute
Document
s
Prepare
for Review
Hold
Review
Meeting
Follow-Up
Actions
Revise
Document
For the actual review itself, there will be five focus groups to go through in order to review
the requirements that have been specified. These groups are; The owners Sue and Tom,
experienced drivers who have worked with the company for a period of at least 1 year,
experienced telephone operators who have also worked for the same period of time,
customers who frequently order from the company and lastly the staff from restaurants who
handle the orders sent by the company to them. The relevant requirements will be presented
to them and reviewed for verifiability, comprehensibility, traceability and adaptability.
29
Group Assignment
UC2F1301SE
3.4.2 Requirements Inspection and Checklist

3.4.2.1
Inspection
According to (T.Y. Chen, 2006), formal inspection was made an integral part of the
development process thanks to Michael E Fagan of IBM. Based on his designs, inspections
are conducted as team activities, which aims to have one or more reviewers formally inspect
the items, which is typically done in a meeting after individual preparations. Normally,
members of the inspection team will include the producer of the item to be inspected as well
as a moderator to facilitate the inspection process.
For this project, the authors of this documentation which is Alexander and Enson, along with
the owners and a selected group of staff will be gathered together to inspect the requirements
based on several methods.
3.4.2.2
Entry criteria
Before the inspection can begin, the requirements must satisfy the following prerequisites:
The document conforms to the standard template.

The document has been spell-checked.
The author has visually examined the document for any layout errors.
Any predecessor or reference documents that the inspectors will require to examine
the document are available.

Line numbers are printed on the document to facilitate referring to specific locations
during the inspection meeting.

All open issues are marked as TBD (to be determined).
The moderator didn't find more than three major defects in a ten-minute examination
of a representative sample of the document.
30
3.4.2.3
Group Assignment
UC2F1301SE
Inspection Stages
An inspection is a multistep process, as illustrated below. The purpose of each inspection

process stage is summarized briefly in the rest of this section.
3.4.2.4
Planning
The authors of this document will plan the inspection together. The participants deemed to be
suitable for the inspections have been narrowed down to the owners and experienced staff
who are familiar with the companys operations. A total of 5 inspection meetings will be held
to cover the amount of material which consists of 26 requirements. Two hours is determined
as the most suitable amount of time to assess the requirements for defects.
3.4.2.5
Overview meeting
During the meeting, the background of the material will be explained to the inspecting team
along with any assumptions that has been made and stated in the project documentation.
During later meetings, this stage will be omitted as the team will have already been familiar
with them.
31
3.4.2.6
Group Assignment
UC2F1301SE
Preparation
Prior to the meeting, each inspector will examine the requirements and highlight any issues or
defects by using a checklist which is described below.
Do requirements exhibit a clear distinction between functions and data?

Do requirements define all the information to be displayed to users?
Do requirements address system and user response to error conditions?
Is each requirement stated clearly, concisely and unambiguously?
Is each requirement testable?
Are there ambiguous or implied requirements?
Are there conflicting requirements?
Are there areas not addressed in the SRS that need to be?
Are performance requirements (Such as response time, data storage requirements)
stated?
If the requirements involve complex decision chains, are they expressed in a form that
facilitates comprehension (i.e. decision tables, decision trees, etc.)?

Have requirements for performing software upgrades been specified?
Are there requirements that contain an unnecessary level of design detail?
Have the real-time constraints been specified in sufficient detail?
Has the precision and accuracy of calculations been specified?
Is it possible to develop a thorough set of tests based on the information contained in
the SRS? If not, what information is missing?

Have Assumptions and Dependencies been clearly stated?
Does the document contain all the information called out in the outline for the SRS?
3.4.2.7
Inspection meeting
In this stage, a reader will be appointed to read to other inspectors in the team to describe the
requirements in their own words. As defects and issues are brought up, they are noted down
by an inspector who will be assigned the role of a recorder. At the end of this stage, the team
will decide whether to accept the requirements as a whole, or indicate that minor or major
changes will be needed to the requirements themselves.
3.4.2.8
Follow-up
In this final stage, the moderator will work with the authors to try and ensure all open issues
are resolves and errors have been corrected properly to bring closure to the inspection
process.
32
3.4.2.9
Group Assignment
UC2F1301SE
Exit Criteria
After all the stages of the inspection have been completed, the moderator then determines
whether the inspection is formally complete based on the following criteria:
All issues raised during the inspection have been addressed.

Any changes made in the document and related work products were made correctly.
The revised document has been spell-checked.
All TBDs have been resolved, or each TBD's resolution process, target date, and
owner has been documented.

The document has been checked into the project's configuration management system.
33
Group Assignment
UC2F1301SE
4 REQUIREMENTS MANAGEMENT
1.2 REQUIREMENTS MANAGEMENT PLANNING
1.2.1 Requirement Identification
Requirement
Requirement Name
Requirement Type
Reference
RE-1
Database for storage of all data used
RE-2
RE-3
RE-4
RE-5
RE-6
RE-7
RE-8
RE-9
RE-10
RE-11
RE-12
RE-13
RE-14
RE-15
RE-16
RE-17
RE-18
RE-19
RE-20
RE-21
RE-22
and created by system

Login Access
Staff Account
Change Staff Details
Customer Account
Operators Create Customer Account
Change Customer Details
Customers Place order
Operators Search Customer Account
Operators Place order
Restaurant quantity restriction
Change Order Details
Logging of changes to order details
Notifying Restaurant of Order
Restaurant Update Order Status
Track Deliveries
Track Driver Availability
Driver Update Order Status
Restaurant menu tracking
Change menu details
Calculate distance of delivery
Calculate delivery cost based on
Compatibility Requirement
Mutable Requirement
Mutable Requirement
delivery distance
RE-23
RE-24
RE-25
RE-26
Consequential Requirement
Calculate fuel cost

Mutable Requirement
Calculation of order totals
Report Generation
Calculation of weekly amount due to
Mutable Requirement
restaurants
34
Group Assignment
UC2F1301SE
1.2.2 Change Management Process

The Change Management process establishes an orderly and effective procedure for tracking
the submission, coordination, review, evaluation, categorization, and approval for release of
all changes to the projects baselines.
Generate CR
Evaluate CR
Authorize CR
Implement CR
Log Updated Status

Report Status
Step
Generate CR
Log CR Status
Evaluate CR
Authorize
Implement
Description
A submitter completes a CR Form and sends the completed form to
the Change Manager
The Change Manager enters the CR into the CR Log. The CRs
status is updated throughout the CR process as needed.
Project personnel review the CR and provide an estimated level of
effort to process, and develop a proposed solution for the suggested
change
Approval to move forward with incorporating the suggested change
into the project/product
If approved, make the necessary adjustments to carry out the
requested change and communicate CR status to the submitter and
other stakeholders
35
Group Assignment
UC2F1301SE
1.3 TRACEABILITY
Legend:
<C>
Customer
<D>
Driver
<O>
Owner
<R>
Restaurant
<S>
All the Staff: Driver, Owner, and Telephone Operator
<T>
Telephone Operator
Requirement
Requirement Name
Requirement Source
Reference
RE-1
Database for storage of all data used
RE-2
RE-3
RE-4
RE-5
RE-6
RE-7
RE-8
RE-9
RE-10
RE-11
RE-12
RE-13
RE-14
RE-15
RE-16
RE-17
RE-18
RE-19
RE-20
RE-21
RE-22
and created by system

Login Access
Staff Account
Change Staff Details
Customer Account
Operators Create Customer Account
Change Customer Details
Customers Place order
Operators Search Customer Account
Operators Place order
Restaurant quantity restriction
Change Order Details
Logging of changes to order details
Notifying Restaurant of Order
Restaurant Update Order Status
Track Deliveries
Track Driver Availability
Driver Update Order Status
Restaurant menu tracking
Change menu details
Calculate distance of delivery
Calculate delivery cost based on
T, C
S
O
C
O, C
C
T
T
T
T
C, T
O
R, T
R, T
C, T
T
D
T
R
O
O
delivery distance
RE-23
RE-24
RE-25
Calculate fuel cost

Calculation of order totals
Report Generation
O
O
O
36
RE-26
Group Assignment
UC2F1301SE
Calculation of weekly amount due to

O, R
restaurants
1.4 REQUIREMENT MANAGEMENT TOOL SUPPORT

There are a number of CASE tools that are available in the market to be used during the
Requirement Management:
Tool Name
Accept 360o, version 4.0
Company Name
Accept Software, Inc.
Accompa
ARCWAY Cockpit
Accompa, Inc.
ARCWAY AG
37
Contact Detail URL

http://www.acceptsoftware.c
om
http://www.accompa.com/
http://www.arcway.com
Group Assignment
UC2F1301SE
5 WEEKLY REPORTS
5.1 PROJECT PROGRESS REPORT 1
Prepared by: Lau Chun Khye on 24 July 2013
Completed Since Last Report
Task
Description
Date Completed
Understanding
project Team members are given 2 23 July2013
background
days
to
understand
the
project background.
In Progress
Task
Problem analysis
Description
Est. Completion Date
Once the project background is 4 August 2013
understood by everyone, the
nature of the problems will be
analyze based on the case.
Outstanding For The Period Ending

Task
Description
Est. Start Date
Propose solution
Solutions will be discuss 5 August 2013
among the team members
based on the problem found
Define scope, aims, and The scope, aims and the 5 August 2013
objectives
objectives of the proposed

solution will be identified.
Issues/Comments
38
Group Assignment
UC2F1301SE

Prepared by: Lau Chun Khye on 12 August 2013
Task
Description
Introduction
Project
Date Completed
background, 11 August 2013
problem analysis, propose

solution, scope, aims, and
objectives
have
been
completed
In Progress
Task
Requirement Elicitation
Description
A set of activities are carry 8 September 2013
out for elicit the requirement

Task
Description
Est. Start Date
Requirement Analysis
The requirements that elicit 9 September 2013
from the previous activities
is then further refined using
various of analysis model
Issues/Comments
39
Group Assignment
UC2F1301SE

Prepared by: Lau Chun Khye on 23 September 2013
Task
Description
Date Completed
Requirement
A set requirements is elicit from 8 September 2013
Elicitation
various techniques:
Questionnaire (Customers)
Interview (Owners, drivers,
telephone operator)
Observation (The flow of
operations of the restaurant
Requirement Analysis
and telephone operators)

The requirements are then refined 22 September 2013
using:
In Progress
Task
Requirement Specification
UML Use Case Diagram
Description
The outcomes of previous 1 October 2013
stages
(elicitation
and
analysis) is documented in
SRS.

Task
Description
Requirement Validation & Some
validation
Verification
Est. Start Date

and 2 October 2013
verification techniques will be

used
Issues/Comments
40
Group Assignment
UC2F1301SE

Prepared by: Lau Chun Khye on 28 October 2013
Task
Description
Date Completed
Requirement Specification
The outcomes of previous 1 October2013
stages
(elicitation
and
analysis) is documented in
SRS.
Requirement Validation & Some
validation
and 13 October 2013
Verification
verification techniques will
Requirement Management
be used
The change-control process 27 October 2013
and requirement traceability
is defined
In Progress
Task
Finalize Documentation
Description
All the work done by every 30 September 2013
members is collected and
compile
to
finalize
the
documentation

Task
Description
Est. Start Date
Issues/Comments
41
Group Assignment
UC2F1301SE
6 REFERENCES
Famuyide, S., 2013. Problem Solving: Unveiling the Multiple Faces of the PIECES
Framework.
[Online]
Available at: http://businessanalystlearnings.com/blog/2013/6/23/problem-solving-unveilingthe-multiple-faces-of-the-pieces-framework

[Accessed 5 October 2013].
Saqi, S. B., 2008. Requirements Validation Techniques practiced in industry: Studies of six
companies.
[Online]
Available
at:
http://www.bth.se/fou/cuppsats.nsf/all/03a48c3772d5b49ac12574ff002e6fd4/$file/Requireme
nts%20Validation%20Techniques%20(RVTs)%20Practiced%20in%20Industry%20%20Studies%20of%20Six%20Companies.pdf
T.Y. Chen, P.-L. P. S.-F. T., 2006. Applying Testing to Requirements Inspection for Software
Quality
Available
Assurance.
at:
[Online]
http://www.isaca.org/Journal/Past-Issues/2006/Volume-6/Pages/Applying-
Testing-to-Requirements-Inspection-for-Software-Quality-Assurance1.aspx
42
Group Assignment
7 APPENDIX : SRS DOCUMENTATION
43
UC2F1301SE

RENG Assignment Template

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RENG Assignment Template

Uploaded by

Copyright:

Available Formats

Module Code

CT056-3.5-2 Requirements Engineering

Current flow of operations...........................................................................................5

Control and Security Problems............................................................................8

Project Aims and Objectives.....................................................................................12

Requirements Development Processes............................................................................15

Use Case Diagram..............................................................................................18

Data Flow Diagram............................................................................................23

Description of template items............................................................................28

Validation & Verification...........................................................................................30

Requirements Inspection and Checklist.............................................................31

Requirements Management Planning........................................................................35

Change Management Process............................................................................36

Requirement Management Tool Support...................................................................38

Project Progress Report 1..........................................................................................39

Project Progress Report 2..........................................................................................40

Project Progress Report 3..........................................................................................41

Project Progress Report 4..........................................................................................42

Appendix : SRS Documentation......................................................................................44

1.2 PROJECT ASSUMPTIONS

1.3.2 Information Problems

1.3.3 Economics Problems

1.3.4 Control and Security Problems

No control over manipulation of records

Too little control Input data is not

is inconsistent in different files

1.3.5 Efficiency Problems

1.3.6 Service Problems

1.4 PROBLEM SOLUTIONS

No knowledge of drivers availability unless System to track deliveries and driver

store their details

reduces chance of inputting wrong data

determine distance between restaurant and

Fuel costs for drivers cannot be traced

against fuel consumption of drivers.

across the system

are reflected equally across the entire

and report generation

upgraded if necessary to handle extra

1.5 PROJECT SCOPE

1.6 PROJECT AIMS AND OBJECTIVES

Identify and propose solutions using the PIECES framework

proposed are valid solutions.

Lau Chun Khye

Requirements Development Processes

Appendix: SRS documentation

3 REQUIREMENTS DEVELOPMENT PROCESSES

3.1.5 Telephone Operators

1.1.2 Use Case Diagram

Use Case Specification

Restaurant, Driver, Owner

User Login (refer UC02)

Restaurant, Driver, Owner

Restaurant, Driver, Owner

PIM.NC.02: All the details of the user id shown

Alternative Courses: PIM.AC.01: Forget Password is clicked before the user

Add New Customer (refer to UC05)

AC.NC.02: All field is filled with no errors

and when customer want to update their

SC.NC.02: Submit button is clicked.

3.2.1 Data Flow Diagram

3.3 REQUIREMENTS SPECIFICATION

3.3.1 Description of template items