McMaster University

SFWR ENG 3RA3

Goal-based Models:
Actors: People, sub-systems or
indirect stakeholders who act
to achieve goals
Roles: actors plays 0..n roles
Position: actor occupies 0..n
positions
Goals: single statement on
want, future intent to do
something
Hard Goals: Goals we can
measure & quantify (rounded
square)
Soft Goals: something we
know we need but can’t
describe (cloud)
Resource: something that can
be used to achieve goals
(square)
Plan: How actors will execute actions to achieve goals
Dependency: A relation between two actors linked through dependums (goals, resource..)
Soft goals can be restated and defined to become testable (imp.)
Fun -> immersion rating > 75
Goal Contributions: hard goals that lead to success of primary (hard/soft) goals
Goal Decomposition: multiple hard goals that relate to one another through relationships
Why? Important to identify the direction the system is heading in, to make sure
stakeholder’s interests are aligned
Goals: often hard to measure, but requirements can be objectively measurable
G: System is deployed internationally -> R: must support languages [x, y, z]
Requirements Basics:
User Requirements: statements regarding the tasks of users satisfied by system
System Requirements: description on how system will satisfy/meet user’s needs
Functional Requirements: things a system must do (transformation – required response to
a condition/event, invariant – properties must always hold, failures – forbidden events)
Verbs: should, must, can, NOT will
NFR: constraints on FRs, ‘should be’ (optimization, timing, reliability)
FC: quantification of a requirement (within 10s 90% of time, etc), should say how you
can measure this and give the steps to do so
Necessary: is needed to make the system work, otherwise it fails to function
Attainable: must be technically feasible and fit within given constraints
Verifiable: can you verify this actually? Determine criteria for acceptance
Layers of abstraction User reqs -> System reqs -> Software reqs
Requirements Elicitation:
Identify problem, collect information, become expert in problem domain
Stakeholders: source of knowledge about work
Non-tacit: “I know that I know it” (explicit)
Semi tacit – can be accessed, recognized knowledge that can be recognized but not
recalled, in working memory
Tacit knowledge – “I don’t know that I know it”, implicit, not consciously learnt
Open interviews – no detailed questions, more general
Closed interviews – explicit set of questions in mind to ask
Use Case: Capture the functional
requirements, describes how actors achieves
goal in a system , protects the interests of
the stakeholders, named capability of a
system that the actors can interact with
Use Case Scenario – used to further
describe a use case
Primary Actor: Cardholder
Supporting Actors: Bank
Precondition: Customer has a bank card
Trigger: Customer inserts card into ATM
Main Success Scenario:
1. ATM offers menu of services.
CardHolder selects “Withdraw Cash”
2. ATM reads account details, PIN from
card
3. ATM passes account details to Bank. Bank validates account details
4. CardHolder enters PIN. ATM validates PIN
5. CardHolder selects amount to withdraw
6. ATM notifies Bank of amount. Bank accepts request
7. ATM delivers cash, returns card
Secondary Scenarios:
1.1 5.1: CardHolder cancels:
ATM discards intermediate
data, terminates
transaction
4.2. PIN not valid: ATM prom