INFO90002 Chap.2 Requirements and Conceptual Modelling
Requirements and Conceptual Modelling
Requirements and Conceptual Modelling turns business rules, entities and attributes and relationships into executable reasoning. The chapter's practical target is to translate stakeholder language into testable data requirements, so every explanation should connect syntax to program state, control flow and observable output.
Treat business rules as a precise program object, not a loose label.
Identify its value or responsibility before execution, then trace what can read it, change it or depend on it. This makes hidden state changes visible before they become debugging guesses.
Conceptual modelling er
In INFO90002, conceptual modelling er belongs with business rules and entities and attributes because students use it to translate stakeholder language into testable data requirements.
A defensible use of conceptual modelling er should define the term, connect it to the case evidence and test the conclusion through relationships; repeating the phrase without that chain does not demonstrate understanding.
Foundations and er modelling
In INFO90002, foundations and er modelling belongs with business rules and entities and attributes because students use it to translate stakeholder language into testable data requirements.
A defensible use of foundations and er modelling should define the term, connect it to the case evidence and test the conclusion through relationships; repeating the phrase without that chain does not demonstrate understanding.
Use entities and attributes to explain the program's next move. Work through one representative input by hand and name the branch, iteration or call that follows.
If the trace cannot be stated, the code may run by accident rather than by understood design.
Bring in relationships as the test of structure.
Compare normal, boundary and invalid inputs; state the expected behaviour first; then use the mismatch between expectation and result to localise the defect.
For the application — translate stakeholder language into testable data requirements — write the smallest complete example that exposes the rule.
Explain why it works, what would break it and how the program should signal or recover from that failure.
Before running a Requirements and Conceptual Modelling example, make a trace table with the important state before and after each operation. Include the value associated with business rules, the control decision governed by entities and attributes and the output or object affected by relationships.
The table turns an unexplained result into a sequence that can be tested one transition at a time.
Test three inputs: an ordinary case, a boundary case and an invalid case. State the expected result for each before execution, then compare it with what the program actually does.
A useful test of entities and attributes isolates one rule; a test that changes several conditions at once cannot tell you which condition caused the failure.
Practise explaining the solution without reading the code.
For INFO90002, name the data representation, the control flow, the responsibility of each function or class and the reason the chosen design supports translate stakeholder language into testable data requirements.
This rehearsal is especially important when a written test or interview asks why the program works rather than whether it produces one correct output.
A complete Requirements and Conceptual Modelling response should make the task visible before the detail: identify what must be decided, define the relevant terms, connect the evidence to entities and attributes, and use relationships to test the result.
The final sentence should answer the question actually asked rather than merely repeat the topic.
The controlling limit is specific: A noun in a narrative is not automatically an entity.
Keep that limit beside the worked example, because it separates a careful INFO90002 answer from one that sounds confident but claims more than the task or evidence supports.
For revision, retrieve business rules, entities and attributes and relationships without notes, explain their relationship aloud, then complete a changed version of the application: translate stakeholder language into testable data requirements.
Record the first point at which your reasoning fails and repair that move before attempting another case.
What this chapter covers
- 01
business rules
- 02
entities and attributes
- 03
relationships
- 04
Applying business rules
- 05
Limits of entities and attributes and relationships
Worked example: Requirements and Conceptual Modelling
- 1Mark the starting condition or object represented by business rules.
- 1Write the change, rule or mechanism supplied by entities and attributes as a verb-led link.
- 1Show how that link reaches relationships; do not skip an intermediate actor, quantity or stage.
- 1Answer the task with the completed chain and preserve this limit: A noun in a narrative is not automatically an entity.
Key terms
- conceptual, logical and physical design (the database development lifecycle)
- Conceptual design models business entities and relationships independently of technology, logical design translates them into a data model and constraints, and physical design specifies storage, indexes and implementation details. In this chapter, use the concept when you translate stakeholder language into testable data requirements.
- Crow's Foot vs Chen notation
- Crow's Foot notation shows cardinality with line-end symbols around entity boxes, whereas Chen notation represents entities, attributes and relationships with rectangles, ovals and diamonds. In this chapter, use the concept when you translate stakeholder language into testable data requirements.
- identifier / primary key; composite, derived and multi-valued attributes
- An identifier uniquely distinguishes entity occurrences and becomes a primary key in a relation; a composite attribute has components, a derived attribute is calculated, and a multi-valued attribute can hold several values per entity. In this chapter, use the concept when you translate stakeholder language into testable data requirements.
Requirements and Conceptual Modelling FAQ
What is the main task in Requirements and Conceptual Modelling?
Translate stakeholder language into testable data requirements.
How do business rules and entities and attributes work together?
Use business rules to establish the object or condition, then use entities and attributes to explain how it changes the outcome being analysed.
What must a INFO90002 answer qualify here?
A noun in a narrative is not automatically an entity.
How should I revise Requirements and Conceptual Modelling?
Retrieve business rules, entities and attributes and relationships, apply them to a changed case, and correct the first point where the evidence no longer supports the conclusion.
Exam move
Reconstruct the relationship among business rules, entities and attributes and relationships; complete the chapter application without notes; then test the result against this limit: A noun in a narrative is not automatically an entity.
Working through Requirements and Conceptual Modelling in INFO90002? Sia is AskSia’s AI Information Technology tutor — ask any INFO90002 Requirements and Conceptual Modelling question and get a clear, step-by-step explanation grounded in how INFO90002 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
