Requirements Analysis: Domain Modeling

Requirements Analysis Activities

• Capture Data Requirements: Domain Modeling
• Capture Functional Requirements: Use-Case Modeling
• Capture Nonfunctional Requirements
• Validate System Requirements (Discussed in Part 12)

The SRS documents the system requirements.

⚫

• It is the official statement of what is required of the system.
• It should include both a definition of user requirements and a specification of the system requirements.

It is NOT a design document.

⚫

• It should state WHAT the system should do, but not HOW it should do it.

NOTE: Many agile methods argue that producing a SRS is a waste

of time as requirements change so quickly.

➔ System Requirements Capture Activities

☞ Capture Data Requirements: Domain Modeling

• Capture Functional Requirements: Use-Case Modeling
• Capture Nonfunctional Requirements
• Validate System Requirements

Captures the most important classes and their associations.

⚫

☞

Things that exist or events that occur for which data must be stored.

⚫

The classes and associations are found from user requirements:

• requirements statement
  • domain experts (users)

The 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.) Provides a Described in a class diagram. glossary of terms.

Attributes usually correspond to nouns followed by possessive

⚫

phrases e.g., password of student; student's address.

Adjectives usually represent specific enumerated values

⚫

e.g., Fall term; PhD degree.

Only identify attributes that directly relate to the application

⚫

domain.

Most attributes will not be given in a requirements statement and will

have to be obtained from domain experts or application documentation.

Are any classes irrelevant to the domain model? → eliminate

⚫

☞

A class should represent persistent data, not transient data.

Are any classes vague (ill-defined)? → makespecific or eliminate

⚫

☞

A class should be specific and well-defined.

Are any classes redundant? → keep most descriptive

⚫ ⚫

Should any classes really be attributes? → consider application requirements ☞

Is the concept dependent or independent?

Do any class names describe a role?

⚫

☞

Roles also appear as nouns!

Do any classes describe an operation/action? → eliminate

⚫ ⚫

Do any classes describe implementation constructs? → eliminate

Are attributes closely related to the class they are in?

⚫

☞

A class should be simple and coherent.

Should any attributes really be classes?

⚫

☞

The concept should be dependent on the class.

Should any attributes be in an association class?

⚫

☞

Does the attribute depend on the existence of an association?

Have object identifiers been included as attributes?

⚫

☞

Object identifiers should not be included in the domain model!

For each class we specify its attributes.

⚫

• Each class is assumed to have two standard operations, get and set, which do not need to be specified.

⚫

For each

attribute we specify

• name (unique within a class)
• type (e.g., string, integer, date, etc.)
• multiplicity (if greater than 1)

For each association we specify

⚫

• name → should say “ what ” not “how” or “why”
• role names (if needed)
• multiplicity (if known)
• association class (if needed)

SYSTEM REQUIREMENTS

ANALYSIS

DOMAIN MODELING EXERCISE

1. Movie Shop System (5.1.1)
2. PSU Registration System(5.1.2)