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;
– Delete “noise” words, even if it is small word:
• Say “System authenticates ...”, rather than “The system
• 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
• Base Scenario (or Main Success Scenario) • 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.
P l aD y i ee r
n aR 2f m ace les V a lu e
1 la y s
D 1 I n ec l u ad me se
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
: Dic eG am e die1 : D ie die2 : D ie
f v 1 : = get F ac eV alue()
f v 2 : = get F ac eV alue()
Class diagram is a more static diagram, in contrast to sequence diagrams which
emphasizes the dynamics of the design. D D i i c e e G
d1:D 2f:i n a i ei t c e e
d2:D i ei e
p( r(i )n o ) l e a t l : l y F
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
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
• 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:
o Select requirements in early iterations in such a way that big risks are
discovered early on during the project.
o As time progresses, risk is reduced, while the full product emerges
[diagram can be drawn with iterations on x-axis] • Continuous verification of quality – test early and test often
o Load testing (system ability to handle the load)
o Usability testing of the UI (getting feedbacks from stakeholders about UI
using partial demos)
• Embrace change
o Rather than trying to fight change, accept it as a positive driver in the
software development process.
o Look forward to feedbacks from stakeholders. When users say in their
feedback it is not exactly what we wanted: don’t groan – say it is great,
now we have the right feedback ...
• Understand the Phases
o INCEPTION: 1 to 5 days – kind of feasibility study
The intent is to establish some initial common vision for the objectives
of the project, determine if it is feasible and decide if it is worth some
serious investigation in elaboration.
o ELABORATION: focus on building the core architecture of the system, and
driving down the risks, and identifying 70% or more of the requirements
o CONTRUCTION: where we do the rest – the less risky and simple parts of
o TRANSITION: release of candidates for feedbacks and evaluation.
– Inception is not requirements
– Elaboration is not design
– Construction is not implementation
- Inception is feasibility
- Elaboration is implementing the core architecture
- Construction is doing the rest
Artifacts in inception
• Vision and business case - Describes high-level goals and constraints.
• Use Case model - Describes functional requirements and related non-
• Supplementary specification - Describes other requirements
• Glossary - Key domain terminology
• Risk list and Risk Management Plan - Describes business, technical, resource
and schedule risks and ideas for their mitigation or response.
• Prototypes and proof-of-concepts
• Iteration plan - Describes what to do in the first elaboration iteration
• Phase Plan & Software development Plan - Guess for elaboration phase
duration. Tools, people, education and other resources.
• Development Case - Description of the customized UP steps and artefacts for
• Artifacts will be partially completed in this phase and will be refined in later
Black-box use cases • Black-box use cases are the ones that do not describe the internal workings
of the system, its components, or design.
• The system is described as having responsibilities (a common unifying
paradigm --- more on this later in course, when we see that objects have
responsibilities and collaborate with other objects also with responsibilities).
• Writing black-box use cases forces us to think about “what” [purpose of
system analysis] the system must do, without deciding “how” [“purpose of
system design”] it will do it.
How to find use cases:
1. Choose system boundary.
2. Find primary actors and goals through brainstorming ...
3. Define use cases
o One use case for each user goal
o Name the use case similar to the user goal.
• It is a partial domain model
• It is drawn using UML class diagram notation, but the domain model is NOT
a class diagram for the system to be designed.
• It provides a conceptual perspective model that describes the real-world
• It does NOT describe the software elements.
What is a domain model?
• The term ‘domain model’ means a visual representation of real-situation
conceptual classes, NOT of software objects.
• It is illustrated using a set of class diagrams in which NO operations are
• It may show:
o Conceptual classes
o Associations among conceptual classes
o Attributes of conceptual classes
• Domain models allow us to understand the domain for which the software
system is to be developed.
• Lowering the representation gap between
o our mental understanding of the domain and our software model for the
system that we intend to develop
• In some cases, domain models are drawn just to gain understanding of the
domain and communicate a rough approximation of key concepts; then they
are discarded shortly after creation.
• If you want the model to be maintained and updated with discoveries of new
concepts, you may consider using a CASE tool; but not always … the software
business logic layer tends to give good hints about the domain model. • We do not always try to create software solutions that reduce the
“representation gap” …
• In some cases, an exact one-to-one mapping may NOT be present, or it may
not even be desirable.
• As with all things in UP, a domain model is optional, and may not be needed
in some cases.
How do we create a domain model?
1. Find the conceptual classes
2. Draw them as classes in a UML class diagram
3. Add associations and attributes
How do we find conceptual classes?
1-Reuse or modify existing (domain and/or data) models
3- Identify noun phrases in textual descriptions of the domain, such as the use
cases for instance.
R I S t S e t gaom l r e s e t e r
S C C L a a u e l se s d hs t g oi e e m r r e r
L i n e I t e m
PC C D a a ar e yo sot ms a h d c l e o r c in g p t tt t i o n
Rule of Thumb:
Description classes - Contain info that describes something else, very common in
o If description is not separate from the underlying object, then deletion of the
object results in loss of all info about that object Associations - It is a relationship between classes (more precisely, instances of
those classes) that indicates some meaningful and interesting connection.
An attribute is a logical data value of an object that needs to be remembered
o Some attributes are derived from other attributes
The usual ‘primitive’ data types
o Numbers, characters, booleans
Common compound data types
o Date, time (or dateTime), address, SSN, phoneNumber, bar codes, etc.
o Compound data types may become full class objects in design
Will associations be implemented in software?
Associations are NOT
o A statement about data flows
o database foreign keys
o instance variables
o object connections in a software solution.
è It is a statement that a relationship is meaningful in a purely conceptual
• Having said that, many of these associations will be implemented in software
as paths of navigation and visibility.
System Sequence Diagrams – A system sequence diagram is a UML diagram that
shows, for one particular scenario of a use case, the events that external actors
generate and their order.
o Can help transition from the functional aspect to the OO design
systm s back box
h enam ecouGd"ueOstemps t
aterchapteron eq en e da gam no tton nthe UM L
exernalactr o ProcessS ae Scenaro
a UM L ooplop moeie]s
e xresso n descrptino
am esa gew th
etuns)au e parm etrs
assoiaed wih h e
peviousm esa ge toal wthtaxes ts ana btracion
ss tm eventof
anabstacton ta t entrng he
gnorespresenttion makeP(ammuntt paymentdata by