Requirements Analysis Modeling Requirements analysis modeling helps - - PowerPoint PPT Presentation

• R. Kuehl/J. Scott Hawker
• p. 1

R I T

Software Engineering

Requirements Analysis Modeling

Requirements analysis modeling helps transition from elicitation to specification, from stakeholder to engineering view

Analysis – the detailed examination of something for explanation or interpretation

• R. Kuehl/J. Scott Hawker
• p. 2

R I T

Software Engineering

From Requirements to Design and Code

 Analysis - a developer’s system/solution perspective

• f requirements

 After requirements validation, evaluate the analysis model from a technical design perspective

 Add, refine, start over, etc.

Requirements Design Analysis Models Software Architecture Validation Analysts and Developers

(boundary is gray)

Requirements Realization

The requirements model realization is the final answer

• n what must be done, but not on how to do it

• R. Kuehl/J. Scott Hawker
• p. 3

R I T

Software Engineering

Use-Case Realization Modeling

 The external behavior of the use case scenario steps are transformed into an object “design”

• f the system

 A first step toward architecture design  The use cases are said to be realized in the system design  One possible realization among design

• ptions

Communication diagrams Sequence diagrams Class diagram

Use Cases

Use Case Use-Case Realization <<trace>> Use Case Specification

Also known as Robustness Analysis

(no implementation constraints, resilient to future changes)

• R. Kuehl/J. Scott Hawker
• p. 4

R I T

Software Engineering

The Goals of Use-Case Analysis

Requirements Perspective  Analyze and validate requirements

 Complete, correct, feasible, etc.  Conceive a solution from the available requirements?

 The analysis model is transitional, conceptual, it evolves quickly

 Explore functional decomposition alternatives  Focus on most important and complex use cases  Think of analysis classes as “proto-classes” representing high level abstractions  The result is a very rough first-draft of the system object model

• R. Kuehl/J. Scott Hawker
• p. 5

R I T

Software Engineering

The Goals of Use-Case Analysis

Architecture Perspective  Gain insight into architecture and design requirements

 An analysis class encapsulates multiple collaborating design objects  An abstraction of the design model; refined during design

• Analysis classes rarely survive into design

unchanged

 Don’t worry about “formal” documentation and a well-polished model

• R. Kuehl/J. Scott Hawker
• p. 6

R I T

Software Engineering

Notes

 The analysis techniques are based the use of UML notation  This is an introduction – detailed techniques and notation will not be covered (see UML references)  Learning the general use case analysis thought process is more important than any specific technique

• R. Kuehl/J. Scott Hawker
• p. 7

R I T

Software Engineering

Use-Case Analysis - Steps

 Supplement the use case description as necessary  For each use-case

 Find classes from use-case behavior  Distribute use-case behavior to classes  Model analysis class interactions in interaction diagrams

 For each resulting analysis class

 Describe responsibilities and attributes  Describe associations

 Unify analysis classes  Review checkpoints

• R. Kuehl/J. Scott Hawker
• p. 8

R I T

Software Engineering

Class Diagrams

• R. Kuehl/J. Scott Hawker
• p. 9

R I T

Software Engineering

Class Attributes and Responsibilities

 Attributes represent domain information  Domain attribute types  Use case “Nouns” that did not become classes  A responsibility is an action an

• bject supports

 Messages on interaction diagrams define responsibilities

ClassName

• (Private) Name : Type = InitialValue

+ (Public) Name: Type = InitialValue # (Protected) Name : Type = InitialValue <<stereotype>>

Supplier // PerformResponsibility // PerformAnotherResponsibility : Supplier : Client // PerformResponsibility // PerformAnotherResponsibility

• R. Kuehl/J. Scott Hawker
• p. 10

R I T

Software Engineering

Association Labels

 Association names label the association link

 Verb phrase with one class the verb subject and the other the verb object

 Association roles define the contextual role an

• bject instance plays for its associated object

instance

 The “face” it presents to its associated object  Acts like an alternative class name

Course <<entity>> 0..n CourseOffering <<entity>> Professor <<entity>> Department <<entity>> departmentHead instructor preRequisites teaches works in (Class object Instances)

• R. Kuehl/J. Scott Hawker
• p. 11

R I T

Software Engineering

Association Multiplicities

There can be multiple associations between classes

• R. Kuehl/J. Scott Hawker
• p. 12

R I T

Software Engineering

Sequence Diagrams

: Client : Supplier

• 1. PerformResponsibility

1.1. PerformAnotherResponsibility

Message Focus of Control (Activation) Object Lifeline Reflexive message (Message to self) Hierarchical message numbering Client object Supplier object

Client Supplier PerformResponsibility() PerformAnotherResponsibility()

The classes Sequence diagrams illustrate how objects interact with each other dynamically

• R. Kuehl/J. Scott Hawker
• p. 13

R I T

Software Engineering

Communication Diagrams

: Supplier : Client

• 1. PerformResponsibility

1.1. PerformAnotherResponsibility

Link Message Client object Supplier object Note: The client initiates the behavior and needs it done, the supplier is responsible for carrying out the behavior at the client’s request. Communication diagrams show the static interactions and links among a set of collaborating objects.

• R. Kuehl/J. Scott Hawker
• p. 14

R I T

Software Engineering

Stereotypes as Analysis Classes

 Separation of concerns - system interface from application logic/control flow from persistent information as specialized class objects (in UML)  Stereotype classes:

 Boundary classes: system boundary

• Interaction between the system and its actors

 Entity classes: system information and associated behavior  Control classes: system behavior coordination and sequencing

• Use-case flow of events

Entity Control Boundary

• R. Kuehl/J. Scott Hawker
• p. 15

R I T

Software Engineering

Stereotype Class Collaboration Pattern

Entity Control Boundary Entity Boundary Boundary <<actor>> External System Actor

Use Case

• R. Kuehl/J. Scott Hawker
• p. 16

R I T

Software Engineering

Why Stereotype Analysis Classes?

 Class stereotypes help

 Clarify and separate class roles - encapsulate  Separate things that tend to change independently - modularize

 Class stereotypes are conceptually straightforward to begin analysis  Supplement with non stereotype classes in future elaborations as needed  Stereotype classes tend to go away in design Design pattern analogy – model-view-controller

• R. Kuehl/J. Scott Hawker
• p. 17

R I T

Software Engineering

Requirements Analysis Meta Model

Learn the Problem Domain Identify Stakeholders and Users Business Modeling User Modeling Task Analysis Use Case Modeling Use Case Analysis Software Requirements Specification Vision and Scope Architecture and Design

With Stakeholders With Users

• User Goals
• User Roles
• Personas
• User centric
• Scenarios
• Activity flow diagrams
• Task decomposition

(Validation)

• Class Models
• Behavioral models
• Data models
• Business Goals, Processes,

and Rules

• System Boundary
• Problem Statement
• Vision & Scope
• Model system functions
• Actors and associated

sets of actions

• Diagram and

descriptions

Iterates