Systems Analysis Assignment -
Related learning outcomes from the unit outline:
- Demonstrate evidence of the knowledge set and skill set required by the systems analyst.
- Apply structured techniques to the analysis of current systems and modelling of future systems.
Part 1 - Specifying business rules
Background: The objective of this tutorial is to provide you with practice in defining business rules. While the elaborated use case extended the description of the use case, it still remains unstructured i.e no clear inclusion of states, state changes, triggers etc. The business rules diagram that is then drawn to accompany the elaborated use case ensures that all relevant states, event, conditions and signals associated with a business rule are captured.
Task: For the add vessel and modify visit elaborated use cases provided, create business rules diagrams. For each work through the following stages:
1. What is the trigger?
2. What messages are generated?
3. What state changes occur?
4. What conditions are tested?
5. Of those conditions which can be checked by states?
6. What events can take place?
7. Connect up the constructs
Note: It is possible to follow a different order to achieve the same result e.g. the state changes could be identified first, then the events that allow the state transition could be added.
Part 2 - Evaluating a Use Case Script
Background: Use Case diagrams express the functions of a system in an abstract, readable way. Use Cases provide the process step detail to explain exactly how a use case succeeds. One way to learn about writing good use cases is to analyse poor ones.
Tasks:
1. Split yourselves into groups of four. Examine the excerpts from the following use cases.
2. Find the errors in the interactions. Re-write as necessary.
3. Discuss with your tutor. Explain your reasoning.
Part 3 -Functional and non-functional requirements
Background: Finding or eliciting the functional (FRs) and non-functional requirements (NFRs) of a system is a critical skill for a systems analyst. For each of the following items, decide if each is a FR or NFR by seeing if it conforms to the definitions given in the lecture (a FR is what is system is supposed to do whilst an NFR is how to do it or a system constraint).
Tasks:
1. Split yourselves into groups of four. Decide if the following items are functional requirements, non-functional requirements or something else then provide reasons for your choice.
2. Discuss if the requirements are well-specified or not.
3. Re-write as necessary, using the following popular format: 1) the user; 2) the capability; 3) the object; and 4) the qualifier. For example: The warehouse manager (user) must be able to create (capability) the incoming stock records (object) anytime within standard business hours (qualifier).
a. The system shall allow users to see all of their invoices for the past 30 days.
b. The system must authenticate users.
c. The system must have an easy to use user interface.
d. The database will be MySQL.
e. All code must be stored in an SVN repository.
f. The system shall charge users' credit cards for purchases.
g. The system shall store user information, specifically name, DOB and address, in an Oracle database.
h. The system shall process all mouse clicks very fast to ensure that users do not have to wait.
i. The system must encode all transactions with 1024 bit RSA keys.
j. The system shall debit a user's account upon withdrawal of funds.
Part 4 - Logical relational data model and Data model navigation
Background: The objective of this tutorial is to provide you with practice in designing a logical relational data model and then confirming its correctness using data model navigation. The task involves reviewing the conceptual data model for the PPA case study and then converting it using the rules described in the lecture into a logical relational data model. It is recommended you do this task in your team to pool your resources.
Tasks:
1. Draw the logical relational data model.
2. Confirm the logical relational data model by conducting data model navigation on:
a. the portbill
b. the invoice
Part 5 - Web page design and Website navigation
Background: The objective of this tutorial is to provide you with practice in designing web pages for a website and in designing a navigation map. The task involves building web pages that make for clear ease of use and user-friendliness throughout. It is recommended you do this task in your team to pool your resources.
Tasks:
Draw at least 4 web pages from the PPA case study starting from the home page.
Draw a navigation map for as much as possible of the whole system.
Part 6 - The Data dictionary
Background: The objective of this tutorial is to provide you with practice in creating the data dictionary. While the tasks can be done individually, there is no reason why you cannot use the expertise within your group to assist you or indeed in checking that your work is correct. In any case, once you have completed this task, your group is able to complete the task in the first assignment where the data dictionary is one of the deliverables.
Task: Prepare elementary and composite data dictionary definitions for the PPA case study.
Summary of tasks:
1. Create composite data dictionary definitions for the invoice and portbill.
2. Create elementary data dictionary definitions for all data items in both of these documents.
Part 7 - Drawing a Use Case Diagram
Background: Use Case diagrams are one of the four core UML diagrams. Use Case diagrams express the functions of a system in an abstract, readable way as well as specifying the actors involved in the use cases.
Tasks:
1. Split yourselves into groups of four. Read the following text and determine the requirements. List any assumptions you make.
2. Using pencil and paper draw a draft use case diagram of the system, using <> and <> stereotypes as appropriate.
3. Discuss your diagram with your tutor. Explain your assumptions. If you have time, gain practice with Visio by re-drawing your draft diagram in Visio. The software is provided to you free and can be found by searching the ECU website for MSDNAA (msdnaa.scss.ecu.edu.au).
The system to be developed is a GUI that allows a passenger to purchase a train ticket. Before boarding a train, a passenger must have a valid ticket. At the ticket machine, a potential passenger can select the number of zones s/he wishes to travel. The passenger can insert cash and/or coins to at least the value of the journey. The machine returns the ticket and any change, unless the ticket machine is out of change. A passenger can cancel a transaction at any time prior to a ticket being issued. If there is no passenger input after 30 seconds, the ticket machine cancels the transaction. If a ticket machine is out of order it will not accept input. A potential passenger can purchase a single journey ticket, a return ticket or a multi-rider ticket (which is an advance purchase of the equivalent of ten tickets for the same number of zones that carries a 10% discount).
Attachment:- Assignment Files.rar