Software Engineering Tutorial

Software Engineering provides a standard procedure to design and develop a

software.

What is Software Engineering?

The term software engineering is the product of two words, software,
and engineering.

The software is a collection of integrated programs.

Software subsists of carefully-organized instructions and code written by developers

on any of various particular computer languages.

Computer programs and related documentation such as requirements, design

models and user manuals.

Engineering is the application of scientific and practical knowledge to invent,

design, build, maintain, and improve frameworks, processes, etc.

Software Engineering is an engineering branch related to the evolution of software

product using well-defined scientific principles, techniques, and procedures. The
result of software engineering is an effective and reliable software product.

Why is Software Engineering required?

Software Engineering is required due to the following reasons:

o To manage Large software

o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management

Need of Software Engineering

The necessity of software engineering appears because of a higher rate of progress
in user requirements and the environment on which the program is working.
 o Huge Programming: It is simpler to manufacture a wall than to a house or
building, similarly, as the measure of programming become extensive
engineering has to step to give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and
engineering ideas, it would be simpler to re-create new software than to scale
an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge
manufacturing has let down the cost of computer and electronic hardware.
But the cost of programming remains high if the proper process is not
adapted.
o Dynamic Nature: The continually growing and adapting nature of
programming hugely depends upon the environment in which the client
works. If the quality of the software is continually changing, new upgrades
need to be done in the existing one.
o Quality Management: Better procedure of software development provides a
better and quality software product.

AD
AD

Characteristics of a good software

engineer
The features that good software engineers should possess are as follows:

Exposure to systematic methods, i.e., familiarity with software engineering principles.

Good technical knowledge of the project range (Domain knowledge).

Good programming abilities.

Good communication skills. These skills comprise of oral, written, and interpersonal
skills.

High motivation.

Sound knowledge of fundamentals of computer science.

Intelligence.

Ability to work in a team

 ADVERTISEMENT

Discipline, etc.

Importance of Software Engineering

The importance of Software engineering is as follows:

AD

1. Reduces complexity: Big software is always complicated and challenging to

progress. Software engineering has a great solution to reduce the
complication of any project. Software engineering divides big problems into
various small issues. And then start solving each small issue one by one. All
these small problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hardwork and software
engineers are highly paid experts. A lot of manpower is required to develop
software with a large number of codes. But in software engineering,
programmers project everything and decrease all those things that are not
needed. In turn, the cost for software productions becomes less as compared
to any software that does not use software engineering method.
3. To decrease time: Anything that is not made according to the project always
wastes time. And if you are making great software, then you may need to run
many codes to get the definitive running code. This is a very time-consuming
procedure, and if it is not well handled, then this can take a lot of time. So if
you are making your software according to the software engineering method,
then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and
they need lots of patience, planning, and management. And to invest six and
seven months of any company, it requires heaps of planning, direction,
testing, and maintenance. No one can say that he has given four months of a
company to the task, and the project is still in its first stage. Because the
company has provided many resources to the plan and it should be
completed. So to handle a big project without any problem, the company has
to go for a software engineering method.
5. Reliable software: Software should be secure, means if you have delivered
the software, then it should work for at least its given time or subscription.
And if any bugs come in the software, the company is responsible for solving
 all these bugs. Because in software engineering, testing and maintenance are
given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the
standards. Software standards are the big target of companies to make it
more effective. So Software becomes more effective in the act with the help of
software engineering.

Software Processes
The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and how
they are to be used.

A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities
are:

1. Software specifications: The functionality of the software and constraints on

its operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.

The Software Process Model

A software process model is a specified definition of a software process, which is
presented from a particular perspective. Models, by their nature, are a simplification,
so a software process model is an abstraction of the actual process, which is being
described. Process models may contain activities, which are part of the software
process, software product, and the roles of people involved in software engineering.
Some examples of the types of software process models that may be produced are:

1. A workflow model: This shows the series of activities in the process along
with their inputs, outputs and dependencies. The activities in this model
perform human actions.
 2. 2. A dataflow or activity model: This represents the process as a set of
activities, each of which carries out some data transformations. It shows how
the input to the process, such as a specification is converted to an output such
as a design. The activities here may be at a lower level than activities in a
workflow model. They may perform transformations carried out by people or
by computers.
3. 3. A role/action model: This means the roles of the people involved in the
software process and the activities for which they are responsible.

There are several various general models or paradigms of software development:

1. The waterfall approach: This takes the above activities and produces them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on. After each stage is defined, it is "signed
off" and development goes onto the following stage.
2. Evolutionary development: This method interleaves the activities of
specification, development, and validation. An initial system is rapidly
developed from a very abstract specification.
3. Formal transformation: This method is based on producing a formal
mathematical system specification and transforming this specification, using
mathematical methods to a program. These transformations are 'correctness
preserving.' This means that you can be sure that the developed programs
meet its specification.
4. System assembly from reusable components: This method assumes the
parts of the system already exist. The system development process target on
integrating these parts rather than developing them from scratch.

Software Crisis
1. Size: Software is becoming more expensive and more complex with the
growing complexity and expectation out of software. For example, the code in
the consumer product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products
defects after putting into use due to ineffective testing technique. For
example, Software testing typically finds 25 errors per 1000 lines of code.
 3. Cost: Software development is costly i.e. in terms of time taken to develop
and the money involved. For example, Development of the FAA's Advanced
Automation System cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the
software takes longer than the estimated time to develop, which in turn leads
to cost shooting up. For example, one in four large-scale development
projects is never completed.

Program vs. Software

Software is more than programs. Any program is a subset of software, and it
becomes software only if documentation & operating procedures manuals are
prepared.

There are three components of the software as shown in fig:

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals. Examples

of documentation manuals are: Data Flow Diagram, Flow Charts, ER diagrams, etc.
3. Operating Procedures: Operating Procedures consist of instructions to set up and
use the software system and instructions on how react to the system failure. Example
of operating system procedures manuals is: installation guide, Beginner's guide,
reference guide, system administration guide, etc.

Capability Maturity Model (CMM) – Software

Engineering
Last Updated : 29 Feb, 2024



Capability Maturity Model (CMM) was developed by the Software Engineering
Institute (SEI) at Carnegie Mellon University in 1987. It is not a software process
model. It is a framework that is used to analyze the approach and techniques
followed by any organization to develop software products. It also provides
guidelines to enhance further the maturity of the process used to develop those
software products.
It is based on profound feedback and development practices adopted by the most
successful organizations worldwide. This model describes a strategy for software
process improvement that should be followed by moving through 5 different
levels. Each level of maturity shows a process capability level. All the levels
except level 1 are further described by Key Process Areas (KPA).
Importance of Capability Maturity Model
 Optimization of Resources: CMM helps businesses make the best use
of all of their resources, including money, labor, and time. Organizations
can improve the effectiveness of resource allocation by recognizing and
getting rid of unproductive practices.
 Comparing and Evaluating: A formal framework for benchmarking
and self-evaluation is offered by CMM. Businesses can assess their
maturity levels, pinpoint their advantages and disadvantages, and
compare their performance to industry best practices.
 Management of Quality: CMM emphasizes quality management
heavily. The framework helps businesses apply best practices for quality
assurance and control, which raises the quality of their goods and
services.
 Enhancement of Process: CMM gives businesses a methodical
approach to evaluate and enhance their operations. It provides a road
map for gradually improving processes, which raises productivity and
usefulness.
 Increased Output: CMM seeks to boost productivity by simplifying and
optimizing processes. Organizations can increase output and efficiency
without compromising quality as they go through the CMM levels.
Principles of Capability Maturity Model (CMM)
 People’s capability is a competitive issue. Competition arises when
different organizations are performing the same task (such as software
development). In such a case, the people of an organization are sources
of strategy and skills, which in turn results in better performance of the
organization.
 The people’s capability should be defined by the business objectives of
the organization.
  An organization should invest in improving the capabilities and skills of
the people as they are important for its success.
 The management should be responsible for enhancing the capability of
the people in the organization.
 The improvement in the capability of people should be done as a process.
This process should incorporate appropriate practices and procedures.
 The organization should be responsible for providing improvement
opportunities so that people can take advantage of them.
 Since new technologies and organizational practices emerge rapidly,
organizations should continually improve their practices and develop the
abilities of people.

Key Process Areas (KPA)

Each of these KPA (Key Process Areas) defines the basic requirements that should
be met by a software process to satisfy the KPA and achieve that level of maturity.
Conceptually, key process areas form the basis for management control of the
software project and establish a context in which technical methods are applied,
work products like models, documents, data, reports, etc. are produced, milestones
are established, quality is ensured and change is properly managed.
Levels of Capability Maturity Model (CMM)
There are 5 levels of Capability Maturity Models. We will discuss each one of
them in detail.
 CMM

Level-1: Initial
 No KPIs defined.
 Processes followed are Adhoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.
 Limited project management capabilities, such as no systematic tracking
of schedules, budgets, or progress.
 We have limited communication and coordination among team members
and stakeholders.
 No formal training or orientation for new team members.
 Little or no use of software development tools or automation.
 Highly dependent on individual skills and knowledge rather than
standardized processes.
 High risk of project failure or delays due to a lack of process control and
stability.
Level-2: Repeatable
  Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar-
natured projects.
 Project Planning- It includes defining resources required, goals,
constraints, etc. for the project. It presents a detailed plan to be followed
systematically for the successful completion of good-quality software.
 Configuration Management- The focus is on maintaining the
performance of the software product, including all its components, for
the entire lifecycle.
 Requirements Management- It includes the management of customer
reviews and feedback which result in some changes in the requirement
set. It also consists of accommodation of those modified requirements.
 Subcontract Management- It focuses on the effective management of
qualified software contractors i.e. it manages the parts of the software
developed by third parties.
 Software Quality Assurance- It guarantees a good quality software
product by following certain rules and quality standard guidelines while
developing.
Level-3: Defined
 At this level, documentation of the standard guidelines and procedures
takes place.
 It is a well-defined integrated set of project-specific software engineering
and management processes.
 Peer Reviews: In this method, defects are removed by using several
review methods like walkthroughs, inspections, buddy checks, etc.
 Intergroup Coordination: It consists of planned interactions between
different development teams to ensure efficient and proper fulfillment of
customer needs.
 Organization Process Definition: Its key focus is on the development
and maintenance of standard development processes.
 Organization Process Focus: It includes activities and practices that
should be followed to improve the process capabilities of an
organization.
 Training Programs: It focuses on the enhancement of knowledge and
skills of the team members including the developers and ensuring an
increase in work efficiency.
Level-4: Managed
 At this stage, quantitative quality goals are set for the organization for
software products as well as software processes.
 The measurements made help the organization to predict the product and
process quality within some limits defined quantitatively.
 Software Quality Management: It includes the establishment of plans
and strategies to develop quantitative analysis and understanding of the
product’s quality.
  Quantitative Management: It focuses on controlling the project
performance quantitatively.
Level-5: Optimizing
 This is the highest level of process maturity in CMM and focuses on
continuous process improvement in the organization using quantitative
feedback.
 The use of new tools, techniques, and evaluation of software processes is
done to prevent the recurrence of known defects.
 Process Change Management: Its focus is on the continuous
improvement of the organization’s software processes to improve
productivity, quality, and cycle time for the software product.
 Technology Change Management: It consists of the identification and
use of new technologies to improve product quality and decrease product
development time.
 Defect Prevention It focuses on the identification of causes of defects
and prevents them from recurring in future projects by improving
project-defined processes.

Spiral Model
The spiral model, initially proposed by Boehm, is an evolutionary software process
model that couples the iterative feature of prototyping with the controlled and
systematic aspects of the linear sequential model. It implements the potential for
rapid development of new versions of the software. Using the spiral model, the
software is developed in a series of incremental releases. During the early iterations,
the additional release may be a paper model or prototype. During later iterations,
more and more complete versions of the engineered system are produced.

The Spiral Model is shown in fig:

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for
that cycle, the various alternatives that are possible for achieving the targets, and the
constraints that exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these
various alternatives based on the goals and constraints. The focus of evaluation in
this stage is located on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking,
simulation, and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice
made whether to continue with a further period of the spiral. If it is determined to
keep, plans are drawn up for the next step of the project.

The development phase depends on the remaining risks. For example, if performance
or user-interface risks are treated more essential than the program development
risks, the next phase may be an evolutionary development that includes developing a
more detailed prototype for solving the risks.
The risk-driven feature of the spiral model allows it to accommodate any mixture of
a specification-oriented, prototype-oriented, simulation-oriented, or another type of
approach. An essential element of the model is that each period of the spiral is
completed by a review that includes all the products developed during that cycle,
including plans for the next cycle. The spiral model works for development as well as
enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.

o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages

o High amount of risk analysis

o Useful for large and mission-critical projects.

Disadvantages

o Can be a costly model to use.

o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

The concurrent development model:

 The concurrent development model is called as concurrent model.
 The communication activity has completed in the first iteration and exits in the
awaiting changes state.
 The modeling activity completed its initial communication and then go to the
underdevelopment state.
 If the customer specifies the change in the requirement, then the modeling activity
moves from the under development state into the awaiting change state.
 The concurrent process model activities moving from one state to another state
.
Advantages of the concurrent development model
 This model is applicable to all types of software development processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
 It needs better communication between the team members. This may not be
achieved all the time.
 It requires to remember the status of the different activities.

Component Based Model (CBM)

Last Updated : 13 Jun, 2022



The component-based assembly model uses object-oriented technologies. In
object-oriented technologies, the emphasis is on the creation of classes. Classes are
the entities that encapsulate data and algorithms. In component-based architecture,
classes (i.e., components required to build application) can be uses as reusable
components. This model uses various characteristics of spiral model. This model is
evolutionary by nature. Hence, software development can be done using iterative
approach. In CBD model, multiple classes can be used. These classes are basically
the prepackaged components. The model works in following manner:
  Step-1: First identify all the required candidate components, i.e., classes
with the help of application data and algorithms.
 Step-2: If these candidate components are used in previous software
projects then they must be present in the library.
 Step-3: Such preexisting components can be excited from the library and
used for further development.
 Step-4: But if the required component is not present in the library then
build or create the component as per requirement.
 Step-5: Place this newly created component in the library. This makes
one iteration of the system.
 Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the
number of iterations required to develop the complete application.

Characteristics of Component Assembly Model:

 Uses object-oriented technology.
 Components and classes encapsulate both data and algorithms.
 Components are developed to be reusable.
 Paradigm similar to spiral model, but engineering activity involves
components.
 The system produced by assembling the correct components.

Agile Model
The meaning of Agile is swift or versatile. “Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks
into smaller iterations, or parts do not directly involve long term planning. The
project scope and requirements are laid down at the beginning of the development
process. Plans regarding the number of iterations, the duration and the scope of
each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller
parts helps to minimize the project risk and to reduce the overall project delivery
time requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.

Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
 6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility.

2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to
your existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of improvement,
so it includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

Scrum
SCRUM is an agile development process focused primarily on ways to manage tasks
in team-based development conditions.

There are three roles in it, and their responsibilities are:

 o Scrum Master: The scrum can set up the master team, arrange the meeting
and remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes
the delay and is responsible for the distribution of functionality on each
repetition.
o Scrum Team: The team manages its work and organizes the work to
complete the sprint or cycle.

AD

eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing demands
or requirements, or when they are not sure about the system's performance.

Crystal:
There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a

development team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:

A. Team updates the release plan.

B. Integrated product delivers to the users.

3. Wrap up: According to the user environment, this phase performs

deployment, post-deployment.

Dynamic Software Development Method(DSDM):

DSDM is a rapid application development strategy for software development and
gives an agile project distribution structure. The essential features of DSDM are that
users must be actively connected, and teams have been given the right to make
decisions. The techniques used in DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping
The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project

Feature Driven Development(FDD):

This method focuses on "Designing and Building" features. In contrast to other smart
methods, FDD describes the small steps of the work that should be obtained
separately per function.

Lean Software Development:

Lean software development methodology follows the principle "just in time
production." The lean method indicates the increasing speed of software
development and reducing costs. Lean development can be summarized in seven
phases.

AD

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
 o When project size is small.

AD

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages(Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial
decisions taken throughout various phases can be misinterpreted at any time
by different team members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project
can become a difficulty.

Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process. Requirement
engineering provides the appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility, negotiating a reasonable
solution, specifying the solution clearly, validating the specifications and managing
the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and
notation to describe a proposed system's intended behavior and its associated
constraints.

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

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: This looks at whether the technology needed to
create a software solution is available, reliable, and within the project's
budget and timeline.
2. Operational Feasibility: This assesses whether the software, once
developed, can effectively address the business needs and problems it
was designed for. It looks at how well the software integrates into
existing operations and processes.
3. Economic Feasibility: This evaluates whether developing and
implementing the software will bring financial benefits to the
organization. It considers factors like cost of development, potential
savings or revenue generation, and return on investment (ROI).

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

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
3. 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.

o 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.
 o 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.
o 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.

AD

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 -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.
o Prototyping: Using an executable model of the system to check
requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during
the requirements engineering process and system development.
New requirements emerge during the process as business needs a change, and a
better understanding of the system is developed.

The priority of requirements from different viewpoints changes during development

process.

The business and technical environment of the system changes during the
development.

Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software development
project. Hence they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

AD

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized into

two categories:

1. Functional Requirements:

 What They Are: Functional requirements describe what a system or

component should do. They outline specific functions, actions, or
tasks that the system must perform.

 Examples: For instance, in a banking application, a functional

requirement might specify that users should be able to log in
 securely, transfer funds between accounts, and view transaction
history.

 Focus on Behavior: Functional requirements focus on the behavior

of the system in response to inputs and under certain conditions.

2. Non-functional Requirements:

 What They Are: Non-functional requirements define criteria that

can be used to judge the operation of a system, rather than
specific behaviors or functions.

 Categories:

 Execution Qualities: These are observable during the

runtime of the system. Examples include security (how
protected the system is against unauthorized access),
usability (how easy the system is to use for its intended
users), and performance (how well the system responds
under different loads).

 Evolution Qualities: These are attributes related to the

structure and maintainability of the system. Examples
include testability (how easily the system can be tested),
maintainability (how easily the system can be maintained
and updated), extensibility (how easily new features can be
added), and scalability (how well the system can handle
increasing amounts of work or users over time).

 Why They're Important: Non-functional requirements are crucial

for ensuring that a system not only performs its intended
functions but also meets quality standards in terms of security,
usability, maintainability, and overall performance.

Analysis principles – Analysis Modelling in

Software Engineering
Last Updated : 25 Apr, 2024



Analysis Model is a technical representation of the system. It acts as a link
between the system description and the design model. In Analysis Modelling,
information, behavior, and functions of the system are defined and translated into
the architecture, component, and interface level design in the design modeling.
Objectives of Analysis Modelling
 Understanding Needs: The process of analysis modelling helps in the
understanding and extraction of user needs for the software system.
 Communication: Analysis models facilitate communication between
users, clients, developers, and testers, among other stakeholders.
 Clarifying Ambiguities: Analysis models assist in resolving
requirements disputes and providing clarification on unclear areas.
 Finding the Data Requirements: Analysis modelling assists in
determining the relationships, entities, and qualities of the data that the
system needs.
 Defining Behavior: Analysis modelling aids in the definition of the
system’s dynamic behavior, including workflows, processes, and inter-
component interactions.
 System Boundary Identification: It is made easier by analysis
modelling, which helps in defining the parameters of the software system
and its interactions with users, other systems, and hardware components.
Elements of Analysis Model
 Elements of Analysis Model

1. Data Dictionary:
It is a repository that consists of a description of all data objects used or
produced by the software. It stores the collection of data present in the
software. It is a very crucial element of the analysis model. It acts as a
centralized repository and also helps in modeling data objects defined
during software requirements.

2. Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting
data modeling activities. The attributes of each object in the Entity-
Relationship Diagram can be described using Data object description. It
provides the basis for activity related to data design.

3. Data Flow Diagram (DFD):

It depicts the functions that transform data flow, and it also shows how
 data is transformed when moving from input to output. It provides the
additional information that is used during the analysis of the information
domain and serves as a basis for the modeling of function. It also enables
the engineer to develop models of functional and information domains at
the same time.

4. State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows
the transitions from one state to another state in the system. It also
provides the details of how the system behaves due to the consequences
of external events. It represents the behavior of a system by presenting its
states and the events that cause the system to change state. It also
describes what actions are taken due to the occurrence of a particular
event.

5. Process Specification:
It stores the description of each function present in the data flow
diagram. It describes the input to a function, the algorithm that is applied
for the transformation of input, and the output that is produced. It also
shows regulations and barriers imposed on the performance
characteristics that apply to the process and layout constraints that could
influence how the process will be implemented.

6. Control Specification:
It stores additional information about the control aspects of the software.
It is used to indicate how the software behaves when an event occurs and
which processes are invoked due to the occurrence of the event. It also
provides the details of the processes which are executed to manage
events.

7. Data Object Description:

It stores and provides complete knowledge about a data object present
and used in the software. It also gives us the details of attributes of the
data object present in the Entity Relationship Diagram. Hence, it
incorporates all the data objects and their attributes.
Key Principles of Analysis Modelling
1. Abstraction: Analysis modelling involves separating important system
components from unneeded specifics. While leaving out unnecessary or
low-level information, it concentrates on capturing the essential ideas,
behaviors, and relationships relevant to the system’s requirements.
2. Modularity: Analysis models ought to be able to break down a system
into smaller, more manageable parts. It is simpler to understand, assess,
and alter the system when each module or component reflects a different
part of its functionality.
3. Consistency: Internally and with other project artifacts, including
requirements documents, design specifications, and implementation
code, analysis models should be consistent. By preventing opposing or
conflicting representations of the system, consistency promotes greater
stakeholder comprehension and alignment.
4. Traceability: Analysis models ought to be able to be linked to other
project components so that interested parties may follow requirements
from their inception to their execution. Throughout the software
development lifecycle, it helps with impact analysis, change
management, and requirements coverage verification.
5. Precision: To provide an unambiguous picture of the needs and
behaviors of the system, analysis models must be accurate and exact.
Accuracy lowers the chance of miscommunication and misunderstanding
among stakeholders as well as implementation problems.
6. Separation of Concerns: Analysis modeling divides various system
components or concerns into discrete representations. For instance,
behavioral modeling aims to capture the dynamic behavior of the system,
whereas data modeling concentrates on expressing the relationships and
structure of data items.