Unified Software ProcessRequirements Analysis

& Software Design(Elaboration)

Software Engineering

April 19, 2023

January 15, 2007 2

Overview of USP

RequirementsElaboaration

(OO-Analysis)

RequirementsElaboaration

(OO-Analysis)

Object-OrientedDesign

Object-OrientedDesign

Object-OrientedImplementation(Programming)

Object-OrientedImplementation(Programming)

Problem Statement& User NeedsUse Case

Model

The process of defining and modeling the Problem Space

The process of defining and modeling the Solution Space

Design & DeploymentModels

Code in anOOPL (Ada95)(C++)(Java)ComponentModel

Mapping design to Implementation Space

RequirementsElicitation

(Definition)

RequirementsElicitation

(Definition)

Analysis Model

January 15, 2007 3

Overview of USP

• Inception

• Elaboration ( focus on “Do-Ability” )(Architecture + high-fidelity cost est.)– Develop detailed use cases (80% of use cases).

– Develop a stable architectural view of the system using the Analysis Model, Design Model, Implementation Model, and Deployment Model.

– Create a baseline system specification (SRS).

– Produce the Software Development Plan (SDP) which describes the next phase.

• Construction

• Transition

Inception Elaboration Construction Transition

Birth Death

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion… …

Itera-tion

Itera-tion

Arch. Design Design Refinement

(Analysis Model) (Design Model)

January 15, 2007 4

Requirements Elicitation vs Elaboration (USP)

Use-case Model Analysis Model Described using the language of the customer.

Described using the language of the developer.

External view of the system. Internal view of the system.

Structured by Use cases; gives structure to external view

Structured by sterotypical classes and packages; gives structure to internal view

Used primarily as a contract between client and developer as to what the system should do.

Used primarily by developers to understand how the system should be shaped; that is, designed and implemented.

May contain redundancies and inconsistencies among requirements

Should be complete, precise, consistent, and testable.

Captures functionality of the system including architecturally significant functionality.

Outlines how to realize functionality within the system; works as the first cut at design.

Defines use cases further analyzed in the analysis model.

Defines Use-case realizations, each one representing the analysis of a use case from the Use Case model.

January 15, 2007 5

UML Process and Artifacts

1: RequirementsElicitation(Capture)

2: RequirementsElaboration(Analysis &

Specification)

3: SoftwareDesign

SoftwareDevelopment

Plan

SoftwareRequirements

Spec

AnalysisModel

Use CaseModel

Use CaseDiagram

CommunicationDiagram

StateChart

ModelSystem/Gui

behavior

Model Use CaseInternal behavior

Define SystemBoundary;

Identify ActorsAnd External

Interfaces;Identify Use Cases

Define InternalView of System

Identify SubsystemsIdentify Classes & Objects

Allocate FunctionalResponsibilities

ClassDiagram

ArchitectureDiagram

Identify Boundary, ControlEntity Classes and their

Relationships

Identify Packagestheir Interfaces &

Relationships

PartitionSoftware into

Work packages.Estimate cost, resources,

Size, and schedule.

ActivityDiagram

ModelUse Case

Flow

CommunicationDiagram

Model Use CaseExternal behavior

January 15, 2007 6

Requirements Elaboration• Purpose

– Identify the Analysis classes and/or subsystems whose instances are needed to perform the use case’s flow of interactions.

– Allocate the functional responsibilities of use cases to interacting objects and/or to participating subsystems.– Define functional requirements for operations and encapsulated data of analysis classes and/or subsystems

and their interfaces.– Capture detailed design requirements for each use case.– Prioritize use cases and subsystems for further development– Plan the design and construction activites, estimate size, effort, schedule and cost.

• Identify Participating Analysis ClassesFor each use case, identify the problem data that enters and leaves the system via that use case. Identify the

problem data that must persist within the system to support other use cases; this is data that must be shared by use cases related on the Use Case Diagram. Assign boundary classes to handle problem data crossing the system boundary.

• Describe Analysis Object Interactions– Construct communication diagrams containing participating actors, analysis objects, and message

transmissions among them. If necessary, create separate diagrams for distinct sub-flows determined by the same use case.

– A use case should be invoked by a message from an actor to an analysis object.– Messages flowing between objects should be labeled with the action requested of the receiving object; these

messages define the functional responsibilities of the receiving object.– Support the collaboration diagram with narrative to clarify details.

• Artifacts of Analysis– Analysis Class Diagrams (UML) – static architectural design – Activity Diagram (UCM) – dynamic flow of use cases or sub- use cases– Communication Diagrams (UML) – dynamic architectural design– Statecharts/Diagrams (UML) – dynamic architectural design– Use Case Coverage Table – architecture completeness; basis for integration and system testing

January 15, 2007 7

Software Requirements Specification (SRS)1

• Title• TOC

1. Introduction1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. Overall Description2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

3.0 Specific Requirements… next slide

1 IEEE Std 830-1998

January 15, 2007 8

Software Requirements Specification (SRS)

3.0 Specific Requirements

3.1 External Interfaces

3.2 Functions

3.3 Performance Requirements

3.4 Logical Database Requirements

3.5 Design Constraints

3.6 Software System Quality Attributes

3.7 Object Oriented Models

3.7.1 Analysis Class Model (Static Model)

3.7.2 Analysis Collaborations (Dynamic Model)

3.8 Additional Comments

• Index

• Appendices

January 15, 2007 9

Software Development Plan (SDP)2

• Front Matter (Title, Toc, Lof, Lot)

1. Overview1.1 Project Summary

1.2 Evolution of Plan

2. References

3. Definitions

4. Project Organization

5. Managerial Process Plans5.1 Start-up Plan

5.2 Work Plan

5.3 Control Plan

5.4 Risk Management Plan

5.5 Closeout Plan

6. Technical Process Plan

7. Supporting Plans

2 IEEE Std 1058-1998

January 15, 2007 10

Requirements Analysis (USP)• Artifacts

– Analysis ClassesAbstractions of one or several classes and/or subsystems in the design. Has the

following characteristics:• Focuses on functional requirements• Seldom defines or provides any interface in terms of operations. Behavior is defined

in terms of responsibilities on a more or less informal level.• Defines attributes, but at an abstract level. Attribute types are conceptual and have

meaning in the problem domain. Attributes found during analysis commonly become classes in the design and implementation.

• Class relationships are more informal and have less significance compared to design and implementation.

• Fall into one of three categories: Boundary, Entity, and Control

– Boundary Classes• Used to model interaction between the system and its actors! The interaction often

involves receiving and presenting information and/or requests. They collect and encapsulate requirements defining external system interfaces - if these change, only boundary classes should be effected.

• Boundary classes are often realized by windows, forms, panes, comm ports, etc. They are characterized by the content and granularity of information that they exchange at the system interface - not the form and style of the exchange.

January 15, 2007 11

OO Modeling Concepts in UMLWHOLE-PART (Composition)

Objects relate to one another in a variety of ways, some relationships are of a physical nature, while others are of a more logical or conceptual nature. For example:

Whole-Part: In this type of relationship, one or more objects are parts or components of a more complex composite object representing the whole. Relationships of this kind tend to model physical or geographic relationships involving tangible objects. For example, an Engine is part of an Automobile.

Whole-Part is also referred to as the “Has-A(n)” relation, that is, an Automobile Has-An Engine.

Whole-Part relationships tend to imply a strong functional interaction (high coupling) between constituent objects.

Composition is usually implied when the “whole” has responsibility for creating its “parts” [Texel]

Whole

Part1 Part2

UML Representation

January 15, 2007 12

OO Modeling Concepts in UMLWHOLE-PART (Aggregation)

Container-Containee: This relationship is somewhat like the Whole-Part where the Whole is an object that plays the role of a “storage container” used to hold and organize instances of some class of “containee” objects. Normally, there is a very little interaction between the Container and its Containees.

For example, a Bag of Groceries. The Bag denotes the container and the groceries are the containees.

This relationship might also be called the “Holds-A(n)” relation. In contrast to Composition, seldom are there any functional dependencies or interactions between the Container and its Containees.

Containers are normally not responsible for creating containees.

Container

Containee

UML Representation

*

January 15, 2007 13

OO Modeling Concepts in UMLWHOLE-PART (Affiliation )

Organization-Member: Affiliations are almost always logical in nature. The Organization may represent a loose collection of Members( people or things ) having a common purpose or interest or other reason for affiliation.

The Member-Organization relationship might also be called the “Belongs-To” relation; conversely, the Organization-Member relationship could be called the “Includes” relation.

This type of relationship may not be formal enough to define a class of objects - it is the type of relationship that can dynamically change its membership; that is, the type of objects that form the affiliation defined by this relationship can change with time.

For example, members of a club or email interest group may have a common background, common interests, or a common hobby that forms the basis for their affiliation, but there may not be a need for a formal organization.

Organization

Member

UML Representation

*

January 15, 2007 14

OO Modeling Concepts in UMLASSOCIATION

This relationship is the most informal of all those mentioned above. This relationship is used to define an instance connections (Coad/Yourdon) between objects; that is, a weak relationship between objects necessary to model some property or “interest” they have in common. Or, objects that have some reason to interact.

For example, a Customer holds a contract with a Vendor. In this association, the customer plays the role of Buyer while the Vendor plays the role as Seller. Both Customer and Vendor are associated with a Contract, but through different relationships. Also note the multiplicity constraints on these associations.

VendorHolds contracts with

Customerassociationrole role

Buyer Seller

Contract

Buyer Seller

UML Representation

1 1

*1

January 15, 2007 15

OO Modeling Concepts in UMLINHERITANCE

Inheritance is a relationship between classes also known as the Generalization-Specialization (Gen-Spec) relation. A superclass is said to generalize its subclasses, conversley, a subclass is said to specialize its superclass. Inheritance implies the following:

Objects of a subclass inherit all attributes defined by the superclass, and may define addtional ones;

Objects of a subclass normally inherit all services (behavioral characteristics) defined by the superclass, and may re-define any subset of them;

Objects of a subclass may define new services (behavior variation) not provided by the superclass.

Superclass

Subclass1 Subclass2

UML Representation

January 15, 2007 16

Analysis Modeling ProcessProduce

Analysis Model2.0

Form WorkPackages

2.2

PrioritizeUse Cases

2.1

Prioritize Schedule & Allocate

Work Packages2.3

Execute WPAnalysis Plan

2.4

List ofUse Cases in

Priority Order

Work PackageSpecifications

and Dependencies

Order Use Cases

for this WP2.4.1

NextInputs:Customer Requirements DocumentsCustomer/User Mtng MinutesUse Case Model

Activity DiagramDefining work

flow for WPAnalysis

AnalyseUse Cases

2.4.2

Define/RefineControl Object

2.4.2.1AnalyzeUse CaseScenarios

2.4.2.2

Define/RefineEntity Objects

2.4.2.3Update

Use CaseCoverage

Table2.4.2..5

Use CaseCoverage

Table

AnalysisControl Class

Spec.

AnalysisEntity Class

Spec.

Define/RefineBndry Objects

2.4.2.4

AnalysisBndry Class

Spec.

For each WP

For each UC

Review/ReviseUse CaseArtifacts

2.4.2.7

See NotesBelow

Use CaseCommunication

Diagram

UpdateSystemClass

Diagram2.4.2.6

Analysis Class

Diagram