04 Requirements

310414
310414
SOFTWARE
SOFTWARE ENGINEERING
ENGINEERING
SYSTEM
SYSTEM REQUIREMENTS
REQUIREMENTS CAPTURE
CAPTURE
310414
REQUIREMENTSCAPTURE 1/67
SYSTEMREQUIREMENTSCAPTUREOUTLINE
System Requirements Capture Unified Process Overview
Importance & Difficulty
Capturing & Documenting Requirements
Life Cycle Role
System Requirements Capture Unified Process Activities

Domain Modeling
Use-Case Modeling
User-interface Specification & Prototyping
System Requirements Validation
310414
SYSTEMREQUIREMENTSCAPTURE
requirement
a feature that the system must have or a constraint that it must satisfy
to be accepted by the customer
requirements capture (gathering, elicitation, ...)
learning about the problem that needs a solution

specifying (in detail) the required features/constraints of the system in a
way that the customer/user understands and can approve
requires the collaboration of
several groups of participants

with different backgrounds
Knowledge
GAP
CHALLENGE:
CHALLENGE:How
Howto
tobridge
bridgethis
thisgap?
gap?
310414
4.1
IMPORTANCEOFREQUIREMENTSCAPTURE1
Reasons for failure of/problems
of/problems with
with software
software development:
development:
incomplete requirements
requirements
13.1%
13.1%
lack of user involvement

involvement
12.4%
12.4%
lack of resources
10.6%
10.6%
unrealistic expectations
expectations
9.9%
9.9%
lack of executive support

support
9.3%
9.3%
changing requirements
requirements and
and specifications
specifications
8.7%
8.7%
lack of planning
8.1%
8.1%
system no longer needed

needed
7.5%
7.5%
> 50%
Requirements capture is involved in a majority of cases

310414
IMPORTANCEOFREQUIREMENTSCAPTURE2
costtofind
andfixadefect
100
60100
log
scale
10.00
10
0.75
1.00
Reqmts
Design
1.50
Code
3.00
Test
System
test
BUT, requirements capture is VERY DIFFICULT!

310414
Field
use
WHYREQUIREMENTSCAPTUREISDIFFICULT
Our aim is to build the right system
a system that meets the users needs
but, users often do not know what they need!

many types of users (only know their own work and needs)
may not see the big picture (do not know entire flow of work)
may not know which aspects of their work can be computerized
for the software engineer, requirements capture is often a

discovery and learning process
need to get users to understand what we have

captured and to approve that it meets their needs
Major
challenges
users need to be able to understand our specifications
but, user is usually not a computer specialist!

310414
REQUIREMENTSCAPTUREPROCESSOVERVIEW
Identify and understand user needs

define the goals of the system
compile list of system constraints
compile list of candidate requirements
define development effort scope
Determine feasibility
economic feasibility
operational feasibility
technical feasibility
organizational impact
Understand, capture and document system requirements

static (persistent data)
(domain model + specifications)
dynamic (processing + constraints)

(use-case model + specifications)
Validate the system requirements

criteria for user acceptance of the completed system (acceptance tests)
every
everysoftware
softwareproject
projectis
isunique
unique>
>need
needto
toadapt
adaptour
ourprocess
process
310414
4.5.1
USERNEEDSIDENTIFICATION
collect data on application domain (may include existing system)

investigation existing documentation
observation work practices
interviews questionnaires, personal
prototyping interface, functions
challenge customers/users model of reality
elicit problems, not solutions
distinguish needs from wants; rate importance of needs
refine system goals, list of requirements, list of constraints ,

system scope, etc.
propose scope of project (what is included, what is excluded)
document requirements system requirements specification
serves as a contract between the customer and developer!
310414
FEASIBILITYDETERMINATION
Can we/should we build the system?
economic feasibility
costs (development, operation) versus benefits

tangible versus intangible
technical feasibility
availability of technology risk of new technology?

maintenance required
operational feasibility
availability of skills to operate the system

fit with current work practices (redesign work practices?)
organizational feasibility
politics; training; user acceptance; . . .
legal feasibility
liability; copyright; patent; . . .
310414
CAPTUREANDDOCUMENTSYSTEMREQUIREMENTS
static requirements (persistent data) domain model
describes the important concepts of the application domain as classes
allows the development of a glossary of terms (data dictionary) for

communicating among everyone on the project
dynamic requirements (processing+constraints) use-case model

functional requirements - describe the interactions between the system
and its environment independent of its implementation
nonfunctional requirements - describe user-visible aspects of the system
that are not directly related with the functional behaviour of the system
e.g., response time, throughput, security, etc.
pseudo requirements - describe restrictions on the implementation of the

system imposed by the customer
e.g., implementation language, platform, etc.
Requirements should only state

what is needed not how it is done
310414
REQUIREMENTSCAPTURELIFECYCLEROLE
CoreWorkflows
Inception
Phases
Elaboration
Construction
Transition
Requirements
Iteration
Analysis
Design
Implementation
Testing
iter.
#1
iter.
#2
iter.
#n-1
iter.
#n
Increments
310414
ARTIFACTS&WORKERS
System
Analyst
Domain
Analyst
UseCase
Specifier
UserInterface
Designer
Architect
responsiblefor
responsible
for
responsible
for
responsible
for
responsible
for
Domain UseCase Actors Glossary

Domain
Model Model
Specification
310414
Userinterface
UseCase
Architecture
Specification&
Specification
Description
Prototyping
UPSYSTEMREQUIREMENTSCAPTUREPROCESS
System
Analyst
FindClasses
FindActorsand
andAssociations
UseCases
Domain
Analyst
Architect
UseCase
Specifier
UserInterface
Designer
310414
Structurethe
UseCaseModel
DetailClasses
andAssociations
Prioritize
UseCases
Detail
UseCases
Prototype
UserInterface
DOMAINMODELING
captures the most important classes and their associations in the

context of the system
things that exist or events that occur in the systems environment
found from
high-level problem statement

lower-level requirements
domain experts (users)
imperative that this be done well so as to establish a
solid foundation and to allow reuse by other systems
classes can be:
business objects (e.g., orders, accounts, etc.)

real-world objects and concepts (e.g., suppliers, customers, etc.)
events (e.g., aircraft arrival/departure, sales, reservations, etc.)
310414
described in a class diagram static system structure

IDENTIFYINGCLASSES&ASSOCIATIONS
naturally occurring things or concepts in the application domain

classes often appear as nouns/noun phrases in application
domain terminology
associations often appear as verbs/verb phrases in application
domain terminology
circle or highlight in problem description
put all terms into singular form/active voice
identify only relevant classes those that are essential

throughout the systems life cycle
leads to a stable system
decomposition
decompositionof
ofaaproblem
probleminto
intoclasses
classesand
andassociations
associationsdepends
depends
on
onjudgement
judgementand
andexperience
experienceand
andthe
thenature
natureof
ofthe
theproblem
problem
310414
DOMAINMODELKEEPINGTHERIGHT
CLASSES
Are any classes redundant?
Are any classes irrelevant to the application domain?
Are any classes vague (ill-defined)?
Should any classes really be attributes?
Do any classes describe an operation?
Do any class names describe a role?
Do any classes describe implementation constructs?
310414
ASSOCIATIONS
Are there any associations between eliminated classes?
Are any associations irrelevant to the application domain?
Do any associations describe an operation?
Can ternary associations be decomposed into binary associations?
Are any associations derived associations?
Are any associations named with how or why names?
Are role names required for any associations?
Should any associations be qualified?
Are multiplicity, ordering specifications missing?
Do any associations describe implementation constructs?
310414
ATTRIBUTES
Are attributes closely related to the class they are in?
Should any attributes really be classes?
Should any attributes be qualifiers?
Have object identifiers been included as attributes?
Should any attributes be in an association class?
310414
DOMAINMODELDETAILATTRIBUTES
meaningful name
itemPrice not itpr
allowable values
short description
payment - a transaction to record a
remittance
deposit - the initial amount paid by the
company on a purchase order
aliases
synonyms - same meaning, but

different name
customer = client
acronyms - shortened name
requisitionNumber = requisNum, reqNo
length as found in the real world
number of digits or letters
310414
continuous - a range of values

price: $0 to $10,000
need to note: range
typical values
exception handling
discrete - only allow certain values
marital-status: single, married,
widowed, divorced
need to note: values and meaning
of each (if coded)
encoding - physical representation

of the value
only if no choice allowed in design

phase
supplementary - other information

relevant to use of the attribute
DOMAINMODELDETAILCLASSES&
ASSOCIATIONS
for each class we can add any operations that we are aware of
at this stage
most operations will be added during analysis & design
for each association we need to specify (if known):

a name (optional)
role names (as necessary)
multiplicity
association class (if necessary)
310414
Place all domain model terms and their definitions in a

glossary of terms/data dictionary
DOMAINMODELDETAILGENERALIZATION
classify classes according to similarity of attributes and

operations
look for kind-of statements that are true in the real world
do not nest too deeply

2-3 levels OK
4-6 levels maybe
10 levels too deep!
Goal: simplicity of representation and modeling clarity
Need to decide how to handle associations

in which subclasses participate
310414
(contd)
Person
Professor
District
Student
*
LivesIn
LivesIn
1
310414
LivesIn
District
(contd)
Person
Professor
*
StudiesIn
LivesIn
District
LivesIn
LivesIn
1
1
Student
310414
USECASEMODELINGEXAMPLE
A video sales and rental shop would like to computerize its management of sales and
rental of its movie videos. As well, it would like to establish a presence on the Web and
allow its customers to rent and buy videos via the Web. Below are the high-level
requirements for a system that will manage the sale and rental of videos for the video
shop:
The system must be able to keep track of which movie videos have been
bought/rented and by whom. For videos bought, the system must record the
quantity bought; for videos rented, the system must record which copy of the
video has been rented and when it is due back.
The system must keep track of overdue rental videos and allow notices to be sent
to customers who have videos overdue.
The video shop will have a customer membership option for an annual fee, which
will entitle the member to discounts (10%) on video sales and rentals.
Members should be able to make reservations for movie video rentals either in
person at the store, by telephone or via the Web.
A member can reserve at most five movie videos at any one time, but there is no
limit on how many movie videos a member or nonmember can rent at any one
time.
As an added feature, the video shop would like to allow customers (either
members or nonmembers) to input, via the Web, mini-reviews (up to 100 words)
310414
USECASEMODELINGEXAMPLE(contd)
and a rating (from 1, lowest, to 5, highest) of movies they have rented. These
reviews should be anonymous if the customer so wishes (i.e., the customer can
specify whether or not he wants his name to be made known when other
customers browse the reviews).
The video shop maintains the following information about all customers (members
or nonmembers): name, address, phone number, fax number, age, sex, and email
address. In addition, members are assigned a membership number by the video
shop when they become members and a password, which allows them to access
the members-only area of the video shop's web site, including accessing and
changing their personal information.
Using the Web, customers should be able to buy and rent videos and browse the
reviews entered by other customers.
Managers must be able to generate various reports on sales/rentals of videos.
Staff must be able to sell/rent videos from the stores inventory and return rented
videos to the store's inventory.
When selling or renting videos, staff must be able to look up customer information
and determine whether the customer is a member.
An employee must be able to enter the basic information about a movie video
(i.e., title, leading actor(s), director, producer, genre, synopsis, release year,
running time, selling price, and rental price).
310414
DOMAINMODELINGEXAMPLEANALYSIS
We first analyze the stated domain model requirements and then present the domain
model.
310414
Members should be able to make reservations for movie video rentals either in person at
the store, by telephone or via the Web.
time.
310414
The video shop maintains the following information about all customers (members or
nonmembers): name, address, phone number, fax number, age, sex, and email
the member's only area of the video shop's web site, including accessing and
310414
When selling or renting videos, staff must be able to look up customer information and
determine whether the customer is a member.
310414
2.2.1;2.4.1
USECASEMODELING
captures the system behavior from the users point of view
developed in cooperation with the domain model
helps in:
capturing data and functional requirements
planning iterations of development
validating the system
dynamic model gets started with use-case analysis

drives the entire development effort
all required functionality is described in the use cases
310414
use-case model is developed incrementally

4.4.1
USECASEMODELACTORS
Something outside the system
that interacts directly with it
actorname
can be people or other systems

provides input to or takes output from the system
a role a user can play multiple roles per user;
multiple users per role
actors are the source for discovering use cases
An actor is a stereotype of class

an actor is a classifier; a specific user is an instance
310414
IDENTIFYINGACTORS
Who or what uses the system?
What roles do they play in the interaction?
Who gets and provides information to the system?
Who installs, starts and shuts down or maintains the system?
What other systems interact with this system?
Does anything happen at a fixed time?
Input devices are not actors!

It is common to have both a domain model class
and an actor that represent the same thing.
Time can be an actor.

For each actor, briefly the describe role it plays
when interacting with the system.
310414
2.4.1;4.4.3
USECASEMODELUSECASE
usecasename
A specific way of using the system by

performing some part of its functionality
specifies the interaction that takes place between
an actor and the system
considered from the users viewpoint
constitutes a complete sequence of events/actions
initiated by an actor
initially, we are only concerned with the normal or usual sequence of

events/actions
ignore exceptions, alternate ways of doing things
A use case is a stereotype of class

use case is a classifier; scenario is an instance
310414
IDENTIFYINGUSECASES
What are the tasks that an actor wants the system to perform?
What information does an actor access (create, store, change,
remove, or read) in the system?
Which external changes does an actor need to inform the system
about?
Which events does an actor need to be informed about by the
system?
How will the system be supported and maintained?
use case name should be stated from the perspective of the

user as a present-tense, verb phrase in active voice
provide a description of the purpose of the use case

and a high-level definition of its functionality
use application domain terms in descriptions

310414
ASUUSECASES
At the beginning of each semester, students may request a course catalog
containing a list of course offerings needed for the semester. Information about each
course, such as instructor, department, and prerequisites are included to help
students make informed decisions.
The new system will allow students to select four course offerings for the coming
semester. In addition, each student will indicate two alternative choices in case a
course offering becomes filled or is canceled. No course offering will have more than
ten students or fewer than three students. A course offering with fewer than three
students will be canceled. Once the registration process is completed for a student,
the registration system sends information to the billing system so the student can be
billed for the semester.
310414
ASUUSECASES
Professors must be able to access the online system to indicate which courses they
will be teaching, and to see which students signed up for their course offerings.
For each semester, there is a period of time that students can change their
schedule. Students must be able to access the system during this time to add or
drop courses.
310414
2.4.1;4.4.2
USECASEMODELSCENARIO
AAconcrete
concrete,,focused
focused,,informal
informaldescription
descriptionof
ofaasingle
single
use
useof
ofthe
thesystem
systemfrom
fromthe
theviewpoint
viewpointof
ofaasingle
singleactor
actor
an attempt to carry out a use case
types of scenarios used in software development

as-is
- describes a current situation (used to understand the

current system)
visionary
- describes a future system
evaluation - describes user tasks to be used to evaluate the system

(e.g., acceptance tests)
training
- used for introducing new users to the system
used to gain a shared understanding between
developers and users of what the system should do
310414
IDENTIFYINGSCENARIOS
Since scenarios are instances of use cases, the same
questions can be asked as for identifying uses cases.
Note: two viewpoints of use-case modeling
1. top-down: start with use cases, refine with scenarios
2. bottom-up: start with scenarios, abstract use cases
In reality, the use case specifier uses both viewpoints
310414
BUT scenarios mostly used to describe

errors and alternate flows
WHATISAGOODUSECASE?
A use case typically represents a major piece of
functionality that is complete from beginning to end.
A use case must deliver something of value to an actor.
Consider students in ASU Course Registration System:
select courses
be added to course offerings
be billed
dealswithonecomplete
sequenceofevents/actions
Consider Registrar in ASU Course Registration System:

add courses
delete courses
modify courses
dealswiththesame
classofobjects
Generally,
Generally,ititis
isbetter
betterto
tohave
havelonger
longerand
andmore
more
extensive
extensiveuse
usecases
casesthan
thansmaller
smallerones
ones
310414
USECASEDETAILFLOWOFEVENTS
AAprecise
precise,,but
buteasy
easyto
toread
read,,description
descriptionof
ofthe
thesequence
sequence
of
ofactions
actionsneeded
neededto
toaccomplish
accomplishaascenario/use
scenario/usecase
case
what the system and the actor should do to perform the actions
(not how it is done; ignore use case interactions)
Basic path: shows one complete normal path from start to end
no errors, no exceptions (always required).
Alternate paths: show exceptional conditions or errors.
start with basic path, then add alternate paths as needed

Goal: specify everything the user might do
310414
USECASEDETAILUSECASESPECIFICATION
use case name
participating actors
preconditions (usually on the system state; relevant to this use case)

things that must be true before the use case can execute
flow of events
required order of actions the normal sequence of events

what interaction the use case has with the actors
what data is needed by the use case
postconditions (usually on the system state; relevant to this use case)

things that must be true at the end of the use case execution
special requirements (if any)
alternate or exceptional flows (if any)

Narrative should be event-response oriented
(i.e., The system does X. The user does Y. etc.)
310414
USECASEDETAILFLOWOFEVENTS
SPECIFICATION
sequence of short steps that are numbered, declarative, and timeordered

n. The something some-action.
branching
n. If boolean-expression
n.1. declarative-statement
n.3.
n+1.
repetition should be used

sparingly!
use-case specification should
be kept as simple as possible
310414
(e.g., 3. The user enters a login id.)
repetition: For
n. For iteration-expression
n.3.
n+1.
repetition: While
n. While boolean-expression
n.3.
n+1.
2.4.1
USECASEMODELDETAILGENERALIZATION
Since
Sinceactors
actorsand
anduse
usecases
casesare
are
classifiers,
classifiers,they
theycan
canbe
begeneralized.
generalized.
Validateuser
Employee
Checkpassword
Salesclerk
Manager
310414
Retinalscan
represents a design decision!

2.4.1;4.4.5
USECASEDETAILINCLUDE
many use cases may share pieces of the same functionality

we can factor out this functionality, place it in a separate use case
and relate it to all use cases that need to use it by an
<<include>> relationship
Validateuser
<<include>>
Registerforcourses
<<include>>
Selectcoursestoteach
includeusecase
(usuallynotinvoked
directlybyuser)
<<include>>
Requestenrollmentlist

310414
mainusecases
(invokeddirectly
byuser)
2.4.1;4.4.5
USECASEDETAILEXTEND
specifies how a use case description may be inserted into, and

thus extend, an existing use case
models conditional additions
to a use cases sequence of
actions
main
usecase
used to show:
extend
usecase
Invalidsemester
<<extend>>
(semesterinvalid)
Selectcoursestoteach
extension
pointlabel
optional behavior
behavior that is executed only under certain conditions
several different subflows that are executed based on the selection of a
particular actor
310414

4.4.7
IDENTIFYINGNONFUNCTIONALREQUIREMENTS
user-visible system properties that cannot be expressed as use

cases, but often place constraints on the use cases
performance (time and throughput) requirements
reliability requirements
the environment in which the software is to operate
possible error sources and suitable measures for the prevention of
such errors and/or the minimization of their effect
constraints on implementation hardware, quality, etc.
life-cycle considerations schedule, budget, etc.
Captured as supplementary requirements

on use cases or on the system as a whole
310414
USECASESTHROUGHTHEDEVELOPMENT
Planning
Basis for negotiation with customer
determine which use cases to provide in the first release
Political aspects
Demonstrate the system doing something valuable to the most
influential people first
use knowledge about how much each user wants their use case
Technical aspects
Deliver the highest risk use cases first
use knowledge from risk analysis
System validation
walk the use case to see if it can provide the required functionality
310414
USECASEMODELINGEXAMPLE
A video sales and rental shop would like to computerize its management of sales and
rental of its movie videos. As well, it would like to establish a presence on the Web and
allow its customers to rent and buy videos via the Web. Below are the high-level
requirements for a system that will manage the sale and rental of videos for the video
shop:
time.
310414
USECASEMODELINGEXAMPLE(contd)
The video shop maintains the following information about all customers (members
or nonmembers): name, address, phone number, fax number, age, sex, and email
the members-only area of the video shop's web site, including accessing and
When selling or renting videos, staff must be able to look up customer information
and determine whether the customer is a member.
310414
USECASEMODELINGEXAMPLEANALYSIS
We first analyze the functional requirements of the system and then present the usecase model. Note that for the purposes of producing the use-case model, we are
only really interested in those functional requirements that provide something of
value for some actor.
The system must keep track of overdue rental videos and allow notices to be
sent to customers who have videos overdue.
310414
The video shop will have a customer membership option for an annual fee, which will
entitle the member to discounts (10%) on video sales and rentals.
time.
310414
As an added feature, the video shop would like to allow customers (either members
or nonmembers) to input, via the Web, mini-reviews (up to 100 words) and a rating
(from 1, lowest, to 5, highest) of movies they have rented. These reviews should be
anonymous if the customer so wishes (i.e., the customer can specify whether or
not he wants his name to be made known when other customers browse the
reviews).
The video shop maintains the following information about all customers
(members or nonmembers): name, address, phone number, fax number, age,
sex, and email address. In addition, members are assigned a membership
number by the video shop when they become members and a password, which
allows them to access the members-only area of the video shop's web site,
including accessing and changing their personal information.
310414

When selling or renting videos, staff must be able to look up customer

information and determine whether the customer is a member or not.
310414
310414
4.3.4
VALIDATESYSTEMREQUIREMENTS
requirements should be continuously validated with the customer

and the user and they should be:
correct - represent the customers view of the system
everything in the requirements model accurately represents an
aspect of the system
complete - all possible scenarios through the system are described,

including exceptional behaviour
all aspects of the system are represented in the
requirements model
consistent - do not contradict themselves

unambiguous - exactly one system is defined
it is not possible to interpret the specification two or more
different ways
realistic - the system can be implemented within the constraints
310414
VALIDATEREQUIREMENTSACCEPTANCETESTS
Tests
Testsmust
mustbe
bespecified
specifiedthat
thatwill
willdemonstrate
demonstrateto
tothe
thecustomer
customerthat
that
all
allfunctions
functionsand
andconstraints
constraintsof
ofaasystem
systemare
arefully
fullyoperational
operational
Functional validity does the system provide the required functionality

and obey the required constraints?
Show that a professor can select a course offering to teach.
Show that a student cannot register for more than four courses.
Interface validity do interfaces perform desired functions (accept

desired input/provide desired output) and follow consistent design
standards?
Show that all required data for course registration can be input.
Information content are the data structures/data bases correct (store

the right data in the required format)?
Show that all required information of a students course schedule is shown.
Performance does the system meet specified performance criteria?

Show the response time to register for a course is less than 1 second.
310414
DERIVINGANACCEPTANCETESTPLAN
restate written requirements in a concise, precise and testable

way
group related requirements
remove any requirements that cannot be tested
add any additional requirements gathered from users

look at use cases for functional and interface requirements
look at domain model for information content requirements
look at nonfunctional requirements for performance requirements
construct, for each requirement, an evaluation scenario that

will demonstrate to the customer that the requirement is met
(since most evaluation scenarios depend on the user interface,
they can not be completed until the user interface is designed)
310414
SUMMARYSYSTEMREQUIREMENTSCAPTURE
requirements are captured over several iterations by specifying:
a domain model
a use-case model
initial user interfaces (and building some user interface prototypes)
an acceptance test plan
These are all documented in the

System Requirements Specification (SRS)
Use cases drive the subsequent iterations/phases
in subsequent iterations/phases we refine and/or transform the

requirements by specifying:
310414
more detail for each of the above artifacts

matching use-case realizations in analysis model
matching use-case realizations in design model
a set of test cases in the test model

04 Requirements

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

04 Requirements

Diunggah oleh

Hak Cipta:

Format Tersedia

310414

System Requirements Capture Unified Process Activities

requirements capture (gathering, elicitation, ...)

learning about the problem that needs a solution

requires the collaboration of

several groups of participants

lack of user involvement

lack of executive support

system no longer needed

Requirements capture is involved in a majority of cases

BUT, requirements capture is VERY DIFFICULT!

but, users often do not know what they need!

for the software engineer, requirements capture is often a

need to get users to understand what we have

users need to be able to understand our specifications

but, user is usually not a computer specialist!

Identify and understand user needs

compile list of system constraints

compile list of candidate requirements

define development effort scope

Understand, capture and document system requirements

dynamic (processing + constraints)

Validate the system requirements

collect data on application domain (may include existing system)

refine system goals, list of requirements, list of constraints ,

costs (development, operation) versus benefits

availability of technology risk of new technology?

availability of skills to operate the system

politics; training; user acceptance; . . .

liability; copyright; patent; . . .

static requirements (persistent data) domain model

describes the important concepts of the application domain as classes

allows the development of a glossary of terms (data dictionary) for

dynamic requirements (processing+constraints) use-case model

pseudo requirements - describe restrictions on the implementation of the

Requirements should only state

Domain UseCase Actors Glossary

captures the most important classes and their associations in the

high-level problem statement

classes can be:

business objects (e.g., orders, accounts, etc.)

described in a class diagram static system structure

naturally occurring things or concepts in the application domain

identify only relevant classes those that are essential

leads to a stable system

Are any classes redundant?

Are any classes irrelevant to the application domain?

Are any classes vague (ill-defined)?

Should any classes really be attributes?

Do any classes describe an operation?

Do any class names describe a role?

Do any classes describe implementation constructs?

Are there any associations between eliminated classes?

Are any associations irrelevant to the application domain?

Do any associations describe an operation?

Can ternary associations be decomposed into binary associations?

Are any associations derived associations?

Are any associations named with how or why names?

Are role names required for any associations?

Should any associations be qualified?

Are multiplicity, ordering specifications missing?

Do any associations describe implementation constructs?

Are attributes closely related to the class they are in?

Should any attributes really be classes?