RENG assignment template

Lecturer Name : SIVANATHAN CHELLIAH Hand in Date : 10th _{November,2014}

Tutorial No. :

Group No. :

T

ABLE

OF

C

ONTENTS

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

3 Schedule Planning...13

3.1 Gantt Chart...13

3.2 Workload Matrix...14

4 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.1 Class Diagram...18

4.2.2 Use Case Diagram...18

4.2.3 Data Flow Diagram...23

4.3 Requirements Specification...27

4.3.1 Description of template items...28

4.4 Validation & Verification...30

4.4.1 Validation Techniques...30

4.4.2 Requirements Inspection and Checklist...31

5 Requirements Management...35

5.1 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

6 Weekly Reports...39

6.1 Project Progress Report 1...39

6.2 Project Progress Report 2...40

6.3 Project Progress Report 3...41

6.4 Project Progress Report 4...42

7 References...43

1 I

NTRODUCTION

1.1 P

B

1.2 P

A

1.3 P

A

1.3.1 Performance Problems

Problem

Consequences

1.3.2 Information Problems

Problem

Consequences

1.3.3 Economics Problems

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 show incorrect totals.

Too little security – Crimes can be committed against data

No control over who has access to what kind of information

Too little security – Ethics are breached on data or information

Changes to records may not be reflected across the system

Too little control – Redundantly stored data is inconsistent in different files

Chance of human error in creating records Too little control – Processing errors are occurring

1.3.5 Efficiency Problems

Problem

Consequences

Details of return customers are recorded in every new transaction

Waste of Time – Data is redundantly input

Every record is written on paper Materials required for tasks is excessive Changes to existing orders means discarding

existing order and writing a new one

Waste of materials and supplies

Calculation of totals, creation of reports are all done manually.

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

call in or are called

The system produces unreliable results

High learning curve for new employees due to complicated operations.

The system is not easy to learn

Manual work based system consumes time and effort

The system not easy to use

Sudden changes such as employee absence can disrupt operation efficiency

The system is inflexible to new or exceptional situations

Additional customers or new restaurants means extra workload on employees

The system is inflexible to change

Changes in food selection, prices and availability in restaurants is not known to company.

The system is not coordinated with other systems.

1.4 P

S

Problem

Proposed Solution

No knowledge of driver’s availability unless they call in or are called

System to track deliveries and driver availability

Manually written records Computers to enter records Telephone operators can only handle limited

number of customers at any one time.

Website to take orders with telephone operators as backup

Individual records and receipts are all separate

Database to store records and receipts

Records are stored by telephone operators while receipts are stored by drivers

Database to store records and receipts

Record and receipts are on paper. Computers to produce digital records Record details are obtained from customer

through voice calls

Customer enters their own details through website

Details of return customers are recorded in every new transaction

Account on database for each customer to store their details

Chance of human error in writing orders Database with on demand information reduces chance of inputting wrong data Unknown knowledge of restaurant food

selections or prices

Client system for restaurants to keep track of their menu

Restaurant food selection availability is unknown

Client system for restaurants to keep track of their menu

Creating reports to monitor performance is very difficult

Reporting function in website to automatically generate reports

Cost of delivery from restaurant to customer address is unknown

Integration with mapping system to determine distance between restaurant and customer residence for calculation of delivery costs

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

Additional telephone operators required on hand to handle increasing customer base.

Website able to handle increasing customers at the same time

No control over manipulation of records Changes to records are logged Possible to modify amount on records to

show incorrect totals.

System automatically calculates amount and restricts changes to menu prices.

No control over who has access to what kind of information

Login system to restrict access to data to relevant employees

across the system are reflected equally across the entire system

Changes to existing orders means discarding existing order and writing a new one

Digital records which can be modified if necessary

Calculation of totals, creation of reports are all done manually.

System functions to take care of calculation and report generation

Chance of human error in producing reports Automate generation of reports renders problem obsolete

High learning curve for new employees due to complicated operations.

User manual and training for system to lower learning curve

Manual work based system consumes time and effort

Automated system reduces employee effort and increases throughput

Sudden changes such as employee absence can disrupt operation efficiency

Backup systems to ensure consistent system availability and performance

Additional customers or new restaurants means extra workload on employees

Processing capability of system can be upgraded if necessary to handle extra workload

Changes in food selection, prices and availability in restaurants is not known to company.

Synchronized restaurant client database and main database ensures changes are known to the company

1.5 P

S

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 P

A

O

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.

2 S

CHEDULE

P

LANNING

2.1 G

C

2.2

M

Task Alexander Ho

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%

3 R

EQUIREMENTS

D

EVELOPMENT

P

ROCESSES

3.1 E

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.

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.

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.

3.2 A

1.1.1 Class Diagram

1.1.2.1 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, Restaurant, Driver, Owner

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 Events:

LG.NC.01: User entered correct username and password in the corresponding field.

LG.NC.02: Submit button is clicked Alternative Courses:

-Case ID UC03

Name Personal Information Management (PIM)

Actor: Telephone Operator, Customer, System Administrator, Restaurant, Driver, Owner

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

Events:

PIM.NC.01: “About Me” button is clicked

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.

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 Actor: Telephone Operator

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

Events:

AC.NC.01: “Customer Registration” is clicked

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

AC.NC.03: “Submit” button is clicked. Alternative Courses:

-Case ID UC06

Name Search Customer Details Actor: Telephone Operator

Description: Searching of customer details Preconditions: Actor must login to the system

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 Events:

SC.NC.01: Valid customer ID is entered

SC.NC.02: “Submit” button is clicked. Alternative Courses:

-Case ID UC07

Name Update Customer Details Actor: Telephone Operator

Description: Updating of customer details Preconditions: Actor must login to the system

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

Events:

UC.NC.01: All field is filled with no errors UC.NC.02: “Submit” button is clicked. Alternative Courses:

-3.2.1 Data Flow Diagram

1.1.2.2 Level 0

1.1.2.4 Data Dictionary

Number 1.0

Name User Access & Management

Description This is the process that allow users to login and_{update their information.} Input Data

Flow User Details Output Data

Flow User Information

Number 2.0

Name Account Registration

Description This is the process that allow customer to register themselves at the website.

Input Data

Flow Customer Details Output Data

Flow Customer Information

Number 3.0

Name View Menu

Description This is the process that allow customer to view_{the existing menu item on the website} Input Data

Flow Item Details Output Data

Flow Menu Item Information

Number 4.1

Name Make New Order

Description This is the process that allow customer and _{telephone operator to make new order.} Input Data

Flow Order Details Output Data

Number 4.2

Name Calculate Price Description

This is the process that calculate the total price of the order by adding the item price with the delivery fees.

Input Data

Flow Order

Output Data

Flow Order price

Number 4.3

Name Assign Order

Description This is the process that assign the order to free _driver. Input Data

Flow Order Detail Output Data

Flow Order

Number 4.4

Name Update order status Description

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

Input Data

Flow Order Status Output Data

Flow Order Detail

Number 4.5

Name Modify Order

Description This is the process that allow users to modify _{their order.} Input Data

Flow Old Order Detail Output Data

Number 5.0

Name Menu Item Management

Description This is the process that allow restaurant to _{manage the menu item that they are selling} Input Data

Flow Item Details Output Data

Flow Item Information

Number 6.0

Name Staff Management Description

This is the process that allow the system administrator to add, update and delete staff of the system

Input Data

Flow Staff Details Output Data

Flow Staff Information

Number 7.0

Name Report Generation

Description This is the process that allow Tom and Sue _{view the report} Input Data

Flow Order Information Output Data

3.3 R

S

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

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

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.

3.3.1.11 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,

Plan Review Distribute Document s Prepare for Review Hold Review Meeting Follow-Up

Actions DocumentRevise

3.4 V

& V

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.

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.

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.

3.4.2.3 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 company’s 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.

3.4.2.6 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.

3.4.2.9 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.

4 R

EQUIREMENTS

M

ANAGEMENT

1.2 R

M

P

1.2.1 Requirement Identification

Reference

Requirement Name Requirement Type

RE-1 Database for storage of all data used

and created by system Consequential Requirement RE-2 Login Access Compatibility Requirement RE-3 Staff Account Compatibility Requirement RE-4 Change Staff Details Compatibility Requirement RE-5 Customer Account Compatibility Requirement RE-6 Operators Create Customer Account Compatibility Requirement RE-7 Change Customer Details Compatibility Requirement RE-8 Customers Place order Compatibility Requirement RE-9 Operators Search Customer Account Compatibility Requirement RE-10 Operators Place order Compatibility Requirement RE-11 Restaurant quantity restriction Compatibility Requirement RE-12 Change Order Details Compatibility Requirement RE-13 Logging of changes to order details Compatibility Requirement RE-14 Notifying Restaurant of Order Compatibility Requirement RE-15 Restaurant Update Order Status Compatibility Requirement RE-16 Track Deliveries Compatibility Requirement RE-17 Track Driver Availability Compatibility Requirement RE-18 Driver Update Order Status Compatibility Requirement RE-19 Restaurant menu tracking Compatibility Requirement RE-20 Change menu details Compatibility Requirement RE-21 Calculate distance of delivery Mutable Requirement RE-22 Calculate delivery cost based on

delivery distance Mutable Requirement RE-23 Calculate fuel cost Mutable Requirement RE-24 Calculation of order totals Compatibility Requirement RE-25 Report Generation Compatibility Requirement RE-26 Calculation of weekly amount due to

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 project’s baselines.

Generate CR

Report Status Log Updated Status

Implement CR Authorize CR

Evaluate CR

Step Description

Generate CR A submitter completes a CR Form and sends the completed form to the Change Manager

Log CR Status The Change Manager enters the CR into the CR Log. The CR’s status is updated throughout the CR process as needed.

Evaluate CR Project personnel review the CR and provide an estimated level of effort to process, and develop a proposed solution for the suggested change

Authorize Approval to move forward with incorporating the suggested change into the project/product

Implement If approved, make the necessary adjustments to carry out the requested change and communicate CR status to the submitter and other stakeholders

1.3 T

<S> All the Staff: Driver, Owner, and Telephone Operator

<T> Telephone Operator

Requirement Reference

Requirement Name Requirement Source

RE-1 Database for storage of all data used and created by system O

RE-2 Login Access T, C

RE-3 Staff Account S

RE-4 Change Staff Details O

RE-5 Customer Account C

RE-6 Operators Create Customer Account O, C RE-7 Change Customer Details C

RE-8 Customers Place order T

RE-9 Operators Search Customer Account T

RE-10 Operators Place order T

RE-11 Restaurant quantity restriction T RE-12 Change Order Details C, T RE-13 Logging of changes to order details O RE-14 Notifying Restaurant of Order R, T RE-15 Restaurant Update Order Status R, T

RE-16 Track Deliveries C, T

RE-17 Track Driver Availability T RE-18 Driver Update Order Status D RE-19 Restaurant menu tracking T

RE-20 Change menu details R

RE-21 Calculate distance of delivery O RE-22 Calculate delivery cost based on

delivery distance O

RE-23 Calculate fuel cost O

RE-26 Calculation of weekly amount due to

restaurants O, R

1.4 R

M

T

S

There are a number of CASE tools that are available in the market to be used during the Requirement Management:

Tool Name Company Name Contact Detail URL

Accept 360o_{, version 4.0 Accept Software, Inc. http://www.acceptsoftware.c} om

Accompa Accompa, Inc. http://www.accompa.com/ ARCWAY Cockpit ARCWAY AG http://www.arcway.com

5 W

EEKLY

R

EPORTS

5.1 P

P

R

1

Prepared by: Lau Chun Khye on 24 July 2013

Completed Since Last Report

Task Description Date Completed

Understanding project background

Team members are given 2 days to understand the project background.

23 July2013

In Progress

Task Description Est. Completion Date

Problem analysis Once the project background is understood by everyone, the nature of the problems will be analyze based on the case.

4 August 2013

Outstanding For The Period Ending

Task Description Est. Start Date

Propose solution Solutions will be discuss among the team members based on the problem found

5 August 2013

Define scope, aims, and objectives

The scope, aims and the objectives of the proposed solution will be identified.

5 August 2013

5.2 P

P

R

2

Prepared by: Lau Chun Khye on 12 August 2013

Completed Since Last Report

Task Description Date Completed

Introduction Project background, problem analysis, propose solution, scope, aims, and objectives have been completed

11 August 2013

In Progress

Task Description Est. Completion Date

Requirement Elicitation A set of activities are carry out for elicit the requirement

8 September 2013

Outstanding For The Period Ending

Task Description Est. Start Date

Requirement Analysis The requirements that elicit from the previous activities is then further refined using various of analysis model

9 September 2013

5.3 P

P

R

3

Prepared by: Lau Chun Khye on 23 September 2013

Completed Since Last Report

Task Description Date Completed

Requirement Elicitation

A set requirements is elicit from various techniques:

 Questionnaire (Customers)  Interview (Owners, drivers,

telephone operator)

 Observation (The flow of operations of the restaurant and telephone operators)

8 September 2013

Requirement Analysis The requirements are then refined using:

 UML Use Case Diagram

22 September 2013

In Progress

Task Description Est. Completion Date

Requirement Specification The outcomes of previous stages (elicitation and analysis) is documented in SRS.

1 October 2013

Outstanding For The Period Ending

Task Description Est. Start Date

Requirement Validation & Verification

Some validation and verification techniques will be used

2 October 2013

5.4 P

P

R

4

Prepared by: Lau Chun Khye on 28 October 2013

Completed Since Last Report

Task Description Date Completed

Requirement Specification The outcomes of previous stages (elicitation and analysis) is documented in SRS.

1 October2013

Requirement Validation & Verification

Some validation and verification techniques will be used

13 October 2013

Requirement Management The change-control process and requirement traceability is defined

27 October 2013

In Progress

Task Description Est. Completion Date

Finalize Documentation All the work done by every members is collected and compile to finalize the documentation

30 September 2013

Outstanding For The Period Ending

Task Description Est. Start Date

6 R

EFERENCES

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-unveiling-the-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 [Accessed 1 October 2013].

T.Y. Chen, P.-L. P. S.-F. T., 2006. Applying Testing to Requirements Inspection for Software

Quality Assurance. [Online]

Available at: http://www.isaca.org/Journal/Past-Issues/2006/Volume-6/Pages/Applying-Testing-to-Requirements-Inspection-for-Software-Quality-Assurance1.aspx