UNIVERSITY OF GREENWICH

MASTER OF SCIENCE IN BUSINESS ADMINISTRATION

COURSE CODE: XXXXXX

TITLE OF ASSIGNMENT

Systems Requirement Specification: A case of Home Made Foods

Author's initials and surname

A. KHAN

Students Registration Number

XXXXXXXX

Month and year of submission

MAY 2009

Page 1

Table of Contents

Introduction..............................................................................................31. Requirement Specification...................................................................3

1.1 Purpose and Scope of these Specifications.....................................31.2. System Scope................................................................................31.3 Operating Environment...................................................................4

1.3.1 Infrastructure............................................................................41.4 Functional Requirement & System Response.................................6

1.4.1 Main Concerns..........................................................................61.4.2 System Solution........................................................................61.4.3 Benefits.....................................................................................6

2. System Specification............................................................................72.1 Data Models....................................................................................72.2 Data Dictionary...............................................................................92.3 Process Models: DFD Diagram......................................................112.4 Behavioural Models: Behavioural Model for the Booking Object...12

2.4.1 Implications on the Data Structure.........................................132.5 Decomposition..............................................................................142.6 User Interface...............................................................................18

2.6.2 The Database Menu Structure................................................213. Key Contributions...............................................................................22

3.1 Reliability of the Proposed Software Systems...............................223.2 Maintainability...............................................................................23

3.2.2 Metric process.........................................................................243.2.3 Metrics project........................................................................24

4. Bibliography & Reference...................................................................24

Page 2

Assignment Overview

Introduction

Home Made Foods Catering Company is currently in the process of expansion and has sought proposals for the design of the project XTY information systems to manage the key functions of its Business. The previous systems was a manual system which often lacked a unified approach to estimate the cost of casual labour, bookings, supplier management and cancellations, thereby hampering productivity and improvement. This report would therefore outline the requirement specification of software requirements which include: functional, technical and interface specifications, which confirmed their completeness, consistency, verifiability and feasibility. The process of this specification is intended to outline the software and technical task of the requirements specification phase to the design, which identifies data, their conversion and transfer, the system functions, procedures, as well as to identify system components and communication between them. Other phases include the hierarchical decomposition of all the processes, the analysis of the key elements of the system that is necessary to establish the correctness of the system.

1. Requirement Specification

1.1 Purpose and Scope of these Specifications

These specifications describe the requirements for XTY Information Systems or "Model Requirements for the Management of customer’s orders, bookings, organizing for suppliers and payments. The needs of different areas were analyzed in detail leading to the requirement specification of the many features essential for the accurate management of the daily functioning of Home Made Foods Limited such as the faster functioning of the booking process, with particular reference to the management of the functions and their different types, the process of order supply, the information for supply and managing multiple employees. It mainly emphasizes on the functional requirement for the establishment of a catering service that utilizes an IT system to change the existing manual service, which is due to several factors, not exclusive of each other. The initial need to evolve as a result of: - A willingness to improve benefits and (or) productivity;

1.2. System Scope In Scope:

I. The XTY Information system is equipped with all the functionality necessary to manage the detailed composition of all the functions,

Page 3

menus and its various dishes, recipes and drinks. The detailed recipes, properly defined, contribute to the automatic management of inventory and production, providing a direct interaction between the composition of the functions, menu and the management of raw materials and finished product;

II. The system also offers full support to the association and the definition of the kinds of non-food, thus ensuring an integrated management of the finished product, as actually delivered to the end of the service;

III. The collection and definition of all the information necessary to book for different types of functions and prepare the recipes and the menu is done easily and guided through a simple registration system, which allows a thorough preparation and a simple maintenance of basic information

IV. Computerization of the stock re-ordering process and other necessary modules which also includes an alert function that informs of a Minimum (Min) - Maximum (Max) level, in order that messages are generated and sent to the relevant suppliers of food and drinks when the company’s stock levels goes down below a certain minimum and maximum levels;

V. Computerization of the staff allocation process and the payment process and staff scheduling process through a process of communication between the scheduled function system and the staff roaster system to determine staff required for the planned event and payment for the casual members of staff;

1.3 Operating Environment

1.3.1 Infrastructure

The created XTY information system is provided in the operating environment in which it will be installed. This must change according to the differences between development environment and operating environment are made.

1.3.1.1 Network Connections & Intranet    The booking of meals will be managed in the work environment with the help of reservation systems and can be varied by simple paper forms by recording customers details and by adopting advanced handheld computers connected to the other functions via modem or Internet, through specific programs personal computer, and finally through the reservation systems based on a remote Web interface. Access to the wide range of World Wide Web is possible from any workstation. This would

Page 4

require the use of an intranet so that the owner / CEO and key employees can all login to the existing network. The other connections would include; cables, connection boxes, and other components and connections can be made without modification to be used. At the terminal would be PC's and workstations, where each PC to be used by the different staff is connected to the Local Area Network (LAN). The company intranet would have a unique address together with the Internet address where the world is clearly responsive. This allows certain devices to be grouped, and so with rights and privileges put in place to restrict the use of certain information.

1.3.1.2 Software

The basic Microsoft office tools would be most appropriate for all members of staff such as Word processing, Microsoft Excel, Microsoft PowerPoint, Microsoft Access database and Microsoft outlook. Web browsers such as Internet explorer, Firefox, Netscape Navigator and a mail client such as Microsoft outlook would suffice.

1.3.1.3 Hardware Platform & Protection    Basic operating system would be the Microsoft NT server 2003, a license version or the Windows NT 4 server / 2000 for client or the licensed version of Windows 2000 professional. For the Database management system is Microsoft SQL Server 2000, as a means of protecting information from unauthorized access. The XTY information system would be operated through an intranet, which demands the operating environment as mentioned above. For the provision of intranet services is, however, this aspect should be closely followed. With the growth of the Internet boom has brought with it the growing risk of misuse or vandalism through shady of computer hackers. As a result, it is critical that the Intranet Services must ensure security against attacks by installing a recognized spyware and anti-virus programme such as Norton. Since using the XTY systems on the intranet and the internet would require the sharing of secret information which is transmitted between the sender and the employee, it is therefore critical that the procedures for system protection is strictly adhered to and that equipment is protected by restricting all unauthorised persons.

1.3.1.4 Service Providers

The performance of the service provider is finally a third major area that in the discussion along with everything else. Depending on the type of services being offered would determine the level of more or less high computational power required. For uninterrupted services would therefore require the use of computer systems with high processing power, lots of memory and disk space is recommended.

Page 5

1.3.1.5 System Performance Concerns

The system performance of the XTY system on the intranet service is dependent on the number of simultaneous users. Unlike the WWW public offering great many computer companies, with several thousand requests per second, is the workload in company’s intranet, which is only within the office area and would therefore have very minor cases of inaccessibility. The required computing power to a server is dependent on the service offered: many applications run from the server (as a CGI application), which means that the actual work is done from the server while the client computer (workstation) only makes requests or waiting for response.

1.4 Functional Requirement & System Response

1.4.1 Main Concerns

1. Management of the booking processManagement of the ordering and supply

2. Management of the order and stock replenishment process

3. Management of the deployment process for staff

4. Management of the payment process for casual

5. Managing the daily menu Management of non-food genres

1.4.2 System Solution

The system is able to manage the movement of stock with different levels of complexity ranging from simple monitoring of goods entering and leaving through to multiple stores shared and used simultaneously from different fields.

The stock management is integrated with the management system of the meal and reservations, with the ability to manually manage or quite automatic handling associated. The handling is done automatically by combining the information on the composition of the plates with the information production.

The creation of bookings and orders can be supported by the XTY system that allows users to anticipate the needs of company on the basis of the completed and signed booking forms and other historical information stored and entered into the system, and a corresponding form of planning, which allows to optimize the allocation of resources and the various stages of production.

Page 6

The XTY information system shall record the initial information necessary for the management of traceability, information which, when integrated with information from bookings, allowing the reconstruction of the history of the product, from supplier to delivery.

1.4.3 Benefits

XTY information system integrates a system of complete control and transfer of all the company’s product and anything else used in the running of the daily business such as plates, food, drinks and raw materials from suppliers to another and manage separate storage of goods in the long term management from raw stock, which includes the goods fast perish ability and current use. In the course features are included all those features peculiar to a typical management, such as inventory management, handling, management of inventories, etc.

2. System Specification

2.1 Data Models

Page 7

Page 8

Figure 1.1: Entity Relationship Diagram

2.2 Data Dictionary

Customer-IDType StringDescription/Purpose:

This number is given to each customer.

Usage Used for identifying the customerDisplay customer information

Range NoneSpecification (BNF)

customer-ID => {Digit}{6}Digit => [0|1|2…|9]

Customer-NameType StringDescription/Purpose:

Name of customer

Usage To identify the customer and any other information

Range NoneSpecification (BNF)

Customer Name => {Letter}*Letter => [A|B|C…|Z]

BookingType DateDescription/Purpose:

The date booked by the customer for the function.

Usage Display the exact time for the proposed eventRange NoneSpecification (BNF)

DOB => Year+Month+DayYear => 4 digit numberMonth => [1|2|3…|12]Day => 2 digit number

Amount DepositedType NumberDescription/Purpose:

The initial amount deposited by the customer for the event.

Usage Secures the function for the employee and based on that it is officially held out for the customer

Range 0~999999Specification (BNF)

Amount Deposited => {Digit}*Digit => [0|1|2…|9]

Page 9

Balance Amount DueType NumberDescription/Purpose:

This is the final amount that is paid by the customer after the function.

Usage This clears the customer of any further debt owed as the booking is finally done away with once the balance amount has been paid

Range 0~999999Specification (BNF)

Balance now due => {Digit}*Digit => [0|1|2…|9]

Customer PhoneType StringDescription/Purpose:

Telephone or mobile number of the customer.

Usage Display the customers informationRange NoneSpecification (BNF)

Telephone number of the customer=> {Digit}{6}Digit => [0|1|2…|9]

ExtrasType StringDescription/Purpose:

This is an instance of where the customer selects other special requirements of the customer has deliberately chosen a couple of other items not in the standard menu.

Usage Used for order extra portions of food DrinksOther extras

Range NoneSpecification (BNF)

B-EID{Digit}{6}Digit => [0|1|2…|9]

Menu StarterType StringDescription/Purpose:

This consist of the main starter which is found in the 10 standard menus is an instance of where the customer selects it either as the starter for a wedding, parties or just a picnic.

Usage Used for order extra portions of food DrinksOther extras

Range NoneSpecification (BNF)

B-EID{Digit}{6}Digit => [0|1|2…|9]

Page 10

Page 11

2.3 Process Models: DFD Diagram

Page 12

Figure 2.2: Level 0 Data Flow Diagram

2.4 Behavioural Models: Behavioural Model for the Booking Object

Figure 3.3: Behavioural Model for the Booking Object

Page 13

2.4.1 Implications on the Data Structure

2.4.1.1 Interpretation

Figure 3.3 above shows the behavioural model and the various states of transitions for the Booking object and the key interactions the entity has with the system. It can be observed from the diagram that the state diagram and history of the object actually starts when a customer makes an enquiry for a function. The employee details are recorded in the system and then subsequently modified over time if they are able to fulfil the terms and conditions of the company with regards booking. If the deposit and the signed booking forms are returned within the seven days stipulated by the company, the booking and function is then confirmed and the object is modified in the system. However, if the forms together with the deposit are not received after seven days, the customer is sent a friendly reminder during which the object is also modified with the sending of the letter. After the function and upon final payment of the balance, the object is further modified to acknowledge receipt of the final payment and the end of that cycle. However, for the customer who has not still replied after the next seven days, a cancellation and deletion is carried out. After both sets of action, the system automatically returns back to its original state.

2.4.1.2 Implication: From Passive to User Display

Based on the transition events explained above, it can then be implied that for each customer who has signed and returned the booking forms together with the deposit, the system transits from the state of reading and recording command on the customer’s payment to actually a prepared state for the customers function ahead, with most definitely a user display outlining the total number of customers who have booked for an event together with all their requirements. This further gives rise to the next state which would probably be processing information for the functions ahead with the confirmed customers. Through this state, top management and the owner can log-in to the system and read the final schedule of confirmed functions in addition to all their requirements. With this information, top management can then assess if the company has got the required resources (both manpower and ingredient) to cope with the functions.

In addition, for the customers who have not yet sent in their completed forms and deposit, the system still changes from a state to another but this time around is in a transition and the forms remain open in the system as the booking is still pending in the system until the seven and fourteen days cooling off period after which the forms are cancelled as a result of not responding to their obligations.

Page 14

Page 15

2.5 Decomposition

Figure 4.4 Level 1 DFD Diagram: Bookings

Page 16

Figure 5.5 Level 1 DFD Diagram: Order New Supplies

Page 17

Figure 6.6 Level 1 DFD Diagram: Employee Payment

Page 18

Figure 7.7 Level 1 DFD Diagram: Cancellations

Page 19

2.6 User Interface

Figure 8.8: Employee Interface

Page 20

Figure 9.9: Customer Interface

Page 21

Figure 10: Main Menu

Table 1.1: Customer Table Description

The key symbol highlights the primary key.

Highlights the main fields for the table

Can allocate a description of the field where required, to give additional information

The data type for each field, i.e. whether it holds a number or a text field. Can be crucial for validation

Can change additional information for the data type, e.g. field length from 20 to 30.

Page 22

2.6.1 Descriptions

Customer Table

FIELD NAME DATA TYPE FIELD SIZE COMMENT

Customer No AutoNumber Long IntegerIs the primary key, defined with an AutoNumber, as a new record is entered, data given a unique identification number

Last Name Text 40 Text field for the last name of the customerFirst Name Text 30 Text field for the first name of the customerTitle Text 10 Text field for the title i.e. Dr, Mr, Mrs Miss, Ms.Street Text 30 Text field for street & house number Town Text 25 Text field for town County Text 20 Text field for the countyPost Code Text 10 Text field for the postcode, as it is a combination

of numbers and fields. Telephone No Number Integer It is an integer as the telephone consists of

numbers only Date of Birth Date/Time Short Date The date of birth is recognised as a date fieldDate of Joining Date/Time Short Date Uses the date format to record the date of

joining date

Gender Yes/No Yes/NoGender is a yes/no field as you can either male or female, recognised with a tick box function for the forms, i.e. if ‘ticked’ then male.

Table 2.2: Customer Table description

Function Table

FIELD NAME DATA TYPE FIELD SIZE COMMENTFunction No AutoNumber Long Integer Primary key – unique identifier for each of the

rentals. Rent Date Date/Time Standard

DateUses a standard recognised format to record the rent date

Due Date Date/Time Standard Date

Uses a standard recognised format to record the due date for the rental

Function Type Number Long Integer It is the function number. Menu ID Number Long Integer Menu chosen by the customerDrink Text 30 Text field for the first name of the customerExtra Number Long Integer It is the number for other extra bits added to the

standard menu Place Text 50 The location of the functionNumber of

GuestNumber Long Integer Records the number of guest being expected

Price Number Long Integer The calculated total price of the event Cake Type Text 50 Outlines the varieties of cakes

Table 3.3 Function Table description

2.6.2 The Database Menu Structure

Within the system have a menu structure that the user can navigate in order to use the system effectively. The menu structure consists of a

Page 23

main menu, form menu and report menu, all are interlinked and allows navigation through the system.

The Main Menu – (Title Slide appears on screen once the system has been opened). The main menu appears on screen automatically as an ‘autoexec’ macro was implemented and recorded. The main menu has links to both additional menus i.e. the form and report menus. The form and report menus are interlinked with each other and both link back to the main menu.

Features On All Menus

I. All have the same background layout, and this shows consistency between the menus.

II. The clipart picture is shown all the menus, links to the video/film theme.

III. All the menus have buttons, depending on the menu features the buttons change accordingly.

IV. All the menu titles are in the Verdana font style, size 20 bold, and so differentiate from the main title heading.

V. All title headings are in the Verdana font style, size 18 bold, also have an indented shadow border which highlights the main title of the menu.

3. Key Contributions

3.1 Reliability of the Proposed Software Systems

Britton and Doake (1996) states that the requirements of reliability in software systems are much stricter than those of general purpose systems. There are three reasons that cause a system failure in real time:

Errors in specification

Inadequate testing

The Main Menu

The Form Menu The Report Menu

Page 24

Defects in any of the components, both hardware and software components

This system has not been adequately tested so on that basis I would recommend that adequate testing be carried out by the users.

One of the main concerns for this system, is the Software and reliability issue. Britton and Doake (1996) states that reliability is the key Criterion for acceptance of a System with the user. This applies to this system as well as adequate testing has not been carried out on the Standard software packages. For the user the main concern will be the frequent failures of Software products and technical devices in its environment. According to Britton and Doake (1996), “under reliability is the ability of a system or component to perform to expectation based on its required function under specified conditions over a specified period of time to execute”, (Britton and Doake, 1996). In discussing the reliability of the software developed, the failure rate plays an important role. In many practical cases of the case in which the failure rate to be constant over the observation time can be adopted.

3.2 Maintainability

We would recommend the need to include software metrics as a form of ensuring that it is able to meet the user requirements. Kan (2002) states that there are a number of features that should accompany effective software metrics.

These characteristics are:

Simple and easy to calculate, (Kan, 2002) Empirically and intuitively persuasive, (Kan, 2002) Consistent and objective, (Kan, 2002) Consisting of the use of units and size, (Kan, 2002) Independent of programming language, (Kan, 2002) Effective feedback mechanism for quality, (Kan, 2002) Although most software metrics satisfy the above characteristics, some of the commonly used metrics fail to fulfil one or two, (Kan, 2002).

Maintainability metrics cannot measure the cost of making a particular change to the system software, but that measure aspects of the complexity and quality of programs as there is a high correlation between the complexity and maintainability (a more complex lower maintainability) and between the quality and maintainability (the higher quality higher maintainability - and vice versa -).

There are ways to measure the maintainability for all software components that are or will be undergoing maintenance code, user documentation, analysis or design documents, etc.

Page 25

Software metrics can be classified into three categories (Kan1, 2002):

3.2.1 Importance of Utilizing Metric for Software Systems

Kan (2002) states that user defined metrics describe the characteristics of the product in any way determine the maintainability, such as the size, complexity or design features.

3.2.2 Metric process

Process metrics can be used to enhance development and maintainability of software. Examples include the effectiveness of removing defects during development, the pattern in which the defects during testing fixed or time response of the process.

3.2.3 Metrics project

Metrics describe the project characteristics and project implementation. For example, the number of developers, the staffing pattern in the life cycle, cost, and planning and productivity software. In addition, some metrics can belong to multiple categories

Hundreds have been proposed for software metrics, but not all provide practical support for the software developer. Some require measurements that are too complex, others are so esoteric that few professionals have the hope of understanding and intuitive violate basic notions of what it really is high quality software, (Kan, 2002).

4. Bibliography & Reference

Britton .C. & Doake .J. (1996) SOFTWARE SYSTEMS DEVELOPMENT McGraw Hill.

Edwards, P. (1993) SYSTEMS ANALYSIS AND DESIGN McGraw Hill.

Coles Sue & Rowley Jenny, (2001) ACCESS 2000, An Advanced Course For Students, Learning Matter Ltd

Jeffrey. A. Hoffer, Mary. B. Prescott, Fred. R. McFadden (2001) MODERN DATABASE MANAGEMENT Prentice Hall.

Kan, S. (2002) Software Quality Metrics Overview. En Metrics and Models in Software Quality Engineering, 2nd Edition. Addison Wesley Professional

Page 26