Words: 1760
Many people they met, however, seemed to want home delivery service but with a more complete food selection. Waiter on Wheels was conceived as the best of both worlds for Sue and Tom – a restaurant service but without the high initial investment. The Backfires contracted with a variety of well-known restaurants in town to accept orders from customers and to deliver the complete meals. After the restaurant prepares the meal to order, It charges Walters on Wheels a wholesale price, and the customer pays retail plus a service charge and tip.
Walters on Wheels started modestly, with only two restaurants and one delivery driver working the dinner shift. Business rapidly expanded, and the Blackboard realized they needed a customer computer system to support their business operations. They hired your consultant firm to help them define what sort of a system they needed. Sue described the current system as such “When a customer calls in wanting to order, I need to record it and get the information to the right restaurant. I need to know which driver to ask to pick up the order, so I need drivers to call in and tell me when they are free.
Sometimes customers call back wanting to change their orders, so I need to get my hands on the original order and notify the restaurant to make the change. ” Tom continued, “The drivers get the copy of the bill directly from the restaurant when they pick up the meal, which should agree with our calculations. The drivers collect money they have and compare it to the records we have. After all drivers report in, we need to create a deposit slip for the bank for the days total receipts. At the end of each week, we calculate what we owe each restaurant at the agreed-to-wholesale price and send them a statement and check.
Basic project requirements Some processing requirements when events such as these occur are: a customer places an order either via telephone or via the company website. A driver is finished with a delivery a driver reports for work The system should also produce information at some specific points in time – for example, when it is: time to produce an end-of-day deposit slip time to produce end-of-week restaurant payments time to produce weekly sales reports State any logical assumption used in the case study.
You are required to: To produce a software requirements specification (SIRS) document. Your team can decide on the requirements for the software to be developed. The specification is derived from the activities undertaken in the requirements development and management process which will compromise of the main body of the project report and the SIRS should be enclosed in the appendix.
The project deliverables should focus on what and how requirements engineering processes that should be undertaken in the throughout the product development cycle Project Requirement Specification Aims: The aims of this assignment are to primarily address the following learning outcomes: Understand the principal requirements engineering activities and their relationship Have been introduced to several techniques of requirements elicitation and analysis Other learning outcomes. Understand their relationship Understand the importance of requirements validation and how requirements reviews are used in this process Understand why requirements management is necessary and how it supports other requirements engineering activities Assessment The total assessment mark of is 100%, which is distributed as follows:- group contribution component of 70% and n individual contribution component comprising of 30%. Outline of Task: You have been given the task to undertake the Requirements Engineering processes in the context of the given case study to produce a Software Requirements Specification (SIRS) document.
The complete set of activities undertaken in the Requirement Engineering process should be documented and forms the main body of the project report. The class will be divided into groups comprising of three (3) team members and the tasks undertaken for this project should be fairly distributed as reflected in the workload matrix. Suggested Presentation Format This project is a group effort and should be treated as though you are proposing a structured organized approach to Requirements Engineering. The following is a suggested minimum report format.
It is recommended that your project report contain at least the following:- Cover Page Your cover page should contain the following items: CIT Logo Subject Title System Name Intake Title Intake Code Group Number Group Members’ Name Table of Contents The table of contents should have the topic title and reference page number attached to each topic and should comprise of the areas of focus as depicted in the marking scheme. Introduction This should include the project background, the scope of the project, aims, and objectives of this project.
Schedule Planning – Giant Chart Matrix tasks and the responsible group member(s) has to be included in your schedule. All this information should be shown in a Giant chart and Workload. Areas of focus Software requirements Some definitions of requirements Requirements Engineering Process Requirements development and management Requirements development processes Elicitation Analysis Specification validation Requirements management processes Requirements management procedures
Tracing requirements and traceability procedure Requirement management tools Good requirements characteristics Attributes of good requirements specification Implementation of Requirements Engineering Requirements Specification Document (SIRS) The Documentation The documentation has to be word processed, printed on single side AY size paper with 1. 5 line spacing (optional) and comb bound (sample of the binding will be shown accordingly). The maximum number of pages should be 50. Your group has to present your research findings to the lecturer and the presentation will be Judged accordingly.
Documentation Standards Project documentation should be complete The project documentation should be at least of average standard in terms of language, layout and flow. The contents of the project documentation should be appropriately structured. References should be accurate, relevant and up to date References should be done using Harvard’s Name System of Referencing. Diagrams / tables / graphs which have been used in the documentation should be properly captioned. (Note: Each group member has to be involved in the presentation) What You Need To Hand In?
Your group needs to hand in the group case study on the due date mentioned on the ate and time allocated to each group. Each group member will be involved in the presentation in which individual separation of marks will be quantified as a final mark set. The workload matrix should indicate the contribution of each individual for each required component (shown in %age form) and should be signed off by each team member. Late submissions will not be assessed unless extenuating circumstances are upheld.
Performance Criteria Grade Assessment Guidelines General Pass answers are expected to be legible, tidy, well organized and written in clear, understandable English. Students who grossly exceed the word limit will be penalized. 0-49% Superficial analysis, concepts and language of the subject are absent or scant. Irrelevant regurgitation of text book. Ideas are poorly expressed. Many key issues are ignored. Concepts and language of the subject are used but are often confused in application and or explanation. Some key issues are ignored. 50-64% Some understanding of the relevant models and concepts.
Some elements of an appropriate structure are present. Restricted analysis of some issues. 65-74% Evidence of reading and research. Understanding of the application of appropriate oodles and concepts is demonstrated. Key issues are identified and analyses, although this may be restricted at times. Some sources are acknowledged. 75-79% Evidence of wider reading. The assignment effectively interprets the information and exhibits the integration of ideas across the subject area. The assignment has credible recommendations. A systematic approach to development and evaluation is used.
Most sources are acknowledged and referenced using Harvard system. 80% and above Arguments are clear and convincing. Confident integration of theory and practices is demonstrated. Consistent referencing to sources using the Harvard system. Marking Scheme and Performance Criteria Group NO; marks – 70% Group Distribution of marks will be according to the performance criteria stated below: Criteria 0-5 6-10 11-15 16-20 Requirements Determination Very few functions are explained or some functions are not clearly explained, leaving the audience confused.
A lot of ambiguities and never consider non-functional requirements. Some functions are explained clearly, some are not well explained. Several ambiguities in the explanation. No discussion about non-functional requirements. Most functions in the software are clearly explained. Very little ambiguities in the statements. Non-functional requirements seemed to be considered, a little explanation is done. All functions in the software are clearly explained in detail. Explanation has no ambiguities and can be easily understood.
Provide some explanation on non-functional requirements. Requirements development processes Validation Specification Document(SIRS) Very few correct approaches to RE engaged. Very poor application of RE procedures and good practices and major limitations in the project seen. No referencing or adoption of good practices. Unstructured specification document poorly reflecting information gather from the requirements development process and of little relevance to the subsequent phases of the software development life cycle.
Poor engagement of procedures undertaken to conduct elicitation, analysis, specification and validation many errors or inappropriate approach to requirements engineering and some good practices seen in RE seen. Little or no referencing seen. Adopts or defines an SIRS template contents partly reflects the requirements development processes which are to be used in the subsequent phases of software placement life cycle. Use correct procedures to conduct elicitation, analysis, specification and validation of requirements.
Some good practices for requirements engineering seem with minor errors in requirements models/requirements specification. Some referencing seen. Adopts or defines an SIRS template and some of its contents are relevant for the subsequent phase of software development life cycle. Clear documentation of the essential steps undertaken to elicit, analyze, specify and validate requirements. Adopted good practices from various practitioners supported with the appropriate referencing. Completely professional analysis and model/ requirements specification.
Adopts or defines an SIRS template and its relevant contents reflects the information for the subsequent phase of software development life cycle. Requirements management Requirements management has omitted addressing most of the components as required. Lacking consistency to the approach of requirements management. Requirements management procedures undertaken, however partially addressed most of the components as required. Use correct procedures to conduct requirements management. Some good practices for requirements management me with minor errors in requirements management.