Derived from dr fawcett s slides phil pratt szeliga fall 2010
1 / 26

Software Architecture and Specification - PowerPoint PPT Presentation

  • Updated On :

Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2010. Software Architecture and Specification. Definitions - Synonyms. A Level Specifications Customer’s Requirement Specification A Spec Engineering Specifications B Level Specifications Developer’s Requirement Specification

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Architecture and Specification' - theresa

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Derived from dr fawcett s slides phil pratt szeliga fall 2010 l.jpg

Derived from Dr. Fawcett’s slides

Phil Pratt-Szeliga

Fall 2010

Software Architecture and Specification

Definitions synonyms l.jpg
Definitions - Synonyms

A Level Specifications

Customer’s Requirement Specification

A Spec

Engineering Specifications

B Level Specifications

Developer’s Requirement Specification

B Spec

Software Requirements Specification (SRS)

C Level Specifications

“As Built” Product Specification

C Spec

Software Design Document (SDD)

Software architecture l.jpg
Software Architecture

Architectural Model = Top level structure + organizing principles

Top level structure: partitioning system into high level components (usually resulting in modules)

Organizing principles: a few concepts and design decisions which set the course of implementation

The model includes an operational description of each component and the system as a whole

Critical Issues

Architectural Model Purpose:

Help focus on dominant design mechanisms

Channel design activities toward implementation

Software architecture4 l.jpg
Software Architecture

Architectural Model bridges between requirements and implementation

An initial architectural model is:

Created for the contract’s proposal

Elaborated in requirements analysis

Completed during preliminary design

All requirements analyses should result in an architectural model

All designs should begin with a top down phase, guided by the architectural model

Software architecture5 l.jpg
Software Architecture

Life Cycle

- Developed during requirements analysis

- Guides top level design and evolves with design

- Should be fairly static during implementation and testing

Software components l.jpg
Software Components

Software Components: Parts of the physical structure of a software system

Programs are components of a software system

Modules are components of a program

Lower level modules, classes and functions are components of a module

Software components7 l.jpg
Software Components

The representation of a software component consists of:

Logical Model: summary description of its operation

Behaviors: specific operations that a component performs. Behaviors are characterized by:

Pre and Post conditions


State: values of internal data

Logical Models and Behaviors defined in B-Spec

State and Control defined in C-Spec

Decomposition l.jpg

All but the smallest and simplest software systems need to be decomposed into partitions

Partitioning is based on one or more criteria:

Logical – identify important objects and the processing for each

Data Driven – decompose processing to minimize data coupling. Promotes robustness under change

Requirements Design – Decompose along A-Spec boundaries. Makes qualification easier and boosts customer confidence

Decomposition9 l.jpg

Partitioning is based on one or more criteria:

Usability – Configure processing for simple, model driven user interfaces

Reuse – Partition into components so that boundaries match existing software to be reused

Device Independence – Isolate all platform processing

Performance – Minimize data transport, contention for resources, operator intervention and balance workload in distributed systems

Breaking down l.jpg
Breaking Down

Software Requirements Analysis and preliminary design are processes of decomposition in the application domain

Requirements decomposed into processes and data flows

Process – logical model of some activity necessary to satisfy part of requirements

Data flows – represent information necessary to sustain activities allocated to the process

Breaking down11 l.jpg
Breaking Down

Each process is allocated part of application’s requirements model

May derive additional requirements to complete or disambiguate processing model

Design Structure

Developed by associating major processes with modules

Public interface of major modules represent associated process and data flow

Each stage of decomposition needs to allocate requirements to its component parts to prove correctness of the design

Building up l.jpg
Building Up

Detailed design and testing

Process of recomposition in the solution domain

A logical module becomes a physical module when its implementation is filled in using functions and private data

Each function and class is tested for conformance to its process model

Modules are populated in order of their dependencies

This process continues until all system requirements are met

Breaking down building up l.jpg
Breaking Down, Building Up

logical behavioral model of

software system


organizing principles

high level structure

design issues

Architectural Concept


in application domain

logical models of

major processing


with data flows


logical process models

--> logical modules

--> functions, classes

--> physical modules


Re composition

in solution domain

physical modules

--> physical programs

--> physical system

Integration & Test

logical behavioral model of

software system

Qualification Test

Requirements specifications l.jpg
Requirements Specifications

Specification Purpose:

Describe the contractual obligations of the developer to the customer

Describe the allowable context – programming language, platform, testing scope, required reviews, schedule

Specification Goals:

Completeness - must describe all processing

Unambiguous – must clearly state each requirement

Brief – no redundancy or extraneous descriptors (no adjectives, no adverbs)

Requirements specifications15 l.jpg
Requirements Specifications

Specification Topics:

Requirements should describe the functioning and performance of a software component but should not describe design

For example:

Good: The swarm computing module shall accept commands from peers. The commands that it shall accept are create variable, set value of variable and add two variables.

Bad: The swarm computing module shall have a blocking queue for each peer and then merge the communication from the blocking queue of each peer into another blocking queue.

Information flow is shown in data flow diagrams but not specified because the flow may change

A level requirements specification l.jpg
A-Level Requirements Specification

Written by the customer often with significant help from developers

Describes requirements from customer’s point of view

Defines what software must do to satisfy developer’s obligations to the customer

Usually accompanied with the required schedule, reviews and process requirements

Each “shall” in the A-Spec represents a contractually binding requirement which is demonstrated during Qualification Testing

A level requirements specification17 l.jpg
A-Level Requirements Specification

A-Level Specification Contains

Logical description of software’s operation

A context diagram which shows developed software as one process with external inputs and outputs shown as rectangles

A function and performance requirements section

Data dictionary which summarizes all information flow into and out of the developed software, only if it is quite complex

A level requirements specification example l.jpg
A-Level Requirements Specification Example

Duplicates A-Spec

On website – lecture 1

B level requirements specification l.jpg
B-Level Requirements Specification

Written by the developers, approved by the customer

Describes the software requirements from developer’s point of view

Describes contractual requirements on software functionality and performance in terms of architectural components

The logical structure and behavior of each component is specified along with the interfaces between each

B level requirements specification20 l.jpg
B-Level Requirements Specification

A B-Level Specification consists of:

Architecture Description – logical descriptions for each software component’s operation

Top Level Modules

Dataflow diagrams – show the information transferred between components

PSpecs – describe the inputs, processing and outputs for each process (e.g. public interface)

Processing descriptions contain the requirements

The basis of qualification testing

Data dictionary (next slide)

Requirements Traceability Matrix (next slide)

B level requirements specification21 l.jpg
B-Level Requirements Specification

Data dictionary – lists each data flow between components and to/from the environment

Requirement Traceability Matrix – shows the allocation and derivation relationships between A and B spec requirements

B level requirements specification22 l.jpg
B-Level Requirements Specification

DFDs are constructed in a hierarchical manner

PSpec matches a DFD process

PSpec contains a HIPO (hierarchical input, processing, output) section which becomes the prologue for the corresponding module which implements it

Data flow diagram example l.jpg
Data Flow Diagram Example

Pspec 2

derived requirement:

shall find names of files in

default directory that match a

given filename pattern


Pspec 3


shall display name of

each file processed



file pattern

filename patterns,



header line

Pspec 1


shall accept a sequence

of filename patterns and

TOP Executive



file handle,

number of lines


file handle,



file text





Pspec 4

Pspec 5

shall display first

shall recognize -n

few lines of file text

command, set number of

lines to n, otherwise set

number of lines to 5

file handle

error message

file text


B level specification example l.jpg
B-Level Specification Example

Duplicates B-Spec

On website, lecture 1

B specification hints l.jpg
B-Specification Hints

Specify what the software shall do, not how

Make testable requirements.

Be complete and unambiguous with shalls

Explicitly use the word “shall” for something that must be done

Effective use of Context and DFD Diagrams:

Balance – the outputs of the context diagram are matched to the inputs of the top level DFD. the inputs to a top level process match up to a diagram of a lower level process

Leveling – creating a hierarchy of data flow diagrams

Numbers on DFD Processes must match PSpecs

DD and RTM must be complete