MT300 Unit 4 Systems Requirements Document Example

Course	MT300 Management of Information Systems
Unit	Unit 4
Paper type	Systems requirements document
Length	About 1,150 words, 7 pages double-spaced
Format	APA 7 student paper
School	Purdue University Global
Program	BS in Business Administration
Updated	October 2026

Free sample paper for MT300 Unit 4

Written So Two Vendors Quote the Same Thing: An MT300 Unit 4 Requirements Document for an Event Rental Company

[Student Name]

Purdue University Global

MT300: Management of Information Systems

Unit 4 Requirements Document

[Instructor Name]

[Date]

Larkfield Event Rentals and its requirements are composite; the methods and sources cited are real.

What this part is doingNaming the test the document must pass in the lead tells the reader how every requirement was written.

Introduction and Scope

This document defines what a replacement rental system must do, from the first availability question to the final invoice. Payroll, the public website and the phone system are outside its scope, and each is named so that no vendor prices them by assumption. Hofmann and Lehner (2001) found that projects with well-defined, stakeholder-checked requirements were more likely to succeed, and the ISO/IEC/IEEE 29148 standard (International Organization for Standardization, 2018) describes good requirements as necessary, unambiguous, verifiable and free of design detail. Every requirement here is written as a behavior, never as a product feature. Laudon and Laudon (2022) note that poorly specified requirements are one of the most common reasons systems fail to deliver their expected value, and the cost of fixing them rises the later they are found.

Current Process

1. A customer asks about dates and items by phone, email or web form (inventory rows 2-3).

2. Sales checks availability in the desktop package (row 1).

3. Sales sends a Word quote and records the deposit by card (rows 4, 10).

4. The warehouse prints a pick ticket the day before (row 5).

5. Crews deliver and collect, texting damage photos (rows 7-8).

6. The office invoices and reconciles deposits by hand (rows 9, 11).

Requirements

Priority is must, should or could. A must is anything the company could not run a June Saturday without.

Availability

AV-01 (must). The system shall show availability by item and date across all confirmed orders. Test: book 120 chairs for a date with 100 free; the system warns before saving.

AV-02 (must). The system shall apply turnaround rules by item type: two days for linens, one day for tents. Test: a tent returned Saturday shows unavailable until Monday.

AV-03 (should). The system shall let staff extend a turnaround when an item returns wet or damaged. Test: extend one tent by a day; availability updates at once.

AV-04 (must). The system shall return an availability check within three seconds for a forty-line order. Test: timed on office internet during the demonstration.

AV-05 (could). The system shall show items sub-rented from other companies separately. Test: add a sub-rental; it appears with its source.

Orders

OR-01 (must). The system shall store each order with event date, venue, contact, items and delivery window. Test: enter a sample order and print it.

OR-02 (must). The system shall record every change to an order with time and user. Test: change a quantity; the history shows who and when.

OR-03 (should). The system shall flag changes made within forty-eight hours of delivery. Test: edit an order due tomorrow; a flag appears for dispatch.

OR-04 (should). The system shall generate a quote from the order with company pricing. Test: produce a quote in under two minutes.

OR-05 (could). The system shall let customers approve quotes online. Test: approve a quote from a phone.

Warehouse

WH-01 (must). The system shall print or display a pick list per truck. Test: generate lists for five trucks from one day's orders.

WH-02 (should). The system shall show items short for the next seven days. Test: overbook one item; it appears on the shortage view.

WH-03 (should). The system shall record items returned, missing and damaged by order. Test: check in a returned order with two missing chairs.

WH-04 (could). The system shall track item condition over time. Test: view a tent's damage history.

WH-05 (could). The system shall support barcode scanning. Test: scan ten items at check-in.

Delivery

DL-01 (must). The system shall provide a driver view of the day's stops and items on a tablet. Test: a driver opens tomorrow's route.

DL-02 (must). The system shall capture photos at delivery and pickup, stored to the order. Test: take three photos; they appear on the order in the office.

DL-03 (must). The check-in shall work without signal, store locally and sync when coverage returns. Test: complete a check-in in airplane mode, then reconnect.

DL-04 (should). A new seasonal driver shall complete a pickup check-in after a ten-minute briefing. Test: timed with a staff member who has not used the system.

DL-05 (should). The system shall record a customer signature at delivery. Test: capture a signature on the tablet.

DL-06 (could). The system shall suggest route order. Test: produce a route for eight stops.

Billing

BL-01 (must). The system shall link deposits and balances to orders automatically. Test: take a deposit; it appears against the order without manual entry.

BL-02 (must). The system shall add damage charges to the invoice from check-in records. Test: record damage; it appears on the invoice draft.

BL-03 (should). The system shall export invoices to the online accounting product. Test: send three invoices; they appear in accounting.

BL-04 (should). The system shall send balance reminders seven days before an event. Test: reminder appears in the outbox.

BL-05 (could). The system shall support split payments. Test: pay a balance by two cards.

Data

DA-01 (must). The system shall hold one customer record per customer, with duplicates flagged at entry. Test: enter an existing customer; a warning appears.

DA-02 (should). The system shall import existing orders and customers from the current package. Test: import last season's file; counts match.

DA-03 (should). The system shall restrict views by role. Test: log in as crew; no payment data visible.

DA-04 (could). The system shall produce a monthly report of revenue by item category. Test: run the report for June.

DA-05 (could). The system shall export reports to a spreadsheet. Test: export one report.

Vendor Terms

VT-01 (must). The vendor shall provide a full data export in a documented format on request. Test: request and open an export during the trial.

VT-02 (must). The vendor shall provide weekend support from April through October. Test: a support call on a Saturday during the trial.

VT-03 (should). Annual price increases shall be capped in the contract. Test: clause present in the draft contract.

VT-04 (should). The vendor shall give ninety days' notice before retiring a feature. Test: clause present.

VT-05 (could). The vendor shall offer a sandbox copy for training. Test: sandbox available during the trial.

If a requirement cannot fail a test, two vendors will read it two ways and quote two different systems.

What this part is doingPairing every requirement with an acceptance test shows the document was written to be checked.

Constraints and Assumptions

Office internet is reliable; signal at rural venues is not. Crews change every season, so training time matters. The company has no in-house technical staff.

Appendix: Demonstration Script

Each vendor will run the same script on one June Saturday from last season's records: forty-one events, five trucks and twelve late changes, entered from a supplied file. Vendors will be scored on the twelve musts first.

What this part is doingA shared demonstration script turns the musts into a fair contest between vendors.

References

Hofmann, H. F., & Lehner, F. (2001). Requirements engineering as a success factor in software projects. IEEE Software, 18(4), 58-66. https://doi.org/10.1109/MS.2001.936219

International Organization for Standardization. (2018). Systems and software engineering: Life cycle processes: Requirements engineering (ISO/IEC/IEEE Standard No. 29148:2018). https://www.iso.org/standard/72089.html

Laudon, K. C., & Laudon, J. P. (2022). Management information systems: Managing the digital firm (17th ed.). Pearson.

MT300 Unit 4 instructions, in plain terms

In Unit 4 students write a requirements document for the system proposed in the business case. The document should state its scope clearly, including what is outside it, and summarize the current process. Requirements should be grouped logically, often following the path a transaction takes through the business. Each requirement should be a single, testable statement, usually using shall, with a priority and an acceptance test. Instructors expect vague words such as fast or easy to be replaced with measures. Requirements should describe behaviors rather than name products or screens. Constraints and assumptions belong in a separate section. Many prompts also ask for vendor terms, such as data export and support, and a method for testing vendors against the same scope.

How this MT300 Unit 4 example is built

The sample's introduction defines scope from the first availability question to the final invoice and names payroll, the website and the phone system as excluded. Six numbered steps summarize the current process, each linked to the Unit 2 inventory. Thirty-six requirements follow in seven groups, availability, orders, warehouse, delivery, billing, data and vendor terms, each with an ID, a shall sentence, a priority and a test. The delivery group includes an offline check-in tested in airplane mode. The highlighted line warns that a requirement that cannot fail a test will be read two ways. Constraints note that rural venues lack signal. The appendix sets a demonstration script of forty-one events and five trucks for every vendor.

Where the points sit in the MT300 Unit 4 rubric

Requirements documents are commonly graded on clarity, testability, completeness and organization. Graders look for single-statement requirements that can pass or fail a test. Measures should replace vague adjectives. Priorities should be justified, not simply assigned. Each line states a behavior the business needs and leaves the product unnamed. Scope and exclusions should be explicit, so vendors cannot price different work. Vendor terms such as data export and support show awareness of business risk. A consistent format across all requirements makes the document usable. Sources in APA 7 should support the method. A shared test or demonstration script is a strong addition, because it lets the next unit's comparison rest on identical evidence for each vendor.

MT300 Unit 4 help from the desk

Requirements documents often borrow feature lists from vendor brochures instead of describing what the business needs. Another common weakness is using words such as user-friendly or fast with no measure attached. Some students list dozens of requirements all marked high priority, which tells vendors nothing. Acceptance tests are frequently missing. Scope sections may omit what is excluded, leaving vendors to guess. Before drafting, walk through your busiest day and write down every point where the current process breaks or slows. Each of those points can become a requirement with a test. Share that walk-through and the template, and a requirements document can be shaped to your process.

Get an MT300 Unit 4 example written to your instructions

Numbered, prioritized and testable is how your requirements document comes back, written for the organization in your case and the Unit 4 rubric you share, within 24-48h. Whatever the case says about the business process goes into it. We waive the fee on a first custom sample, and user stories replace shall statements wherever your section prefers them. The paper above is an original model document written by our desk, not a submitted student paper and not an official Purdue University Global document.

More MT300 papers and BS in Business Administration samples

MT300 Unit 4 questions, answered

What makes a requirement testable?

A condition someone could check during a demonstration and record as pass or fail. The system shall let staff see availability is not testable; the system shall show availability for any date and item within three seconds is. Each requirement also benefits from a short reason, so a reader knows what the business loses if a vendor falls short.

Shall statements or user stories?

Both appear in MT300 sections, and the prompt usually signals which. Shall statements suit a document meant for vendor bidding, which is how this example is framed. User stories, as a dispatcher I want tomorrow's loads by truck so that I can plan crews, suit an agile project. Whichever form is used, every item needs an acceptance condition attached.

How many requirements are enough?

Enough to cover the process end to end without splitting one behavior across several lines. Twenty to forty is common for a small business like this one. Fewer usually means whole steps were skipped, and far more usually means features are being listed rather than needs. Grouping by process stage makes any gap visible quickly.

Where can I find a free MT300 Unit 4 sample paper?

The complete MT300 Unit 4 requirements document is on this page, with thirty-six testable needs for an event rental company.

How are priorities set in the MT300 Unit 4 sample?

A requirement is a must if the company could not run a June Saturday without it, and each must carries that consequence.