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

1

Requirements Engineering

Group Assignment

UC2F1301SE

TABLE OF CONTENTS 2

3

4

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

Requirements Engineering

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

6

UC2F1301SE

4.2.1

4.3

5

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

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

6.3

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

6.4

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

7

References........................................................................................................................43

8

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

3

Requirements Engineering

Group Assignment

1 INTRODUCTION 1.1 PROJECT BACKGROUND

1.2 PROJECT ASSUMPTIONS 1.3 PROBLEM ANALYSIS 1.3.1 Performance Problems Problem

Consequences

4

UC2F1301SE

Requirements Engineering

Group Assignment

1.3.2 Information Problems Problem

Consequences

1.3.3 Economics Problems Problem

Consequences

5

UC2F1301SE

Requirements Engineering

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.

6

Requirements Engineering

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.

7

Requirements Engineering

Group Assignment

UC2F1301SE

1.4 PROBLEM SOLUTIONS Problem

Proposed Solution

No knowledge of driver’s 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

Requirements Engineering

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

9

Requirements Engineering

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

Requirements Engineering

Group Assignment

UC2F1301SE

2 SCHEDULE PLANNING 2.1 GANTT CHART 2.2

MATRIX

Task

Alexander Ho YingHan

11

Lau Chun Khye

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering

Group Assignment

3.2 ANALYSIS 1.1.1 Class Diagram

1.1.2 Use Case Diagram

16

UC2F1301SE

Requirements Engineering

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,

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 LG.NC.01: User entered correct username and password in Events: the corresponding field. LG.NC.02: Submit button is clicked Alternative Courses: -

17

Requirements Engineering

Group Assignment

UC2F1301SE

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

Requirements Engineering

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

Alternative Courses: -

19

UC2F1301SE

Requirements Engineering

Group Assignment

UC2F1301SE

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 SC.NC.01: Valid customer ID is entered Events:

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 UC.NC.01: All field is filled with no errors Events: UC.NC.02: “Submit” button is clicked. Alternative Courses: -

20

Requirements Engineering

Group Assignment

3.2.1 Data Flow Diagram 1.1.2.2

Level 0

1.1.2.3

Level 1

21

UC2F1301SE

Requirements Engineering 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

Requirements Engineering 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

Requirements Engineering 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

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering 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

Requirements Engineering

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

Requirements Engineering

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

Requirements Engineering

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

31

Requirements Engineering

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

Requirements Engineering 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

Requirements Engineering

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 Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement Compatibility Requirement 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 Compatibility Requirement Report Generation Compatibility Requirement Calculation of weekly amount due to Mutable Requirement restaurants

34

Requirements Engineering

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 project’s 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 CR’s 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

Requirements Engineering

Group Assignment

UC2F1301SE

1.3 TRACEABILITY Legend:

Customer



Driver



Owner



Restaurant



All the Staff: Driver, Owner, and Telephone Operator



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

O

Calculate fuel cost Calculation of order totals Report Generation

O O O 36

Requirements Engineering 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

Requirements Engineering

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

Requirements Engineering

Group Assignment

UC2F1301SE

5.2 PROJECT PROGRESS REPORT 2 Prepared by: Lau Chun Khye on 12 August 2013 Completed Since Last Report 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 Est. Completion Date A set of activities are carry 8 September 2013 out for elicit the requirement

Outstanding For The Period Ending 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

Requirements Engineering

Group Assignment

UC2F1301SE

5.3 PROJECT PROGRESS REPORT 3 Prepared by: Lau Chun Khye on 23 September 2013 Completed Since Last Report 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 Est. Completion Date The outcomes of previous 1 October 2013 stages

(elicitation

and

analysis) is documented in SRS.

Outstanding For The Period Ending Task Description Requirement Validation & Some validation Verification

Est. Start Date and 2 October 2013

verification techniques will be used

Issues/Comments

40

Requirements Engineering

Group Assignment

UC2F1301SE

5.4 PROJECT PROGRESS REPORT 4 Prepared by: Lau Chun Khye on 28 October 2013 Completed Since Last Report 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 Est. Completion Date All the work done by every 30 September 2013 members is collected and compile

to

finalize

the

documentation

Outstanding For The Period Ending Task Description

Est. Start Date

Issues/Comments

41

Requirements Engineering

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

42

Requirements Engineering

Group Assignment

7 APPENDIX : SRS DOCUMENTATION

43

UC2F1301SE