OBJECT OREINTED ANALYSIS & DESIGN

(OOAD)
➢ COURSE OBJECTIVES:
❖ The focus of this course is on design rather than implementation.
❖ Introducing the Unified Process and showing how UML can be used within the process.
❖ Case study experience with architecture, analysis, and design.
❖ Programmatic interactions using UML diagrams and OOP.
➢ COURSE OUTCOMES:
❖ Understand the concepts of object-oriented modeling.
❖ Apply qualitative knowledge and techniques to develop use case diagrams.
❖ Create class diagrams that model both the domain model and design model of a software
system.
❖ Create interaction diagrams that model the dynamic aspects of a software system.
❖ Design a logical architecture in terms of layers and partitions with the Layers pattern
with case study.
 UNIT – 2
INCEPTION & USE CASE DIAGRAMS
➢ CONTENTS:
❖ Introduction to Inception
✓ Artifacts in Inception, and
✓ Understanding Requirements – The FURPS+ Model.
❖ Understanding Use Case Model
✓ Introduction to Use Case Model,
✓ Use case Types, & Formats,
✓ Writing Use cases – Goals & Scope of a Use Case, and
✓ Elements / Sections of a Use Case.
❖ Use Case Diagrams
✓ Use Cases in the UP Context and UP Artifacts,
✓ Identifying Additional Requirements, and
✓ Writing Requirements for the Case Study in the Use Case Model.
INTRODUCTION TO INCEPTION:
❖ INCEPTION is the initial short step to establish a common vision and basic scope for the
Project. It will include analysis of perhaps 10% of the use cases, analysis of the critical
non- Functional requirement, creation of a business case, and preparation of the
development Environment so that programming can start in the elaboration phase.
❖ Inception in one Sentence: Envision the Product Scope, Vision, and Business Case.
❖ The RUP defines several artifacts that are produced during the achievement of the
Lifecycle Objectives Milestone. Some Artifacts (scientific investigation or experiment that
is not naturally present but occurs as a result of the preparative or investigative
procedure) may start in Inception Phase that includes:
✓ Vision and Business Case,
✓ Use – Case Model,
✓ Supplementary Specification,
✓ Glossary (list of words & their meanings --- vocabulary),
✓ Risk List & Risk Management Plan,
✓ Prototypes (Optional Artifacts), and
✓ Proof-of-concepts etc.,.
1. The Project Business Case:
❖ The Business Case defines the economic advantages obtained from successful project
execution. It addresses the following questions like:
✓ What overall problem would be solved by the project's results?
✓ What would happen if a decision not to pursue the project were made?
✓ Are there other alternatives to spending funds on this project?
✓ Could the same solution be obtained from a Commercial Off-The-Shelf (COTS) product?
✓ If so, how do the costs of the COTS solution compare to a custom solution, and what are the
advantages and disadvantages of each?
❖ On most outsourced projects, these questions have already been answered. If your role on
the project is that of a contractor, it is worthwhile to thoroughly understand the Business
Case, because it will influence your judgment for the many decisions yet to come.
❖ Certainly, it is helpful to read any Vision documents produced by the customer. See the
later section “Seeing the World Through the Customer's Eyes” for other ideas.
2. The Project Vision Statement:
❖ The Vision Statement is written from the perspective of the customer and end users. Its
purpose is to define what project success looks like.
❖ In other words, if the project were successful,
✓ What would the product look like?
✓ What are its key characteristics and features, and how will this help its users perform their
functions better?
❖ One key difference between the Business Case and the Vision Statement is that:
✓ The Business Case considers all options for solving the problem, without delving too deeply
into the specifics of any single solution, except for the costs, advantages, and disadvantages.
✓ The Vision Statement assumes that you have decided to conduct the project. It defines, at a
management level, how management will be able to tell if the mission has been accomplished.
❖ Although most outsourcing organizations may have elements of a Vision Statement
identified, it may not be formally stated in a document. If this is the case, the contractor's
role is two-fold:
a. Help the customer define and envision what the product will do and how it will help the
customer.
b. Work closely with your project team to communicate this vision, and promote the vision to
everyone on the project.
❖ The goal is for the project team to understand the problem from the customer's
perspective and to buy in to the ideas the customer has for solving the problem.
3. The Project Risk List & Risk Management Plan:
❖ Every project has risks. Successful projects recognize the risks and tackle them head-on.
In fact, the RUP was designed to help uncover risks as early as possible in the project
lifecycle.
❖ The Risk can be defined as a situation involving exposure to danger. The main four types
of risks are:
a. Strategic Risk: For e.g. a competitor coming on to the market.
b. Compliance & Regulatory Risk: For e.g. introduction of new rules or legislation.
c. Financial Risk: For e.g. interest rate rise on your business loan or a non-paying
customer.
d. Operational Risk: For e.g. the breakdown or theft of key equipment.
❖ Many projects not only maintain a list of risks to the project but also define a Risk
Management Plan describing how the project risks will be identified, communicated, and
managed.
❖ For example, in Business, the risk management is defined as the process of identifying,
monitoring and managing potential risks in order to minimize the negative impact they
may have on an organization.
❖ Examples of potential risks include security breaches, data loss, cyberattacks, system
failures and natural disasters.
4. The Project Software Development Environment:
❖ In the Inception phase, the team's Software Development Environment is established.
❖ These tools support the disciplines, such as visual modeling, requirements management,
change request management, configuration management, and testing.
5. The Project Software Development Plan (SDP):
❖ Most contractors have company procedures that dictate the contents of an SDP.
❖ The SDP defines the methodologies, tools, and processes used to conduct the project. The
SDP should also define the estimated resources and roles needed for the project.
❖ It may also be possible at this point to estimate how many iterations the project will
require and their expected duration. But it is not possible to plan in detail the contents of
each iteration.
❖ It should be noted that the resource estimates, schedules, and so on produced in the SDP
are estimates only. As the project progresses, you must adjust these estimates. Therefore,
the SDP is an example of a “living and breathing” document that gets updated
periodically during the project.
❖ The RUP also suggests the optional creation of a product acceptance plan, which may be
contained within the SDP. In an outsourced project, a product acceptance plan is vital. It
states what the customer will consider proof that the project has been successfully
accomplished.
❖ The details of such a plan may not be completely known during Inception. But a draft of
the document should be produced and shared with the customer.
❖ Even if the detailed contents of the document are not completely known, the existence of
the document signals to the customer that you expect the customer to consider specific
criteria that will enable it to sign off on the project.
❖ Obviously, this document can and should be updated over time, and the document should
be shared with the contracting organization.
❖ I have seen several projects that have had difficulty coming to a conclusion because there
was no agreed upon criteria to indicate when the project was done. This is a source of
angst for both the customer and the contractor.
6. The Iteration Plan:
❖ The Iteration Plan is a detailed, fine-grained plan showing a list of activities and tasks
that are to be accomplished in a specific period of time. These tasks and activities are
driven by specific risks and requirements assigned to that iteration.
❖ The focus of the Iteration Plan changes from phase to phase. In the Inception phase,
examples of iterations might be to clarify the project's scope and vision, possibly through
the creation of prototypes. In general, an iteration should always produce something
executable; however, the Inception phase is the one exception to this rule.
❖ Iteration Plans cannot be produced reliably far in advance. The nature of iterative
development is such that an iteration's success (or failure) dictates the contents or order
of subsequent iterations. Consequently, detailed planning too far in advance will cause
those plans to be rewritten as the project progresses.
7. The Development Process:
❖ The RUP is a customizable process framework. For each project, a document
should be prepared explaining the development process to be used on the project
and which artifacts will be produced. This document is called a Development
Case. It is important to confer with the customer on the Development Case.
❖ On some projects, your Statement of Work may already specify what artifacts
are official deliverables to the customer. These may or may not map well to the
suggested artifacts defined by the RUP. Your Development Case should take this
into account.
8. The Project Glossary:
❖ Many are tempted to skip creating a glossary, because it seems like a trivial
exercise. But the glossary serves two purposes not immediately apparent:
✓ It helps those new to the project to get up to speed more quickly with the key
terms, abbreviations, and acronyms commonly in use on the project.
✓ Without a glossary, project personnel will learn the meaning of the terms
through osmosis. This is not a reliable or consistent way to learn the language
of the customer's environment. The glossary establishes a common repository
for the proper definitions of the terms used.
9. The Use Case Model:
❖ A Use Case Model should be created during the Inception phase that captures the
following:
✓ The system's key actors. This includes all the system's important users, as well as
other external entities, such as other systems, that must interface with the system
being built.
✓ The system's key use cases. You should identify the most important functionality
areas of the system to be built.
❖ Each area is a use case, and for each use case, the threads of functionality (flows) should
be explained step by step.
10. Optional Artifacts:
❖ The RUP also suggests some optional artifacts that may or may not be necessary during
the Inception Phase:
a. Business Analysis Model:
✓ If the system to be built involves a significant or complex business process, or workflow, a
Business Analysis Model should be built.
✓ This model describes the business rules of the organization that will use the system to be built.
✓ This model is created without regard for how the system will be implemented. This serves as a
reference when formulating the system's functional requirements.
b. Functional Prototypes:
❖ If there is significant uncertainty over the conceptual ideas presented in the
Vision Statement, a small prototype can be built. The purpose of the prototype
can be one or more of the following:
✓ Gain consensus on what the product's form or look and feel should be.
✓ Demonstrate viability of a new technology or to prove that the use of a new
technology is technically feasible.
✓ Explore certain aspects of a system's requirements that are particularly
risky, such as performance and throughput concerns.
✓ Gain the confidence of potential supporters of a system by producing a
proof-of-concept.
❖ FUNCTIONAL REQUIREMENTS & NON – FUNCTIONAL REQUIREMENTS:
✓ Functional Requirements specifically specify the input and output behavior of a system. Also
requirements that are not Functional in nature are called Non – Functional Requirements.
✓ Non – Functional Requirements describe only attributes of the system or attributes
of the system environment.
UNDERSTANDING REQUIREMENTS – THE FURPS+ MODEL:
What do Requirements Stand for???
❖ Requirements become a key focus of analysis activities in System / Software
Development Life Cycle (SDLC).
❖ Analysts spend most of their time to requirements: gathering information about
requirements, formalizing them through generating models and prototypes, refining and
expanding them, prioritizing them, and generating and evaluating such alternatives.
Because of this, we need to know or to have a clear definition of Requirements as:
❖ According to Satzinger, Jackson, & Burd, the System Requirements are all the activities
must perform or support and the constraints that the new system must meet.
❖ System Requirements are divided into “two” categories: Functional Requirements and
Non – Functional Requirements.
❖ Functional Requirements describe the behavior and information that the solution will
manage and describe capabilities the system will be able to perform in terms of
behaviors or operations – a specific system action or response.
✓ In a simpler word, Functional Requirements refer to the activities that the system
must perform based on the procedures and rules that the organization uses to run its
business, such as generating fund transfer electronically, calculating commission
amounts, calculating payroll taxes, and so on in a payroll system.
❖ Non – Functional Requirements refer to the characteristics of the system other than
those activities it must perform or support.
✓ Non – Functional Requirements used to describe attributes within the system, such
as how fast the system response to a specific command is, how efficient system
performs such tasks is, etc.,.
❖ Sometimes, it finds a little difficult to differentiate Functional Requirements from Non –
Functional Requirements. To distinguish those ‘two’ categories, the analysts use a
framework for identifying and classifying requirements that is most widely used and can
be called as “FURPS+”.
FURPS+ MODEL:
❖ “FURPS” is an acronym that stands for Functionality, Usability, Reliability,
Performance, and Security. The “F” letter in FURPS refers to the Functional
Requirements that have defined previously and the “remaining” letters in FURPS
describe the Non – Functional Requirements.
1. FUNCTIONALITY:
✓ The “F” in the FURPS+ acronym represents the main product features that are familiar
within the business domain of the solution being developed, simply called as “Functionality”.
✓ The Functional Requirements can also be very technically oriented.
2. USABILITY:
✓ “Usability” includes looking at, capturing, and stating requirements based around user
interface issues – things such as accessibility, interface aesthetics, and consistency within the
user interface.
3. RELIABILITY:
✓ “Reliability” includes aspects such as availability, accuracy, and recoverability – for example,
computations, or recoverability of the system from shut-down failure.
4. PERFORMANCE:
✓ “Performance” involves things such as throughput of information through the system, system
response time (which also relates to usability), recovery time, and start-up time.
5. SUPPORTABILITY:
✓ Finally, we tend to include a section called “Supportability”, where we specify a number of
other requirements such as testability, adaptability, maintainability, compatibility,
configurability, installability, scalability, localizability, and so on. (OR)
✓ It also describes the steps or procedures of systems installation, configuration, monitoring,
and maintenance.
6. SECURITY Requirements refer to the grant of access control to application and data
protection during storage and transmission.
+++++
❖ The “+” of the FURPS+ acronym allows us to specify constraints that includes design,
implementation, interface, and physical constraints.
1. DESIGN CONSTRAINTS:
✓ A design constraint, as the name implies, limits the design – for example, requiring a
relational database stipulates the approach that we take in developing the system.
✓ It also refers to restrictions to which the hardware and software must adhere (stick fast to).
2. IMPLEMENTATION CONSTRAINTS:
✓ An implementation constraint puts limits on coding or construction – standards, platform, or
implementation language.
✓ It also refers to constraints related to programming languages and tools, documentation
method and its level of detail, and so on.
3. INTERFACE CONSTRAINTS:
✓ An interface constraint is a requirement to interact with an external item.
✓ When you develop within an enterprise, quite often you have to interact with external
systems.
✓ It also refers to requirements / constraints related to interaction among systems, that might
be internal or external systems.
4. PHYSICAL CONSTRAINTS:
✓ The physical constraints affect the hardware characteristics of the system / hardware used to
house the system – for example, shape, size, and weight.
✓ It also refers to requirements / constraints that describe hardware characteristics in its size,
weight, electrical consumption, and operating conditions.
❖ Hence, the “FURPS+” acronym’s for FURPS as Functionality, Usability, Reliability,
Performance, and Supportability, with the plus (+) used to represent all other
requirements, such as design or implementation constraints. “FURPS+” classification
addresses both Functional Requirements and Non – Functional Requirements.
DEFINING REQUIREMENTS:
❖ Requirements are capabilities and conditions to which the system – and more broadly, the project
– must conform. A prime challenge of requirements – work is to find, communicate, and remember
(that usually means record) what is really needed, in a form that clearly speaks to the client and
development team members.
❖ The UP promotes a set of best practices, one of which is manage requirements. This does not refer
to the waterfall attitude of attempting to fully define and stabilize the requirements in the first
phase of a project, but rather – in the context of inevitably changing and unclear stakeholder's
wishes – “a systematic approach to finding, documenting, organizing, and tracking the changing
requirements of a system” [RUP]; in short, doing it skillfully and not being sloppy.
❖ Note the word ‘changing’, the UP embraces change in requirements as a fundamental driver on
projects. Finding is another important term; that is, skillful elicitation via techniques such as use
case writing and requirements workshops.
TYPES OF REQUIREMENTS:
❖ In the UP, requirements are categorized according to the FURPS+ Model [Grady Booch
Methodology], a useful mnemonic with the following meaning as:
1. Functional: features, capabilities, security.
2. Usability: human factors, help, documentation.
3. Reliability: frequency of failure, recoverability, predictability.
4. Performance: response times, throughput, accuracy, availability, resource usage, and
5. Supportability: adaptability, maintainability, internationalization, configurability.
❖ The “+” in FURPS+ indicates ancillary and sub-factors, such as:
1. Implementation: resource limitations, languages and tools, hardware, ...
2. Interface: constraints imposed by interfacing with external systems.
3. Operations: system management in its operational setting.
4. Packaging, and
5. Legal: licensing & so forth.
❖ It is helpful to use FURPS+ categories (or some categorization scheme) as a checklist for
requirements coverage, to reduce the risk of not considering some important facet of the system.
❖ Some of these requirements are collectively called the “quality attributes”, or “quality
requirements”, or the “-ilities” of a system. These include usability, reliability, performance, and
supportability. In common usage, requirements are categorized as functional (behavioral) or non-
functional (everything else); some dislike this broad generalization, but it is very widely used.
❖ Functional Requirements are explored and recorded in the Use-Case Model, the subject of the next
chapter, and in the system features list of the Vision artifact. Other requirements can be recorded
in the use cases they relate to, or in the Supplementary Specifications artifact.
❖ The Vision artifact summarizes high-level requirements that are elaborated in these other
documents. The Glossary records and clarifies terms used in the requirements. The Glossary in the
UP also encompasses the concept of the data dictionary, which records requirements related to
data, such as validation rules, acceptable values, and so forth. Prototypes are a mechanism to
clarify what is wanted or possible.
UNDERSTANDING USE CASE MODEL:
Introduction to Use Case Model:
❖ A Use Case Model describes the proposed functionality of a new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. This interaction is
a single unit of meaningful work, such as Create Account or View Account Details.
❖ Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case's functionality or extend another Use Case with its own behavior.
❖ A Use Case description will generally includes:
1. General comments and notes describing the use case.
2. Requirements: The formal functional requirements of things that a Use Case must provide to
the end user, such as <ability to update order>. These correspond to the functional
specifications found in structured methodologies, and form a contract that the Use Case
performs some action or provides some value to the system.
3. Constraints: The formal rules and limitations a Use Case operates under, defining what can
and cannot be done. These include:
a. Pre-conditions that must have already occurred or be in place before the use case is run; for
example, <create order> must precede <modify order>
b. Post-conditions that must be true once the Use Case is complete; for example, <order is
modified and consistent>
c. Invariants that must always be true throughout the time the Use Case operates; for example,
an order must always have a customer number.
4. Scenarios: Formal, sequential descriptions of the steps taken to carry out the use case, or the
flow of events that occur during a Use Case instance. These can include multiple scenarios, to
cater for exceptional circumstances and alternative processing paths. These are usually created
in text and correspond to a textual representation of the Sequence Diagram.
5. Scenario Diagrams: Sequence Diagrams to depict the workflow; similar to Scenarios but
graphically portrayed.
6. Additional attributes, such as implementation phase, version number, complexity rating,
stereotype and status.
WRITING USE CASES – GOALS & SCOPE OF A USE CASE:
WRITING USE CASES – GOALS & SCOPE OF A USE CASE: [Cont…]
❖ Use cases often need to be more elaborate than this, but the essence is discovering and
recording functional requirements by writing stories of using a system to help fulfill various
stakeholder goals; that is, cases of use. It isn't supposed to be a difficult idea, although it may
indeed be difficult to discover or decide what is needed, and write it coherently at a useful
level of detail.
❖ Much has been written about use cases, and while worthwhile, there is always the risk among
creative, thoughtful people to obscure a simple idea with layers of sophistication. It is usually
possible to spot a novice use-case modeler (or a serious Type A analyst) by an over-concern
with secondary issues such as usecase diagrams, use case relationships, use case packages,
optional attributes, and so forth, rather than writing the stories. That said, a strength of the
use case mechanism is the capacity to scale both up and down in terms of sophistication and
formality, depending on need.
❑BACKGROUND:
❖The idea of use cases to describe functional requirements was introduced in 1986 by
Ivar Jacobson, a main contributor to the UML and UP. Jacobson's use case idea was
seminal and widely appreciated; simplicity and utility being its chief virtues.
❖Although many have made contributions to the subject, arguably the most influential,
comprehensive, and coherent next step in defining what use cases are (or should be)
and how to write them came from Alistair Cockburn, summarized in the very
popular text Writing Effective Use Cases.
ELEMENTS & SECTIONS OF USE CASES:
USE CASES and ADDING VALUE:
❖ First, some informal definitions: an actor is something with behavior, such as a person
(identified by role), computer system, or organization; for example, a cashier.
❖ A scenario is a specific sequence of actions and interactions between actors and the system
under discussion; it is also called a use case instance. It is one particular story of using a
system, or one path through the use case; for example, the scenario of successfully
purchasing items with cash, or the scenario of failing to purchase items because of a credit
card transaction denial.
❖ Informally then, a use case is a collection of related success and failure scenarios that
describe actors using a system to support a goal. For example, here is a casual format use
case that includes some alternate scenarios:
❑ HANDLE RETURNS:
❖ Main Success Scenario:
✓ A customer arrives at a checkout with items to return. The cashier uses the POS system to
record each returned item...
❖ Alternate Scenarios:
✓ If the credit authorization is reject, inform the customer and ask for an alternate payment
method.
✓ If the item identifier is not found in the system, notify the Cashier and suggest manual entry of
the identifier code (perhaps it is corrupted).
✓ If the system detects failure to communicate with the external tax calculator system, ...
ELEMENTS & SECTIONS OF USE CASES: [Cont…]
USE CASES and ADDING VALUE:
❑ HANDLE RETURNS:
❖ An alternate, but similar definition of a use case is provided by the RUP:
✓ A set of use-case instances, where each instance is a sequence of actions a system
performs that yields an observable result of value to a particular actor [RUP].
❖ The phrasing “an observable result of value” is subtle but important, because it stresses the
attitude that the system behavior should emphasize providing value to the user.
✓ A key attitude in use case work is to focus on the question “How can using the system
provide observable value to the user, or fulfill their goals?”, rather than merely thinking
of system requirements in terms of a "laundry list" of features or functions.
USE CASES and FUNCTIONAL REQUIREMENTS:
❖ Use Cases are Requirements; primarily they are Functional Requirements that indicate “what the
system will do”. In terms of the FURPS+ requirements types, they emphasize the “F” (functional
or behavioral), but can also be used for other types, especially when those other types strongly
relate to a use case.
❖ In the UP – and most modern methods – Use Cases are the central mechanism that is
recommended for their discovery and definition.
❖ Use Cases define a promise or contract of how a system will behave. To be clear: Use Cases are
Requirements (although not all requirements).
❖ Some think of Requirements only as “the system shall do...” as function or feature lists can be
defined as older style and rather than new, i.e., Write Use Cases for the Functional Requirements.
❖ Use Cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing. However, the UML defines a USE CASE DIAGRAM to illustrate
the names of use cases and actors, and their relationships.
USE CASE TYPES and FORMATS:
❑ Black – Box Use Cases and System Responsibilities:
❖ Black – Box Use Cases are the most common and recommended kind; they do not describe the
internal workings of the system, its components, or design. Rather, the System is described as
having Responsibilities, which is a common unifying metaphorical theme in object-oriented
thinking – software elements have responsibilities and collaborate with other elements that have
responsibilities.
❖ By defining System Responsibilities with Black – Box Use Cases, it is possible to specify what the
system must do (the Functional Requirements) without deciding how it will do it (the Design).
❖ Indeed, the definition of “analysis” versus “design” is sometimes summarized as “what” versus
“how”. This is an important theme in good software development: During requirements analysis
avoid making “how” decisions, and specify the external behavior for the system, as a Black – Box.
Later, during design, create a solution that meets the specification.
USE CASE TYPES and FORMATS:
❑ Formality Types:
❖ Use Cases are written in different formats, depending on need. In addition to the black-
box versus white-box visibility type, use cases are written in varying degrees of formality:
✓ Brief: terse one-paragraph summary, usually of the main success scenario. The prior
Process Sale example was brief.
✓ Casual: informal paragraph format. Multiple paragraphs that cover various
scenarios. The prior Handle Returns example was casual.
✓ Fully Dressed: the most elaborate. All steps and variations are written in detail, and
there are supporting sections, such as preconditions and success guarantees.
❖ The following example is a fully dressed case for our Nextgen Case Study:
❑Fully Dressed Example: PROCESS SALE
❖ Fully Dressed Use Cases show more detail and are structured; they are useful in order
to obtain a deep understanding of the goals, tasks, and requirements.
❖ In the Nextgen POS Case Study, they would be created during one of the early
requirements workshops in a collaboration of the system analyst, subject matter
experts, and developers.
USE CASE TYPES and FORMATS:
❑ Fully Dressed Example: PROCESS SALE
➢ The Usecases.org Format
✓ Various format templates re available for fully dressed use cases. However, perhaps the most widely
used and shared format is the template available at www.usecases.org. The following example
illustrates this style for our NextGen POS Case Study with its common elements and issues like:
USE CASE TYPES and FORMATS:
❑ Fully Dressed Example: PROCESS SALE
USE CASE TYPES and FORMATS:
❑ Fully Dressed Example: PROCESS SALE
USE CASE TYPES and FORMATS:
❑ Fully Dressed Example: PROCESS SALE
USE CASE TYPES and FORMATS:
❑ Fully Dressed Example: PROCESS SALE
USE – CASE MODEL: WRITING REQUIREMENTS IN CONTEXT
❑ The Two – Column Variation: PROCESS SALE in NextGen POS System
❖ Some prefer the two-column or conversational format, which emphasizes the fact that
there is an interaction going on between the actors and the system. It was first proposed
by Rebecca Wirfs-Brock in 1993, and is also promoted by Constantine and Lockwood to
aid usability analysis and engineering in 1999. Here is the same content using the two-
column format with reference to Fully – Dressed Format for POS System is:
USE – CASE MODEL: WRITING REQUIREMENTS IN CONTEXT
❑ The Two – Column Variation: PROCESS SALE in NextGen POS System

USE – CASE MODEL: EXPLAINING ELEMENTS & SECTIONS

USE – CASE MODEL: EXPLAINING ELEMENTS & SECTIONS
USE – CASE MODEL: EXPLAINING ELEMENTS & SECTIONS
USE – CASE MODEL: EXPLAINING ELEMENTS & SECTIONS
USE – CASE MODEL: EXPLAINING ELEMENTS & SECTIONS
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE

❑ Use Cases for Elementary Business Processes (EBP):

❖ Which of these is a Valid Use Case?
✓ Negotiate a Supplier Contract,
✓ Handle Returns, and
✓ Log In.
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ Use Cases for Elementary Business Processes (EBP):
❖ Which of these is a Valid Use Case?
✓ Negotiate a Supplier Contract,
✓ Handle Returns, and
✓ Log In.
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ Use Cases and Goals:
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ FINDING PRIMARY ACTORS, GOALS, AND USE CASES:
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ FINDING PRIMARY ACTORS, GOALS, AND USE CASES:
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ FINDING PRIMARY ACTORS, GOALS, AND USE CASES:
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ FINDING PRIMARY ACTORS, GOALS, AND USE CASES:
USE – CASE MODEL: GOALS & SCOPE OF A USE CASE
❑ FINDING PRIMARY ACTORS, GOALS, AND USE CASES:
USE – CASE MODEL: WRITING REQUIREMENTS IN CONTEXT
USE – CASE MODEL: WRITING REQUIREMENTS IN CONTEXT

USE – CASE DIAGRAMS:

❖ The UML provides Use Case Diagram notation to illustrate the names of use cases can actors, and the
relationships between them.
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS:
USE – CASE DIAGRAMS: