- 2072 Asoj · 5 marks
Functional vs non-functional; include and extend
Short answer
Functional requirements define what the system does, non-functional define quality constraints like speed and security. The <<include>> relationship is mandatory: base use case always calls included one, arrow points base→included. The <<extend>> relationship is optional: extending use case adds behavior under a condition, arrow points extending→base.
Differentiate between functional and non-functional requirement. What are the relationships in Use Case Diagrams and explain <<include>> and <<extend>> relationships with diagram?
Functional vs non-functional requirements
| Point | Functional | Non-functional |
|---|---|---|
| Meaning | What the system must do (functions, services) | How well the system does it (quality, constraints) |
| Describes | Features, inputs, processing, outputs | Performance, security, usability, reliability, portability |
| Verification | By functional testing against use cases | By measuring (load test, security test) |
| Documented as | Use cases, user stories | Supplementary specification |
| Example | "The system shall let a user withdraw cash" | "Withdrawal must complete within 5 seconds" |
Relationships in a use case diagram
- Association: line between an actor and a use case.
- Generalization: between actors (or between use cases): specialised one inherits the behaviour.
- Include: one use case always uses another.
- Extend: one use case optionally adds behaviour to another under a condition.
<<include>>
The base use case always calls the included use case, which is the common behaviour shared by several use cases. Arrow points from base to the included one. Used to avoid repetition.
<<extend>>
The extending use case optionally adds behaviour to the base use case when a condition (extension point) is true. Arrow points from the extending to the base use case.
[Customer]--( Withdraw Cash )--<<include>>-->( Verify PIN )
^
| <<extend>> [balance low]
( Show Low Balance Warning )
<<include>> | <<extend>> |
|---|---|
| mandatory, always runs | optional, conditional |
| arrow base -> included | arrow extension -> base |
| base is incomplete without it | base is complete without it |
✓ Answer checked by Claude Sonnet 5.5
Related questions
- Coffee vending machine use case diagram · Object Oriented Analysis and Design, chapter 2
- Importance of use case diagram · Object Oriented Analysis and Design, chapter 2
- Collaboration and use case diagram case · Object Oriented Analysis and Design, chapter 2
- Math Training Institute use case diagram · Object Oriented Analysis and Design, chapter 2
- Requirement elicitation and system behavior · Object Oriented Analysis and Design, chapter 2
- Video rental shop class diagram · Object Oriented Analysis and Design, chapter 2
- Functional versus non-functional requirements · Software Engineering, chapter 1
- Functional block diagram of excitation control · Power Plant Equipment, chapter 3
- Analog and digital system block diagrams; linear and non-linear distortion · Communication Systems, chapter 1
- Case study: existing vs proposed system · Instrumentation II, chapter 10
All Object Oriented Analysis and Design chapter 2 questions →