Study Guides (390,000)
CA (150,000)
Ryerson (10,000)
ITM (400)

ITM 430 Study Guide - Final Guide: Domain Model, Use Case, Unified Medical Language System

Information Technology Management
Course Code
ITM 430
Junlian Xiang
Study Guide

This preview shows pages 1-3. to view the full 18 pages of the document.
Requirements Analysis - The purpose of requirements analysis is to
understand some of the goals of the computer system that we will design.
Use case model
Supplementary specification
Business rules
Use cases - provide a way of describing the functional requirements through
stories of using the system.
a use case is a text story of some actor using a system to meet goals.
Use cases are not diagrams. They are TEXT.
Use cases are NOT object-oriented artifacts! They feed into other OO models.
Actors - Anything with behavior that triggers use case execution.
Three kinds of actors:
Primary Actor accomplishes goals via use case
Example: the cashier
Secondary Actor provides a service to use case (often a computer system,
but could be an organization)
Example: the automated payment authorization service
Offstage actor is interested in use case results
Example: government tax agency
Scenarios - a specific sequence of actions and interactions between actors and the
It represents a one possible path through the use case.
Three possible use case formats
Write in an ‘essential’ UI-free style.
“Keep the interface out; focus on intent.”
Write terse use cases, i.e., make your style “brief and to the point;
effectively concise”.
Delete “noise” words, even if it is small word:
Say “System authenticates ...”, rather than “The system
authenticates ...”
Brief format: one paragraph summary usually of the main success scenario
Casual format: multiple paragraphs that cover various scenarios.
Fully dressed: all steps and variations are written in detail. In addition, there
are supporting sections such as preconditions and postconditions.
Use case Name in ‘Verb Noun’ format
Close Account, Process a Sale
The system under design
Stakeholders and interests
Who cares about this use case and what they want
What must be true on start and worth telling the reader
Postconditions (or Success Guarantee)
What must be true upon completion of the use case, and worth telling
the reader.
Base Scenario (or Main Success Scenario)

Only pages 1-3 are available for preview. Some parts have been intentionally blurred.

: D ic e G am e
play ()
die1 : D ie
f v 1 : = get F ac eV alue()
die2 : D ie
f v 2 : = g et F ac e V alue()
Steps describing the sequence of actions that must occur assuming no
alternative flows or error conditions --- it is the ‘happy day scenario’.
Alternate scenarios
Special Requirements
Non-functional requirements
Technology and Data Variations List
Varying I/O methods and data formats
Frequency of Occurrence
This will influence investigation, testing, and timing of implementation
Open issues
Domain model - Creating a domain model is a basic object-oriented step, and is
part of the analysis.
Goal: to identify the major concepts in a domain and express that visually.
UML sequence diagram - shows interactions among software objects in terms of
messages and collaborations in order to fulfill the system requirements .
It provides us with a detailed way to think about how the objects are going to
Class diagram is a more static diagram, in contrast to sequence diagrams which
emphasizes the dynamics of the design.
P l a y e r
n a m e
D i c e G a m e
D i e
f a c e V a l u e
R o l l s
P l a y s
I n c l u d e s

Only pages 1-3 are available for preview. Some parts have been intentionally blurred.

Models are cohesive set of artefacts meant to describe in an abstracted way some
aspects of the problem at hand, of the requirements, or the system design.
The artefacts could be text, diagrams, or more mathematical.
To record our thoughts when we think about a problem.
To deal with the complexity of systems at hand. Instead of getting into the
details of coding, we want to focus on the big picture or major design
Models represent a communication tool for people involved in the software
UML - It is a standard diagramming notation for describing object-oriented software
It is just a notation, not a process and not a method --- think about civil
engineering or electrical engineering ...
So, one can very well say that it is not important --- it is just a standard for
drawing diagrams
Sequential Waterfall Lifecycle - Requirements, then design, then implementation,
then at the end test ...
The most risky and failure prone approach to develop software, while in
1970s many thought-leaders, books, profs, project managers promoted this
approach as the way to reduce risk and get more successful projects.
Iterative Lifecycle – Iteration lasts between 2 weeks to 6 weeks, but not 4 months or
4 years
Reduces risk and leads to successful projects
Iterations are not allowed to exceed the time that was allotted to them. Once
we chose a period of time, that becomes fixed (remove work or sharpen your
Mitigate High Risks Early on:
oSelect requirements in early iterations in such a way that big risks are
discovered early on during the project.
oAs time progresses, risk is reduced, while the full product emerges
[diagram can be drawn with iterations on x-axis]
D i e
f a c e V a l u e : i n t
g e t F a c e V a l u e( ) : i n t
r o l l( )
D i c e G a m e
d i e1 : D i e
d i e2 : D i e
p l a y( )
You're Reading a Preview

Unlock to view full version