Unit 2

SOFTWARE ENGINEERING
UNIT-II
School of CSA
Dr.Hemanth.K.S
UNIT -2: [13 HOURS]
Requirement Modeling and Design:

Requirement: Functional & Non-functional requirements,
Requirement Modeling: Understanding Requirements, Requirements Modelling
(Scenario-based & Class-based methods)
Design: Design Concepts.

Architectural design (Webapp Design, Mobileapp Design)
UNIT -1 QUESTIONS 21/03/2023
1. What are some common misconceptions about software development and how
have they impacted the software engineering discipline?
2. How has the software development process evolved over time, and what factors
have driven these changes?
3. What are the key components of a software process model, and how can these
models be customized for specific types of projects or industries?
4. How can software engineers balance the need for structure and discipline in the
development process with the need for creativity and innovation?
5. What are some emerging trends in software engineering, and how are these
trends likely to impact the future of the industry?
SOFTWARE REQUIREMENT
Software requirement refers to the specific

capabilities, features, functionalities, and qualities
that a software system must have to meet the
needs of its users, stakeholders, or business
requirements.
In software development, requirements are
documented, analyzed, and used as a foundation
for designing, developing, testing, and deploying
software systems.
• Software requirements can be classified into two main categories:

functional requirements and non-functional requirements.
• Functional requirements describe what the software system is
expected to do, while non-functional requirements describe how the
software system should perform.
Examples of functional requirements include login functionality, search
capability, and checkout process,
Examples of non-functional requirements include performance, security,
usability, scalability, and reliability.
How to gathered Requirement ?
• Requirements can be gathered from various sources, including

business requirements, user needs, regulations and standards, and
stakeholder input.
• Effective requirements gathering, documentation, and management
are essential to ensure that software systems meet user needs, are
delivered on time and within budget, and achieve the desired quality
and performance objectives.
SOFTWARE
REQUIREMENT
How to gathered
Requirement ?
• The end goal of a project is to deliver a high quality product exactly as

the customer asked for. Functional requirements are the primary way
that a customer communicates their requirements to the project team.
Functional requirements help to keep project team going in the right
direction.
• Unclear requirements leads to a poorly defined scope that creates a lot
of challenges from the beginning of the project. A poorly defined scope
leads to extension in the schedule and increase in cost. The customer
may not have the time and money to invest, so they just accept a
product with low quality.
Understanding the difference between functional and non-functional

requirements will help both, the client and the IT supplier as they will be
able to understand their requirements clearly. This leads to scope
refinement, optimized cost, and finally a happy customer.
What are Functional Requirements?

“Any Requirement Which Specifies What The System Should Do.”
In other words, a functional requirement will describe a particular behaviour of
function of the system when certain conditions are met,
Example: “Send email when a new customer signs up” or “Open a new account”.
What are Functional Requirements?

Some of the more typical functional
requirements include:
• Authorization levels
• Business Rules • Audit Tracking
• Transaction corrections, adjustments • External Interfaces
and cancellations • Certification Requirements
• Administrative functions • Reporting Requirements
• Authentication • Historical Data
• Legal or Regulatory Requirements
What are non-functional requirements ?

The definition of a non-functional requirement is:
“Any Requirement That Specifies How The System Performs A Certain Function.”
In other words, a non-functional requirement will describe how a system should
behave and what limits there are on its functionality.
Non-functional requirements cover all the remaining requirements which are not
covered by the functional requirements.
What are non-functional requirements ?

Some typical non-functional requirements
are: • Recoverability
• Maintainability
• Performance – for example Response
• Serviceability
Time, Throughput, Utilization, Static
• Security
Volumetric
• Regulatory
• Scalability
• Manageability
• Capacity
• Environmental
• Availability
• Data Integrity
• Reliability
• Usability
• Interoperability
UNDERSTANDING THE REQUIREMENTS
Understanding the requirements of a problem is among the most difficult tasks that
face a software engineer.
When you first think about it, developing a clear understanding of requirements
doesn’t seem that hard. After all, doesn’t the customer know what is required?
Shouldn’t the end users have a good understanding of the features and functions that
will provide benefit?
Why is it important?
Designing and building an elegant computer program that solves the wrong problem
serves no one’s needs. That’s why it’s important to understand what the customer
wants before you begin to design and build a computer-based system.
What are the steps?

Requirements engineering
begins with inception—a task that defines the scope and nature of the problem to be
solved.
It moves onwards to elicitation—a task that helps stakeholders define what is
required, and then elaboration—where basic requirements are refined and modified.
As stakeholders define the problem, negotiation occurs—what are the priorities,
what is essential, when is it required? Finally, the problem is specified in some
manner and then reviewed or validated to ensure that your understanding of the
problem and the stakeholders’ understanding of the problem coincide.
REQUIREMENTS ENGINEERING
Requirements engineering provides the appropriate mechanism for

understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system
Inception
At project inception,you establish a basic understanding of the problem, the
people who want a solution, the nature of the solution that is desired, and the
effectiveness of preliminary communication and collaboration between the other
stakeholders and the software team.
Elicitation
Identify a number of problems that are encountered as elicitation
occurs.
Problems of scope.
Problems of understanding
Problems of volatility
Elaboration
Elaboration in requirement engineering refers to the process of adding more detail
to the requirements to ensure that they are complete, unambiguous, and
consistent.
elaboration is an essential part of requirement engineering that ensures the

requirements are well-defined and understood by all stakeholders.
By taking the time to refine and elaborate the requirements, project teams can
avoid costly mistakes and deliver a successful system that meets the needs of all
stakeholders.
Negotiation.
Negotiation in requirement engineering refers to the process of resolving conflicts
and finding common ground among stakeholders with differing requirements,
expectations, and priorities.
Effective negotiation is a crucial part of the requirement engineering process

because it ensures that all stakeholders are satisfied with the final set of
requirements, and that the resulting system will meet their needs.
Specification.
specification means different things to different people. A specification
can be a written document, a set of graphical models, a formal
mathematical model, a collection of usage scenarios, a prototype, or
any combination of these
Validation
The work products produced as a consequence of requirements engineering are
assessed for quality during a validation step.
Requirements validation examines the specification5 to ensure that all software

requirements have been stated unambiguously; that inconsistencies, omissions,
and errors have been detected and corrected; and that the work products conform
to the standards established for the process, the project, and the product.
ESTABLISHING THE GROUNDWORK
Stakeholders and software engineers work together on the same team. In such
cases, requirements engineering is simply a matter of conducting meaningful
conversations with colleagues who are well-known members of the team. But
reality is often quite different.
Identifying Stakeholders
Business operations managers, product managers, marketing people, internal and external
customers, end users, consultants, product engineers, software engineers, support and
maintenance engineers, and others. Each stakeholder has a different view of the system,
achieves different benefits when the system is successfully developed, and is open to
different risks if the development effort should fail. In an ideal setting, stakeholders and
software engineers
Recognizing Multiple Viewpoints
Because many different stakeholders exist, the requirements of the system will be
explored from many different points of view
Working toward Collaboration

Collaboration does not necessarily mean that requirements are defined by committee. In
many cases, stakeholders collaborate by providing their view of requirements, but a strong
“project champion”(e.g., a business manager or a senior technologist) may make the final
decision about which requirements make the cut.
Asking the First Questions
Questions asked at the inception of the project should be “context free”. The first
set of context-free questions focuses on the customer and other stakeholders, the
overall project goals and benefits. For example, you might ask:
• Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
What questions will help you gain a preliminary
understanding of the problem?
ELICITING REQUIREMENTS
Requirements elicitation (also called requirements gathering) combines elements

of problem solving, elaboration, negotiation, and specification.
In order to encourage a collaborative, team-oriented approach to requirements

gathering, stakeholders work together to identify the problem, propose elements
of the solution, negotiate different approaches and specify a preliminary set of
solution requirements
Collaborative Requirements Gathering

Many different approaches to collaborative requirements gathering have been
proposed. Each makes use of a slightly different scenario, but all apply some variation
on the following basic guidelines:
• Meetings are conducted and attended by both software engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage the free flow of ideas.
• A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic
bulletin board, chat room, or virtual forum) is used.
Quality Function Deployment
Quality function deployment (QFD) is a quality management technique that translates the
needs of the customer into technical requirements for software. QFD “concentrates on
maximizing customer satisfaction from the software engineering process”.
Normal requirements: The objectives and goals that are stated for a product or system
during meetings with the customer.
Expected requirements: These requirements are implicit to the product or system and
may be so fundamental that the customer does not explicitly state them.
Exciting requirements. These features go beyond the customer’s expectations and prove
to be very satisfying when present.
Usage Scenarios
• As requirements are gathered, an overall vision of system functions and features
begins to materialize.
• However, it is difficult to move into more technical software engineering activities
until you understand how these functions and features will be used by different
classes of end users.
• To accomplish this, developers and users can create a set of scenarios that identify a
thread of usage for the system to be constructed.
• The scenarios, often called use cases, provide a description of how the system will be
used.
Elicitation Work Products
The work products produced as a consequence of requirements elicitation will vary depending
on the size of the system or product to be built.
• A statement of need and feasibility.

• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraints that
apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under
different operating conditions.
• Any prototypes developed to better define requirements.
DEVELOPING USE CASES
Use cases are defined from an actor’s point of view. An actor is a role that people
(users) or devices play as they interact with the software.
Once actors have been identified, use cases can be developed
• Who is the primary actor, the secondary actor(s)?

• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
BUILDING THE REQUIREMENTS MODEL
The intent of the analysis model is to provide a description of the required informational,
functional, and behavioral domains for a computer-based system.
The model changes dynamically as you learn more about the system to be built, and
other stakeholders understand more about what they really require.
Elements of the Requirements Model

There are many different ways to look at the requirements for a computer-based
system. Some software people argue that it’s best to select one mode of representation
(e.g., the use case) and apply it to the exclusion of all other modes.
Scenario-based elements
Class-based elements
Behavioral elements
NEGOTIATING REQUIREMENTS
“A compromise is the art of dividing a cake in such a way that everyone believes
he has the biggest piece.”
The best negotiations strive for a “win-win” result.
That is, stakeholders win by getting the system or product that satisfies the majority of
their needs and you (as a member of the software team) win by working to realistic
and achievable budgets and deadlines.
VALIDATING REQUIREMENTS
When I review requirements, what questions should I ask?
As each element of the requirements model is created, it is examined for

inconsistency, omissions, and ambiguity
A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives 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?
REQUIREMENTS MODELING (SCENARIO-BASED & CLASS-
BASED METHODS)
At a technical level, software engineering begins with a series of modeling tasks that
lead to a specification of requirements and a design representation for the software to
be built.
The requirements model— actually a set of models—is the first technical representation
of a system.
Requirements modeling uses a combination of text and diagrammatic forms to depict

requirements in a way that is relatively easy to understand, and more important,
straightforward to review for correctness, completeness, and consistency.
BASED METHODS)
To validate software requirements, you need to examine them from a number of

different points of view. requirements modeling from three different perspectives:
scenario-based models, data (information) models, and class-based models.
BASED METHODS)
REQUIREMENTS ANALYSIS
Requirements analysis results in the specification of software’s operational
characteristics, indicates software’s interface with other system elements, and
establishes constraints that software must meet.
Requirements analysis allows you to elaborate on basic requirements established during

the inception, elicitation, and negotiation tasks that are part of requirements
engineering.
BASED METHODS)
The requirements modeling action results in one or more of the following types of
models:
• Scenario-based models of requirements from the point of view of various system

“actors”
• Data models that depict the information domain for the problem
BASED METHODS)
• Class-oriented models that represent object-oriented classes (attributes and
operations) and the manner in which classes collaborate to achieve system
requirements
• Flow-oriented models that represent the functional elements of the system and how
they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a consequence of
external “events”
BASED METHODS)
BASED METHODS)
SCENARIO-BASED MODELING
The success of a computer-based system or product is measured in many
ways, user satisfaction resides at the top of the list.
If you understand how end users (and other actors) want to interact with a system, your
software team will be better able to properly characterize requirements and build
meaningful analysis and design model.
BASED METHODS)
Creating a Preliminary Use Case

Use case describes a specific usage scenario in straightforward language from the point
of view of a defined actor.
But how do you know
(1) what to write about,
(2) How much to write about it,
(3) how detailed to make your description, and
(4) how to organize the description?
BASED METHODS)
Refining a Preliminary Use Case
Description of alternative interactions is essential for a complete understanding of
the function that is being described by a use case. Therefore, each step in the primary
scenario is evaluated by asking the following questions:
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this point? If
so, what might it be?
• Is it possible that the actor will encounter some other behavior at this point (e.g.,
behavior that is invoked by some event outside the actor’s control)? If so, what
might it be?
BASED METHODS)
Scenario-based requirements modeling involves the following steps:
1.Identify the users: Identify the different types of users who will interact with the
system. This includes end-users, administrators, managers, etc.
2.Define the scenarios: Identify the different scenarios or use cases that the users will
encounter while interacting with the system. A scenario is a sequence of actions that a
user performs to achieve a specific goal.
BASED METHODS)
Scenario-based requirements modeling involves the following steps:
1.Describe the scenarios: Describe each scenario in detail, including the steps involved,
inputs required, and the expected outputs.
2.Identify the requirements: Identify the requirements that are necessary to fulfill
each scenario. These requirements may include functional requirements, non-
functional requirements, performance requirements, etc.
3.Analyze the requirements: Analyze each requirement to ensure that it is complete,

consistent, and unambiguous.
BASED METHODS)
1.Prioritize the requirements: Prioritize the requirements based on their importance
and feasibility.
2.Document the requirements: Document the requirements in a clear and concise

manner, using diagrams, tables, and other visual aids to enhance their understanding.
By using a scenario-based approach, requirements can be better understood and

communicated, leading to a more successful project outcome. Additionally, by focusing
on the users and their needs, the resulting system is more likely to meet their
expectations and be adopted more readily.
BASED METHODS)
SCENARIO-
BASED
MODELING
BASED METHODS)
CLASS-BASED MODELING
Class-based modeling is a requirements modeling technique that focuses on identifying

the objects and classes that are required for the development of a software system. In
this approach, requirements are derived from the perspective of the objects and classes
that are involved in the system.
Identifying Analysis Classes
We can begin to identify classes by examining the usage scenarios developed as

part of the requirements model and performing a “grammatical parse” on
the use cases developed for the system to be built. Classes are determined by underlining
each noun or noun phrase and entering it into a simple table.
BASED METHODS)
Specifying Attributes
Attributes describe a class that has been selected for inclusion in the requirements
Model.
To develop a meaningful set of attributes for an analysis class, you should study each use
case and select those “things” that reasonably “belong” to the class
BASED METHODS)
Defining Operations
Operations define the behavior of an object. Although many different types of
operations exist, they can generally be divided into four broad categories:
(1)operations that manipulate data in some way (e.g., adding, deleting, reformatting,
selecting),
(2)operations that perform a computation,
(3)operations that inquire about the state of an object, and
(4)operations that monitor an object for the occurrence of a controlling event.
BASED METHODS)
Class-Responsibility-Collaborator (CRC) Modeling
Class-responsibility-collaborator (CRC) modeling provides a simple means for

identifying and organizing the classes that are relevant to system or product
requirements.
BASED METHODS)
Associations and Dependencies
In many instances, two analysis classes are related to one another in some fashion,
much like two data objects may be related to one another (Section 6.4.3). In UML
these relationships are called associations.
BASED METHODS)
The class-based modeling process involves the following steps:
1.Identify the objects: Identify the different objects that will be involved in the system.
Objects are entities that have specific attributes and behaviors.
2.Define the classes: Define the classes that will be required to represent the objects in
the system. Classes are templates or blueprints that define the attributes and behaviors
of objects.
BASED METHODS)
1.Identify the relationships: Identify the relationships between the classes.
Relationships describe how the classes interact with each other.
2.Define the attributes: Define the attributes of each class. Attributes are the
characteristics or properties of an object that are relevant to the system.
3.Define the behaviors: Define the behaviors of each class. Behaviors are the actions or
operations that the objects can perform.
4.Analyze the requirements: Analyze each requirement to ensure that it is complete,

consistent, and unambiguous.
BASED METHODS)
1.Prioritize the requirements: Prioritize the requirements based on their importance
and feasibility.
2.Document the requirements: Document the requirements in a clear and concise

manner, using diagrams, tables, and other visual aids to enhance their understanding.
By using a class-based modeling approach, requirements can be more accurately and

precisely defined, leading to a more successful project outcome. Additionally, the
resulting system is more likely to be extensible, maintainable, and scalable, as the
objects and classes have been designed with a focus on reusability.
BASED METHODS)
DESIGN CONCEPT
What is it?
Design is what almost every engineer wants to do. It is the place where creativity
rules—where stakeholder requirements, business needs, and technical
considerations all come together in the formulation of a product or system.
Design creates a representation or model of the software, but unlike the
requirements model (that focuses on describing required data, function, and
behavior), the design model provides detail about software architecture, data
structures, interfaces, and components that are necessary to implement the
system
DESIGN CONCEPT
Who does it?
Software engineers conduct each of the design tasks.

DESIGN CONCEPT
Design allows you to model the system or product that is to be built. This model can be
assessed for quality and improved before code is generated, tests are conducted, and
end users become involved in large numbers. Design is the place where software quality
is established.
DESIGN CONCEPT
What are the steps?
Design depicts the software in a number of different ways. First, the architecture of the
system or product must be represented. Then, the interfaces that connect the software
to end users, to other systems and devices, and to its own constituent components are
modeled. Finally, the software components that are used to construct the system are
designed. Each of these views represents a different design action, but all must conform
to a set of basic design concepts that guide software design work.
DESIGN CONCEPT
What is the work product?

A design model that encompasses architectural, interface, component level, and
deployment representations is the primary work product that is produced during
software design.
DESIGN CONCEPT
How do I ensure that I’ve done it right?
The design model is assessed by the software team in an effort to determine whether it
contains errors, inconsistencies, or omissions; whether better alternatives exist; and
whether the model can be implemented within the constraints, schedule, and cost that
have been established.
THE DESIGN PROCESS
Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
As design iterations occur, subsequent refinement leads to design representations at

much lower levels of abstraction.
THE DESIGN PROCESS
Software Quality Guidelines and Attributes
the quality of the evolving design is assessed with a series of technical reviews.
• The design must implement all of the explicit requirements contained in the requirements
model, and it must accommodate all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
THE DESIGN PROCESS
Quality Attributes
Hewlett-Packard {Gra87] developed a set of software quality attributes that has been given
the acronym FURPS—functionality, usability, reliability, performance, and supportability.
Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
THE DESIGN PROCESS
Quality Attributes
• Usability is assessed by considering human factors, overall aesthetics, consistency, and

documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the
predictability of the program.
THE DESIGN PROCESS
Quality Attributes
• Performance is measured by considering processing speed, response time, resource

consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,

serviceability
THE DESIGN PROCESS
DESIGN CONCEPTS
A set of fundamental software design concepts has evolved over the history of software
Engineering.
• What criteria can be used to partition software into individual components?

• How is function or data structure detail separated from a conceptual
representation of the software?
• What uniform criteria define the technical quality of a software design?
THE DESIGN PROCESS
DESIGN CONCEPTS
Abstraction
At lower levels of abstraction, a more detailed description of the solution is provided.
Problem-oriented terminology is coupled with implementation-oriented terminology

in an effort to state a solution.
As different levels of abstraction are developed
A procedural abstraction and A data abstraction

THE DESIGN PROCESS
DESIGN CONCEPTS
Abstraction
A procedural abstraction
A procedural abstraction refers to a sequence of instructions that have a specific
and limited function.
A data abstraction is a named collection of data that describes a data object. In

the context of the procedural abstraction open, we can define a data abstraction
called door.
THE DESIGN PROCESS
DESIGN CONCEPTS
Architecture
Software architecture alludes to “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system.
• One goal of software design is to derive an architectural rendering of a system.

• This rendering serves as a framework from which more detailed design activities
are conducted.
• A set of architectural patterns enables a software engineer to solve common
design problems.
THE DESIGN PROCESS
DESIGN CONCEPTS
Architecture
Set of properties that should be specified as part of an architectural design.
• Structural properties.
• Extra-functional properties
• Families of related systems
“A software architecture is the development work product that gives the highest
return on investment with respect to quality, schedule, and cost.”
Len Bass et al.
THE DESIGN PROCESS
DESIGN CONCEPTS
Patterns
Design pattern describes a design structure that solves a particular design problem
within a specific context and amid “forces” that may have an impact on the
manner in which the pattern is applied and used.”
“Each pattern describes a problem which occurs over and over again in our environment,
and then describes the core of the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing it the same way twice.”
Christopher
Alexander
THE DESIGN PROCESS
DESIGN CONCEPTS
Separation of Concerns
Separation of concerns is a design concept that suggests that 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.
THE DESIGN PROCESS
DESIGN CONCEPTS
Modularity
Modularity is the most common manifestation of separation of concerns. Software is

divided into separately named and addressable components, sometimes called
modules, that are integrated to satisfy problem requirements.
It has been stated that “modularity is the single attribute of software that allows a
program to be intellectually manageable” .
THE DESIGN PROCESS
DESIGN CONCEPTS
Information Hiding
The principle of information hiding suggests that modules be “characterized by design

decisions that (each) hides from all others.”
The intent of information hiding is to hide the details of data structures and procedural
processing behind a module interface. Knowledge of the details need not be known by
users of the module.
The use of information hiding as a design criterion for modular systems
provides the greatest benefits when modifications are required during testing
and later during software maintenance.
THE DESIGN PROCESS
DESIGN CONCEPTS
Functional Independence
Functional independence is achieved by developing modules with “singleminded”
function and an “aversion” to excessive interaction with other modules.
To summarize, functional independence is a key to good design, and design is the

key to software quality.
Independence is assessed using two qualitative criteria: cohesion and coupling.

Cohesion is an indication of the relative functional strength of a module. Coupling
is an indication of the relative interdependence among modules.
THE DESIGN PROCESS
DESIGN CONCEPTS
Refinement
Refinement is actually a process of elaboration. You begin with a statement of
function (or description of information) that is defined at a high level of abstraction.
That is, the statement describes function or information conceptually but provides
no information about the internal workings of the function or the internal structure
of the information.
You then elaborate on the original statement, providing more and more detail as
each successive refinement (elaboration) occurs.
THE DESIGN PROCESS
DESIGN CONCEPTS
Aspects
It is important to identify aspects so that the design can properly accommodate them
as refinement and modularization occur.
In an ideal context, an aspect is implemented as a separate module (component)
rather than as software fragments that are “scattered” or “tangled” throughout many
components .
To accomplish this, the design architecture should support a mechanism for defining
an aspect—a module that enable the concern to be implemented across all other
concerns that it crosscuts.
THE DESIGN PROCESS
DESIGN CONCEPTS
Refactoring
“Refactoring is the process of changing a software system in such a way that it does
not alter the external behavior of the code [design] yet improves its internal
structure.”
When software is refactored, the existing design is examined for redundancy, unused
design elements, inefficient or unnecessary algorithms, poorly constructed or
inappropriate data structures, or any other design failure that can be corrected to
yield a better design.
THE DESIGN PROCESS
DESIGN CONCEPTS
Object-Oriented Design Concepts

Design Classes
Design classes refer to the fundamental building blocks of an object-oriented design.

These classes describe the behaviour and properties of objects in a software system.
As the design model evolves, you will define a set of design classes that refine the analysis
classes by providing design detail that will enable the classes to be implemented, and
implement a software infrastructure that supports the business solution.
THE DESIGN PROCESS
DESIGN CONCEPTS
Design Classes
Five different types of design classes, each representing a different layer of the design architecture.
• User interface classes: define all abstractions that are necessary for human computer
interaction (HCI).
• Business domain classes: The classes identify the attributes and services (methods) that are
required to implement some element of the business domain.
THE DESIGN PROCESS
DESIGN CONCEPTS

Design Classes
Five different types of design classes, each representing a different layer of the design architecture.
• Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the execution
of the software.
• System classes implement software management and control functions that enable the system
to operate and communicate within its computing environment and with the outside world.
ARCHITECTURAL DESIGN
What is it?
Architectural design represents the structure of data and program components that
are required to build a computer-based system. It considers the architectural style
that the system will take, the structure and properties of the components that
constitute the system, and the interrelationships that occur among all architectural
components of a system.
Architectural design in software design refers to the process of designing the overall
structure and organization of a software system.
The architectural design phase is critical in the software development process

because it sets the foundation for the rest of the project.
A well-designed architecture can help ensure that the system is easy to develop, test,
and maintain, and can also support future enhancements and changes.
“A database or data warehouse designer creates the data architecture for a system”.
What are the steps?

Architectural design begins with data design and then proceeds to the derivation of
one or more representations of the architectural structure of the system. Alternative
architectural styles or patterns are analyzed to derive the structure that is best suited
to customer requirements and quality attributes. Once an alternative has been
selected, the architecture is elaborated using an architectural design method.
The architecture is not the operational software. Rather, it is a

representation that enables you to
• Analyze the effectiveness of the design in meeting its stated requirements,
• Consider architectural alternatives at a stage when making design changes is still
relatively easy, and
• Reduce the risks associated with the construction of the software..
Why Is Architecture Important?
three key reasons that software architecture is important

1. Representations of software architecture are an enabler for communication
between all parties (stakeholders) interested in the development of a computer-
based system.
2. 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.
3. Architecture “constitutes a relatively small, intellectually graspable model of how
the system is structured and how its components work together” [Bas03].
Architectural Descriptions
Architectural descriptions are an important part of software design, as they provide a

high-level overview of the software's structure and organization. These descriptions
help to communicate the design of the software to stakeholders, including
developers, project managers, and clients, and they can also help to identify
potential issues or problems before the software is implemented.
Architectural Descriptions
An architectural description typically includes information such as the software's

components, their relationships to one another, the interactions between
components, and the design patterns and principles that have been used in the
software's construction. The description may also include diagrams, such as block
diagrams or UML diagrams, to illustrate the software's structure and behaviours.
Architectural Decisions
Architectural decisions are the key design choices that shape the overall structure
and organization of a software system. These decisions have a significant impact on
the software's functionality, performance, maintainability, and other important
characteristics.
Making effective architectural decisions requires careful consideration of a range of
factors, including the project's goals, the available resources, the technical
capabilities of the development team, and the constraints of the development
environment
Architectural Styles
Architectural styles refer to the fundamental principles or patterns that guide the
organization of software systems.
Here are some of the most common architectural styles in software design:
• Monolithic Architecture
• Client-Server Architecture
• Microservices Architecture
• Service-Oriented Architecture (SOA)
• Event-Driven Architecture
• Layered Architecture
• Domain-Driven Design
Each of these architectural styles has its own strengths and weaknesses, and the choice of
style depends on the requirements of the project and the goals of the development team.
Architectural Design
Architectural design is the process of creating plans, drawings, and models for
buildings, structures, and landscapes. It involves the planning, design, and
coordination of various elements such as site selection, building systems, aesthetics,
and functionality.
Architectural design is a complex process that requires a combination of creativity,

technical knowledge, and problem-solving skills. The goal of architectural design is
to create spaces that are functional, safe, sustainable, and aesthetically pleasing.
Assessing alternative architectural designs

Assessing alternative architectural designs is an important aspect of the design
process, as it helps to ensure that the chosen design is the best possible option for
the client's needs and requirements. The following are some steps that can be taken
to assess alternative are
• Define the goals and objectives:
• Generate multiple design options
• Evaluate each design option
• Select the best design option
• Refine the selected design option
• Evaluate the final design
Overall, assessing alternative architectural designs involves a systematic and
objective approach to ensure that the best possible design option is selected for the
project.
Architectural mapping using data flow

Architectural mapping using data flow is a technique used to identify the flow of data
within a software system and map it to the system's architecture. This technique helps in
understanding the behaviour of a software system and identifying its components and
their interactions.
To perform architectural mapping using data flow, you need to follow the following steps:
• Identify the data sources and sinks
• Identify the data flows
• Map the data flows to the architecture
• Analyze the architecture
Overall, architectural mapping using data flow is a powerful technique that can help you understand
the behavior of a software system and identify areas for improvement.
ARCHITECTURAL DESIGN WEBAPP
MOBILEAPP

Unit 2

Uploaded by

Copyright:

Available Formats

Unit 2

Uploaded by

Document Information

Original Description:

Original Title

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

Unit 2

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

Requirement Modeling and Design:

Design: Design Concepts.

Software requirement refers to the specific

• Software requirements can be classified into two main categories:

How to gathered Requirement ?

• Requirements can be gathered from various sources, including

• The end goal of a project is to deliver a high quality product exactly as

Understanding the difference between functional and non-functional

What are Functional Requirements?

What are Functional Requirements?

What are non-functional requirements ?

What are non-functional requirements ?

What are the steps?

Requirements engineering provides the appropriate mechanism for

elaboration is an essential part of requirement engineering that ensures the

Effective negotiation is a crucial part of the requirement engineering process

Requirements validation examines the specification5 to ensure that all software

Recognizing Multiple Viewpoints

Working toward Collaboration

Asking the First Questions

• Who is behind the request for this work?

Requirements elicitation (also called requirements gathering) combines elements

In order to encourage a collaborative, team-oriented approach to requirements

Collaborative Requirements Gathering

Quality Function Deployment

Elicitation Work Products

• A statement of need and feasibility.

Once actors have been identified, use cases can be developed

• Who is the primary actor, the secondary actor(s)?

Elements of the Requirements Model

The best negotiations strive for a “win-win” result.

When I review requirements, what questions should I ask?

As each element of the requirements model is created, it is examined for

Requirements modeling uses a combination of text and diagrammatic forms to depict

To validate software requirements, you need to examine them from a number of

Requirements analysis allows you to elaborate on basic requirements established during

• Scenario-based models of requirements from the point of view of various system

Creating a Preliminary Use Case

3.Analyze the requirements: Analyze each requirement to ensure that it is complete,

2.Document the requirements: Document the requirements in a clear and concise

By using a scenario-based approach, requirements can be better understood and

Class-based modeling is a requirements modeling technique that focuses on identifying

Identifying Analysis Classes

We can begin to identify classes by examining the usage scenarios developed as

Class-responsibility-collaborator (CRC) modeling provides a simple means for

The class-based modeling process involves the following steps:

4.Analyze the requirements: Analyze each requirement to ensure that it is complete,

2.Document the requirements: Document the requirements in a clear and concise

By using a class-based modeling approach, requirements can be more accurately and

Who does it?

Software engineers conduct each of the design tasks.

What are the steps?

What is the work product?

How do I ensure that I’ve done it right?

As design iterations occur, subsequent refinement leads to design representations at

Software Quality Guidelines and Attributes

Software Quality Guidelines and Attributes