Layered Technology

• Software engineering is a fully layered technology, to develop

software we need to go from one layer to another. All the layers are
connected and each layer demands the fulfillment of the previous
layer.
Layered technology is divided into four
parts:
• 1.A quality focus: It defines the continuous process improvement
principles of software. It provides integrity that means providing
security to the software so that data can be accessed by only an
authorized person, no outsider can access the data. It also focuses on
maintainability and usability.
• 2. Process: It is the foundation or base layer of software engineering.
It is key that binds all the layers together which enables the
development of software before the deadline or on time. Process
defines a framework that must be established for the effective delivery
of software engineering technology. The software process covers all
the activities, actions, and tasks required to be carried out for software
development.
Layered technology is divided into four
parts:
Layered technology is divided into four
parts:
• Process activities are listed below:-
• Communication: It is the first and foremost thing for the
development of software. Communication is necessary to know the
actual demand of the client.
• Planning: It basically means drawing a map for reduced the
complication of development.
• Modeling: In this process, a model is created according to the client
for better understanding.
• Construction: It includes the coding and testing of the problem.
• Deployment:- It includes the delivery of software to the client for
evaluation and feedback.
Layered technology is divided into four
parts:
• 3. Method: During the process of software development the answers
to all “how-to-do” questions are given by method. It has the
information of all the tasks which includes communication,
requirement analysis, design modeling, program construction, testing,
and support.
• 4. Tools: Software engineering tools provide a self-operating system
for processes and methods. Tools are integrated which means
information created by one tool can be used by another.
• Last Updated : 09 Jun, 2022
Process Framework:
• A process framework establishes the foundation for a complete software
process by identifying a small number of framework activities that are
applicable to all software projects, regardless of size or complexity.
• It also includes a set of umbrella activities that are applicable across the
entire software process.
• Each framework activity is populated by a set of software engineering
actions – a collection of related tasks that produces a major software
engineering work product (e.g. design is a software engineering action).
• Each action is populated with individual work tasks that accomplish some
part of the work implied by the action.
• The following generic process framework is applicable to the vast majority
of software projects :
Process Framework:
• 1. Communication: This framework activity involves heavy
communication and collaboration with the customer (and other
stakeholders) and encompasses requirements gathering and other
related activities.
• 2. Planning: This activity establishes a plan for the software
engineering work that follows. It describes the technical tasks to be
conducted, the risks that are likely, the resources that will be required,
the work products to be produced and a work schedule.
• 3. Modeling: This activity encompasses the creation of models that
allow the developer and the customer to better understand software
requirements and the design that will achieve those requirements.
Process Framework:
• 4. Construction: This activity combines code generation (either
manual or automated) and the testing that is required to uncover errors
in the code.
• 5. Deployment: The software is delivered to the customer who
evaluates the delivered product and provides feedback based on
evaluation.
Process Framework:
• Some most applicable framework activities are described below.
Capability Maturity Model Integration (CMMI)

• Capability Maturity Model Integration (CMMI) is a successor of

CMM and is a more evolved model that incorporates best components
of individual disciplines of CMM like Software CMM, Systems
Engineering CMM, People CMM, etc. Since CMM is a reference
model of matured practices in a specific discipline, so it becomes
difficult to integrate these disciplines as per the requirements. This is
why CMMI is used as it allows the integration of multiple disciplines
as and when needed.
Capability Maturity Model Integration (CMMI)

• Objectives of CMMI :
1.Fulfilling customer needs and expectations.
2.Value creation for investors/stockholders.
3.Market growth is increased.
4.Improved quality of products and services.
5.Enhanced reputation in Industry.
Capability Maturity Model Integration (CMMI)

• A representation allows an organization to pursue a different set of

improvement objectives. There are two representations for CMMI :
• Staged Representation :
• uses a pre-defined set of process areas to define improvement path.
• provides a sequence of improvements, where each part in the sequence serves
as a foundation for the next.
• an improved path is defined by maturity level.
• maturity level describes the maturity of processes in organization.
• Staged CMMI representation allows comparison between different
organizations for multiple maturity levels.
Capability Maturity Model Integration (CMMI)

• Continuous Representation :
• allows selection of specific process areas.
• uses capability levels that measures improvement of an individual process
area.
• Continuous CMMI representation allows comparison between different
organizations on a process-area-by-process-area basis.
• allows organizations to select processes which require more improvement.
• In this representation, order of improvement of various processes can be
selected which allows the organizations to meet their objectives and eliminate
risks.
Capability Maturity Model Integration (CMMI)

• CMMI Model – Maturity Levels :

In CMMI with staged representation, there are five maturity levels
described as follows :
1.Maturity level 1 : Initial
1. processes are poorly managed or controlled.
2. unpredictable outcomes of processes involved.
3. ad hoc and chaotic approach used.
4. No KPAs (Key Process Areas) defined.
5. Lowest quality and highest risk
Capability Maturity Model Integration (CMMI)

2.Maturity level 2 : Managed

1. requirements are managed.
2. processes are planned and controlled.
3. projects are managed and implemented according to their documented plans.
4. This risk involved is lower than Initial level, but still exists.
5. Quality is better than Initial level.
3.Maturity level 3 : Defined
1. processes are well characterized and described using standards, proper
procedures, and methods, tools, etc.
2. Medium quality and medium risk involved.
3. Focus is process standardization.
Capability Maturity Model Integration (CMMI)
4. Maturity level 4 : Quantitatively managedquantitative
objectives for process performance and quality are set.
• Quantitative objectives are based on customer requirements,
organization needs, etc.
• process performance measures are analyzed quantitatively.
• higher quality of processes is achieved.
• lower risk
Capability Maturity Model Integration (CMMI)
• 5. Maturity level 5 : Optimizingcontinuous improvement in processes
and their performance.
• improvement has to be both incremental and innovative.
• highest quality of processes.
• lowest risk in processes and their performance
CMMI Model – Capability Levels
• A capability level includes relevant specific and generic practices for a
specific process area that can improve theorganization’s processes
associated with that process area. For CMMI models with continuous
representation, there aresix capability levels as described below :
• 1.Capability level 0 : Incomplete
• incomplete process – partially or not performed.
• one or more specific goals of process area are not met.
• No generic goals are specified for this level.
• this capability level is same as maturity level 1.
CMMI Model – Capability Levels
2.Capability level 1 : Performed
• process performance may not be stable.
• objectives of quality, cost and schedule may not be met.
• a capability level 1 process is expected to perform all specific and
generic practices for this level.
• only a start-step for process improvement
CMMI Model – Capability Levels
• 3. Capability level 2 : Managed
• process is planned, monitored and controlled.
• managing the process by ensuring that objectives are achieved.
• objectives are both model and other including cost, quality, schedule.
• actively managing processing with the help of metrics.
• 4.Capability level 3 : Defined
• a defined process is managed and meets the organization’s set of
guidelines and standards.
• focus is process standardization.
CMMI Model – Capability Levels
• 5.Capability level 4 : Quantitatively Managed
• process is controlled using statistical and quantitative techniques.
• process performance and quality is understood in statistical terms and metrics.
• quantitative objectives for process quality and performance are established.
• 6.Capability level 5 : Optimizing
• focuses on continually improving process performance.
• performance is improved in both ways – incremental and innovation.
• emphasizes on studying the performance results across the organization to ensure
that common causes or issuesare identified and fixed.
Process Patterns

• As the software team moves through the software process they

encounter problems. It would be very useful if solutions to these
problems were readily available so that problems can be resolved
quickly. Process-related problems which are encountered during
software engineering work, it identifies the encountered problem and
in which environment it is found, then it will suggest proven solutions
to problem, they all are described by process pattern. By solving
problems a software team can construct a process that best meets
needs of a project.
Process Patterns

• Uses of the process pattern:

• At any level of abstraction, patterns can be defined. They can be used to
describe a problem and solution associated with framework activity in some
situations. While in other situations patterns can be used to describe a
problem and solution associated with a complete process model.
• Template:
• Pattern Name – Meaningful name must be given to a pattern within
context of software process (e.g. Technical Reviews).
• Forces – The issues that make problem visible and may affect its solution
also environment in which pattern is encountered.
Process Patterns

• It is of three types :
1.Stage pattern – Problems associated with a framework activity for process
are described by stage pattern. Establishing Communication might be an
example of a staged pattern. This pattern would incorporate task pattern
Requirements Gathering and others.
2.Task-pattern – Problems associated with a software engineering action or
work task and relevant to successful software engineering practice (e.g.,
Requirements Gathering is a task pattern) are defined by task-pattern.
3.Phase pattern – Even when the overall flow of activities is iterative in
nature, it defines sequence of framework activities that occurs within
process. Spiral Model or Prototyping might be an example of a phase
pattern
Process Assessment

• Software process assessment examines whether the software processes

are effective and efficient in accomplishing the goals. This is
determined by the capability of selected software processes. The
capability of a process determines whether a process with some
variations is capable of meeting user’s requirements.
Process Assessment
Process Assessment
• SPICE (Software Process Improvement and Capability
Determination) is a standard used for both process improvement and
process capability determination. SPICE provides a framework for
assessing the software process and is used by the organizations
involved in planning, monitoring, developing, managing, and
improving acquisitions. It is carried out in accordance with the
International Organization for Standardization (ISO) and International
Electro-technical Committee (IEC), which are used together and
known as ISO/IEC 15504. The functions of SPICE (ISO/IEC 15504)
are listed below.
Process Assessment

• Not performed: At this level, the processes are unable to accomplish the
required outcomes. Thus, no identifiable products are created.
• Performed informally: At this level, the implemented process accomplishes
the defined outcomes. It is not planned and tracked; rather it depends on
individual knowledge and identifiable products.
• Planned and tracked: At this level, the defined process delivers products
according to quality requirements within a specified time. The processes
and products are verified according to the procedures, standards, and
requirements.
• Well-defined: At this level, the processes based on software engineering
principles which are capable of achieving defined outcomes are used.
Process Assessment
• Quantitatively controlled: At this level, the performance measures,
prediction capability and objective management are evaluated
quantitatively. In addition, existing processes perform consistently
within the defined limits to accomplish the desired outputs.
• Continuously improved: At this level, the existing processes adapt to
meet future business goals. For continuous improvement, various
kinds of statistical methods are used.
Personal and Team Process Model

• The best software process is personal and team process model one that
is close to the people who will be doing the work. Watts Humphrey
proposed two process models. Models “Personal Software Process
(PSP)” and “Team Software Process (TSP).” Both require hard work,
training, and coordination, but both are achievable.
• Personal Software Process (PSP)
• The Personal Software Process (PSP) emphasizes personal
measurement of both the work product that is produced and the
resultant quality of the work product.
Personal and Team Process Model

• Planning. This activity isolates requirements and develops both size

and resource estimates. In addition, defects estimate (the number of
defects projected for the work) is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and
a project schedule is created.
• High level design. External specifications for each component to be
constructed are developed and a component design is created.
Prototypes are built when uncertainty exists. All issues are recorded
and tracked.
Personal and Team Process Model

• High level design review. Formal verification methods are applied to

uncover errors in the design. Metrics are maintained for all important
tasks and work results.
• Development. The component level design is refined and reviewed.
Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important tasks and work results.
• Postmortem. Using the measures and metrics collected, the
effectiveness of the process is determined. Measures and metrics
should provide guidance for modifying the process to improve its
effectiveness.
Software Requirements

• According to IEEE standard 729, a requirement is defined as follows:

• A condition or capability needed by a user to solve a problem or
achieve an objective
• A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
• A documented representation of a condition or capability as in 1 and 2.
Software Requirements

• Main types of software requirement can be of 3 types:

• Functional requirements
• Non-functional requirements
• Domain requirements
Software Requirements

• Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. It
can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform. 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. They are
basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.
Software Requirements

• For example, in a hospital management system, a doctor should be

able to retrieve the information of his patients. Each high-level
functional requirement may involve several interactions or dialogues
between the system and the outside world. In order to accurately
describe the functional requirements, all scenarios must be
enumerated. 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. Functional Requirements in Software Engineering are also
called Functional Specification.
Software Requirements
• Non-functional requirements: These are basically the quality
constraints that the system must satisfy according to the project
contract.Nonfunctional requirements, not related to the system
functionality, rather define how the system should perform The
priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:
Software Requirements
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Software Requirements
• NFR’s are classified into following types:
• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability, portability, etc.
• Economic constraints
Software Requirements
• Domain requirements: Domain requirements are the requirements
which are characteristic of a particular category or domain of projects.
Domain requirements can be functional or nonfunctional. Domain
requirements engineering is a continuous process of proactively
defining the requirements for all foreseeable applications to be
developed in the software product line.
Software Requirements
• Other common classifications of software requirements can be:
1.User requirements: These requirements describe what the end-user
wants from the software system. User requirements are usually
expressed in natural language and are typically gathered through
interviews, surveys, or user feedback.
2.System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces. System
requirements are typically expressed in technical terms and are often
used as a basis for system design.
Software Requirements
• 3.Business requirements: These requirements describe the business goals
and objectives that the software system is expected to achieve. Business
requirements are usually expressed in terms of revenue, market share,
customer satisfaction, or other business metrics.
• 4.Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other legal
compliance requirements.
• 5.Interface requirements: These requirements specify the interactions
between the software system and external systems or components, such as
databases, web services, or other software applications.
Software Requirements
• Design requirements: These requirements describe the technical
design of the software system. They include information about the
software architecture, data structures, algorithms, and other technical
aspects of the software.
• Advantages of classifying software requirements include:
• Better organization
• Improved communication:
• Increased quality:
• Improved traceability:
Software Requirements
• Disadvantages of classifying software requirements include:
• Complexity:
• Rigid structure
• Misclassification:
User and System Requirements
Software requirements document

• Introduction
• Purpose
• Intended Use
• Scope
• Definitions and Acronyms:
• Overall Description
• User Needs
Software requirements document
• 1. Introduction
• 1.1 Purpose: Set the expectations for the outcome of the product.
• 1.2 Intended Audience: Who is the software for? Who is the end-user?
Will the software be used internally at a company or externally?
• 1.3 Intended Use: What is the software for? What problem is it solving?
• 1.4 Scope: Explain the scope of the software. What are the main goals and
objectives? How do they relate to the company’s goals?
• 1.5 Definitions and Acronyms: Provide an overview of any definitions the
reader should understand before reading on.
• 2. Overall Description: Describe what you are building and for who.
• 2.1 User Needs: Explain the user needs for this software.
Software requirements document
• 2.2 Assumptions and Dependencies: What assumptions are you making
that could cause an error in your approach? Is the project reliant on any
other factors that could affect the development of the software?
• 3. System Features and Requirements
• 3.1 Functional Requirements: Take time to define the functional
requirements that are essential for the software to build.
• 3.2 External Interface Requirements: Are there any UX and UI
requirements that you must keep in mind as you build?
• 3.3 System Features: What features are required for the software to even
work.
• 3.4 Nonfunctional Requirements: Are there any non-functional
requirements that you need to address (i.e. budget, team, etc.)
Requirements Engineering Process
• Requirements engineering is the process of identifying, eliciting, analyzing,
specifying, validating, and managing the needs and expectations of
stakeholders for a software system.
• Requirement Engineering Process
• It is a four-step process, which includes -
1.Feasibility Study
2.Requirement Elicitation and Analysis
3.Software Requirement Specification
4.Software Requirement Validation
5.Software Requirement Management
Requirements Engineering Process
1. Feasibility Study:
• The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change and
conformable to established standards.
• Types of Feasibility:
1.Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
2.Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3.Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.
• 2. Requirement Elicitation and Analysis:
• This is also known as the gathering of requirements. Here, requirements
are identified with the help of customers and existing systems processes, if
available.
• Analysis of requirements starts with requirement elicitation. The
requirements are analyzed to identify inconsistencies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve
conflicts if any.
• Problems of Elicitation and Analysis
•
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system
requirements.
• Software Requirement Specification:
• Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.
• The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
• Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a
company, an organization, a set of procedures, a computer hardware system, a software
system, or any combination of the preceding. The DFD is also known as a data flow graph
or bubble chart.
• Data Dictionaries: Data Dictionaries are simply repositories to store information about all
data items defined in DFDs. At the requirements stage, the data dictionary should at least
define customer data items, to ensure that the customer and developers use the same
definition and terminologies.
• Entity-Relationship Diagrams: Another tool for requirement specification is the entity-
relationship diagram, often called an "E-R diagram." It is a detailed logical representation
of the data for the organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.
• 4. Software Requirement Validation:
• After requirement specifications developed, the requirements discussed in
this document are validated. The user might demand illegal, impossible
solution or experts may misinterpret the needs. Requirements can be the
check against the following conditions -
• If they can practically implement
• If they are correct and as per the functionality and specially of software
• If there are any ambiguities
• If they are full
• If they can describe
• Requirements Validation Techniques
• Requirements reviews/inspections: systematic manual analysis of
the requirements.
• Prototyping: Using an executable model of the system to check
requirements.
• Test-case generation: Developing tests for requirements to check
testability.
• Automated consistency analysis: checking for the consistency of
structured requirements descriptions.