UNIVERSITY OF GREENWICH
MASTER OF SCIENCE IN BUSINESS ADMINISTRATION 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..............................................................................................3 1. Requirement Specification...................................................................3 1.1 Purpose and Scope of these Specifications ..............................................................................................................3 1.2. System Scope.............................. Scope.................................................................. ...................................................3 ...............3 1.3 Operating Environment................................................................ Environment...................................................................4 ...4 1.3.1 Infrastructure............................................................................4 1.4 Functional Requirement & System Response.................................6 1.4.1 Main Concerns..........................................................................6 1.4.2 System Solution........................................................................6 1.4.3 Benefits............................ Benefits................................................................ .........................................................7 .....................7 2. System Specification............................................................................ Specification............................................................................ 7 2.1 Data Models....................................................................................7 2.2 Data Dictionary...............................................................................9 2.3 Process Models: DFD Diagram......................................................12 2.4 Behavioural Models: Behavioural Model for the Booking Object...13 2.4.1 Implications on the Data Structure.........................................14 2.5 Decomposition..............................................................................16 2.6 User Interface....................... Interface........................................................... .........................................................20 .....................20 2.6.2 The Database Menu Structure................................................23 3. Key Contributions............................................................................. Contributions...............................................................................24 ..24 3.1 Reliability of the Proposed Software Systems...............................24 3.2 Maintainability.......................... Maintainability.............................................................. .....................................................25 .................25 3.2.2 Metric process ........................................................................26 ........................................................................26 3.2.3 Metrics project .......................................................................26 4. Bibliography & Reference...................................................................26 Reference...................................................................26
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 process Management 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-ID Type String Description/Purpo This number is given to each customer. se: Usage Used for identifying the customer Display customer information Range None Specification customer-ID => {Digit}{6} (BNF) Digit => [0|1|2…|9] Customer-Name Type Description/Purpo se: Usage Range Specification (BNF)
String Name of customer To identify the customer and any other information None Customer Name => {Letter}* Letter => [A|B|C…|Z]
Booking Type Date Description/Purpo The date booked by the customer for the se: function. Usage Display the exact time for the proposed event Range None Specification DOB => Year+Month+Day (BNF) Year => 4 digit number Month => [1|2|3…|12] Day => 2 digit number Amount Deposited Type Description/Purpo se: Usage
Range Specification (BNF)
Number The initial amount deposited by the customer for the event. Secures the function for the employee and based on that it is officially held out for the customer 0~999999 Amount Deposited => {Digit}* Digit => [0|1|2…|9]
Balance Amount
Page 9
Due Type Number Description/Purpo This is the final amount that is paid by the se: 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~999999 Specification Balance now due => {Digit}* (BNF) Digit => [0|1|2…|9]
Customer Phone Type String Description/Purpo Telephone or mobile number of the customer. se: Usage Display the customers information Range None Specification Telephone number of the customer=> {Digit} (BNF) {6} Digit => [0|1|2…|9] Extras Type String Description/Purpo This is an instance of where the customer se: 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 Drinks Other extras Range None Specification B-EID{Digit}{6} (BNF) Digit => [0|1|2…|9] Menu Starter Type String Description/Purpo This consist of the main starter which is found in se: 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 Drinks Other extras Range None Specification B-EID{Digit}{6} (BNF) 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 The key symbol highlights the primary key.
Can allocate a description of the field where required, to give additional information
Highlights the main fields for the table
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.
Table 1.1: Customer Table Description
Page 22
2.6.1 Descriptions Customer Table FIELD NAME
Customer No
DATA TYPE
FIELD SIZE
AutoNumber
Long Integer
Text Text Text Text Text Text Text
40 30 10 30 25 20 10
Number
Integer
Date/Time Date/Time
Short Date Short Date
Yes/No
Yes/No
Last Name First Name Title Street Town County Post Code Telephone No Date of Birth Date of Joining Gender
COMMENT Is the primary key, defined with an AutoNumber, as a new record is entered, data given a unique identification number Text field for the last name of the customer Text field for the first name of the customer Text field for the title i.e. Dr, Mr, Mrs Miss, Ms. Text field for street & house number Text field for town Text field for the county Text field for the postcode, as it is a combination of numbers and fields. It is an integer as the telephone consists of numbers only The date of birth is recognised as a date field Uses the date format to record the date of joining date Gender 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 Function No
DATA TYPE AutoNumber
FIELD SIZE Long Integer
Rent Date
Date/Time
Due Date
Date/Time Number Number Text Number
Standard Date Standard Date Long Integer Long Integer 30 Long Integer
Text Number
50 Long Integer
COMMENT Primary key – unique identifier f or each of the rentals. Uses a standard recognised format to record the rent date Uses a standard recognised format to record the due date for the rental It is the function number. Menu chosen by the customer Text field for the first name of the customer It is the number for other extra bits added to the standard menu The location of the function Records the number of guest being expected
Number Text
Long Integer 50
The calculated total price of the event Outlines the varieties of cakes
Function Type Menu ID Drink Extra Place Number of Guest Price Cake Type
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
The Form Menu
he Report Menu
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. II. III. IV. V.
All have the same background layout, and this shows consistency between the menus. The clipart picture is shown all the menus, links to the video/film theme. All the menus have buttons, depending on the menu features the buttons change accordingly. All the menu titles are in the Verdana font style, size 20 bold, and so differentiate from the main title heading. 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
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
