Reference no: EM131002240

PART I Words: 3000 + use case diagram, context diagram, RMT (TASK 1 TO 7)

Macquarie University Library System (MULS)

Macquarie University has decided to set up its own library system, (MULS) for its members (employees and students). Each member will be identified using their OneID. Details are retrieved from HROnline and eStudent systems.
Library staff will manage the new system and will be able to search the book borrower's details, add, search and update book information, assist with borrowing and returning a book. For every book borrowed, a transaction gets created to record the details. A receipt is generated for every transaction and will hold the details of any fines for overdue books.
Members will be able to request for a book, borrow books (based on a limit set by their degree of study), return books, pay fines and check their book-borrowed status. An automatic alert message is sent out when the book is not returned by the due date. Staff can borrow up to 7 books whereas the number of books a student can borrow depends on 5 books. Staff also can make a special request for a book to be brought in from public libraries. Higher Degree students have the same borrowing rights as staff.
Books could be general books, magazines or reference books. They are identified using a ISBN number (for magazines, a mock number gets generated).
MULS V1.0 is primarily a standalone system, however, it will interface with HROnline (Human Resource Management/Payroll to check currency of staff account) and with eStudent to check which units a student is enrolled in.
As the business Analyst, you are being asked to identify, specify and model the system requirements and initial software design for MULS V1.0. You are being asked to provide a solution that uses object-oriented technology and which fits with the current corporate identity. Additionally, you will need to identify possible new features (requirements) for future versions of the software.

REQUIREMENTS: First Deliverable Due by Monday 21st March 5pm
10 Marks

Task 1: Requirements engineering (1/2-1 pages) (2 marks):
• Describe suitable techniques for gathering requirements (e.g. surveys, interviews, JAD, user stories, etc) 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 come up with the SRS. What data did you collect and how did you use it? (0.75 mark)
• Write 2 user stories (As a <user>, I want <....>, [so that .....]. (0.5 mark)

Task 2: System engineering (high-level) design and models (2 marks):
• Draw a Context diagram (level 0 Data Flow Diagram) which depicts data flows, the system scope and entities. (1 page) (1 mark)
• Draw a Use Case diagram. This is a graphic model showing the actors, the use cases and the relationships between them. (1 page) (1 mark)

Use any UML CASE tool to draw diagrams.

Task 3: Develop a Software Requirements Specification (5 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. Make sure your document passes the Requirements Review see https://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html

Task 4 (1 mark) Requirements Traceability Matrix (RTM): Set up an RTM with the following columns:
Requirement-ID (from SRS)
From Requirement-ID
To Requirement-ID
Type (Essential or Extensional)

The purpose of the RTM is to ensure that you have not forgotten any requirements in development of the system.
There should be one row for each requirement. "From Requirement" and "To Requirement" indicate dependencies between requirements and the direction. This is important in case you need to modify and trace a requirement. In "Type" you need to specify if the requirement is essential (i.e .mandatory) for the system or extensional (i.e. desirable/optional). Essential requirements will be part of version 1, extensional requirements will be considered for future versions of the software.

Task 5: 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 student ONLY. Task 6 Requirements and Systems Engineering (2-4 pages) (4 marks) (total marks will be scaled out of 10):

Describe and discuss techniques for gathering requirements. When are each appropriate? Provide examples (including questions or activities) of how each could be used for the current problem. (1-2 pages) (1.5 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-2 pages) (1.5 mark)

Comment on whether your document passes the Requirements Review at https://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html (0.5-1 page) (1 mark)

What to submit for Part I
Create a single Word document that includes your answers in the following order:
Task 1: Questions and your answers.
SRS (include context diagram in SRS section 1.2)
Use Case Diagram
RTM
Assumptions
ITEC654 students only: Task 6: Questions and answers.

(1) In the ISYS254 assignment box on the ground floor of building E6A submit a single printed document (preferably stapled rather than in a folder). The deliverable will be marked from this paper copy, and
(2) electronically on iLearn, submit a .zip file containing all documents and diagrams. This file is a backup in case of a missing paper copy.

Analysis and Modelling: Second Deliverable Due by Friday 8th April 9am
(15 Marks)

ANALYSIS MODELS
Based on the problem description and consistent with the SRS, create the following analysis diagrams which model the problem domain.

Use any UML CASE tool to draw all diagrams.

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, use case description and state diagram.

Task 1: (1.75 marks) Updated 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 2: (1.75 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 3: (4 mark) 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 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 4: (3 mark) 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.

Task 5: (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 6: (2 marks) Linking Class Diagram and Code: Review and run the Java code that has been created to date for this system. Make sure that your class diagram includes all of those classes. List differences between your class diagram and the code (e.g. different classes, methods, associations) and why your model is different (e.g. because of additional/other features you have included in your SRS).

Task 6: (0.5 mark) Updated Requirements Traceability Matrix (RTM): Set up an RTM with the following columns:
Requirement-ID (from SRS)
From Requirement-ID
To Requirement-ID
Type (Essential or Extensional)
Use Case/s
Classes
Build No

Update the RTM you previously submitted and add the additional columns. Under the headings Use Case and Classes list the names relevant to that requirement. Please include a Build Number which is the build of the system (ie compiling all the parts together into an executable) in which you think that functionality should be included. Builds are planned because you should not put everything into one final build. A build is like a version/release but usually smaller and designed for internal purposes rather than for the client. Since you are not doing any implementation just make a guess at what you think should be implemented in what order and combination.

Task 7: 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. Task 8: (6 marks) Activity Diagram and Future Enhancements: 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 MULS and model them as an activity diagram. Include a written description of the process/rules that is consistent with your diagram. (2.5 marks)

Provide an explanation of what changes need to be made to the design and code to support the future changes you suggested in PART I. 

What to submit for Part II

Create a single Word document that includes your answers in task number order. Make sure you label each diagram/task.

(1) In the ISYS254 assignment box on the ground floor of building E6A submit a single printed document (preferably stapled rather than in a folder). The deliverable will be marked from this paper copy, and
(2) electronically on iLearn, submit a .zip file containing all documents and diagrams. This file is a backup in case of a missing paper copy.