ISYS254 – Applications Modelling and Development 代写
100%原创包过,高质量代写&免费提供Turnitin报告--24小时客服QQ&微信：273427
ISYS254 – Applications Modelling and Development 代写
MACQUARIE UNIVERSITY
Faculty of Science and Engineering
Department of Computing
ISYS254 – Applications Modelling and Development
2017 - Semester 1
ASSIGNMENT 1 – Individual
Requirements and Modelling
Due by Monday 10
th April 5pm
15 Marks
About the marking
Specific feedback will be given via a marking sheet and general feedback via a forum post on iLearn.
Ensure you review all feedback as you do not want to make the same errors again in the exam. As no one
solution is correct, but many incorrect solutions are possible, the top two/three student submissions will
be made available to other students, with their permission.
Learning Activities:
Identify appropriate requirements engineering methods.
Identify the scope of the system and model the scope.
Perform analysis and practice modelling using UML
Understand how the different UML diagrams relate to one another.
Use appropriate tools and techniques to prepare and validate analysis models.
Problem statement for the assignment
Macquarie University Request Efficient Response Management
System (MURMERS)
The Office of Facilities Management (OFM) provides “environmentally sustainable, high quality facilities and services to our
customers in a professional, courteous and cost effective manner which enhances the University's image of being a University
of distinction” (http://www.ofm.mq.edu.au/). Within their responsibilities, OFM manages cleaning and maintenance; general
space management including refurbishments and planning new spaces; preparation and distribution of information relating to
campus maps, public transport and parking options; casual room bookings & room hire; class and room timetabling; campus
safety and security and lost property; and, not least of all, sustainability.
To achieve their goals and fulfilling their role within the university, OFM must keep track of requests for services and ensure that
they are dealt with in a timely manner. You have been asked to develop a system, to be known as Macquarie University
Request Efficient Response Management System (MURMERS) that will allow requests for services to be efficiently handled.
The system will need to keep track of who requested the service, the nature of the request, allocation of resources to respond to
and/or carry out the request, when the service is due, estimates of time needed and any overdue services. MURMERS will need
to provide reports such as a daily request list or an overdue request exception report and generate email/SMS request
messages for urgent requests.
MURMERS will not replace other systems used by OFM such as the timetabling or room booking systems or university-wide
systems such as HROnline (Human Resource Management/Payroll system). However, MURMERS will need to interface to
some existing systems. For example, to determine which staff are available (i.e. not on leave) and assign them to handle a
request, MURMERS will need to talk to HROnline.
Requirements (5 marks)
Task 1: Requirements engineering (1/2-1 pages) (2.5 marks):
• Suggest and describe techniques for gathering requirements (e.g. surveys, interviews, JAD, user
stories, etc) that are appropriate to the problem you are trying to solve. Say why you suggested
those (and not others).
(0.75 mark)
• Describe the requirements elicitation, specification and validation you have actually done to
identify and specify the user stories. What data did you collect and how did you use it? (0.75
mark)
• Specify the requirements using user stories. Ensure you identify each of the users and provide at
least 2 user stories for each user. Write user stories (As a <user>, I want <….>, [so that …..]. (1
mark)
http://ilearn.mq.edu.au/pluginfile.php/4455861/mod_resource/content/8/254_Assignment1-2017.doc 8/4/17, 9D03 pm
Page 1 of 5
Task 2: System engineering (high-level) design and context diagram (2.5 marks):
• Draw a Context diagram (level 0 Data Flow Diagram) which depicts data flows, the system scope
and entities. (1 page) (1 mark)
• Outline the system you envisage (that is, how will the software relate to other parts of the system
such as people, hardware, processes/work activities and data) and other systems in the
organisation. Diagram/s may help depict your ideas. What level of management and decision-
making is related to this system? (1 page) (1.5 mark)
UML Modelling (10 marks)
Use any UML CASE tool to draw all diagrams (in practicals we have PowerDesigner and Enterprise
Architect).
Hand written diagrams will receive a penalty of up to 2 marks.
HINT: For all documents/models in this deliverable remember you are modelling the problem – not the solution.
So, for example, on your use case description don’t say “user clicks the submit button” because you don’t know yet
that there is a submit button – that is part of the solution. Instead say “the user submits the order/request”.
Note: A full model requires a use case description and sequence diagram for every use case which will
elaborate the full functionality of the system and also reveal all the classes/objects and the public methods
needed to achieve this functionality. However, as this is an individual assignment, you will just create one
sequence diagram, one use case description and one state diagram.
Task 3: (2 marks) Use Case Diagram: Update your use case diagram according to feedback and your
revised understanding. While you are not asked to write all use case descriptions, think about what steps
are included in each one so you can identify overlaps, missing use cases or relationships between them.
As a rule of thumb – if the description of a use case is very short (e.g. one or two steps only) or very
similar to another use case, then consider combining the use cases and describing the alternate courses of
action within that use case. Structure the use cases using <<includes>> to show reused/common
functionality in more than one use case and the generalization arrow to show hierarchical relationships
where a higher level use case can be broken into more than one lower level detailed use case (e.g.
Maintain Customer <<includes>> Create Customer; Delete Customer, Update Customer. For exceptions
or functionality not used in the “normal course of events” use the <<extends>> relationship. Remember
Use Cases concern the functional view from the users’ point of view – not the developers. Include system
boundary.
Task 4: (1.0 mark) Use Case Description: Choose one use case and provide a corresponding textual
description using the template provided with this specification. Sub-use cases can be combined in the one
use case as long as the differences can be sensibly articulated.
Task 5: (0.5 mark) Linking Use Cases and User Stories: List each use case and indicate which user
story/ies they cover. Use cases and user stories specify the functionality needed by the user, so they
should map.
Task 6: (2 marks) Analysis Class Diagram: At the analysis stage you would normally not have considered
Boundary/Presentation/View, Control/Database/Foundation classes or other classes needed for the design
and implementation phases. Thus I only expect to see Entity classes. These are classes that stakeholders,
especially system users, would recognise as concepts which exist in their domain e.g. patients, beds,
nurses, doctors, medication, etc in the Hospital Domain. Tip: Make sure any classes or methods on your
sequence and state diagrams have been included on the class diagram.
Full method signatures (e.g. with return types and parameters) do not need to be given on the analysis
class diagram, but you can specify them now if you chose. Do not show traversals. The diagram must
include: classes, attributes, labeled associations (or associations with roles), inheritance and/or
aggregation (if applicable), multiplicities.
Task 7: (2.5 marks) Sequence Diagram: Draw a sequence diagram for the same use case you chose for
your Use Case Description. Tip: The objects and messages must be shown on the Class Diagram.
http://ilearn.mq.edu.au/pluginfile.php/4455861/mod_resource/content/8/254_Assignment1-2017.doc 8/4/17, 9D03 pm
Page 2 of 5
Task 8: (2 marks) State Diagram: A state diagram shows the life cycle of an object and thus all objects
can be represented in a State Diagram. However, many objects have boring lives and it is not necessary to
explicitly model them. For this deliverable consider each class on your class diagram and choose one
objects (i.e. instances of a class) with interesting states and a draw a state diagram for those objects in
Enterprise Architect. Tip: The object and messages must be shown on the Class Diagram.
Task 9: List of Assumptions (max. 1 page): This will help the marker/client understand why you have
done certain things and clear up any misunderstandings. Please review the assumptions before
submission. A poor assumption (one clearly contrary to the information you have been provided and
common sense) will not be a valid reason for poor requirements specification/analysis/design models.
(-0.25 for non-submission)
ITEC654 students ONLY. (total marks will be scaled out of 15):
ITEC654 students ONLY Task 10: Develop a Software Requirements Specification (3 marks) (4-10
pages): This should follow the IEEE standard below:
1 Introduction (1 mark) (1-3 pages)
1.1 Purpose of the requirements document
1.2 Scope of the product (include your context diagram here)
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview of the remainder of the document
2 Overall Description (1 mark) (1-3 pages)
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 User Documentation
3 Requirements (3 marks) (1.5- 5 pages)
3.1 Functional Requirements
3.2 Performance Requirements
3.3 Design Requirements
3.4 Other Non-functional Requirements
3.5 Future Requirements
You may want to look at, but please do not pay for the IEEE standard (The most widely known
requirements document standard is IEEE/ANSI 830-1998 (IEEE, 1998). You can modify the template
provided on iLearn or other similar one which follows the standard.
ITEC654 students ONLY. Task 11 Requirements Review (1-2 pages) (1 mark)
Comment on whether your SRS document passes the Requirements Review at
http://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html.
ITEC654 students ONLY. Task 12: Activity Diagram (2 marks): An activity diagram can be used to
model business processes, decision processes, business rules or logic. Identify and design one or two
business processes or decisions needed by MURMERS and model them as an activity diagram. Include a
written description of the process/rules that is consistent with your diagram.
What to submit
Create a single Word document that includes your answers in task number order. Make sure you label
each diagram/task. Submit you single .doc/.docx or .pdf file electronically on iLearn.
Marking Sheet Student Name_______________ Number
Requirements
Suitable requirements gathering techniques identified and
described
/0.5
Choice justified /0.25
Describe the requirements elicitation, specification and validation
you have actually done to come up with the SRS. What data did
you collect and how did you use it?
/0.75
http://ilearn.mq.edu.au/pluginfile.php/4455861/mod_resource/content/8/254_Assignment1-2017.doc 8/4/17, 9D03 pm
Page 3 of 5
Correct user story structure (As a <user>, I want <….>, [so that
…..].
/0.25
ISYS254 – Applications Modelling and Development 代写
Reasonable users /0.25
Reasonable features /0.25
Covers requirements /0.25
Flows correctly labelled /0.25
Valid entities /0.25
Correct notation /0.25
Covers/correct scope /0.25
Identifies all parts of the system (people, hardware, software, data) /0.5
Describes/depicts processes and activities that link the parts /0.75
Management level identified and described. /0.25
TOTAL REQUIREMENTS /5.00
UML/drawing tool used
Modelling
USE CASE DIAGRAM
Covered main use cases /0.5
Covered actors /0.25
Correct includes/extends/generalisation /0.35
System Border /0.15
Correct use of diagram /0.75
/2.0
USE CASE DESCRIPTIONS
Use case on diagram /0.25
Clear format /0.25
Reasonable description/steps /0.25
Pre/post conditions, exception, triggers /0.25
/1.00
LINKING USE CASES & USER STORIES
Covers all user stories/use cases /0.25
Actors match users /0.10
Naming matches Use Case Diagram and User Stories /0.15
/0.50
Analysis CLASS DIAGRAM
Covered classes/functionality /0.25
Reasonable classes /0.25
Reasonable attributes /0.25
Reasonable methods /0.25
Reasonable assoc/role /0.25
Reasonable multiplicity/visibility /0.25
Inheritance/Composition correctly used /0.50
/2.00
SEQUENCE DIAGRAMS
Use case on diagram /0.5
Sensible collaborations /0.5
Objects correspond to classes /0.5
Operations/assoc. found on class diagram /0.5
Shows logic/conditions/branching/alternatives /0.5
/2.5
STATE DIAGRAM
Correct use of diagram(object on class diagram) /0.5
Operations appear on class/sequence diagrams /0.5
http://ilearn.mq.edu.au/pluginfile.php/4455861/mod_resource/content/8/254_Assignment1-2017.doc 8/4/17, 9D03 pm
Page 4 of 5
Reasonable states /0.5
Reasonable events/actions /0.5
/2.0
Assumptions – Penalty -0.25 /
TOTAL Modelling /10.00
Grand Total /15.00
ITEC654 Only
SRS
Purpose/Project Scope /0.25
Definitions/References/Overview /0.15
Product Perspective/Features /0.20
User Classes and Characteristics /0.5
Operating Environment/User Documentation /0.20
Functional Requirements (FR)“The system shall …” /0.20
FR Uniquely identified /0.10
FR Organized/structured/grouped /0.10
FR Covers functionality /0.20
NonFR (security, performance, access, etc) /0.50
Design/Implementation Req (platform,language, etc) /0.20
Usability Requirements (ease of use, training, etc) /0.20
Follows Format Specified/Well-presented /0.25
TOTAL SRS /3
ACTIVITY DIAGRAM
Correct use of diagram (shows flow/logic/processes/activities) /1.0
Reasonable activities, decision points, conditions /0.5
Description of process /0.5
Total Activity /2.0
REQUIREMENTS REVIEW
Covers most review criteria /0.50
Reasonable analysis /0.50
Total Review /2.0
TOTAL /15.00
ISYS254/2011
Page 5 of 6
http://ilearn.mq.edu.au/pluginfile.php/4455861/mod_resource/content/8/254_Assignment1-2017.doc 8/4/17, 9D03 pm
Page 5 of 5
ISYS254 – Applications Modelling and Development 代写
