UNIT 2

Software requirments and Specifications

The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements
can be obvious or hidden, known or unknown, expected or unexpected from client’s point of
view.

Requirement Engineering

The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –

 Feasibility Study

 Requirement Gathering

 Software Requirement Specification

 Software Requirement Validation

Feasibility study

When the client approaches the organization for getting the desired product developed, it
comes up with rough idea about what all functions the software must perform and which all
features are expected from the software.
Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether
the software product can be practically materialized in terms of implementation, contribution
of project to organization, cost constraints and as per values and objectives of the organization.
It explores technical aspects of the project and product such as usability, maintainability,
productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should provide and which features they
want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various
stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed
of operation, response time of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of
system analyst to document the requirements in technical language so that they can be
comprehended and useful by the software development team.
SRS should come up with following features:

User Requirements are expressed in natural language.

Technical requirements are expressed in structured language, which is used inside the
organization.

Design description should be written in Pseudo code.

Format of Forms and GUI screen prints.

Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document
are validated. User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions -

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

 If they can be practically implemented

 If they are valid and as per functionality and domain of software

 If there are any ambiguities

 If they are complete

 If they can be demonstrated

Requirements gathering - The developers discuss with the client and end users and know their
expectations from the software.

Organizing Requirements - The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.

Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and conflicts,
they are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.

Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in
the software system development.

There are various ways to discover requirements

Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.

 Non-structured (open) interviews, where information to gather is not decided in

advance, more flexible and less biased.

 Oral interviews

 Written interviews

 One-to-one interviews which are held between two persons across the table.
Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over
to all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a
great help to analyze general and specific requirements.

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.

Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret
the features of intended software product. It helps giving better idea of requirements. If there
is no software installed at client’s end for developer’s reference and the client is not aware of
its own requirements, the developer creates a prototype based on initially mentioned
requirements. The prototype is shown to the client and the feedback is noted. The client
feedback serves as an input for requirement gathering.
There are four types of model available:

A) Rapid Throwaway Prototyping –

This technique offers a useful method of exploring ideas and getting customer feedback for
each of them. In this method, a developed prototype need not necessarily be a part of the
ultimately accepted prototype. Customer feedback helps in preventing unnecessary design
faults and hence, the final prototype developed is of better quality.

B) Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the basis of
customer feedback till it finally gets accepted. In comparison to Rapid Throwaway
Prototyping, it offers a better approach which saves time as well as effort. This is because
developing a prototype from scratch for every iteration of the process can sometimes be very
frustrating for the developers.

C) Incremental Prototyping – In this type of incremental Prototyping, the final expected

product is broken into different small pieces of prototypes and being developed individually.
In the end, when all individual pieces are properly developed, then the different prototypes
are collectively merged into a single final product in their predefined order. It’s a very
efficient approach which reduces the complexity of the development process, where the goal
is divided into sub-parts and each sub-part is developed individually. The time interval
between the project begin and final delivery is substantially reduced because all parts of the
system are prototyped and tested simultaneously. Of course, there might be the possibility
that the pieces just not fit together due to some lack ness in the development phase – this
can only be fixed by careful and complete plotting of the entire system before prototyping
starts.
Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of
the existing installed systems. They observe the workflow at client’s end and how execution
problems are dealt. The team itself draws some conclusions which aid to form requirements
expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project.
Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

Clear

Correct

Consistent

Modifiable

Verifiable

Prioritized

Unambiguous

Traceable

Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation
phase and what kinds of requirements are expected from the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements

Requirements, which are related to functional aspect of software fall into this category.

They define functions and functionality within and from the software system.

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. These are represented or stated in the form of input to be
given to the system, the operation performed and the output expected.

There are many ways of expressing functional requirements e.g., natural language, a structured
or formatted language with no rigorous syntax and formal specification language with proper
syntax.

Examples -

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.

 Users can be divided into groups and groups can be given separate rights.

 Should comply business rules and administrative functions.

 Software is developed keeping downward compatibility intact.

Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category.

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.They are implicit or expected
characteristics of software, which users make assumption of.

Non-functional requirements include -

 Security

 Logging

 Storage

 Configuration
  Performance

 Cost

 Interoperability

 Flexibility

 Disaster recovery

 Accessibility

These can can be classified as :

Performance constraints –
Reliability, security, response time, etc.
 Operating constraints –
These include physical constraints (size, weight), personnel availability, skill level
considerations, system accessibility for maintenance, etc.
1.Interface constraints –

These describe how the system is to interface with its environment, users, and other
systems. For example, user interfaces and their qualities (e.g., user-friendliness).

1. Economic constraints –
Immediate and/or long-term costs.

2. Lifecycle requirements – Quality of the design:

These measured in terms such as maintainability, enhance ability, portability.

Advantages of Non-Functional Requirement :

 They ensure the software system follows legal and adherence rules.
 They specify the quality attribute of the software.
 They ensure the reliability, availability, performance, and scalability of the software
system
 They help in constructing the security policy of the software system.
 They ensure good user experience, ease of operating the software, and minimize the
cost factor.

Disadvantages of Non-functional requirement :

 The nonfunctional requirement may affect the various high-level software subsystem.
 They generally increase the cost as they require special consideration during the
software architecture/high-level design phase.
 It is difficult to change or alter non-functional requirements once you pass them to the
architecture phase.
User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely

accepted if it is -

 easy to operate

 quick in response

 effectively handling operational errors

 providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for
users to perceive the system. A well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface. Otherwise the functionalities of
software system can not be used in convenient way. A system is said be good if it provides
means to use it efficiently. User interface requirements are briefly mentioned below -

 Content presentation

 Easy Navigation

 Simple interface

 Responsive

 Consistent UI elements

 Feedback mechanism

 Default settings

 Purposeful layout

 Strategical use of color and texture.

 Provide help information

  User centric approach

 Group based view settings.

System Requirements

system requirements are the required specifications a device must have in order to use certain
hardware or software. For example, a computer may require a specific I/O port to work with a
peripheral device. A smartphone may need a specific operating system to run a particular app.

Before purchasing a software program or hardware device, you can check the system
requirements to make sure the product is compatible with your system. Typical system
requirements for a software program include:

 Operating system

 Minimum CPU or processor speed

 Minimum GPU or video memory

 Minimum system memory (RAM)

 Minimum free storage space

 Audio hardware (sound card, speakers, etc)

System requirements listed for a hardware device may include:

 Operating system

 Available ports (USB, Ethernet, etc)

 Wireless connectivity

 Minimum GPU (for displays and graphics hardware)

 Requirements management

The purpose of requirements management is to ensure product development goals are

successfully met. It is a set of techniques for documenting, analyzing, prioritizing, and agreeing
on requirements so that engineering teams always have current and approved requirements.

Requirements management provides a way to avoid errors by keeping track of changes in

requirements and fostering communication with stakeholders from the start of a project
throughout the engineering lifecycle.

Requirements management plan (RMP):A requirements management plan (RMP) helps explain
how you will receive, analyze, document and manage all of the requirements within a project.

Requirements management process

Collect initial requirements from stakeholders

Analyze requirements

Define and record requirements

Prioritize requirements

Agree on and approve requirements

Trace requirements to work items

Query stakeholders after implementation on needed changes to requirements

Utilize test management to verify and validate system requirements

Assess impact of changes

Revise requirements

Document changes

Requirements attributes

In order to be considered a “good” requirement, a requirement should have certain

characteristics, which include being:
  Specific

 Testable

 Clear and concise

 Accurate

 Understandable

 Feasible and realistic

 Necessary

SRS -Software requirment specification document

Software Requirement Specification (SRS) Format as name suggests, is complete specification

and description of requirements of software that needs to be fulfilled for successful
development of software system. These requirements can be functional as well as
non-requirements depending upon type of requirement. The interaction between different
customers and contractor is done because its necessary to fully understand needs of
customers.

Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be
done to increase quality of product and to satisfy customer’s demand.

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.

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.

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.

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.

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.

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.

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.

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.

Appendices :

In this, additional information like references from where information is gathered, definitions of
some specific terms, acronyms, abbreviations, etc. are given and explained.

System models
System modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system. It is about representing a system
using some kind of graphical notation, which is now almost always based on notations in the
Unified Modeling Language (UML). Models help the analyst to understand the functionality of
the system; they are used to communicate with customers.

Models can explain the system from different perspectives:

 An external perspective, where you model the context or environment of the system.

 An interaction perspective, where you model the interactions between a system and its
environment, or between the components of a system.

 A structural perspective, where you model the organization of a system or the structure
of the data that is processed by the system.

 A behavioral perspective, where you model the dynamic behavior of the system and
how it responds to events.

Five types of UML diagrams that are the most useful for system modeling:

 Activity diagrams, which show the activities involved in a process or in data processing.

 Use case diagrams, which show the interactions between a system and its environment.
  Sequence diagrams, which show interactions between actors and the system and
between system components.

 Class diagrams, which show the object classes in the system and the associations
between these classes.

 State diagrams, which show how the system reacts to internal and external events.

Models of both new and existing system are used during requirements engineering. Models of
the existing systems help clarify what the existing system does and can be used as a basis for
discussing its strengths and weaknesses. These then lead to requirements for the new system.

Models of the new system are used during requirements engineering to help explain the
proposed requirements to other system stakeholders. Engineers use these models to discuss
design proposals and to document the system for implementation.

1.Context and process models

Context models are used to illustrate the operational context of a system - they show what lies
outside the system boundaries. Social and organizational concerns may affect the decision on
where to position system boundaries. Architectural models show the system and its
relationship with other systems.

System boundaries are established to define what is inside and what is outside the system.
They show other systems that are used or depend on the system being developed.

Context models simply show the other systems in the environment, not how the system being
developed is used in that environment. Process models reveal how the system being developed
is used in broader business processes.

2.Interaction models

Types of interactions that can be represented in a model:

 Modeling user interaction is important as it helps to identify user requirements.

 Modeling system-to-system interaction highlights the communication problems that

may arise.
  Modeling component interaction helps us understand if a proposed system structure is
likely to deliver the required system performance and dependability.

 Use cases were developed originally to support requirements elicitation and now
incorporated into the UML. Each use case represents a discrete task that involves
external interaction with a system. Actors in a use case may be people or other systems.
Use cases can be represented using a UML use case diagram and in a more detailed
textual/tabular format.

3.Structural models

Structural models of software display the organization of a system in terms of the components
that make up that system and their relationships. Structural models may be static models,
which show the structure of the system design, or dynamic models, which show the
organization of the system when it is executing. You create structural models of a system when
you are discussing and designing the system architecture.

4.Object oriented model

An object class can be thought of as a general definition of one kind of system object. An
association is a link between classes that indicates that there is some relationship between
these classes.

 Identify objects and group into classes

 Identify the relationships among classes

 Create user object model diagram

 Define user object attributes

Define the operations that should be performed on the classes

Various object model

1. Generalization

2.Aggregation

1.An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.

2.In object-oriented languages, such as Java, generalization is implemented using the class
inheritance mechanisms built into the language. In a generalization, the attributes and
operations associated with higher-level classes are also associated with the lower-level classes.
The lower-level classes are subclasses inherit the attributes and operations from their
superclasses. These lower-level classes then add more specific attributes and operations.
Behavioral models

Behavioral models are models of the dynamic behavior of a system as it is executing. They show
what happens or what is supposed to happen when a system responds to a stimulus from its
environment. Two types of stimuli:

Some data arrives that has to be processed by the system.

Some event happens that triggers system processing. Events may have associated data
although this is not always the case.

Flow oriented model

The flow oriented modeling represents how data objects are transformed at they move through
the system. Derived from structured analysis, flow models use the data flow diagram, a
modeling notation that depicts how input is transformed into output as data objects move
through the system

Flow oriented modeling focuses on structured analysis and design, follows a top to down
methodology and uses a graphical technique depicting information flows and the
transformations that are applied as data moves from input to output.

Data Flow Diagram :

The data flow diagram represents the flows of data between different process in a business. It
is a graphical technique that depicts information flow and transforms that are applied as data
from input to output. It provides a simple, intuitive method for describing business processes
without focusing on the details of computer systems. DFDs are attractive techniques because
they provide what users do rather than what computers do. In DFD, there are four symbols are
used :

1. Process :

The circle represents the process. An activity that changes or transforms data flows. Since they
transform incoming data to outgoing data, all processes must have inputs and outputs on a
DFD.

2. Data Flow :

The labeled arrows indicate incoming and outgoing data flow. Movement of data between
external entities, processes and data stores is represented with an arrow symbol, which
indicates the direction of flow.
3. Data Store :

The rectangle represents an external entity. A data store does not generate any operations but
simply holds data for later access.

4. External Entity :

In Data Flow Diagrams external entities produce and consume data that flows between the
entity and the system being diagrammed.

Data oriented model

Data-driven models show the sequence of actions involved in processing input data and
generating an associated output. They are particularly useful during the analysis of
requirements as they can be used to show end-to-end processing in a system.
Many business systems are data-processing systems that are primarily driven by data. They are
controlled by the data input to the system, with relatively little external event
processing. Data-driven models show the sequence of actions involved in processing input data
and generating an associated output. They are particularly useful during the analysis of
requirements as they can be used to show end-to-end processing in a system.
Data-driven models can be created using UML activity diagrams:

Software design
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.
Software Design Levels

Software design yields three levels of results:

1. Detailed Design

Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.

The detailed design may include:

 Decomposition of major system components into program units.

 Allocation of functional responsibilities to units.

 User interfaces

 Unit states and state changes

 Data and control interaction between units

 Data packaging and implementation, including issues of scope and visibility of program
elements

 Algorithms and data structures

2. Architectural Design -

The architectural design is the highest abstract version of the system. It identifies the software
as a system with many components interacting with each other. At this level, the designers get
the idea of proposed solution domain.

Architectural design is the specification of the major components of a system, their

responsibilities, properties, interfaces, and the relationships and interactions between them.
In architectural design, the overall structure of the system is chosen, but the internal details
of major components are ignored.

The architectural design adds important details ignored during the interface design. Design of
the internals of the major components is ignored until the last phase of the design.

Issues in architectural design includes:

 Gross decomposition of the systems into major components.
 Allocation of functional responsibilities to components.
 Component Interfaces
 Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
 Communication and interaction between components.

3. Interface Design:

Interface design is the specification of the interaction between a system and its environment.
this phase proceeds at a high level of abstraction with respect to the inner workings of the
system i.e, during interface design, the internal of the systems are completely ignored and the
system is treated as a black box. Attention is focussed on the dialogue between the target
system and the users, devices, and other systems with which it interacts. The design problem
statement produced during the problem analysis step should identify the people, other
systems, and devices which are collectively called agents.

Interface design should include the following details:

Precise description of events in the environment, or messages from agents to which the system
must respond. Precise description of the events or messages that the system must produce.
Specification on the data, and the formats of the data coming into and going out of the system.

Specification of the ordering and timing relationships between incoming events or messages,
and outgoing events or outputs..

Objectives of Software Design:

Correctness: Software design should be correct as per requirement.

Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.

Efficiency: Resources should be used efficiently by the program.

Flexibility: Able to modify on changing needs.

Consistency: There should not be any inconsistency in the design.

Maintainability: The design should be so simple so that it can be easily maintainable by other
designers.

Different Design

1.Modularization

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Functional Independence: Functional independence is achieved by developing functions that

perform only one kind of task and do not excessively interact with other modules.
Independence is important because it makes implementation more accessible and faster. The
independent modules are easier to maintain, test, and reduce error propagation and can be
reused in other programs as well. Thus, functional independence is a good design feature which
ensures software quality.

Information hiding: Modules should be specified that data include within a module is
inaccessible to other modules that do not need for such information.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects

 Desired level of abstraction can be brought in the program

 Components with high cohesion can be re-used again

 Concurrent execution can be made possible

 Desired from security aspect

Disadvantages of Modularity

 Execution time maybe, but not certainly, longer

 Storage size perhaps, but is not certainly, increased

 Compilation and loading time may be longer

 Inter-module communication problems may be increased

 More linkage required, run-time may be longer, more source lines must be written, and
more documentation has to be done

Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules based on
some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as single entity but may refer to each other to
work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.

Cohesion

Cohesion is a measure that defines the degree of intra-dependability within elements of a

module. The greater the cohesion, the better is the program design.

There are seven types of cohesion, namely –

Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of
breaking the program into smaller modules for the sake of modularization. Because it is
unplanned, it may serve confusion to the programmers and is generally not-accepted.

Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.

Temporal Cohesion - When elements of module are organized such that they are processed at
a similar point in time, it is called temporal cohesion.

Procedural cohesion - When elements of module are grouped together, which are executed
sequentially in order to perform a task, it is called procedural cohesion.

Communicational cohesion - When elements of module are grouped together, which are
executed sequentially and work on same data (information), it is called communicational
cohesion.

Sequential cohesion - When elements of module are grouped because the output of one
element serves as input to another and so on, it is called sequential cohesion.

Functional cohesion - It is considered to be the highest degree of cohesion, and it is highly

expected. Elements of module in functional cohesion are grouped because they all contribute
to a single well-defined function. It can also be reused.

Coupling

Coupling is a measure that defines the level of inter-dependability among modules of a

program. It tells at what level the modules interfere and interact with each other. The lower the
coupling, the better the program.

There are five levels of coupling, namely -

Content coupling - When a module can directly access or modify or refer to the content of
another module, it is called content level coupling.

Common coupling- When multiple modules have read and write access to some global data, it
is called common or global coupling.

Control coupling- Two modules are called control-coupled if one of them decides the function
of the other module or changes its flow of execution.

Stamp coupling- When multiple modules share common data structure and work on different
part of it, it is called stamp coupling.

Data coupling- Data coupling is when two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as parameter, then the receiving
module should use all its components.

3. Object oriented design

 In the object-oriented design method, the system is viewed as a collection of objects
(i.e., entities). The state is distributed among the objects, and each object handles its
state data. For example, in a Library Automation Software, each library representative
may be a separate object with its data and functions to operate on these data.

 Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.

 Classes: A class is a generalized description of an object. An object is an instance of a

class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.

 Messages: Objects communicate by message passing. Messages consist of the

integrity of the target object, the name of the requested operation, and any other
action needed to perform the function. Messages are often implemented as
procedure or function calls.

 Abstraction In object-oriented design, complexity is handled using abstraction.

Abstraction is the removal of the irrelevant and the amplification of the essentials.

 Encapsulation: Encapsulation is also called an information hiding concept. The

data and operations are linked to a single unit. Encapsulation not only bundles
essential information of an object together but also restricts access to the data
and methods from the outside world.

 Inheritance: OOD allows similar classes to stack up in a hierarchical manner

where the lower or sub-classes can import, implement, and re-use allowed
variables and functions from their immediate superclasses.This property of OOD
is called an inheritance. This makes it easier to define a specific class and to
create generalized classes from specific ones.

 Polymorphism: OOD languages provide a mechanism where methods

performing similar tasks but vary in arguments, can be assigned the same name.
This is known as polymorphism, which allows a single interface is performing
functions for different types. Depending upon how the service is invoked, the
respective portion of the code gets executed.
1.Object oriented

2.Function oriented design

3.structed design

REFFER NOTEBOOK

Design approches:

1.Top down approch

2.Bottom up approch

Design Pattern

Creational Patterns

These design patterns provide a way to create objects while hiding the creation logic, rather
than instantiating objects directly using new operator. This gives program more flexibility in
deciding which objects need to be created for a given use case.
Structural Patterns

These design patterns concern class and object composition. Concept of inheritance is used to
compose interfaces and define ways to compose objects to obtain new functionalities.

Behavioral Patterns

These design patterns are specifically concerned with communication between objects.

Software architecture design

IEEE defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development of a
computer system.” The software that is built for computer-based systems can exhibit one of
these many architectural styles.

Each style will describe a system category that consists of :

 A set of components(eg: a database, computational modules) that will perform a

function required by the system.

 The set of connectors will help in coordination, communication, and cooperation

between the components.

 Conditions that how components can be integrated to form the system.

 Semantic models that help the designer to understand the overall properties of the
system.

Architecture serves as a blueprint for a system. It provides an abstraction to manage the system
complexity and establish a communication and coordination mechanism among components.

It defines a structured solution to meet all the technical and operational requirements, while
optimizing the common quality attributes like performance and security.

Further, it involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the final product. These decisions
comprise of −

 Selection of structural elements and their interfaces by which the system is composed.
  Behavior as specified in collaborations among those elements.

 Composition of these structural and behavioral elements into large subsystem.

 Architectural decisions align with business objectives.

 Architectural styles guide the organization.

Architectural styles

Data centred architectures:

A data store will reside at the center of this architecture and is accessed frequently by the other
components that update, add, delete or modify the data present within the store.

The figure illustrates a typical data centered style. The client software access a central
repository. Variation of this approach are used to transform the repository into a blackboard
when data related to client or data of interest for the client change the notifications to client
software.

This data-centered architecture will promote integrability. This means that the existing
components can be changed and new client components can be added to the architecture
without the permission or concern of other clients.

Data can be passed among clients using blackboard mechanism.

Data flow architectures/pipe and filter architecture:

This kind of architecture is used when input data to be transformed into output data through a
series of computational manipulative components.

The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a
set of components called filters connected by pipes.

Pipes are used to transmit data from one component to the next.

Each filter will work independently and is designed to take data input of a certain form and
produces data output to the next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.

If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

Disadvantages

The format for data transfer has to be agreed between communicating transformations.

Each transformation must parse its input and unparse its output to the agreed form. This

increases system overhead and may mean that it is impossible to reuse architectural

components that use incompatible data structures

Call and Return architectures:

It is used to create a program that is easy to scale and modify. Many sub-styles exist within this
category. Two of them are explained below.
Remote procedure call architecture: This components is used to present in a main program or
sub program architecture distributed among multiple computers on a network.

Main program or Subprogram architectures: The main program structure decomposes into
number of subprograms or function into a control hierarchy. Main program contains number of
subprograms that can invoke other components.

Object Oriented architecture:

The components of a system encapsulate data and the operations that must be applied to
manipulate the data. The coordination and communication between the components are
established via the message passing.

Layered architecture:

A number of different layers are defined with each layer performing a well-defined set of
operations. Each layer will do some operations that becomes closer to machine instruction set
progressively.

At the outer layer, components will receive the user interface operations and at the inner
layers, components will perform the operating system interfacing(communication and
coordination with OS)

Intermediate layers to utility services and application software functions.

Repository architecture

The majority of systems that use large amounts of data are organized around a shared

database or repository. This model is therefore suited to applications in which data is

generated by one component and used by another. There is no need to transmit data explicitly
from one component to another.

Data in a system is managed in a central repository that is accessible to all system

components. Components do not interact directly, only through the repository.

You should use this pattern when you have a system in which large volumes of information are
generated that has to be stored for a long time. You may also use it in data-driven systems
where the inclusion of data in the repository triggers an action or tool.

Advandage

Components can be independent; they do not need to know of the existence of other

components. Changes made by one component can be propagated to all components. All data
can be managed consistently

Disadvantage

The repository is a single point of failure so problems in the repository affect the whole

system. May be inefficiencies in organizing all communication through the repository.

Distributing the repository across several computers may be difficult.

Client–server architecture

In a client–server architecture, the system is presented as a set of services, with each service

delivered by a separate server. Clients are users of these services and access servers to make
use of them.Used when data in a shared database has to be accessed from a range of locations.
Because servers can be replicated, may also be used when the load on a system is
variable.Client–server architectures are usually thought of as distributed systems architectures,
but the logical model of independent services running on separate servers can be implemented
on a single computer.

Advantage

The principal advantage of this model is that servers can be distributed across a network.

General functionality (e.g., a printing service) can be available to all clients and does not

need to be implemented by all services.

Disadvantages

Performance may be unpredictable because it depends on the network as well as the system.
Management problems may arise if servers are owned by different organizations.
Goals of Architecture

The primary goal of the architecture is to identify requirements that affect the structure of the
application. A well-laid architecture reduces the business risks associated with building a
technical solution and builds a bridge between business and technical requirements.

 Expose the structure of the system, but hide its implementation details.

 Realize all the use-cases and scenarios.

 Try to address the requirements of various stakeholders.

 Handle both functional and quality requirements.

 Reduce the goal of ownership and improve the organization’s market position.

 Improve quality and functionality offered by the system.

 Improve external confidence in either the organization or system.

Limitations

 Lack of tools and standardized ways to represent architecture.

 Lack of analysis methods to predict whether architecture will result in an

implementation that meets the requirements.

 Lack of awareness of the importance of architectural design to software development.

 Lack of understanding of the role of software architect and poor communication among
stakeholders.

 Lack of understanding of the design process, design experience and evaluation of design.

Architectural design: Refer CA notes

Modular decomposition

Definition: a software entity encapsulating the representation of an abstraction and providing

anabstract interface to it.
• Module interaction

– Module hides implementation details so that the rest of the system is insulated and protected
from the details AND vice versa.

– Modules communicate only through well-defined interfaces.

Abstraction is a tool that supports focus on important,inherent properties and suppression of

unnecessary detail.

– permits separation of conceptual aspects of a system from the implementation details.

– allows postponement of design decisions.

 Information Hiding

Information hiding is a decomposition principle that requiresthat each module hides its
internal details and is specified by as little information as possible.

– forces design units to communicate only through well-defined interfaces.

– enables clients to be protected if internal details change.

Sample entities to encapsulate:

– abstract data types

– algorithms

– input and output formats

– processing sequence

– machine dependencies

– policies (e.g. security issues, garbage collection, etc.)

Domain specific architecture