Sunteți pe pagina 1din 8

UCTI Degree Level 2

Requirements Engineering

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION Level 2 CT056-3.5-2 Requirements Engineering Project Specification

WAITERS ON WHEELS: COMPUTERIZED DELIVERY TRACKING SYSTEM Waiters on Wheels are a restaurant meal-delivery service started in 1997 by Sue and Tom Bickford. The Bickfords both worked for restaurants while in college and always dreamed of opening their own restaurant. But unfortunately, the initial investment was always out of reach. The Bickfords noticed that many restaurants offer takeout food, and some restaurants, primarily pizzerias, offer home delivery service. 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 Bickfords 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 Waiters on Wheels a wholesale price, and the customer pays retail plus a service charge and tip. Waiters on Wheels started modestly, with only two restaurants and one delivery driver working the dinner shift. Business rapidly expanded, and the Bickfords 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 the amount plus a service charge. When drivers report in at closing, we add up the 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.

CT056-3.5-2-RENG

Asia Pacific University College of Technology & Innovation

UCTI Degree Level 2

Requirements Engineering

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 (SRS) 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 SRS 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

CT056-3.5-2-RENG

Asia Pacific University College of Technology & Innovation

UCTI Degree Level 2

Requirements Engineering

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. Distinguish the various subcomponents of Requirements Engineering and 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 an 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 (SRS) 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: UCTI Logo Subject Title System Name Intake Title Intake Code Group Number Group Members Name
CT056-3.5-2-RENG Asia Pacific University College of Technology & Innovation 3

UCTI Degree Level 2

Requirements Engineering

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 - Gantt Chart &Workload Matrix This should include your groups schedule on this assignment and the dates and tasks and the responsible group member(s) has to be included in your schedule. All this information should be shown in a Gantt chart and Workload. Areas of focus Software requirements Some definitions of requirements Requirements Engineering Process Requirements development and management o Requirements development processes Elicitation Analysis Specification validation o 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 (SRS)

The Documentation The documentation has to be word processed, printed on single side A4 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 Harvards Name System of Referencing.
CT056-3.5-2-RENG Asia Pacific University College of Technology & Innovation 4

UCTI Degree Level 2

Requirements Engineering

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 cover sheet of the assignment. The presentation will be conducted according to the date 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.

CT056-3.5-2-RENG

Asia Pacific University College of Technology & Innovation

UCTI Degree Level 2

Requirements Engineering

Performance Criteria Grade General Assessment Guidelines Pass answers are expected to be legible, tidy, well organised and written in clear, understandable English. Students who grossly exceed the word limit will be penalized. 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. Some understanding of the relevant models and concepts. Some elements of an appropriate structure are present. Restricted analysis of some issues. Evidence of reading and research. Understanding of the application of appropriate models and concepts is demonstrated. Key issues are identified and analysed, although this may be restricted at times. Some sources are acknowledged. 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. and Arguments are clear and convincing. Confident integration of theory and practices is demonstrated. Consistent referencing to sources using the Harvard system.

0-49%

50-64% 65-74%

75-79%

80% above

CT056-3.5-2-RENG

Asia Pacific University College of Technology & Innovation

CTI Degree Level 2 Group No._________

Requirements Engineering

Marking Scheme and Performance Criteria Group NO;____________________ Group marks 70% Distribution of marks will be according to the performance criteria stated below:
Criteria Requirements Determination o Software requirements o Some definitions of requirements 0-5 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. 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. 6-10 Some functions are explained clearly, some are not well explained. Several ambiguities in the explanation. No discussion about non-functional requirements. 11-15 Most functions in the software are clearly explained. Very little mbiguities in the statements. Nonfunctional requirements seemed to be considered, a little explanation is done. 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 SRS template and some of its contents are relevant for the subsequent phase of software development life cycle. 16-20 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 o Elicitation o Analysis o Specification o Validation o Specification Document(SRS)

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 SRS template contents partly reflects the requirements development processes which are to be used in the subsequent phases of software development life cycle.

Clear documentation of the essential steps undertaken to elicit, analyze, specify and validate requirements. Adopted good practices from various practioners supported with the appropriate referencing. Completely professional analysis and model/requirements specification. Adopts or defines an SRS template and its relevant contents reflects the information gather in requirements development phase which makes it an effective deliverable for the subsequent phase of software development life cycle.

CT056-3.5-2

Asia Pacific University College of Technology & Innovation

CTI Degree Level 2 Group No._________

Requirements Engineering

Requirements management o Requirements management procedures o Tracing requirements and traceability procedure o Requirement management tools

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.

Criteria Project management

0-2 No timeline and schedule. If there is, very little information given. No minutes of meeting or any other indications that the project is monitored.

3-5 Some tasks are not delivered. Vague timeline and schedule with very little information. Provide at least minutes of meeting to indicate some form of management done.

Use correct procedures to conduct requirements management. Some good practices for requirements management seem with minor errors in requirements management. Some components as required have been left unaddressed. 6-8 Several problems encountered in delivering some tasks on time but able to recover. Provides timeline and schedule. Some effort to monitor progress of project (providing minutes of meeting etc)

Clear documentation of the essential steps undertaken to :- Establish baseline and control version of requirements. - Defines change-control process. - Create requirements traceability matrix. - Use requirements mgt. tools Referencing to good practices seen.

9-10 Clear indication of a well-managed project. Provides clear timeline and schedule. Shows effort to track and monitor progress of project.

Individual contribution 30%


Criteria Presentation 0-4 Most questions not answered. Reading from text/slide most of the time. Seems unstructured and unprepared with very little knowledge of the project. Marks will be given marks = 10 marks. 5-9 Not able to answer some questions. Reading from text/slide. Some flow of explanation available and seems to understand what the project is all about. 10 - 14 Able to answer questions. Some reading from text/slide. Acceptable flow of explanation and show some knowledge of the project undertaken. 15 - 20 Able to answer questions. No reading from text/slide. Smooth flow of explanation and shows knowledge of project.

Peer assessment

according to the assessments done by their peers. This will be checked based on the workload matrix provided. Total

CT056-3.5-2

Asia Pacific University College of Technology & Innovation