CSE_2014 SE MODULE 2 V1

SOFTWARE ENGINEERING
(CSE 2014)
Department of Computer Science and Engineering

School of Engineering,
PRESIDENCY UNIVERSITY
Topics
Requirements Engineering: Eliciting requirements, Functional and
non- Functional requirements, Software Requirements Specification
(SRS), Requirement Analysis and validation. Requirements modelling-
Introduction to Use Cases, Activity diagram and Swim lane diagram.
CASE- Characteristics of CASE Tools, Architecture of a CASE
Environment.
Design: Design concepts, Architectural design, Component
based design, User interface design.
Module 2: Software Requirements, Analysis and
Design
Requirements Engineering:
1. Eliciting requirements
2. Functional and non- Functional requirements
3. Software Requirements Specification (SRS)
4. Requirement Analysis and validation.
Introduction
• The requirements of a system are the descriptions of the features or services that the
system exhibits within the specified constraints.
• The requirements collected from the customer are organized in some systematic
manner and presented in the formal document called software requirements
specification (SRS) document.
• Requirements engineering is the process of gathering, analyzing, documenting,

validating, and managing requirements.
• The main goal of requirements engineering is to clearly understand the customer

requirements and systematically organize these requirements in the SRS.
What is a requirement?
• It may range from a high-level abstract statement of a service or of a system

constraint to a detailed mathematical functional specification.
• This is inevitable as requirements may serve a dual function

May be the basis for a bid for a contract - therefore must be open to
interpretation;
May be the basis for the contract itself - therefore must be defined in detail;
Both these statements may be called requirements.
Requirements engineering
• The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services
and constraints that are generated during the requirements engineering
process.
Software Requirements
• A requirement is a detailed, formal description of system functionalities. It specifies a
function that a system or component must be able to perform for customer satisfaction.
• IEEE defines a requirement as :

“a condition or capability of a system required by customer to solve a problem
or achieve an objective.”
“a capability that a product must possess or something a product must do in
order to ultimately satisfy customer need, contract, constraint, standard,
specification or other formally imposed documents.”
“a documented representation of a condition or capability as in (1) or (2).”
TYPES OF REQUIREMENTS
1. Functional Requirements
• These are the requirements that the end user
specifically demands as basic facilities that
the system should offer.
• All these functionalities need to be
necessarily incorporated into the system as a
part of the contract.
A functional requirement can express an

if/then relationship, as in the example below:
• If an alarm is received from a sensor, the

system will report the alarm and halt until the
alarm is acknowledged and cleared.
2. Non Functional Requirements

• These are basically the quality constraints
that the system must satisfy according to the
project contract.
• The priority or extent to which these factors
are implemented varies from one project to
other. They are also called non-behavioral
requirements.
• A system can meet its functional

requirements and fail to meet its
nonfunctional requirements.
• NFRs define the software's characteristics

and expected user experience (UX). They
cover:
• performance
• usability
• scalability
• security
• portability
An example nonfunctional requirement related
to performance and UX could state:
• The pages of this web portal must load

within 0.5 seconds.
FUNCTIONAL NON FUNCTIONAL
REQUIREMENTS REQUIREMENTS
A non-functional requirement
1. A functional requirement defines a
defines the quality attribute of a
system or its component.
software system.
It places constraints on “How should
2. It specifies “What should the
the software system fulfill the
software system do?”
functional requirements?”
Non-functional requirement is
3. Functional requirement is specified by technical peoples e.g.
specified by User. Architect, Technical leaders and
software developers.
4. It is mandatory. It is not mandatory.
5. It is captured in use case. It is captured as a quality attribute.
6. Defined at a component level. Applied to a system as a whole.
7. Helps you verify the functionality Helps you to verify the performance
of the software. of the software.
8. Functional Testing like System, Non-Functional Testing like
Integration, End to End, API testing, Performance, Stress, Usability,
etc are done. Security testing, etc are done.
9. Usually easy to define. Usually more difficult to define.
Requirements Analysis and
Specification
• Many projects fail:
•Because they start implementing the
system.
•Without determining whether they are
building what the customer really
wants.
Specification
• It is important to learn:
•Requirements analysis and
specification techniques carefully.
Specification
• Goals of requirements analysis and
specification phase:
• Fully understand the user requirements.
• Remove inconsistencies, anomalies, etc. from
requirements.
• Document requirements properly in an SRS
document.
Specification
• Consists of two distinct activities:
• Requirements Gathering and
Analysis
• Specification
Who Carries Out Requirements
Analysis and Specification?
• The person who undertakes requirements
analysis and specification:
• Known as systems analyst:
• Collects data pertaining to the product
• Analyzes collected data:
• To understand what exactly needs to be done.
• Writes the Software Requirements Specification
(SRS) document.
Specification
• Final output of this phase:
• Software Requirements Specification (SRS)
Document.
• The SRS document is reviewed by the customer.
• Reviewed SRS document forms the basis of all
future development activities.
Requirements Analysis
• Requirements analysis consists of two

main activities:
• Requirements gathering
• Analysis of the gathered requirements
Requirements Analysis
• Analyst gathers requirements through:

• Observation of existing systems,
• Studying existing procedures,
• Discussion with the customer and end-users,
• Analysis of what needs to be done, etc.
Requirements Gathering
• Also known as requirements elicitation.
• If the project is to automate some existing
procedures
• e.g., automating existing manual accounting
activities,
• The task of the system analyst is a little easier
• Analyst can immediately obtain:
• input and output formats
• accurate details of the operational procedures
Requirements Gathering Activities
•1. Studying the existing documentation

•2. Interview
•3. Task analysis
•4. Scenario analysis
•5. Form analysis
Requirements Gathering (CONT.)
• In the absence of a working system,
• Lot of imagination and creativity are
required.
• Interacting with the customer to gather
relevant data:
• Requires a lot of experience.
Requirements Gathering (CONT.)
• Some desirable attributes of a good

system analyst:
•Good interaction skills,
•Imagination and creativity,
•Experience.
Case Study: Automation of Office
Work at CSE Dept.
• The academic, inventory, and financial
information at the CSE department:
--Being carried though manual processing by
two office clerks, a store keeper, and two
attendants.
• Considering the low budget he had at his
disposal:
--The HoD entrusted the work to a team of
student volunteers.
Work at CSE Dept.
• The team was first briefed by the HoD about

the specific activities to be automated.
• The analyst first discussed with the two
clerks:
• Regarding their specific responsibilities
(tasks) that were to be automated.
• The analyst also interviewed student and
faculty representatives who would also use
the software.
Work at CSE Dept.
•For each task, they asked:

• About the steps through which these are
performed.
• They also discussed various scenarios that
might arise for each task.
• The analyst collected all types of forms
that were being used.
SRS-Software requirement specification (SRS)
• Software requirement specification (SRS) document is a formal document that

provides the complete description of the proposed software, i.e., what the
software will do without describing how it will do so.
• Software requirements specification is one of the important documents required in
the software development
• SRS is needed for a variety of reasons:

• Customers and users rely more on and better understand a written formal
document than some technical specification.
SRS-Software requirement specification (SRS)
• It provides basis for later stages of software development, viz., design, coding, testing,
standard compliances, delivery, and maintenance.
• It acts as the reference document for the validation and verification of the work products
and final software.
• It is treated as an agreement on the features incorporated in the final system of project
between customer and the supplier.
• A good quality SRS ensures high quality software product.
• A high quality SRS reduces development effort (schedule, cost, and resources) because
unclear requirements always lead to unsuccessful projects.
Characteristics of a good SRS
• Correctness : User review is used to ensure the

correctness of requirements stated in the SRS. SRS
is said to be correct if it covers all the requirements
that are actually expected from the system.
• Unambiguity : A SRS is said to be unambiguous if
all the requirements stated have only 1
interpretation. Some of the ways to prevent
unambiguousness include the use of modelling
techniques like ER diagrams, proper reviews and
buddy checks, etc.
• Completeness : Completeness of SRS indicates every

sense of completion including the numbering of all the
pages, resolving the to be determined parts to as much
extent as possible as well as covering all the functional
and non-functional requirements properly.
• Consistency : Requirements in SRS are said to be

consistent if there are no conflicts between any set of
requirements. Examples of conflict include differences
in terminologies used at separate places, logical
conflicts like time period of report generation, etc.
• Should be ranked for importance and/or stability: There should

a criterion to classify the requirements as less or more important
or more specifically as desirable or essential. An identifier mark
can be used with every requirement to indicate its rank or
stability.
• Verifiability : A SRS is verifiable if there exists a specific

technique to quantifiably measure the extent to which every
requirement is met by the system. For example, a requirement
starting that the system must be user-friendly is not verifiable
and listing such requirements should be avoided.
• Modifiability :SRS should be made as modifiable as

possible and should be capable of easily accepting changes
to the system to some extent. Modifications should be
properly indexed and cross-referenced.
• Testability : A SRS should be written in such a way that it
is easy to generate test cases and test plans from the
document.
• Traceability : One should be able to trace a requirement to
design component and then to code segment in the
program. Similarly, one should be able to trace a
requirement to the corresponding test cases.
Software Requirement Specification
(SRS) Format
• In order to form a good SRS, here you will see some points which can be
used and should be considered to form a structure of good SRS. These are
as follows
1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
(SRS) Format
1. Introduction
(i) Purpose of this document:
At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.
(ii) Scope of this document: In this, overall working and
main objective of document and what value it will provide
to customer is described and explained. It also includes a
description of development cost and time required.
(iii) Overview: In this, description of product is explained.
It’s simply summary or overall review of product.
(SRS) Format
2. General description:
In this, general functions of product which includes
objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes
features of user community.
3. Functional Requirements:
In this, possible outcome of software system which includes
effects due to operation of program is fully explained. All
functional requirements which may include calculations,
data processing, etc. are placed in a ranked order.
(SRS) Format
4. Interface Requirements:
In this, software interfaces which mean how software program

communicates with each other or users either in form of any
language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.
5. Performance Requirements:
In this, how a software system performs desired functions under

specific condition is explained. It also explains required time,
required memory, maximum error rate, etc.
(SRS) Format
6. Design Constraints:
In this, constraints which simply means limitation or restriction
are specified and explained for design team. Examples may
include use of a particular algorithm, hardware and software
limitations, etc.
7. Non-Functional Attributes :
In this, non-functional attributes are explained that are required
by software system for better performance. An example may
include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
(SRS) Format
8. Preliminary Schedule and Budget :
In this, initial version and budget of project plan are explained

which include overall time duration required and overall cost
required for development of project.
9. Appendices :
In this, additional information like references from where

information is gathered, definitions of some specific terms,
acronyms, abbreviations, etc. are given and explained.
Requirements Validation
Requirements validation is the process of checking that requirements
defined for development, define the system that the customer really
wants. To check issues related to requirements, we perform requirements
validation.
 Is each requirement consistent with the overall objective for the system/product?
 Have all requirements been specified at the proper level of abstraction? That is,
do some requirements provide a level of technical detail that is inappropriate at
this stage?
 Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?
Requirements Validation
Is each requirement achievable in the technical environment
that will house the system or product?
Is each requirement testable, once implemented?
Does the requirements model properly reflect the information,
function and behavior of the system to be built.
Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly validated?
Are all patterns consistent with customer requirements?
Requirements Modelling
• Requirements modelling uses a combination
of diagrams and text to depict requirements in
a way that is easier to understand.
• It is required to validate the software
requirements because through modelling we
can examine the system from various
perspectives.
• USE CASE DIAGRAM:
• UML, short for Unified Modeling Language, is a
standardized modeling language consisting of an
integrated set of diagrams, developed to help
system and software developers for specifying,
visualizing, constructing, and documenting the
artifacts of software systems, as well as for
business modeling and other non-software
systems.
It is a behavior diagram show the dynamic behavior of
the objects in a system, which can be described as a series
of changes to the system over time.
A use-case model describes a system's functional
requirements in terms of use cases. It is a model of the
system's intended functionality (use cases) and its
environment (actors). Use cases enable you to relate what
you need from a system to how the system delivers on
those needs.
A use case diagram doesn't go into a lot of detail
—for example, don't expect it to model the
order in which steps are performed. Instead, a
proper use case diagram depicts a high-level
overview of the relationship between use cases,
actors, and systems.
• Use case diagram components
• System :
• Actor
Actors are basically users of the SUD who are external entities (people or other
systems) who interact with the SUD to achieve a desired goal. Actors are represented as
stick figures.
Types of Actors:
• Primary Actor
The Actor(s) using the system to achieve a goal.
• Secondary Actor
Actors that the system needs assistance from to achieve the primary actors goal.
• Use Case
A use case is a collection of possible sequences of interactions between the SUD and its
Actors, relating to a particular goal. The collection of Use Cases should define all
system behavior relevant to the actors to assure them that their goals will be carried out
properly.
A use case is drawn as a horizontal ellipse.
Use Cases:
• Hold Functional Requirements in an easy to read, easy to track text format.
• Represents the goal of an interaction between an actor and the system. The
goal represents a meaningful and measurable objective for the actor.
• Records a set of paths (scenarios) that traverse an actor from a trigger event
(start of the use case) to the goal (success scenarios).
• Records a set of scenarios that traverse an actor from a trigger event toward a
goal but fall short of the goal (failure scenarios).
• Are multi-level: one use case can use/extend the functionality of another.
• Use Case Names Begin With a Strong Verb
• Use Cases are named using the domain terminologies
•Use case diagram components
Use Cases Do Not…
• Specify user interface design. They specify the intent, not
the action detail
Mock up screens/ Prototype may be included depicting
the functionality
• Specify implementation detail (unless it is of particular
importance to the actor to be assured that the goal is
properly met)
• Use Case Relationships (Associations)
Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is
involved with an interaction described by a use case.
There are several types of relationships that may appear on a use
case diagram:
• An association between an actor and a use case
• An association between two use cases
• A generalization between two actors
• A generalization between two use cases
• Includes Relationship
"X includes Y" indicates that the task "X" has a subtask "Y"; that is,
in the process of completing task "X", task "Y" will be completed at
least once.
• Extends Relationship
"X extends Y" indicates that "X" is a task of the same type as "Y",
but "X" is a special, more specific case of doing "Y". That is, doing X is
a lot like doing Y, but X has a few extra processes to it that go above
and beyond the things that must be done in order to complete Y.
Association
Use Case 1 <<include>> Use Case 3
relationship
Generalization
Actor
Use Case 2 <<extend>> Use Case 4
Use Case Diagram
Airline Reservation System
Reservation System
Add Reservation
Cancel Reservation
Ticket Clerk
Check-in Passenger <<include>> Weigh Luggage
<<include>>
Assign Seat <<extend>> Assign Window Seat
<<extend>>
Assign Aisle Seat

Use Case Diagram
Online Shopping System
Use Case Diagram
Use Case Diagram
ATM Transaction
Activity Diagrams
• Activity diagram is another important diagram in UML
to describe the dynamic aspects of the system.
• Activity diagram is basically a flowchart to represent
the flow from one activity to another activity. The
activity can be described as an operation of the system.
• The control flow is drawn from one operation to
another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of
flow control by using different elements such as fork,
join, etc
Activity Diagrams
Purpose of Activity Diagrams
• The basic purposes of activity diagrams is
similar to other behavior diagrams. It captures
the dynamic behavior of the system.
• Activity is a particular operation of the
system. Activity diagrams are used for
visualizing the dynamic nature of a system.
Activity Diagrams
How to Draw an Activity Diagram?
Activity diagrams are mainly used as a
flowchart that consists of activities performed
by the system.
Activity diagrams are not exactly flowcharts as
they have some additional capabilities.
These additional capabilities include
branching, parallel flow, swimlane, etc.
Activity Diagrams
• Basic components of an activity diagram
• Action: A step in the activity wherein the users
or software perform a given task. The actions
are symbolized with round-edged rectangles.
• Decision node: A conditional branch in the
flow that is represented by a diamond. It
includes a single input and two or more outputs.
Activity Diagrams
• Basic components of an activity diagram
• Control flows: Another name for the connectors
that show the flow between steps in the diagram.
• Start node: Symbolizes the beginning of the
activity. The start node is represented by a black
circle.
• End node: Represents the final step in the activity.
The end node is represented by an outlined black
circle.
Activity Diagrams
Connector
Activity Diagrams
Activity Diagrams
Swimlane Diagrams
UML has no specific Swimlane diagram.
It is a special case under Activity diagram.
Swimlane diagram is also graphical representation of
the System. Swimlane diagrams are also known as the
Rummler-Brache diagram or a cross-functional
diagram. Swimlanes are sometimes called functional
bands.
It simply describes who is responsible for the
activities being performed in the activity diagram and
how they are responsible.
Swimlane Diagrams
Symbols used in Swimlane Diagram :
“Parallel Segment” is the extra symbol in
swimlane diagram along with all symbols of
Activity Diagram.
Responsibilities are represented as “Parallel
Segments” that divide the diagram vertically ,
like the lanes in a swimming pool hence the
name “swimlane”.
Swimlane Diagrams
Swimlane Diagrams
Swimlane Diagrams
CASE
1. CASE support in Software Life Cycle
2. Characteristics of CASE Tools
3. Architecture of a CASE Environment.
CASE support in Software Life Cycle
Computer aided software engineering
(CASE) is the implementation of computer
facilitated tools and methods in software
development. CASE is used to ensure a high-
quality and defect-free software. CASE
ensures a check-pointed and disciplined
approach and helps designers, developers,
testers, managers and others to see the project
milestones during development.
CASE can also help as a warehouse for
documents related to projects, like business
plans, requirements and design specifications.
One of the major advantages of using CASE is
the delivery of the final product, which is more
likely to meet real-world requirements as it
ensures that customers remain part of the
process.
CASE can also help as a warehouse for
documents related to projects, like business
plans, requirements and design specifications.
One of the major advantages of using CASE is
the delivery of the final product, which is more
likely to meet real-world requirements as it
ensures that customers remain part of the
process.
CASE illustrates a wide set of labor-saving
tools that are used in software development.
It generates a framework for organizing
projects and to be helpful in enhancing
productivity.
CASE tools
The essential idea of CASE tools is that in-
built programs can help to analyze developing
systems in order to enhance quality and
provide better outcomes. Throughout the 1990,
CASE tool became part of the software
lexicon, and big companies like IBM were
using these kinds of tools to help create
software.
CASE tools Diagramming Tools
Helps in diagrammatic and graphical
representations of the data and system
processes.
Represents system elements, control flow and
data flow among different software
components and system structure in a pictorial
form.
For example, Flow Chart Maker tool for
making state-of-the-art flowcharts.
CASE tools Computer Display and
Report Generators
Helps in understanding the data requirements
and the relationships involved.
CASE tools Analysis Tools
Focuses on inconsistent, incorrect specifications
involved in the diagram and data flow.
Helps in collecting requirements, automatically check
for any irregularity, imprecision in the diagrams, data
redundancies or erroneous omissions.
For example,
(i) Accept 360, Accompa, CaseComplete for
requirement analysis.
(ii) Visible Analyst for total analysis.
CASE tools Central Repository
Provides the single point of storage for data diagrams,
reports and documents related to project
management.
CASE tools Documentation Generators
Helps in generating user and technical documentation
as per standards.
Creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp

for documentation.
CASE tools Code Generators
Aids in the auto generation of code, including
definitions, with the help of the designs, documents
and diagrams
Advantages of the CASE approach
• As special emphasis is placed on redesign as well as testing, the servicing
cost of a product over its expected lifetime is considerably reduced.
• The overall quality of the product is improved as an organized approach

is undertaken during the process of development.
• Chances to meet real-world requirements are more likely and easier with
a computer-aided software engineering approach.
• CASE indirectly provides an organization with a competitive advantage

by helping ensure the development of high-quality products.
Disadvantages of the CASE approach
• Cost: Using case tool is a very costly. Mostly firms engaged in software
development on a small scale do not invest in CASE tools because they
think that the benefit of CASE are justifiable only in the development of
large systems.
• Learning Curve: In most cases, programmers productivity may fall in
the initial phase of implementation , because user need time to learn the
technology. Many consultants offer training and on-site services that can
be important to accelerate the learning curve and to the development and
use of the CASE tools.
• Tool Mix: It is important to build an appropriate selection tool mix to
urge cost advantage CASE integration and data integration across all
platforms is extremely important.
Characteristics of CASE Tools
1) Standard Methodology :
A CASE tool should support standard software development methodologies and
modelling techniques. Presently, CASE tools use UML.
2) Flexibility :
A CASE tool must provide flexibility and options to the user for editors and other
tools.
3) Strong Integration :
CASE tools must be integrated with all stages of software development. This
means that if a change is made in a model, it must reflect in the code
documentation and all related design. Hence, this offers an organised environment
for software generation
Characteristics of CASE Tools
4) Integration with Testing Software :
CASE tools should provide interfaces for automatic testing tools. This helps in
regression and other testing software's under changing conditions.
5) Support for Reverse Engineering :
CASE tools should be as that it can create complex models from existing code.
6) Online Help :
CASE tools offer online tutorials.
Architecture of Computer Aided Software
Engineering (CASE) Environment
• A database for storing information.
• An object management system for managing
variations made to the information.
• A tools control mechanism for coordinating
the use of the CASE tools.
• A user interface for establishing a consistent
pathway between the tools and user actions.
1) User Interface Layer :
It is made up of an interface toolkit that is standardized. It
implements a common protocol which is used for presentation.
The components of the interface are a library which contains
display objects and software that facilitates management of
interface between human and computer.
With the help of these two components the individual CASE tools
and components can communicate with each other consistently.
The tool access mechanism, use of mouse and keyboard, menu
names, object names, icons and screen layout are described in the
presentation tool.
2) Tools Layer :
Along with the CASE tools a set of services to manage the tools are
also included
The behavior of the tools within the environment is controlled by
the Tools Management Services (TMS).
TMS carries out multitask communication and synchronization in
case multitasking is performed by executing multiple tools at a time.
This is done by gathering metrics on the usage of the tools,
coordinating the information flow between the repository and
management system to the tools. The auditing and security
functions are also completed by it.
3) Object Management Layer (OML) :
The configuration management tasks are performed by it. A mechanism
that enables in tool incorporation is the essence of the software that is
present in this layer of the framework architecture.
Each case tool has been plugged into the object management layer. The
OML and the CASE repository works in unison to provide integration
services.
The tools are coupled with the repository by this set of standard modules.
Apart from all these functions, the OML also support change control,
status accounting and audits.
Configuration management services such as the task of classifying those
configuration objects that perform version control are also executed by it.
4) Shared Repository Layer :
It is made up of those access control functions with the help of
which the object management layer interacts with the CASE
database that is present in this layer. Shared repository layers
and object management helps in attaining data integration.
4) Shared Repository Layer :
It is made up of those access control functions with the help of
which the object management layer interacts with the CASE
database that is present in this layer. Shared repository layers
and object management helps in attaining data integration.
Design Engineering
• It covers the set of principles, concepts, and practices that lead to
the development of a high quality system or product.
• Goal of design engineering is to produce a model or representation
that depict:
• Firmness – program should not have any bug that inhibits its functions.
• Commodity – suitable to its intended use.
• Delight - pleasurable to use
• The design model provides detail about software data structures,
architecture, interfaces, and components that are necessary to
implement the system.
Software Design
• Software design model consists of 4 designs:

• Data/class Design
• Architectural Design
• Interface Design
• Component Design
Translating Analysis model to
Design model
Translating Analysis model to Design
model
• Data/class design - Created by transforming the analysis model class-

based elements into classes and data structures required to implement the
software
• Architectural design - defines the relationships among the major
structural elements of the software, it is derived from the class-based
elements and flow-oriented elements of the analysis model
• Interface design - describes how the software elements, hardware
elements, and end-users communicate with one another, it is derived from
the analysis model scenario-based elements, flow-oriented elements, and
behavioral elements
• Component-level design - created by transforming the structural elements
defined by the software architecture into a procedural description of the
software components using information obtained from the analysis model
class-based elements, flow-oriented elements, and behavioral elements
Quality Guidelines
A design should exhibit an architecture that (1) has been created using
recognizable architectural styles or patterns, (2) is composed of
components that exhibit good design characteristics and (3) can be
implemented in an evolutionary fashion
 A design should be modular; that is, the software should be logically

partitioned into elements or subsystems
 A design should contain distinct representations of data, architecture,

interfaces, and components.
 A design should lead to data structures that are appropriate for the
classes to be implemented and are drawn from recognizable data patterns.
Quality Guidelines
A design should lead to components that exhibit independent
functional characteristics.
Adesign should lead to interfaces that reduce the complexity of

connections between components and with the external
environment.
A design should be derived using a repeatable method that is

driven by information obtained during software requirements
analysis.
A design should be represented using a notation that effectively

communicates its meaning.
Design Principles
• S/W design is both a process and a model.

• Design process - sequence of steps that
enable the designer to describe all aspects of
the software to be built.
• Design model - created for software provides
a variety of different views of the computer
software
Design Principles
• The design process should not suffer from ‘tunnel vision.’ -

Designer should consider alternative approaches.
• The design should be traceable to the analysis model - a single
element of the design model often traces to multiple requirements,
it is necessary to have a means for tracking how requirements have
been satisfied by the design model.
• The design should not reinvent the wheel- use already exists
design pattern because time is short and resource are limited.
• The design should “minimize the intellectual distance” between
the software and the problem as it exists in the real world. – design
should be self-explanatory
Design Principles
• The design should exhibit uniformity and integration – before

design work begins rules of styles and format should be defined
for a design team.
• The design should be structured to accommodate change
• The design should be structured to degrade gently, even when
unusual data, events, or operating conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not
after the fact
• The design should be reviewed to minimize conceptual (semantic)
errors.
Design concepts
Abstraction - data, procedure, control
 Architecture - the overall structure of the software
 Separation of concerns - any complex problem can be
more easily handled if it is subdivided into pieces
 Modularity - compartmentalization of data and
function
 Functional independence - single-minded function and
low coupling
 Design Classes - provide design detail that will enable
analysis classes to be implemented
Abstraction
• At the highest level of abstraction – a solution is stated in broad terms
• At lower level of abstraction – a more detailed description of the solution is
provided.
• Two types of abstraction:
• Procedural abstraction: Sequence of instructions that have a specific and
limited function.
Ex. Open a door
open implies long sequence of activities (e.g. walk to the door, grasp knob,
turn knob and pull the door, etc).
• Data abstraction: collection of data that describes a data object.
Ex. Open a door. – door is data object.
• Data abstraction for door would encompass a set of attributes that describe
the door. (E.g. door type, swing direction, opening mechanism, etc.)
Software Architecture
Software architecture refers to the high level structures

of a software system and the discipline of creating such
structures and systems.
Each structure comprises:

- Software elements
- Relations among the elements
- Properties of both elements and relations
Dept. of CSE, SOE, Presidency University

105
Separation of Concerns
 Any complex problem can be more easily handled if it is

subdivided into pieces that can each be solved and/or
optimized independently
 A concern is a feature or behavior that is specified as part
of the requirements model for the software
 By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to
solve.

106
Modularity
• Architecture and design pattern embody modularity.

• Software is divided into separately named and addressable
components, sometimes called modules, which are integrated
to satisfy problem requirement.
• modularity is the single attribute of software that allows a
program to be intellectually manageable
• It leads to a “divide and conquer” strategy. – it is easier to solve
a complex problem when you break into a manageable pieces.
• Refer fig. that state that effort (cost) to develop an individual
software module does decrease if total number of modules
increase.
• However as the no. of modules grows, the effort (cost)
associated with integrating the modules also grows.
Modularity and software cost
Modularity
• Undermodularity and overmodularity should be

avoided. But how do we know the vicinity of M?
• We modularize a design so that development can be
more easily planned.
• Software increments can be defined and delivered.
• Changes can be more easily accommodated.
• Testing and debugging can be conducted more
efficiently and long-term maintained can be conducted
without serious side effects.
Functional Independence
 Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive interaction
with other modules.
 Cohesion is an indication of the relative functional strength of a
module.
 A cohesive module performs a single task, requiring little
interaction with other components in other parts of a program.
Stated simply, a cohesive module should (ideally) do just one
thing.
 High cohesiveness is desired in good design
Coupling is an indication of the relative interdependence among
modules.
 Coupling depends on the interface complexity between modules,
the point at which entry or reference is made to a module, and what
data pass across the interface.
 Low coupling is desirable .

110
Design classes
• Each of the software team should define a set of
design classes
• Classes should describe the elements of
problem domain and that should focus the
customer requirement
• It should create a new set of design classes that
must support the business solutions

111
Architectural Design
1.1 Software Architecture
• The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components, and
the relationships among them.
1.2 Importance of Software Architecture
 Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in the
development of a computer-based system.
 The architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows and, as
important, on the ultimate success of the system as an operational entity.
 Architecture “constitutes a relatively small, intellectually graspable
mode of how the system is structured and how its components work
together”

112
1.3 Architectural Styles
• An architectural style is a transformation that is imposed on the
design of an entire system.
Each style describes a system category that encompasses:
(1) Set of components (e.g., a database, computational modules) that
perform a function required by a system
(2) Set of connectors that enable “communication, coordination and
cooperation” among components
(3) Constraints that define how components can be integrated to form
the system, and
(4) Models that enable a designer to understand the overall properties of
a system by analyzing the known properties of its constituent parts.

113
Types of Architectural Styles
Data-centered architectures
Data flow architectures
Call and return architectures
Layered architectures

114
1. Data-centered architectures
1. Data-centered architectures
• In data-centered architecture, the data is centralized and
accessed frequently by other components, which modify
data.
• The main purpose of this style is to achieve integrality of
data.
• Data-centered architecture consists of different components
that communicate through shared data repositories.
• The components access a shared data structure and are
relatively independent, in that, they interact only through
the data store.
2. Data flow architectures
2. Data flow architectures
• In data flow architecture, the whole software
system is seen as a series of transformations on
consecutive pieces or set of input data, where
data and operations are independent of each
other.
• In this approach, the data enters into the system
and then flows through the modules one at a time
until they are assigned to some final destination
(output or a data store).
3. Call and return architectures
3. Call and return architectures
• Call and return architectures are the most
dominant architectures since the inception of
software development.
• They decompose the main program into a number
of program components which, in turn, may
invoke other program components.
• They enable code modularity.
• They are easy to scale and modify.
• If interfaces are not well defined they may lead to
tight data coupling.
4. Layered architectures
4. Layered architectures
• The lowest layer includes system support software—
typically database and operating system support.
• The next layer is the application layer that includes the
components concerned with the application functionality
and utility components that are used by other application
components.
• The third layer is concerned with user interface
management and providing user authentication and
authorization, with the top layer providing user interface
facilities.
• Of course, the number of layers is arbitrary. Any of the
layers in Figure could be split into two or more layers.
User Interface Design

123
Interface Design
Easy to learn?
Easy to use?
Easy to understand?

124
Interface Design
Typical Interface Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
unfriendly

125
Schneiderman’s Eight Golden Rules for
Interface Design
Ben Shneiderman is an American scientist with a
strong expertise in the field of human-machine
interaction. Many of his works are fundamental to
today's human-machine interaction, for example the
creation of the "Treemap".
Shneiderman proposed a collection of these
principles derived from his experience, which, after
being refined, developed and explained, are
applicable to interactive systems.

126
Interface Design
1. Strive for Consistency
Whether it is the layout, the size of the button, the color code
or the tone used when writing the page, it is important to be
consistent throughout the site. This consistency will allow
you to develop your identity and not lose users as they
navigate your site.
In the example below, you can recognize Amazon, by
applying this first heuristic, there is a consistency between all
the pages present on Amazon, the layout is the same, the size
of the button is always similar, and the color code are very
specific to Amazon.

127
Interface Design
1. Strive for Consistency

128
Interface Design
2. Enable Frequent Users to Use Shortcuts
Allow your users to access all parts of the website
with a minimum of clicks. To do this, you not only
need to establish a good hierarchy in the menu, but
also make things clear.
You should think about incorporating features for

advanced users and for beginners for example, with
keyboard shortcuts or macro facilities

129
Interface Design
3. Offer Informative Feedback
If your users have performed or are performing
actions on your website, it is best to display
feedback immediately so that they have an idea of
where their processes are

130
Interface Design
4. Design Dialog to Yield Closure
Remember to close any interaction made with a user based
on the cause of the interaction :
•Thank you message.
•Validation message.
•Summary message during a purchase.
Your user must see the path in his action, by offering him
the end of an interaction through feedback you reduce his
mental load and improve his experience on your interface.

131
Interface Design
4. Design Dialog to Yield Closure

132
Interface Design
5. Offer Simple Error Handling
A good interface should be designed to avoid errors as
much as possible. However, if something goes wrong, your
system should make it easy for users to understand and
resolve the problem.
Simple ways to deal with errors include displaying clear
error notifications and descriptive hints to resolve the
problem.
For example, on a site, it informs you when you log in if
your login information is wrong.

133
Interface Design
6. Permit Easy Reversal of Actions
• Immediately discovering that it is easy to choose
"Cancel" after making an error is a very good thing for
the user.
• If your users know that there is an easy way to solve a

problem, they will feel less anxious and more willing to
explore the options.
• The rule can be applied to all operations or groups of

operations.

134
Interface Design
7. Support Internal Locus of Control
• We need to give control and freedom to the users, so that
they can feel that they are in control of the system
themselves, giving them some form of free will helps to
reassure the user.
• For example, YouTube lets us choose how much
notification we want to see, by doing this, YouTube is
giving freedom to the users and making them feel like they
have control over what they will receive.

135
Interface Design
8. Reduce Short-Term Memory Load
• The limitation of human information processing in short-term
memory requires that displays be kept simple, multiple page
displays be consolidated, window-motion frequency be reduced,
and sufficient training time be allotted for codes, mnemonics, and
sequences of actions.
• Avoid overloading your site or application with information of the
same level. You have to deduce which ones should be placed first
or you will lose the user's attention. No matter where you place
your site, whether it's the home page or the menus, make sure that
your user can't be distracted by unnecessary information.

136
User Interface Design Steps
Designing the user interface is an iterative process defined with

the help of a spiral model. The designing of an interface starts
from the mid of the spiral.

137
The model encompasses four different phases those are:
Interface Analysis and Modelling

Design
Construction
Validation
Interface Analysis and Modelling
Before designing any solution, you need to know what actually you have
to design. In this framework, you have to study the user’s profile who will
use this interface.

138
In this phase, the designer must understand the people who
will interact with the system using the interface.
What type of task the user has to perform to achieve the

goal? Further, the designer must investigate the content that
has to present as a part of the interface.
The designer must also analyze the environment where the user will
interact with the system via an interface.
Interface Design

139
After completing the interface analysis, the designer identifies the
task that the end-user requires.
Interface designing is also an iterative process. The designer first

identifies the objects and the operations performed on those
objects.
The designer also has to define the events that would change the
state of the user interface. Further, the designer has to outline each
state of the user interface as it would appear to the end-user.

140
Interface Construction
After identifying the objects, operations and events the designer
creates a prototype. This prototype helps in the evaluation of the
real-world scenario. This process is also iterative and the
construction continues till the prototype is approved for
conducting real-world scenarios.
Interface validation
The validation phase is performed to see whether the interface can
perform user tasks along with all the variations in the real world.
Like, as to whether the interface can perform all general user
tasks? Is it easy to use, and understand and we can accept it as a
useful tool?

141
WebApp Interface Design
 Where am I? The interface should:
 provide an indication of the WebApp that has been accessed
 inform the user of her location in the content hierarchy.
 What can I do now? The interface should always help the user
understand his current options
 what functions are available?
 what links are live?
 what content is relevant?
 Where have I been, where am I going? The interface must
facilitate navigation.
 Provide a “map” (implemented in a way that is easy to
understand) of where the user has been and what paths may be
taken to move elsewhere within the WebApp.

142
Effective WebApp Interfaces
 Bruce Tognozzi [TOG01] suggests…
 Effective interfaces are visually apparent and forgiving,
instilling in their users a sense of control. Users
quickly see the breadth of their options, grasp
how to achieve their goals, and do their work.
 Effective interfaces do not concern the user with the inner
workings of the system. Work is carefully and
continuously saved, with full option for the user
to undo any activity at any time.
 Effective applications and services perform a maximum of work,
while requiring a minimum of information from
users.

143
5. WebApp Interface Design Principles I
 Anticipation - A WebApp should be designed so that it
anticipates the use’s next move.
 Communication - The interface should communicate the
status of any activity initiated by the user
 Consistency - The use of navigation controls, menus, icons,
and aesthetics (e.g., color, shape, layout)
 Controlled autonomy - The interface should facilitate user
movement throughout the WebApp, but it should do so in a
manner that enforces navigation conventions that have been
established for the application.
 Efficiency - The design of the WebApp and its interface
should optimize the user’s work efficiency, not the
efficiency of the Web engineer who designs and builds it or
the client-server environment that executes it.

144
WebApp Interface Design Principles II
 Focus - The WebApp interface (and the content it presents) should stay focused on
the user task(s) at hand.
 Fitt’s Law - The law predicts that the time required to rapidly move to a
target area is a function of the ratio between the distance to the target and
the width of the target
 Human interface objects - A vast library of reusable human interface objects has
been developed for WebApps.
 Latency reduction - The WebApp should use multi-tasking in a way that lets the
user proceed with work as if the operation has been completed.
 Learnability - A WebApp interface should be designed to minimize learning time,
and once learned, to minimize relearning required when the WebApp is revisited.

145
WebApp Interface Design Principles III
 Maintain work product integrity - A work product (e.g., a form
completed by the user, a user specified list) must be
automatically saved so that it will not be lost if an error
occurs.
 Readability - All information presented through the interface
should be readable by young and old.
 Track state - When appropriate, the state of the user
interaction should be tracked and stored so that a user can
logoff and return later to pick up where she left off.
 Visible navigation - A well-designed WebApp interface
provides “the illusion that users are in the same place, with the
work brought to them.”

146
Component Level Design
Component
• A component is a modular building block for computer software. More
formally, the OMG Unified Modeling Language Specification
[OMG03a] defines a component as “. . . a modular, deployable, and
replaceable part of a system that encapsulates implementation and
exposes a set of interfaces.”
Object - Oriented view

• Each class within a component has been fully elaborated to include all
attributes and operations that are relevant to its implementation.
• As part of the design elaboration, all interfaces that enable the classes
to communicate and collaborate with other design classes must also be
defined.

147
Designing class based components
Basic Design Principles
• The open – Closed Principle(OCP): A module [component]

should be open for extension but closed for modification
• The Liskov substitution Principle(LSP): Subclasses should
be substitutable for their base classes
• Dependency Inversion Principle(DIP):Depend on
abstractions. Do not depend on concretions
• The Interface Segregation Principle(ISP): Many client-
specific interfaces are better than one general purpose
interface
Dept. of CSE, SOE, Presidency University 148

Basic Design Principles
• The Release Reuse Equivalency Principle (REP). “The
granule of reuse is the granule of release”
The Common Closure Principle (CCP). “Classes that change
together belong together.”
The Common Reuse Principle (CRP). “Classes that aren’t
reused together should not be grouped together.
Dept. of CSE, SOE, Presidency University 149

Component-Level Design Guidelines
A set of pragmatic design guidelines can be applied as component-level
design proceeds. These guidelines apply to components, their
interfaces, and the dependencies and inheritance characteristics that
have an impact on the resultant design.
Ambler [Amb02b] suggests the following guidelines:
Components. Naming conventions should be established for
components that are specified as part of the architectural model and
then refined and elaborated as part of the component-level model.
Interfaces. Interfaces provide important information about
communication and collaboration
Dependencies and Inheritance. For improved readability, it is a good
idea to model dependencies from left to right and inheritance from
bottom (derived classes) to top (base classes).
150
Cohesion
Cohesion is an indication of the relative functional strength of a module.
Lethbridge and Laganiére [Let01] define a number of different types of
cohesion
Functional. Exhibited primarily by operations, this level of cohesion
occurs when a component performs a
targeted computation and then returns a result.
Layer. Exhibited by packages, components, and classes, this type of
cohesion occurs when a higher layer
accesses the services of a lower layer, but lower layers do not access
higher layers.
Communicational. All operations that access the same data are defined
within one class. In general, such
classes focus solely on the data in question, accessing and storing it

151
Coupling
Coupling is an indication of the relative interdependence among modules.
Lethbridge and Laganiére [Let01] define the following coupling categories:
Content coupling. Occurs when one component “surreptitiously modifies
data that is internal to another
component” [Let01]. This violates information hiding—a basic design
concept.
Common coupling. Occurs when a number of components all make use of
a global variable. Although this
is sometimes necessary ,common coupling can lead to uncontrolled error
propagation and unforeseen side
effects when changes are made.
Control coupling. Occurs when operation A() invokes operation B() and
passes a control flag to B. The
control flag then “directs” logical flow within B.

152
Coupling
The problem with this form of coupling is that an unrelated change in B can result
in the necessity to change the meaning of the control flag that A passes. If this is
overlooked, an error will result.
Stamp coupling. Occurs when ClassB is declared as a type for an argument of an
operation of ClassA. Because ClassB is now a part of the definition of ClassA,
modifying the system becomes more complex.
Data coupling. Occurs when operations pass long strings of data arguments. The
“bandwidth” of communication between classes and components grows and the
complexity of the interface increases. Testing and maintenance are more difficult.
Routine call coupling. Occurs when one operation invokes another. This level of
coupling is common and is often quite necessary. However, it does increase the
connectedness of a system.
Type use coupling. Occurs when component A uses a data type defined in
component B (e.g., this occurs whenever “a class declares an instance variable or
a local variable as having another class for its type”

153
Conducting Component level Design
Steps for designing
1. Identify all design classes that correspond to the problem domain.
2. Identify all design classes that correspond to the infrastructure domain.
3. Elaborate all design classes that are not acquired as reusable components.
4. Describe persistent data sources (databases and files) and identify the
classes required to manage them.
5. Develop and elaborate behavioral representations for a class or component.
6. Elaborate deployment diagrams to provide additional implementation detail.
7. Refactor every component-level design representation and always consider
alternatives.

154

CSE_2014 SE MODULE 2 V1

Uploaded by

Copyright:

Available Formats

You might also like

CSE_2014 SE MODULE 2 V1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSE_2014 SE MODULE 2 V1

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

Department of Computer Science and Engineering

• Requirements engineering is the process of gathering, analyzing, documenting,

• The main goal of requirements engineering is to clearly understand the customer

• It may range from a high-level abstract statement of a service or of a system

• This is inevitable as requirements may serve a dual function

system and the constraints under which it operates and is developed.

• The requirements themselves are the descriptions of the system services

and constraints that are generated during the requirements engineering

• IEEE defines a requirement as :

A functional requirement can express an

• If an alarm is received from a sensor, the

2. Non Functional Requirements

• A system can meet its functional

• NFRs define the software's characteristics

• The pages of this web portal must load

• Requirements analysis consists of two

• Analyst gathers requirements through:

•1. Studying the existing documentation

• Some desirable attributes of a good

• The team was first briefed by the HoD about

•For each task, they asked:

• Software requirement specification (SRS) document is a formal document that

• SRS is needed for a variety of reasons:

• Correctness : User review is used to ensure the

• Completeness : Completeness of SRS indicates every

• Consistency : Requirements in SRS are said to be

• Should be ranked for importance and/or stability: There should

• Verifiability : A SRS is verifiable if there exists a specific

• Modifiability :SRS should be made as modifiable as

In this, software interfaces which mean how software program

In this, how a software system performs desired functions under

In this, initial version and budget of project plan are explained

In this, additional information like references from where

Assign Seat <<extend>> Assign Window Seat

Assign Aisle Seat

For example, Doxygen, DrExplain, Adobe RoboHelp

• The overall quality of the product is improved as an organized approach

• CASE indirectly provides an organization with a competitive advantage

• Software design model consists of 4 designs:

• Data/class design - Created by transforming the analysis model class-

 A design should be modular; that is, the software should be logically

 A design should contain distinct representations of data, architecture,

Adesign should lead to interfaces that reduce the complexity of

A design should be derived using a repeatable method that is

A design should be represented using a notation that effectively

• S/W design is both a process and a model.

• The design process should not suffer from ‘tunnel vision.’ -

• The design should exhibit uniformity and integration – before

Software architecture refers to the high level structures

Each structure comprises:

Dept. of CSE, SOE, Presidency University

 Any complex problem can be more easily handled if it is

Dept. of CSE, SOE, Presidency University

• Architecture and design pattern embody modularity.

• Undermodularity and overmodularity should be

Dept. of CSE, SOE, Presidency University

Dept. of CSE, SOE, Presidency University

Dept. of CSE, SOE, Presidency University