Assignment 1:
Macquarie University Library System:
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.
Task 1: Requirements engineering (1/2-1 pages):
1) 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).
2) 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?
3) Write 2 user stories (As a , I want <….>, [so that …..].
Task 2: System engineering (high-level) design and models:
1) Draw a Context diagram (level 0 Data Flow Diagram) which depicts data flows, the system scope and entities. (1 page)
2) Draw a Use Case diagram. This is a graphic model showing the actors, the use cases and the relationships between them. (1 page)
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-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-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 (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
Task 4 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.
Task 6 Requirements and Systems Engineering (2-4 pages)
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)
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)
Comment on whether your document passes the Requirements Review at https://www.SoftwareEngineering-9.com/Web/Requirements/Reviews.html (0.5-1 page)
Assignment 2: Analysis and Modelling
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.
Task 1: 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 <> 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 <> Create Customer; Delete Customer, Update Customer . For exceptions or functionality not used in the “normal course of events” use the <> relationship. Remember Use Cases concern the functional view from the users’ point of view – not the developers. Include system boundary.
Task 2: 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: 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: 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: 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: 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).