.

ITECH2002 Systems Modelling

    ITECH2002 Systems Modelling
    School of Engineering and Information Technology
    Assignment 1
    Federation University Australia
    

Assignment 1 – System Requirements, Use Cases and Domain and Use Case Modelling

Overview

The purpose of the assignment is to provide students with the opportunity to apply knowledge and skills developed during the semester with particular reference to:

  1. How to model a system using familiar tools;
  2. How to document functional requirements using techniques widely used in the IT industry including use case texts/descriptions, user stories, use case diagrams and classNamediagrams; and
  3. How different stakeholders contribute to the definition of requirements.

Students complete the assignment in groups of three.

As suggested in your text, Systems Analysis and Design in a Changing World (Satzinger, Jackson & Burd, 2016), you live in an age of ubiquitous computing. As IT students you should understand how to implement best practices for the analysis and design of information systems. This Course and this assignment in particular, concentrates on systems analysis, the activities of systems development that enable a person to understand and specify what a system is supposed to accomplish (Satzinger, Jackson & Burd 2016).

In this assignment you will work in a group to analyze and specify some of the requirements of a work management system for G!gM@n@g3rs Pty. Ltd. Your analysis and specification will use components of the Unified Modelling Language (UML) and these need to be presented according to the notation specified in your text. You are expected to read the case study provided and determine and describe a sufficient number of user stories and use cases and provide a sufficient number of use case and classNamediagrams to describe the system. You are also expected to provide some overarching documentation such as pictorial mockup of the system, stakeholder chart, organization chart and vision and mission statements for the company and system. The case study is deliberately complex and detailed so that you can understand and experience some of the complexities and difficulties actually encountered in analysis.

Learning Outcomes Assessed

The following course learning outcomes are assessed by completing this assessment:

K1 Explain how models are used to assist in analysing and modifying existing business systems;

K2 Define various roles involved in the processes of system analysis;

K3 Describe techniques used to gather required information for system analysis;

K4 Explain the various stages of the system development life cycle;

S1 Identify appropriate models for given scenarios;

S2 Perform Object Oriented Analysis to construct various object models used to communicate the scope and requirements of the project.

A1 Write integrated reports, using appropriate models, providing detailed analysis of given textual scenarios

This is a group assignment. Groups must contain three students.

Requirements

Demonstrate an understanding of particular concepts covered in lectures, tutorials, laboratories and reading to provide the details requested. This may require further reading and research beyond the material discussed in className.

Assessment Details

This assignment will be assessed by your lecturer/tutor. The assignment has both group work and individual work components. One submission is required for the group and an individual submission is required from each student

for their individual work. A student’s mark will be made up of the group component mark and their individual mark.

Both the group submission and individual submissions must follow the format of a professional report. Further information is given in the Marking Criteria section of this document.

Background – G!gM@n@g3rs Pty. Ltd. Information Technology Gig Work Management System (ITGWMS)

As a team of Software Engineering consultants, your task is to develop reports containing an organizational overview, system requirements and analysis models for the Information Technology Gig Work Management System (ITGWMS) for G!gM@n@g3rs Pty. Ltd. The ITGWMS is a new computerized system to be developed to support the business operations of G!gM@n@g3rs. G!gM@n@g3rs currently operates in Ballarat and Melbourne, Victoria. They have plans to increase their footprint in those cities and also expand into other states e.g. in the next six months they plan to start operations in Sydney and Brisbane. G!gM@n@g3rs is run by two friends, Sanjit Singh and Eric Robinson. They have been friends since primary school and after completing university degrees in Commerce and Marketing respectively they worked professionally in different industries including IT, Communications, Food, Agriculture and Retail and Hospitality. Now after 7 years of working for others they want to gain some independence and satisfy their entrepreneurial spirits by pursuing fulltime the gig work management business they have been running on a part-time basis.

At the moment they have a disorganized business model that has grown without much planning. Their business has a number of operations including “hub provision”, “hub access” and “hub management”. Further details are provided below about these areas. Currently, these operations are handled by a combination of technology and manual means. For example the “hub access” operation is handled by a website (created by using WordPress) and developed by Sanjit. Sanjit and Eric are able to download information in csv format and load into MS Excel to examine how operations are going. They often decide to send emails from outside the application to follow up users. For the “hub management” operations they use Slack and Trello to communicate about their management and demonstrate/track mentoring/consulting by technical support/outsiders. At the same time they have manual mechanisms for dealing with the contracting of those mentors.

They realize that they need to become more sophisticated about how they operate their business and part of this sophistication involves streamlining and developing an integrated enterprise system so that they will be able to achieve enterprise control of the management of their business and operations. They use their accountant, Clare Accent and a former marketing lecturer, Professor Martin Mason as consultant advisers and are in the process of hiring managers for each of their operational areas. They dream that one day their business will be considered to be the first choice in the IT Gig management space in the world. So every day they want to strive to provide customer focused, holistic and quality IT Gig management services. If the ITGWMS is properly understood, designed and implemented G!gM@n@g3rs should be able to operate a seamless technology suite that satisfies the provision of Gig Management to world’s best practice standard.

You are expected to use the understanding of what happens in the current business and its systems and any other information (all provided below) to come up with an analysis that will support G!gM@n@g3rs’ understanding of their current operations/future requirements.

Specifically, your job as consultants is to:

  • perform an appropriate analysis;
  • elicit/collect the requirements; and
  • include provision of models to provide an integrated solution to handle all of G!gM@n@g3rs Gig Work Management needs.

G!gM@n@g3rs is also expecting some meaningful graphical and diagrammatic additions to your analysis including:

  • a pictorial mockup of the system and its operations;
  • a stakeholder analysis diagram;
  • an organizational chart of senior management and the divisions you have identified;
  • vision and mission statements for the company;
  • vision statement for the project.

(Naturally a system of this size would be quite complicated both from a software and hardware perspective, so what follows is an attempt to simplify and focus the reader on the possible systems/sub-systems to define in the analysis).

As part of your investigation, you conduct interviews, distribute and collect questionnaires, observe and document business processes and collect other information from customers, contractors, users and management.

To make things a little easier to understand, a description of current manual and existing processes is not given; what follows is a description of what the system should do.

Hub Provision

Hub Provision is the identification, rental, fit out and marketing of Hub services and infrastructure. G!gM@n@g3rs does not own any premises and relies on long term leases of appropriate buildings. They have a record of all the buildings they lease with the address, name of the building, space occupied, floors, capacity, types and descriptions of facilities ( lighting, heating/cooling, desks, chairs, devices (desktop, laptop, tablet, mobile), networks, internet connectivity and type, conference rooms, meeting rooms, dining/meal room, toilets, gymnasium, car parks) and comments. They want to be able to add other facilities and their characteristics to the sub-system so that they can best describe the hub.

Sanjit and Eric have a list of real estate agents that they use to source properties. If they lease a property from that real estate agent they record that detail. They record any of their interactions with the real estate agent and also score the estate agent based on usefulness. If they are looking for a new property for example they first access their premium agents, then their professional agents, then they might try their average agents. These agents try to understand the requirements and suggest properties. After face to face meetings and site visits, Sanjit and Eric weigh up the properties. If they choose one they agree the lease terms and conditions, agree on a move in date and record the lease and its details in the sub-system. The recording of the lease triggers the generation of a calendar/set of lease payment dates that the sub-system will then use to generate automatic payments to the real estate agent (as collector of payments for the owner).

At the move in date, they create a basic building record and assign a status of “fit-out” to it. They assess the state of the building and record a fit-out record for the building. The fit out record details the facilities required by the building and the expected payment/completion dates for various stages of the fit out. They then send out fit-out requests for quotes (including due dates to return the quote) to their register of preferred fit-out specialists (they maintain a record (name, address, phone, payment details, workforce size, specializations) of those that have performed work for them in the past and sometimes add new specialists. As each quote is received they register the quote and its details in the sub-system with a status of “offered” and link it to the fit-out record. When the due date for the requests for quotes is reached, Sanjit and Eric evaluate each of the quotes, mainly on price, progress payment/completion and expertise and award the job to their preferred specialist. Within the sub-system the awarding of the quote means changing the quote status to “successful” on the preferred specialist’s quotation and “unsuccessful” on the others. The sub-system also then generates a suggested calendar of progress payments for the fit-out. This is a calendar with two sets of records – the payment/completion date from the fit-out record and the payment/completion date from the quotation. Mostly these are the same but in cases where they are different it is because Sanjit and Eric have accepted that difference when selecting the specialist and therefore pay according to the quotation date. The subsystem does not automatically pay at this date though; Sanjit and Eric must complete a favorable inspection record in the sub-system before the sub-system will generate the progress payment and transfer the funds. On final inspection and payment, Sanjit and Eric update the fit-out record with the actual fit out that occurred e.g. if 14 desks were requested but 13 were supplied then 13 is recorded against the actual figures for the fit-out. Once this is done, they ask the sub-system to update the building record with the fit-out actuals and upon completion, update the building record with a status of “operational”. There are a number of reporting screens available to assist Sanjit and Eric with assessing agents, quotations, fit-outs and payments for same. For example in one screen they can ask the sub-system to report on the history of their agents in terms of successful leases and changes in status/churn. With respect to fit out specialists there is a screen to assess the abilities of the specialists in meeting their quotation timelines, actual fit-out compared with proposed and inconsistencies between request and quotation payments.

Once the building is operational, it may be advertised on the G!gM@n@g3rs website. The website includes information about all G!gM@n@g3rs buildings available for space rental. The description of the building is largely taken from the information within the building record, but a screen is available to format and massage the presentation of the detail provided to the website. A feature of the Hub Access sub-system used from within the Hub Provision sub-system is the number of spaces available at the chosen building. A potential or existing member/gigster can query the number of spaces available for a location based on a set of dates. The returned calendar displays a colour coded calendar and the user can hover over any day and note the space available and any car spaces also available.

G!gM@n@g3rs also engage marketing agencies (they have a preferred list) to promote their business and they often ask them to quote for jobs to do this. This is particularly so with newly created hubs. They go through a similar process to that described for fitting out of a hub i.e. marketing record, request for quotes (with, for example, specifications of the purpose, the preferred type of campaign, purpose, dates, prices and frequency), registering of quotes, selection of quote and calendar of progress payments. Sometimes they choose not to proceed with the marketing campaign. If they proceed with a campaign, they also have a facility for adding comments to the marketing record as the campaign progresses. These comments are usually based on an assessment of statistics obtained from analyses available in the Hub Access sub-system.

Hub Access

Hub Access is the access and use of facilities for individuals to explore IT development ideas. G!gM@n@g3rs provides cheap rental space to qualifying individuals to allow them to develop their IT ideas. Only individuals carrying out IT development are permitted to use this service. That is, no businesses are permitted to operate from the rental space. When an individual uses these sites they pay a lower rent than they would for sites in the same vicinity and they do not need to worry about infrastructure or support. G!gM@n@g3rs and the individual also sign a contract that allows the individual to retain the intellectual property of their idea but agree to remit a percentage of their future revenue for a set period.

The management of these sites – provision, fitting out, operation - is handled by the Hub Provision sub-system and

Hub Management sub-system respectively but there is a strong interrelationship between all sub-systems. In the Hub Access sub-system, an individual needs to first sign-up to the sub-system using an email address and password. They must then provide their member (gigster) details. They must provide details of their profile - name, address (street, city, postcode, state and country) phone number(s), email notification details – notification flag (on/off) and frequency for - nomination, awarding of place, news and announcements from G!gM@n@g3rs, marketing emails, G!gM@n@g3rs deals, monthly newsletter and gigster contact requests. To be a member they must also enter their payment details – bank account, credit card or paypal details. Once they are have registered and saved their details, they are in a state of “nominated” and “unchecked” and are placed in an awaiting authorisation queue.. Every five minutes a daemon runs to pick up entries in the queue and runs a two-step operation – checks the name and address details against external ABN/corporate records and validates the payment option by placing a hold on a minimal amount on the nominated payment details. Sanjit or Eric periodically check the awaiting authorization queue and authorize/reject the nomination. They largely do this based on a consideration of the checks. Sometimes they don’t update the entry but instead write a comment requesting further information and this generates an email to the gigster. The gigster may check on their nomination status at any time and/or receive an email about their nomination status based on the setup of notification mentioned previously.

When a gigster is authorized, they may submit one or more gig proposals. They may submit a new proposal at any time. In their proposal they must describe their gig proposal with a type, description, technology used, intended market/s, potential uptake and plan/timeline. When they save the proposal it is given a status of “intended”, parsed for likely success based on an proprietary algorithm and updated with a success value ((likely, neutral, unlikely) and then placed in a proposal awaiting authorization queue. Sanjit or Eric periodically check the proposal awaiting authorization queue and authorize/reject the proposal. If the proposal is authorized its status is updated to “approved”, the proposal includes an expected G!gM@n@g3rs revenue rate and time period (both manually keyed in by Sanjit or Eric) and the gigster is sent a contract that they must sign and return. The contract states the terms of the rental from a legal perspective and also contains a clause regarding the retention of intellectual property by the individual and the percentage rate of future revenue and time period of same that G!gM@n@g3rs is entitled to. If the individual returns the signed contract, this is registered in the system by updating the contract record and by changing the status of the proposal to “contracted”.

Once a gigster has a contracted proposal they may make one or more bookings against that proposal. A gigster has one booking record per place booked. The booking relates to one contracted proposal only. When they make a booking they specify what level of support they want. For each level of support a gigster pays a different amount and receives different levels of service. At the moment they have bronze, silver or gold support levels but would like the flexibility to change/add to these in terms of altering what is offered under each level and also by offering other levels. At the moment for the bronze level they receive office space (one hot desk and chair) and infrastructure support (lighting, heating/cooling, desktop/laptop, network and internet connectivity). For the silver level they receive the bronze services plus meals, access to gig talks and technical assistance of up to four hours/week. For gold level they receive bronze and silver services plus up to four hours/week of direct mentoring from a gig coach, access to database of reference materials as well as discounted fees based on length of continuous gig rental. A gigster can upgrade or downgrade their level of support for a booking at any time but they can only have one change of level per week for any of their bookings.

When they book a space or spaces they first select the starting date for their booking. They are then presented with a list of locations that have available spaces. They choose the location and then they are presented with the spaces available. They choose the space, specify the length of time or date-to (the minimum booking time is one week and the maximum three months) and the level of support required. When they have confirmed their selection the subsystem calculates and displays the charge (the charge is based on a set charge per location and booking together with level of membership and any discounts applicable) and then asks for confirmation. The sub-system tries to save the booking including charging the fee and returns a notification to the gigster. This may be a message that the booking was successful or that it was not successful due to not being able to finance the booking or spaces no longer being available. If they successfully book, they receive a QR code and a bar code in the notification and the booking is marked as “active”. These codes are associated with the one booking. They may also request a car parking space if one is available. They must use the QR code or bar code to do this and must specify the dates (these must be within the time frame for the booking). The sub-system then calculates the parking charge (These are periodically set by Sanjit and Eric based on building location, number of spots and demand) and the gigster is asked to proceed. If they proceed an attempt is made to charge the amount and if successful the car park is reserved.

A gigster cannot enter the location they have booked without using The QR code or bar code they have been assigned (there is a system connected device reader at the entrance/car park entrance to the location). Once they have entered the location, they find a desk/pod and begin work. Normally this means they will need to connect to the location’s network. They can do this either by the devices available or by using their own device. In either case, to connect to the network they need again to identify their QR or bar code and follow the two step authentication by keying in the security code sent to their mobile/nominated device. The sub-system records their time in the location based on the entry and connection to the network and the closure/shut down of that network connection and the exit from the location (they need to present their QR or bar code to a reader inside the entrance to exit the building).

A gigster can make another booking at the same or different location for another contracted proposal but the booking will not be permitted if it overlaps an existing booking. A booking can be shortened, to no less than one week. In such a case, the gigster will receive a refund or select to add the amount to an existing booking at the rate the added to booking was charged at. A gigster can browse their usage history of a location and/or booking. An administrator can browse all gigster location and booking history. A gigster can also browse their payment and contracted proposals history and an administrator can do this on a location, gigster, payment value or proposal type basis. It is also possible to obtain comparative statistical analyses of hub performance i.e. bookings, actual usage of facilities in terms of time and infrastructure to assist with marketing program evaluation. This capability is only available to Sanjit and Eric.

If the gigster has a level of service that provides for extra support e.g. gig talks, technical assistance and mentoring, then they can browse the available calendars for those services and book a time. With meals however, the gigster may make a request at any time and the meal will be delivered within one hour (the notification and delivery of meals is handled through the Hub Management sub-system with the gigster able to rate the meal and other details such as delivery time, after the delivery has occurred). When any of the other services that require face to face contact occur, the provider must record the gigster details (identify QR or bar code) and describe what happened and the gigster can later rate the contact and usefulness of advice. The gigster can also at any time interact with others at the location, but must attend (and record this fact) one daily stand-up per week to describe their activities. At an administration level there is a capacity to obtain network access information for a specified time period. Information reported includes gigster, IP addresses, names, sizes and frequencies.

There is also an inspection suggestions screen where an administrator specifies a set of parameters such as IP addresses, size, frequency, inspection record and the sub-system checks the logs and suggests time and gigster/s to conduct an inspection against. When an inspection occurs the inspector queries the gigster and records their interaction. The inspector then records either a positive or negative status on the inspection interaction. If it is a positive interaction, the inspector is authorized to credit the time spent in discussions with any gigster back to the gigster at the rate for the booking/proposal they are working on. If the inspection is a negative one, the inspector must record that status against the inspection record and warn the gigster that any further breaches within a specified time period (at the moment 1 month) means they will be removed from the premises. If the breach is a second breach, the inspector must escort the gigster from the premises, disable the QR and bar code and update the booking status to “suspended”.

Hub Management

Hub Management is the management of all services for each operating hub. As previously described, an individual with administrator rights can use the Hub Access sub-system to query booking, usage and payment history. Under Hub Management an administrator facilitates the operation of the hub. They do this by taking care of all the infrastructure, personnel and financial issues associated with the hub. The Hub Management sub-system records work tickets. These work tickets are either created automatically or manually. An example of an automatic ticket being created is when a device such as a reader or an appliance such as a central heating system is malfunctioning. Sensors on the devices/appliances periodically transmit their state to the sub-system. If the sub-system detects a malfunction, then a ticket is raised.

An example of a manually created ticket is when the administrator receives a query about a fault with a device or appliance (gigsters are not able to raise these tickets other than through communication with hub administrators). A

gigster for example may complain about the speed of a provided laptop or complain about the temperature near a desk they are using. When a work ticket is created it is given a state of “open” and also given a type and level. That type and level have an associated alert email and mobile phone notification list. A work ticket must be assigned to someone so that it is “resolved”. Usually someone on the alert/notification list assigns themselves to the ticket (the state is updated to “assigned”). In the case of a manually raised ticket the administrator may assign someone. The assignee attends to the issue, updates the progress along the way (with comments) and hopefully/eventually corrects the issue (stating the resolution) and closes (“resolves”) the ticket. Trying to resolve the issue might include obtaining outside help. In such a case, the administrator can select from a list of registered suppliers/servicers stored in the sub-system and call them to discuss the nature of the problem and their availability to fix it. When they have settled on who they would like to use, they can generate a work specification for them which is automatically electronically sent when it has been completed. The work specification contains the location and nature of the work, G!gM@n@g3rs contact details, the expected charge out rates and level of urgency. When the supplier/servicer turns up and carries out the work, the administrator records the work details, resolution and closes the ticket.

Sometimes administrators need to change the state to “escalated”. In such a case the level is upgraded and an email/mobile phone text is sent to the corresponding list recipients. There is a work ticket query screen that allows an administrator to check on work tickets based on parameters such as date and time, type, level and state.

In addition to the work ticket practices, the hub must provide the personnel and services that have been advertised for the hub and must also provide a list of registered suppliers/services. All personnel and services are managed in the sub-system through a request for service, quotation, service contract, operation work flow. In all cases, the subsystem keeps registers of preferred suppliers/service providers. The registered suppliers/servicers for assisting with work tickets has already been described.

In the case of meals at a hub, there is a preferred list of meal providers and these include cafes/restaurants in the vicinity of the hub as well as general food delivery services. Each hub has one food supplier for each day. A food supplier may be the selected supplier for more than one day. When a new hub is being created Sanjit and Eric attend local cafes/restaurants and discuss opportunities with the owners. If they feel they might be a preferred café/restaurant then they register them in the sub-system for that hub. They also authorize any other delivery organisations that they have had good experiences with either in a personal capacity or at other hubs. They then select the preferred food suppliers and prepare a request for quote stating the quotation return date, types of food required, prices, hours of availability, delivery requirements and supply period. They register each of the returned quotation details and when the returned date has passed, evaluate the quotations and select the appropriate supplier for each day/days. They then sign a contract and agree on payment terms.

When a gigster requests food, this is registered in the Hub Access sub-system with a notification to the administrator of the hub. The administrator assesses the order and if acceptable, generates an order to the food supplier. If unacceptable they send an email to the gigster suggesting changes and the gigster can make those changes or let the order lapse. The delivery of the food must occur/be registered by the administrator or G!gM@n@g3rs is not responsible for payment. The administrator then physically delivers the food to the meal room and notifies the gigster. The food supplier/s are paid on a periodic basis based on their contract terms. Each evening, the Hub Management sub-system checks the contract terms and conditions, queries the food requests for fulfilled requests and generates payment transactions and an email alert to the Sanjit and Eric. Sanjit and Eric review the list of payment transactions and authorize those for payment. When authorized an actual payment is sent to the supplier’s bank account/payment facilities.

In the case of technical assistance or gig mentors, once again there are preferred suppliers for these personnel. These preferred suppliers have service contracts with agreed payment terms and conditions. G!gM@n@g3rs prefers to use personnel agencies to handle hiring and payment of personnel rather than handling them individually. This includes interviewing/verifying the capabilities of the individual. If G!gM@n@g3rs have a requirement for a technician or mentor they create a resource record for the hub and provide a request for service stating the requirement, skills required, experience levels, time period for availability and closure date. They send this request to their preferred suppliers. The preferred suppliers provide lists of applicants complete with details and rating. Sanjit and Eric choose a non-excluded applicant and assign their details to the resource record. The applicant is notified with an email containing details of the job, location, QR code and bar code. As already described, the Hub Access sub-system permits gigsters to comment on their interaction with the technicians and mentors. The Hub Management sub-system also permits an administrator to make general comments on the performance of those technicians and mentors. Nightly jobs run to evaluate the gigster and administrator comments and a list is provided that Sanjit and Eric then classify in terms of “nothing to worry about”, “temporarily unfavourable” (with time period) or “permanently excluded”.

Each evening, the Hub Management sub-system checks the contract terms and conditions – the personnel agencies are paid an amount made up of base amount for service access plus base amount for provision of employee plus amount to employee for being available plus any work carried out at the rate agreed (the sub-system checks for actual records of interactions with gigsters)) - and generates payment transactions and an email alert to the Sanjit and Eric. Sanjit and Eric review the list of payment transactions and authorize those for payment. When authorized an actual payment is sent to the supplier’s bank account/payment facilities.

Sanjit, Eric and the administrator of a hub have the ability to query the IT infrastructure, facilities and assistant resource loading at a particular hub based on the parameters of hub identifier, time period and grouping. For the IT infrastructure loading a screen is available to query the load on the network/servers and internet connectivity. The resulting display (available for printing in PDF format) shows the expected loading (based on the number of active users), actual loading and warning indicators where appropriate. For the facilities loading a screen is available to query the load on the facilities provided in the hub. The expected loading is again based on the number of active users and the actual loading is based on entry and exiting of the facilities within the hub based on infrared readers at the entrances. Finally for the resource loading, a display of the actual services requested (based on support level attached to bookings for the hub) against the actual provision of these services and the actual usage of those services is provided. These reports help with assessing the need for greater or reduced infrastructure, facilities and assistant resources for a hub.

Assessable Tasks/Requirements

This assignment has a group work and individual work components. We require only one report for the group and separate report submissions for individual work. As a group you are required to understand the ITGWMS requirements by analyzing the information provided, identify factors about the organization that are useful, model them and also break the ITGWMS into sub-systems. Each student in the group needs to select one identified subsystem (no two students in the same group may choose the same sub-system) and then model the requirements through the use of user stories, use case descriptions, use case diagrams and domain model diagrams. Students are to consolidate this information as a group and provide a group report and also submit their individual findings on their selected sub-system in a separate report. The following information is required in the group report:

  • Pictorial Model of the Organization (see Fig 2-1 of text for example)
  • High Level Organizational Chart (see Fig 2-5 of text for example)
  • Stakeholder Chart (see Fig 2-4 of text for example)
  • Organization (not system) Vision Statement
  • Organization Mission Statement
  • System Vision Statement
  • Consolidated Domain Model classNameDiagram (see chapter 4 of text for Domain Modelling)

The following work is to be completed by each student and submitted in an individual report:

  • Two User Stories complete with statement and acceptance criteria
  • A User Goal Table (see Fig 3-2 of text) for the two User Stories identified
  • Eight Use Case Descriptions (see Fig 3-9 of text for examples) (Only two report types Use cases are permitted and you cannot have all your Use Cases triggered by only one event type)
  • A Use Case Diagram of the ten use cases identified (see Fig 3-11 to 3-15 of your text for examples)
  • A Domain Model classNameDiagram for the selected sub-system to support the identified use cases

You may use drawing or modelling packages such as DrawIO, LucidChart or Enterprise Architect to create your model diagram but you must conform to the standards of the text.

.