ISYS90050 · It Project and Change Management
Requirements Engineering & Management
Week 2 teaches what a requirement is (the IEEE definition) and why a requirements-management process matters early, when the cost of change is lowest. The examinable core is the split between functional, non-functional and domain requirements, the vertical user/system/software hierarchy, the contractual language (shall / should / will), and the classic challenges. Expect short-answer classification drills and a scenario asking you to elicit and validate requirements — a skill also exercised directly in the group planning report.
What this chapter covers
- 01Requirement (IEEE): a condition/capability a user needs, or one a system must meet to satisfy a contract/standard
- 02Functional (what the system does) vs non-functional (constraints/qualities) vs domain (application-area) requirements
- 03User -> system -> software requirements (vertical use-level hierarchy)
- 04Contractual language: shall (mandatory, verifiable), should (goal), will (statement of fact), avoid must
- 05Elicitation methods: interviews, document analysis, workshops/brainstorming, observation, personas, prototyping; the value-vs-complexity prioritisation matrix
- 06Requirements challenges: customers don't know what they want, requirements change, unreasonable timelines, communication gaps
- 07Validation qualities: verifiable, comprehensible, traceable, adaptable; complete and consistent (hard in practice)
- 08Scope creep: requirements set the scope, so uncontrolled requirement change expands it
Classify and repair requirements for a small booking system
- +1Line 1 is not a testable requirement at all — "will make everything easier" is a vague statement of purpose with no verifiable behaviour. Mark it for rework, not classification.
- +1Line 2 amalgamates several requirements: a functional one (search tutors and book a slot), a non-functional performance one (be fast) and a non-functional/external one (comply with privacy law). Combining them with "and" is the amalgamation fault — one requirement should be one sentence.
- +1Line 3 is a domain requirement: "availability follows the school-term calendar" reflects a constraint of the tutoring application domain, not a system behaviour the team chose.
- +1Rewrite line 2 as separate, verifiable statements using disciplined language: "The system shall allow a student to search available tutors and book a slot." "The system shall return search results within 2 seconds" (a measurable non-functional target). "The system shall store personal data in accordance with applicable privacy law." Each is one sentence, testable, and avoids the un-verifiable "must".
Key terms
- Requirement (IEEE)
- A condition or capability needed by a user to solve a problem or achieve an objective, or one that a system must meet to satisfy a contract, standard or specification. Defined early as what should be implemented or a constraint on the system.
- Functional requirement
- A service the system shall provide — its outputs, its reaction to inputs, its behaviour in particular situations. Describes what the system should do.
- Non-functional requirement
- A constraint on the system's services or qualities — performance, reliability, usability, security, privacy. Applies to the system as a whole, is harder to verify, and can matter more than functional requirements because it shapes the architecture.
- Domain requirement
- A requirement reflecting the characteristics and constraints of the application domain (e.g. legal rules, term calendars, dietary categories). May be functional or non-functional.
- Shall / should / will
- Requirements language: shall = mandatory and verifiable (contractually binding); should = a desired goal, addressed but not formally verified; will = a statement of fact, not verified. Avoid must.
- Scope creep
- The uncontrolled growth of scope as new requirements are added after the baseline is set. Because requirements set the scope, disciplined requirements change management is the guard against it.
Requirements Engineering & Management FAQ
What is the difference between functional and non-functional requirements?
A functional requirement is something the system does — a service, an output, a response to an input. A non-functional requirement is a quality or constraint on how it does it — speed, reliability, usability, security, privacy. Non-functional requirements apply system-wide, are harder to verify, and often shape the architecture more than functional ones do.
Why is "shall" preferred over "must" in a requirement?
"Shall" signals a mandatory, contractually binding, verifiable requirement and has held up in court; "must" is not clearly distinguished from "shall" and has not held up as well. The convention keeps requirements testable and unambiguous — shall for mandatory, should for a goal, will for a statement of fact.
How can requirements go wrong even when written in plain English?
Natural language invites ambiguity (words read differently by writer and reader), confusion (functional and non-functional mixed), amalgamation (several requirements in one sentence) and over-flexibility (the same thing said many ways). The fixes are one-requirement-per-sentence, avoiding and/or, and validating each for being verifiable, traceable, comprehensible and adaptable.
Can AI help me with requirements engineering in ISYS90050?
Yes, as a study aid. Sia can drill you on sorting mixed one-liners into functional, non-functional and domain, show how to rewrite an amalgamated requirement into clean shall-statements, and rehearse elicitation techniques. Use it to learn the method; it does not do your graded assignment, and University of Melbourne academic-integrity rules apply — confirm details on Canvas.
Exam move
Make the three-way sort automatic: given any one-line requirement, decide functional, non-functional or domain and justify it in a phrase. Practise rewriting bad requirements — spot ambiguity, amalgamation and un-verifiable wording, then reissue as one-sentence shall-statements with measurable targets — because that skill is examined in short answers and used directly in the group planning report. Memorise the validation qualities (verifiable, comprehensible, traceable, adaptable) and the challenge list, and be able to name two elicitation methods for a given client. Since the exam is closed-book, rehearse the shall/should/will distinction until it is reflex.
Working through Requirements Engineering & Management in ISYS90050? Sia is AskSia’s AI IT Project Management tutor — ask any ISYS90050 Requirements Engineering & Management question and get a clear, step-by-step explanation grounded in how ISYS90050 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
