SOFTWARE

ENGINEERING
NOTES
UNIT 1

Ms. Deepika yadav

Assistant Professor
CSE department
1
INTRODUCTION TO SOFTWARE ENGINEERING

WHAT IS SOFTWARE?

Computer programs and associated documentation

Software products may be developed for a particular customer or may be developed for a
general market

Software products may be

 Generic - developed to be sold to a range of different customers

 Bespoke (custom) - developed for a single customer according to their specification

 What is software engineering?

The term software engineering is composed of two words, software and engineering.

Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be a collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific
principles and methods.

So, we can define software engineering as a detailed study of engineering to the design,
development and maintenance of software. Software engineering was introduced to address
the issues of low-quality software projects. Problems arise when a software generally exceeds
timelines, budgets, and reduced levels of quality. It ensures that the application is built
consistently, correctly, on time and on budget and within requirements.

IEEE defines software engineering as: The application of a systematic, disciplined,

quantifiable approach to the development, operation and maintenance of software.

2
Software engineers should

 Adopt a systematic and organized approach to their work

 Use appropriate tools and techniques depending on
 The problem to be solved,
 The development constraints and
 The resources available

Software Characteristics: - To gain an understanding of SW, it is important to examine the

characteristics of software that make it different from other things that human being built.
When hardware is built, the human creative Process (analysis, design, construction, testing)
is ultimately translated into a physical form. Software is a logical rather than a physical
system element. Therefore, software has characteristics that differ considerably from those
of hardware:

 Operational: -This tells how good a software works on operations like budget, usability,
efficiency, correctness, functionality, dependability, security and safety.
 Transitional: - Transitional is important when an application is shifted from one platform
to another. So, portability, reusability and adaptability come in this area.
 Maintenance: - This specifies how good a software works in the changing environment.
Modularity, maintainability, flexibility and scalability come in maintenance part.
 Software is developed or engineered; Software is developed or engineered; it is not
manufactured in the classical sense. Although some similarities exist between software
development and hardware manufacture, the two activities are fundamentally different.
 Software doesn't "wear out.": The hardware exhibits relatively high failure rates early in
its life (these failures are often attributable to design or manufacturing defects); defects
are corrected and the failure rate drops to a steady-state level (Ideally, quite low) for some
period of time. As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies.
 Most software is custom-built, rather than being assembled from existing components.

3
SDLC – Software Development Life Cycle:
The Software Development Lifecycle is a systematic process for building software that
ensures the quality and correctness of the software built. SDLC process aims to produce high-
quality software which meets customer expectations. The software development should be
complete in the pre-defined time frame and cost. It consists of a detailed plan describing how
to develop, maintain and replace specific software. Software life cycle models describe phases of
the software cycle and the order in which those phases are executed. Each phase produces
deliverables required by the next phase in the life cycle. A typical Software Development Life
Cycle (SDLC) consists of the following phases:

1. Requirement gathering
2. System Analysis
3. Design
4. Development /Implementation or coding
5. Testing
6. Deployment
7. Maintenance

4
1. Requirement gathering:

 Requirement gathering and analysis is the most important phase in software development
lifecycle. Business Analyst collects the requirement from the Customer/Client as per the
client’s business needs and documents the requirements in the Business Requirement
Specification.
 This phase is the main focus of the project managers and stake holders. Meetings with
managers, stake holders and users are held in order to determine the requirements like;
who is going to use the system? How will they use the system? What data should be input
into the system? What data should be output by the system?
2. Analysis Phase:
 Once the requirement gathering and analysis is done the next step is to define and
document the product requirements and get them approved by the customer. This is done
through SRS (Software Requirement Specification) document.
SRS consists of all the product requirements to be designed and developed during the
project life cycle.

 Key people involved in this phase are Project Manager, Business Analysist and Senior
members of the Team.
 The outcome of this phase is Software Requirement Specification.

3. Design Phase:
 In this third phase the system and software design is prepared from the requirement
specifications which were studied in the first phase.
 System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture.
 There are two kinds of design documents developed in this phase:
 High-Level Design (HLD): It gives the architecture of the software product to be developed
and is done by architects and senior developers. It gives brief description and name of
each module. It also defines interface relationship and dependencies between modules,
database tables identified along with their key elements
 Low-Level Design (LLD): It is done by senior developers. It describes how each and every
feature in the product should work and how every component should work. Here, only the
design will be there and not the code. It defines the functional logic of the modules, database
5
 tables design with size and type, complete detail of the interface. Addresses all types of
dependency issues and listing of error messages.
4. Coding/Implementation Phase:
 In this phase, developers start build the entire system by writing code using the chosen
programming language.
 Here, tasks are divided into units or modules and assigned to the various developers. It is the
longest phase of the Software Development Life Cycle process.
 In this phase, Developer needs to follow certain predefined coding guidelines. They also need
to use programming tools like compiler, interpreters, debugger to generate and implement
the code.
 The outcome from this phase is Source Code Document (SCD) and the developed product.
5. Testing Phase:

 After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
 They either test the software manually or using automated testing tools depends on process
defined in STLC (Software Testing Life Cycle) and ensure that each and every component of
the software works fine. The development team fixes the bug and send back to QA for a re-
test. This process continues until the software is bug-free, stable, and working according to
the business needs of that system.

6. Deployment:

After successful testing the product is delivered / deployed to the customer for their use. As
soon as the product is given to the customers they will first do the beta testing. If any changes
are required or if any bugs are caught, then they will report it to the engineering team. Once
those changes are made or the bugs are fixed then the final deployment will happen.

7. Maintenance:
Software maintenance is a vast activity which includes optimization, error correction, and
deletion of discarded features and enhancement of existing features. Since these changes are
necessary, a mechanism must be created for estimation, controlling and making
modifications. The essential part of software maintenance requires preparation of an
accurate plan during the development cycle. Typically, maintenance takes up about 40-80%

6
 of the project cost, usually closer to the higher pole. Hence, a focus on maintenance
definitelyhelpskeepcostsdown.

Importance of Software Engineering

The importance of Software engineering is as follows:

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 hard work 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.

7
Importance of Software Engineering as a discipline

The importance of Software engineering is as follows:

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.

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

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

Discipline, etc.
9
Software Applications

Software may be applied in any situation for which a pre-specified set of procedural steps
(i.e., an algorithm) has been defined (notable exceptions to this rule are expert system
software and neural network software). Information content and determinacy are important
factors in determining the nature of a software application. Content refers to the meaning
and form of incoming and outgoing information. For example, many business applications
use highly structured input data (a database) and produce formatted “reports.” Software that
controls an automated machine (e.g., a numerical control) accepts discrete data items with
limited structure and produces individual machine commands in rapid succession.
Information determinacy refers to the predictability of the order and timing of information.

 system software

 application software

 engineering/scientific software

 embedded software

 product-line software

 Web Apps (Web applications)

 AI software

 Legacy Software

System software: System software is a collection of programs written to service other

programs. Some system software (e.g., compilers, editors, and file management utilities) process
complex, but determinate, information structures. Other systems applications (e.g., operating
system components, drivers, telecommunications processors) process largely indeterminate
data. In either case, the system software area is characterized by heavy interaction with
computer hardware; heavy usage by multiple users; concurrent operation that requires
scheduling, resource sharing, and sophisticated process management; complex data structures;
and multiple external interfaces.

Real-time software. Software that monitors/analyzes/controls real-world events as they occur

is called real time. Elements of real-time software include a data gathering component that
collects and formats information from an external environment, an analysis component that
10
transforms information as required by the application, a control/output component that

responds to the external environment, and a monitoring component that coordinates all other
components so that real-time response (typically ranging from 1 millisecond to 1 second) can
be maintained.

Engineering and scientific software. Engineering and scientific software have been
characterized by "number crunching" algorithms. Applications range from astronomy to
volcanology, from automotive stress analysis to space shuttle orbital dynamics, and from
molecular biology to automated manufacturing. However, modern applications within the
engineering/scientific area are moving away from conventional numerical algorithms.
Computer-aided design, system simulation, and other interactive applications have begun to
take on real-time and even system software characteristics.

Embedded software. Intelligent products have become commonplace in nearly every consumer
and industrial market. Embedded software resides in read-only memory and isused to control
products and systems for the consumer and industrial markets. Embedded software can perform
very limited and esoteric functions (e.g., keypad control for a microwave oven) or provide
significant function and control capability (e.g., digital functions in an automobile such as fuel
control, dashboard displays, and braking systems).

Web-based software. The Web pages retrieved by a browser are software that incorporates
executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a variety
of visual and audio formats). In essence, the network becomes a massive computer
providing an almost unlimited software resource that can be accessed by anyone with a
modem.

Artificial intelligence software. Artificial intelligence (AI) software makes use of non-
numerical algorithms to solve complex problems that are not amenable to computation or
straightforward analysis. Expert systems, also called knowledge based systems, pattern
recognition (image and voice), artificial neural networks, theorem proving, and game playing
are representative of applications within this category.

Legacy Programs/ Legacy Software: Today, a growing population of legacy programs isforcing
many companies to pursue software reengineering strategies. The term legacy programs are a
euphemism for older, often poorly designed and documented software that is

11
 Business critical and must be supported over many years. Some legacy systems have
relatively solid program architecture, but individual modules were coded in a way that makes
them difficult to understand, test, and maintain. In such cases, the code within the suspect
modules can be restructured.

Software Crisis
The software crisis problem was encountered during software development.
Since the early 1960s with this increased use of computers and the complexity of applications, the need for
software was increasing. From simple programming exercises, the focus shifted to developing software
systems. The techniques for writing simple programs could not be scaled up for developing software systems.
Software crisis software can be defined as a set of problems raised during the software development periods.
The term software crisis was used to describe the impact of the rapid increase in computer power and the
complexity of the problems to be tackled. So the complexity, expectations, and change hindered the software
development process. This software crisis was growing rapidly.

The reason responsible for Software Crisis

The cause of the software crisis is linked to all the problems and complexities associated with the
development process. Various contributing factors responsible for the software crisis are:

The problem of scale:-

The ways to develop a small software having hundred having thousands of lines. In other words, the
methods used for developing small systems generally do not scale up to large systems.

Software is expensive:-
The cost to develop software is high as compared to hardware. Highly qualified and skilled manpower is
required to develop the software. They have to be paid a large amount of money which increases
expenses. Thus, the manpower cost is the dominant cost n this case.

Software is late:-
The term ‘late’ means that software cannot be completed within the specified period of time. The software
is not delivered in time.

Software is unreliable:-
The unreliability means that software does not perform the required function. Many failures occur due to
bugs that get introduced into the software.

Inconsistent productivity:-
The productivity of programmers could not keep up with demand.

High optimistic estimates regarding software development time and cost.

12
Lack of understanding of the problem and its environment:-
The software developed was poorly suited for the intended use of the system.

The code was difficult to maintain:-

Maintenance revolves around understanding existing software and maintainers have to spend most of their
time to understand the software that they want to modify.

Increase in complexity of the problem area:-

Demand for large and more complex software systems increased.

Duplication of efforts:-
Due to the absence of automation in most of the software development activities, the efforts have to be
repeated.

Software Process:
A structured set of activities required to develop a software system. There are many
different software processes but all involve:

 Specification – defining what the system should do;

 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.

13
Software Process Model:

A software process model is an abstract representation of a process. It presents a description

of a process from some particular perspective. When we describe and discuss processes, we
usually think about the activities in these processes such as specifying a data model,
designing a user interface, etc. and the ordering of these activities. There are different models
available.

Water fall Model (Linear-Sequential Life Cycle Model):

 The Waterfall Model was first Process Model to be introduced. It is very simple to
understand and use. In a Waterfall model, each phase must be completed before the next
phase can begin and there is no overlapping in the phases.
 Waterfall model is the earliest SDLC approach that was used for software development.
 In “The Waterfall” approach, the whole process of software development is divided into
separate phases.
 The outcome of one phase acts as the input for the next phase sequentially.
 This means that any phase in the development process begins only if the previous phase
is complete.
 At the end of each phase, a review takes place to determine if the project is on the right
path and whether or not to continue or discard the project.

1. Communication: The major task performed is requirement gathering which helps in

finding out the exact need of the customer. Once all the needs of the customer are gathered
the next step is planning.

14
2. Planning: Major activities like planning for schedule, keeping tracks on the processes and the
estimation related to the project are done. Planning is even used to find the types of risks
involved throughout the projects. Planning describes how technical tasks are going to take place
and what resources are needed and how to use them.
3. Modeling: This is one the important phases of the architecture of the system is designed in
this phase. Analysis is carried out and depending on the analysis a software model is designed.
Different models for developing software are created depending on the requirements gathered
in the first phase and the planning done in the second phase.
4. Construction: The actual coding of the software is done in this phase. This coding is done
on the basis of the model designed in the modeling phase. So in this phase software is actually
developed and tested.
5. Deployment: In this last phase the product is actually rolled out or delivered & installed
at customer’s end and support is given if required. A feedback is taken from the customer to
ensure the quality of the product.

Advantages of waterfall model:

 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not overlap.
 Waterfall model works well for smaller projects where requirements are very well
understood.
Disadvantages of waterfall model:
 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.

15
When to use the waterfall model
• This model is used only when the requirements are very well known, clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

Prototyping Model:

Prototype: Prototype is an early approximation of a final system/product or Prototype is

a working model of software with some limited functionality.

The Software Prototyping refers to building software application prototypes which

displays the functionality of the product under development, but may not actually hold
the exact logic of the original software.

1. The basic idea in Prototype model is that instead of freezing the requirements before
a design or coding can proceed, a throwaway prototype is built to understand the
requirements. This prototype is developed based on the currently known
requirements.
2. A first prototype of the new system is constructed from the preliminary design. This
is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.
3. The users thoroughly evaluate the first prototype, noting its strengths and
weaknesses, what needs to be added, and what should to be removed. The
developer collects and analyzes the remarks from the users.
4. The first prototype is modified, based on the comments supplied by the users, and a
second prototype of the new system is constructed.
5. The second prototype is evaluated in the same manner as was the first prototype.
6. The process of refining the prototype is repeated till all the requirements of users
are met.

16
7. When the users are satisfied with the developed prototype then the system is
developed on the basis of final prototype and it is thoroughly evaluated and tested.

Advantages of Prototyping Model

 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system by the
user.
 Earlier error detection takes place in this model.
 It gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the confusing or
difficult functions.

Disadvantages of Prototyping Model

 The client involvement is more and it is not always considered by the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a throw away prototype when the users are confused with it.

When to use Prototype model:

17
  Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
 Typically, online systems, web interfaces have a very high amount of interaction
with end users, are best suited for Prototype model. It might take a while for a
system to be built that allows ease of use and needs minimal training for the end
user.
 Prototyping ensures that the end users constantly work with the system and
provide a feedback which is incorporated in the prototype to result in a useable
system. They are excellent for designing good human computer interface systems.

Incremental Process model:

 The incremental model combines the elements of waterfall model and they are applied in
an iterative fashion.
 The first increment in this model is generally a core product.
 Multiple development cycles take place. Cycles are divided up into smaller, more easily
managed modules. Each module passes through the requirements, design,
implementation and testing phases.
 Each increment builds the product and submits it to the customer for any suggested

modifications.
 The next increment implements on the customer's suggestions and add additional
requirements in the previous increment.

 This process is repeated until the product is finished.

For example, the word-processing software is developed using the incremental model.

18
Advantages of incremental model
 This model is flexible because the cost of development is low and initial product
delivery is faster.
 It is easier to test and debug during the smaller iteration.
 The working software generates quickly and early during the software life cycle.
 The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
 The cost of the final product may cross the cost estimated initially.
 This model requires a very clear and complete planning.
 The planning of design is required before the whole system is broken into small
increments.
 The demands of customer for the additional functionalities after every increment
causes problem during the system architecture.

Spiral Model:

 The spiral model was first mentioned by Barry Boehm in his 1986 paper.
 The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis.
 The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.

19
 A software project repeatedly passes through these phases in iterations (called Spirals in
this model).
 The baseline spiral, starting in the planning phase, requirements is gathered and risk is
assessed. Each subsequent spiral builds on the baseline spiral.
 Each phase in spiral model begins with a design goal and ends with the client reviewing
the progress.

20
 Spiral Model Phases:

Spiral Model Phases Activities performed during phase

 It includes estimating the cost, schedule and resources for the iteration.
 It also involves understanding the system requirements for continuous
communication between the system analyst and the customer
Planning
 Requirements are gathered from the customers and the objectives are identified,
elaborated and analyzed at the start of every phase. Then alternative solutions
possible for the phase are proposed in this quadrant.

Risk Analysis  Identification of potential risk is done while risk mitigation strategy is planned and
finalized
 During the second quadrant all the possible solutions are evaluated to select the
best possible solution.
 Then the risks associated with that solution is identified and the risks are resolved
using the best possible strategy.
 At the end of this quadrant, Prototype is built for the best possible solution.

 It includes testing, coding and deploying software at the customer site

 During the third quadrant, the identified features are developed and verified
Engineering
through testing. At the end of the third quadrant, the next version of the software is
available.

 Evaluation of software by the customer. Also, includes identifying and monitoring

risks such as schedule slippage and cost overrun.
Evaluation  In the fourth quadrant, the Customers evaluate the so far developed version of the
software.
 In the end, planning for the next phase is started.

When to use Spiral Methodology?

 When project is large

 When releases are required to be frequent.
 When risk and costs evaluation is important
 For medium to high-risk projects
 When requirements are unclear and complex
 When changes may require at any time

21
 Advantages and Disadvantages of Spiral Model
Advantages Disadvantages
 Additional functionality or changes  Risk of not meeting the schedule or
can be done at a later stage budget

 Cost estimation becomes easy as the  It works best for large projects only
prototype building is done in small also demands risk assessment
fragments expertise

 Continuous or repeated development  For its smooth operation spiral model

helps in risk management protocol needs to be followed strictly

 Development is fast and features are  Documentation is more as it has

added in a systematic way intermediate phases

 There is always a space for customer  It is not advisable for smaller project,
feedback it might cost them a lot

SOFTWARE REQUIREMENT ANALYSIS AND

SPECIFICATION
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
22
 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

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.

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

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.
24
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:

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:

Functional Requirements
Functional requirements define a function that a system or system element must be qualified to perform
and must be documented in different forms. The functional requirements describe the behavior of the
system as it correlates to the system's functionality.

Functional requirements should be written in a simple language, so that it is easily understandable. The
examples of functional requirements are authentication, business rules, audit tracking, certification
requirements, transaction corrections, etc.

These requirements allow us to verify whether the application provides all functionalities mentioned in
the application's functional requirements. They support tasks, activities, user goals for easier project
management.

25
There are a number of ways to prepare functional requirements. The most common way is that they are
documented in the text form. Other formats of preparing the functional requirements are use cases,
models, prototypes, user stories, and diagrams.

Non-functional requirements
Non-functional requirements are not related to the software's functional aspect. They can be the
necessities that specify the criteria that can be used to decide the operation instead of specific behaviors
of the system. Basic non-functional requirements are - usability, reliability, security, storage, cost,
flexibility, configuration, performance, legal or regulatory requirements, etc.

They are divided into two main categories:

Execution qualities like security and usability, which are observable at run time.

Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the
static structure of the software system.

Non-functional requirements specify the software's quality attribute. These requirements define the
general characteristics, behavior of the system, and features that affect the experience of the user. They
ensure a better user experience, minimizes the cost factor. Non-functional requirements ensure that the
software system must follow the legal and adherence rules. The impact of the non-functional
requirements is not on the functionality of the system, but they impact how it will perform. For a well-
performing product, at least some of the non-functional requirements should be met.

Functional requirements v/s Non-functional requirements

Now, let's see the comparison chart between the functional and non-functional requirements.

Functional Requirements Non-functional requirements

Functional requirements help to understand the functions of They help to understand the system's
the system. performance.

Functional requirements are mandatory. While non-functional requirements are not

mandatory.

They are easy to define. They are hard to define.

They describe what the product does. They describe the working of product.

It concentrates on the user's requirement. It concentrates on the expectation and

experience of the user.

26
 It helps us to verify the software's functionality. It helps us to verify the software's performance.

These requirements are specified by the user. These requirements are specified by the software
developers, architects, and technical persons.

There is functional testing such as API testing, system, There is non-functional testing such as usability,
integration, etc. performance, stress, security, etc.

Examples of the functional requirements are - Examples of the non-functional requirements are
Authentication of a user on trying to log in to the system. -
The background color of the screens should be
light blue.

These requirements are important to system operation. These are not always the important
requirements, they may be desirable.

Completion of Functional requirements allows the system to While system will not work only with non-
perform, irrespective of meeting the non-functional functional requirements.
requirements.

User Requirements Specification

The User Requirements Specification describes the business needs for what users require from the
system. User Requirements Specifications are written early in the validation process, typically before
the system is created. They are written by the system owner and end-users, with input from Quality
Assurance. Requirements outlined in the URS are usually tested in the Performance Qualification or
User Acceptance Testing. User Requirements Specifications are not intended to be a technical
document; readers with only a general knowledge of the system should be able to understand the
requirements outlined in the URS.

The URS is generally a planning document, created when a business is planning on acquiring a system
and is trying to determine specific needs. When a system has already been created or acquired, or for
less complex systems, the user requirement specification can be combined with the functional
requirements document.

User Requirements Examples

Good requirements are objective and testable. For example:

 Screen A accepts production information, including Lot, Product Number, and Date.
 System B produces the Lab Summary Report.
 Twenty users can use System C concurrently without noticeable system delays.
 Screen D can print on-screen data to the printer.
 System E will be compliant with 21 CFR 11.
27
The URS should include:

 Introduction – including the scope of the system, key objectives for the project, and the applicable regulatory
concerns

 Program Requirements – the functions and workflow that the system must be able to perform

 Data Requirements – the type of information that a system must be able to process

 Life Cycle Requirements – including how the system will be maintain and users trained

Requirements are usually provided with a unique identifier, such as an ID#, to aid in traceability
throughout the validation process.

User Requirements Specifications should be signed by the system owner, key end-users, and Quality.
Once approved, the URS is retained according to your organization’s practices for document retention.

What is System Requirements Document?

System Requirements Document is also known as System Requirements Specifications. System
requirements document is a set of documentation that describes the behavior and features of a software
or system. It comprises of various elements that attempt to characterize the functionality needed by the
client to satisfy their users. In other words, the system requirements document (SRD) describes the
system-level performance and functional requirements for a system.

System Requirements Document or System Requirements Specification is defined as a document which

defines what the software will do and how it will be required to perform, and it also defines the
functionality the software needs to satisfy all stakeholders (users, business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it eventually characterizes
the functional and non-functional requirements of the system. The document doesn't layout design or
technology solutions. These decisions will be taken by the developers later.

The well-written system requirement document should:

o Split the problem into manageable parts.

o Notify design specifications i.e., SRD needs to comprise adequate information on software requirements
to present an effective design.
o Gives feedback to the customer or client.
o For testing and validation, serve as a reference.

According to the IEEE standards, SRDs must cover the following important topics.

28
 o Quality
o Security/Privacy
o Functional capabilities
o Safety
o Performance levels
o Constraints and Limitations
o Data Structure/Elements
o Reliability
o Interfaces

Main Elements of System Requirements Document

Based on the procedure employed (Waterfall vs. agile), the degree of convention and detail in the SRS
will differ, however in general, system requirement document or system requirement specification
contains a description of the system requirements, functional requirements, technical requirements,
acceptance criteria, assumptions and constraints. We have explained each of these in more detail below:

Constraints and Assumption

The constraints and assumption section will underline the lack of any design imposed by the client on
the system design, resulting in removing some options from being considered by the developers. This
section also comprises assumptions which are made by the team of requirement engineering at the time
of requirements gathering and analysis. If there is an incorrect assumption, it is needed to re-evaluate
the system requirements specification in order to ensure that the documented requirements are still
valid.

Functional and System Requirements

This segment normally comprises a hierarchical arrangement of requirements, with the
functional/business requirements at the uppermost level and the detailed system requirements are listed
as their child items.

Mostly in the form of statements, the requirements are written like "System requires the capability to do
x," with supporting information comprised as required.

Technical Requirements
This part is utilized to list any of the non-functional requirements, which basically personifies the technical
environment that the product requires to work in and incorporate the technical limitations that it requires

29
to work under. These technical requirements are important in deciding how high-level functional
requirements can decompose into more definite system requirements.

Business Drivers
This part depicts the reasons why the client is hoping to build the system. The new system's rationale is
significant because it will manage the choices made by business experts, engineers, and system
architects. Another convincing purpose behind recording the business logic and behind the system is
that during the project, client can change the staff. Documentation that absolutely recognizes the
business explanations for the system will help to continue support the project if the original sponsor
proceeds onward.

The drivers may comprise issues as well as opportunities. Generally, a mix of issues and opportunities
are required to give inspiration to a new system.

System Qualities
The system qualities are the non-functional requirements which are used to define the system's quality.
These qualities are frequently known as "ilities," and the reason behind that is many of these qualities
end with "ility". They are comprised of items like availability, maintainability, security, reliability, and
scalability.

Unlike functional requirements, the quality of the system generally contains tables of particular metrics
that the system should meet to be acknowledged.

Business Models
This part portrays the fundamental business model of the client that the system will require to support.
This contains current-state, future-state and organizational context state diagrams, key business
functions, business context and process flow diagrams. This part is generally made during the functional
analysis phase.

Acceptance Criteria
This part will portray the measures by which the client will "sign-off" the final system. Based on the
procedure, this may occur toward the end of the testing and quality assurance stage, or in agile
methodology, toward the finish of every iteration.

Usually, this measure refers to the requirement in order to complete all user acceptance tests and fix all
bugs/defects which meet a pre-defined priority or severity limits.

Business and System Use Cases

This segment ordinarily comprises a UML use case diagram, which shows the main external entities that
will collaborate with the system along with diverse use cases that should be met. There will be a formal
30
definition of the steps for every use case which is required to fulfill the purpose of the business, along
with the essential pre-conditions and post-conditions.

Generally, the system use cases are derived from the system requirements and the business use case is
derived from the functional requirements. By using the flowchart, the steps of use cases are represented.

Characteristics of a Good System Requirements Document

There are various characteristics of good system requirements:

1. Completeness
2. Correctness
3. Modifiability
4. Consistency
5. Testability
6. Design independence
7. Understandable by the customer
8. Traceability
9. Verifiability
10. Unambiguousness

1. Completeness
The completeness of the system requirements specification or system requirements document shows
each meaning of completion, together with the number of pages, that properly covers all the functional
and non-functional requirements as well as resolving parts to the extent possible.

2. Correctness
The reviews of the users are used to make sure the accuracy of the requirements states in the system
requirements document. The system requirements document is called true if it contains all the
requirements which are really anticipated from the system.

3. Modifiability
The system requirements document should be modified as well as able to adapt changes to the system.
Modifications must be appropriately indexed and cross-referenced.

4. Consistency
31
In the system requirements document, requirements are called consistent if in between any
requirements, there is no conflict. Examples of conflicts: logical conflicts such as time period of the report
generation, terminologies which are used at separate places, etc.

5. Testability
A system requirement document must be written in a manner which is simple to create test plans and
test cases from the document.

6. Design Independence
For the final system, it must be an option to select from the different design alternatives. In particular,
the system requirement document should not include any details regarding implementation.

7. Understandable by the Customer

An end-user possibly a specialist in his/her particular domain; however probably won't be a specialist in
computer science. Thus, the utilization of formal notations and symbols must be avoided as much as
possible. It is must that the language should be simple and clear.

8. Traceability
One must be capable to design a component in a program and then to detect a requirement for a code
fragment. Similarly, one needs to be able to detect the need for related test cases.

9. Verifiability
A system requirements document is validated if, in the system requirements document, a particular
technique is present in order to quantifiably measure the degree to which the system meets each
requirement. For instance, a requirement expressing that the system should be easy to use isn't verifiable
and listing such requirements must be dodged.

10. Unambiguousness
If each requirement in the system requirements document has only a single interpretation, then the
system requirement document is unambiguous. If we want to avoid unambiguousness, we have to use
some modeling techniques such as proper reviews, ER diagrams, buddy checks, etc.

Requirements Elicitation for Software

 Before requirements can be analyzed, modeled, or specified they must be gathered through
an elicitation process.
 A customer has a problem that may be amenable to a computer-based solution. A developer
responds to the customer's request for help.
32
 Communication Analysis techniques are as follows

2.1 Initiating the Process

 The most commonly used requirements elicitation technique is to conduct a meeting or
interview.
 The first meeting between a software engineer (the analyst) and the customer can be
awkward.
 The analyst starts by asking context-free questions. That is, a set of questions that will lead
to a basic understanding of the problem, the people who want a solution, the nature of the
solution that is desired, and the effectiveness of the first encounter itself.
 The first set of context-free questions focuses on the customer, the overall goals, and the
benefits. For example, the analyst 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?
 These questions help to identify all stakeholders who will have interest in the software to be
built.
 In addition, the questions identify the measurable benefit of a successful implementation
and possible alternatives to custom software development.
 The next set of questions enables the analyst to gain a better understanding of the problem
and the customer to voice his or her perceptions about a solution:
 How would you characterize "good" output that would be generated by a successful solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the environment in which the solution will be used?
 Will special performance issues or constraints affect the way the solution is approached?
 The final set of questions focuses on the effectiveness of the meeting.
 These questions (and others) will help to "break the ice" and initiate the communication that
is essential to successful analysis.

33
 But a question and answer meeting format is not an approach that has been overwhelmingly
successful. In fact, the Q&A session should be used for the first encounter only and then
replaced by a meeting format that combines elements of problem solving, negotiation, and
specification.

2.2 Facilitated Application Specification Techniques(FAST)

 Customers and software engineers have an unconscious “us and them” mind-set. With these
problems in the mind that a number of independent investigators have developed a team-
oriented approach to requirements gathering that is applied during early stages of analysis
and specification called facilitated application technique (FAST).
 Facilitated application specification techniques (FAST), approach encourages the creation of
a joint team of customers and developers who work together to identify the problem,
propose elements of the solution, negotiate different approaches and specify a preliminary
set of solution requirements.
 FAST has been used predominantly by the information systems community, but the
technique offers potential for improved communication in applications of all kinds.
 Basic guidelines for this technique are:
 A meeting is conducted at a neutral site and attended by both software engineers
and customers.
 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” controls the meeting.
 A “definition mechanism” is used
 The goal is to identify the problem, propose elements of the solution, negotiate
different approaches, and specify a preliminary set of solution requirements in an
atmosphere that is conductive to the accomplishment of the goal.

34
 A meeting place, time, and date for FAST are selected and a facilitator is chosen. Attendees
from both the development and customer/user organizations are invited to attend. The
product request is distributed to all attendees before the meeting date.
 Initial meeting between the developer and customer occur and basic questions and answers
help to establish the scope of the problem and the overall perception of a solution. The
product request distributed to all attendees before the meeting date.
 The FAST team is composed of representatives from marketing, software and hardware
engineering, and manufacturing.
 As the FAST meeting begins, the first topic of discussion is the need and justification for the
new product – everyone should agree that the product justified. Once agreement has been
established, each participant his or her list for discussion.
 After individual lists are presented in one topic area, a combined list is created by the group.
The combined list eliminates redundant entries, adds any new ideas that come up during the
discussion, but does not delete anything. The combined list is shortened, lengthened, or
reworded to properly reflect the product or system to be developed.
 The objective is to develop a consensus list in each topic area. Each sub team presents its
mini-specs to all FAST attendees for discussion. After the mini-specs are completed, each
FAST attendee makes a list of validation criteria for the product or system and presents his or
her to the team.

2.3 Quality Function Deployment(QFD)

 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.
 QFD emphasizes an understanding of what is valuable to the customer and then deploys
these values throughout the engineering process.
 QFD identifies three types of requirements:

35
1. Normal requirements. The objectives and goals that are stated for a product or system
during meeting with customer. If these requirements are present, the customer is satisfied.
Examples of normal requirements might be requested types of graphical displays, specific
system functions, and defined levels of performance.

2. Expected requirements. These requirements are implicit to the product or system and may
be so fundamental that the customer does not explicitly state them. Their absence will be a
cause for significant dissatisfaction.
Examples of expected requirements are: ease of human/machine interaction, overall
operational correctness and reliability, and ease of software installation.

3. Exciting requirements. These features go beyond the customer’s expectations and prove to
be very satisfying when present.
For example, word processing software is requested with standard features. The delivered
product contains a number of page layout capabilities that are quite pleasing and
unexpected.

Functional deployment is used to determine the value of each function that is required for the
system. Information deployment identifies both the data objects and events that the system must
consume and produce. These are tied to the functions. Finally, task deployment examines the
behavior of the system or product within the context of its environment. Value analysis is
conducted to determine the relative priority of requirements determined during each of the
three deployments.

2.4. Use-Cases

 As requirements are gathered as part of informal meetings, FAST, or QFD, the software
engineer (analyst) 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.

36
  To create a use-case, the analyst must first identify the different types of people (or devices)
that use the system or product. These actors actually represent roles that people (or devices)
play as the system operates.
 Defined somewhat more formally, an actor is anything that communicates with the system
or product and that is external to the system itself. It’s most important to note that an actor
and a user are not the same thing.
 An actor represents a class of external entities that play just one role. Once actors have been
identified, use-case can be developed.
 The use-case describes the manner in which an actor interacts with the system. The use-case
should be answer below questions:
 What main tasks or functions are performed by an actor?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

In general, use-case is simply a written narrative that describes the role of an actor as interaction
with the system occurs.

REQUIREMENT ANALYSIS USING Data Flow

Diagrams
A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system.
A neat and clear DFD can depict the right amount of the system requirement graphically. It can be
manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and any person who plays a part in the order that acts as
a starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
37
 2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of events; arrows
in DFD represents flowing data. A DFD does not involve any order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD, suppress
that urge! A diamond-shaped box is used in flow charts to represents decision points with multiple exists
paths of which the only one is taken. This implies an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until the end of the
analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data store indicates
that the data is stored which can be used at a later stage or by the other processes in a different order.
The data store can have an element or group of elements.

38
Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of
system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs may be
partitioned into levels that represent increasing information flow and functional detail. Levels in DFD are
numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the data flow diagram, which are:
0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFDM

It is also known as fundamental system model, or context diagram represents the entire software
requirement as a single bubble with input and output data denoted by incoming and outgoing arrows.
Then the system is decomposed and described as a DFD with multiple bubbles. Parts of the system
represented by each of these bubbles are then decomposed and documented as more and more detailed
DFDs. This process may be repeated at as many levels as necessary until the program at hand is well
understood. It is essential to preserve the number of inputs and outputs between levels, this concept is
called leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output y, then the
expanded DFD, that represents "A" should have exactly two external inputs and one external output as
shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in fig. As the
bubbles are decomposed into less and less abstract bubbles, the corresponding data flow may also be
needed to be decomposed.

39
1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we
highlight the main objectives of the system and breakdown the high-level process of 0-level DFD into
subprocesses.

40
2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or record the
specific/necessary detail about the system's functioning.

41
42
43
44
 Data Dictionaries
A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary hold
records about other objects in the database, such as data ownership, data relationships to other objects,
and other data. The data dictionary is an essential component of any relational database. Ironically,
because of its importance, it is invisible to most database users. Typically, only database administrators
interact with the data dictionary.

The data dictionary, in general, includes information about the following:

o Name of the data item

o Aliases
o Description/purpose
o Related data items
o Range of values
o Data structure definition/Forms

The name of the data item is self-explanatory.

45
Aliases include other names by which this data item is called DEO for Data Entry Operator and DR for
Deputy Registrar.

Description/purpose is a textual description of what the data item is used for or why it exists.

Related data items capture relationships between data items e.g., total_marks must always equal to
internal_marks plus external_marks.

Range of values records all possible values, e.g. total marks must be positive and between 0 to 100.

Data structure Forms: Data flows capture the name of processes that generate or receive the data items.
If the data item is primitive, then data structure form captures the physical structures of the data item. If
the data is itself a data aggregate, then data structure form capture the composition of the data items
in terms of other data items.

The mathematical operators used within the data dictionary are defined in the table:

Notations Meaning

x=a+b x includes of data elements a and b.

x=[a/b] x includes of either data elements a or b.

x=a x includes of optimal data elements a.

x=y[a] x includes of y or more occurrences of data element a

x=[a]z x includes of z or fewer occurrences of data element a

x=y[a]z x includes of some occurrences of data element a which are between y and z.

46
Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual data
model of an information system. Diagrams created using this ER-modeling method are called Entity-
Relationship Diagrams or ER diagrams or ERDs.

Purpose of ERD
o The database analyst gains a better understanding of the data to be contained in the database through
the step of constructing the ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the database to users. In particular, the ERD
effectively communicates the logic of the database to users.

Components of an ER Diagrams

1. Entity

47
An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An
entity is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers,
classes, and courses offered can be treated as entities. All these entities have some attributes or
properties that give them their identity.

Entity Set

An entity set is a collection of related types of entities. An entity set may include entities with attribute
sharing similar values. For example, a Student set may contain all the students of a school; likewise, a
Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values. For example,
a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a student's
name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.

There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
48
 4. Multi-valued attribute
5. Derived attribute

1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among
the entity set. For example, the roll_number of a student makes him identifiable among students.

There are mainly three types of keys:

1. Super key: A set of attributes that collectively identifies an entity in the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An entity set may have more than one
candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database designer to uniquely
identify the entity set.

2. Composite attribute: An attribute that is a combination of other attributes is called a composite

attribute. For example, In student entity, the student address is a composite attribute as an address is
composed of other characteristics such as pin code, state, country.

49
3. Single-valued attribute: Single-valued attribute contain a single value. For example,
Social_Security_Number.

4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-valued
attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person can have
more than one phone number, email-address, etc.

5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database,
but their values are derived from other attributes present in the database. For example, age can be
derived from date_of_birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.

50
3. Relationships
The association among entities is known as relationship. Relationships are represented by the diamond-
shaped box. For example, an employee works_at a department, a student enrolls in a course. Here,
Works_at and Enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a relationship too can
have attributes. These attributes are called descriptive attributes.

Degree of a relationship set

The number of participating entities in a relationship describes the degree of the relationship. The three
most common relationships in E-R models are:

1. Unary (degree1)

51
 2. Binary (degree2)
3. Ternary (degree3)

1. Unary relationship: This is also called recursive relationships. It is a relationship between the instances
of one entity type. For example, one person is married to only one person.

2. Binary relationship: It is a relationship between the instances of two entity types. For example, the
Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the
relationships "may have" provide the association of three entities, i.e., TEACHER, STUDENT, and SUBJECT.
All three entities are many-to-many participants. There may be one or many participants in a ternary
relationship.

In general, "n" entities can be related by the same relationship and is known as n-ary relationship.

52
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the number
of entities of other sets via relationship set.

Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity set B and
vice versa. Let us assume that each student has only one student ID, and each student ID is assigned to
only one person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with more than one instances of
another entity then it is called one to many relationships. For example, a client can place many orders; a
order cannot be placed by many customers.

Using Sets, it can be represented as:

53
3. Many to One: More than one entity from entity set A can be associated with at most one entity of
entity set B, however an entity from entity set B can be associated with more than one entity from entity
set A. For example - many students can study in a single college, but a student cannot study in many
colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than one entity from B and vice-versa.
For example, the student can be assigned to many projects, and a project can be assigned to many
students.

54
Using Sets, it can be represented as:

System Requirements Document

System Requirements Document is also known as System Requirements Specifications. System
requirements document is a set of documentation that describes the behavior and features of a software
or system. It comprises of various elements that attempt to characterize the functionality needed by the
client to satisfy their users. In other words, the system requirements document (SRD) describes the
system-level performance and functional requirements for a system.

System Requirements Document or System Requirements Specification is defined as a document which

defines what the software will do and how it will be required to perform, and it also defines the
functionality the software needs to satisfy all stakeholders (users, business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it eventually characterizes
the functional and non-functional requirements of the system. The document doesn't layout design or
technology solutions. These decisions will be taken by the developers later.

The well-written system requirement document should:

o Split the problem into manageable parts.

55
 o Notify design specifications i.e., SRD needs to comprise adequate information on software requirements
to present an effective design.
o Gives feedback to the customer or client.
o For testing and validation, serve as a reference.

According to the IEEE standards, SRDs must cover the following important topics.

o Quality
o Security/Privacy
o Functional capabilities
o Safety
o Performance levels
o Constraints and Limitations
o Data Structure/Elements
o Reliability
o Interfaces

Main Elements of System Requirements Document

Based on the procedure employed (Waterfall vs. agile), the degree of convention and detail in the SRS
will differ, however in general, system requirement document or system requirement specification
contains a description of the system requirements, functional requirements, technical requirements,
acceptance criteria, assumptions and constraints. We have explained each of these in more detail below:

Constraints and Assumption

The constraints and assumption section will underline the lack of any design imposed by the client on
the system design, resulting in removing some options from being considered by the developers. This
section also comprises assumptions which are made by the team of requirement engineering at the time
of requirements gathering and analysis. If there is an incorrect assumption, it is needed to re-evaluate
the system requirements specification in order to ensure that the documented requirements are still
valid.

Functional and System Requirements

This segment normally comprises a hierarchical arrangement of requirements, with the
functional/business requirements at the uppermost level and the detailed system requirements are listed
as their child items.

56
Mostly in the form of statements, the requirements are written like "System requires the capability to do
x," with supporting information comprised as required.

Technical Requirements
This part is utilized to list any of the non-functional requirements, which basically personifies the technical
environment that the product requires to work in and incorporate the technical limitations that it requires
to work under. These technical requirements are important in deciding how high-level functional
requirements can decompose into more definite system requirements.

Business Drivers
This part depicts the reasons why the client is hoping to build the system. The new system's rationale is
significant because it will manage the choices made by business experts, engineers, and system
architects. Another convincing purpose behind recording the business logic and behind the system is
that during the project, client can change the staff. Documentation that absolutely recognizes the
business explanations for the system will help to continue support the project if the original sponsor
proceeds onward.

The drivers may comprise issues as well as opportunities. Generally, a mix of issues and opportunities
are required to give inspiration to a new system.

System Qualities
The system qualities are the non-functional requirements which are used to define the system's quality.
These qualities are frequently known as "ilities," and the reason behind that is many of these qualities
end with "ility". They are comprised of items like availability, maintainability, security, reliability, and
scalability.

Unlike functional requirements, the quality of the system generally contains tables of particular metrics
that the system should meet to be acknowledged.

Business Models
This part portrays the fundamental business model of the client that the system will require to support.
This contains current-state, future-state and organizational context state diagrams, key business
functions, business context and process flow diagrams. This part is generally made during the functional
analysis phase.

Acceptance Criteria
This part will portray the measures by which the client will "sign-off" the final system. Based on the
procedure, this may occur toward the end of the testing and quality assurance stage, or in agile
methodology, toward the finish of every iteration.

57
Usually, this measure refers to the requirement in order to complete all user acceptance tests and fix all
bugs/defects which meet a pre-defined priority or severity limits.

Business and System Use Cases

This segment ordinarily comprises a UML use case diagram, which shows the main external entities that
will collaborate with the system along with diverse use cases that should be met. There will be a formal
definition of the steps for every use case which is required to fulfill the purpose of the business, along
with the essential pre-conditions and post-conditions.

Generally, the system use cases are derived from the system requirements and the business use case is
derived from the functional requirements. By using the flowchart, the steps of use cases are represented.

Characteristics of a Good System Requirements Document

There are various characteristics of good system requirements:

1. Completeness
2. Correctness
3. Modifiability
4. Consistency
5. Testability
6. Design independence
7. Understandable by the customer
8. Traceability
9. Verifiability
10. Unambiguousness

1. Completeness
The completeness of the system requirements specification or system requirements document shows
each meaning of completion, together with the number of pages, that properly covers all the functional
and non-functional requirements as well as resolving parts to the extent possible.

2. Correctness
The reviews of the users are used to make sure the accuracy of the requirements states in the system
requirements document. The system requirements document is called true if it contains all the
requirements which are really anticipated from the system.

58
 3. Modifiability
The system requirements document should be modified as well as able to adapt changes to the system.
Modifications must be appropriately indexed and cross-referenced.

4. Consistency
In the system requirements document, requirements are called consistent if in between any
requirements, there is no conflict. Examples of conflicts: logical conflicts such as time period of the report
generation, terminologies which are used at separate places, etc.

5. Testability
A system requirement document must be written in a manner which is simple to create test plans and
test cases from the document.

6. Design Independence
For the final system, it must be an option to select from the different design alternatives. In particular,
the system requirement document should not include any details regarding implementation.

7. Understandable by the Customer

An end-user possibly a specialist in his/her particular domain; however probably won't be a specialist in
computer science. Thus, the utilization of formal notations and symbols must be avoided as much as
possible. It is must that the language should be simple and clear.

8. Traceability
One must be capable to design a component in a program and then to detect a requirement for a code
fragment. Similarly, one needs to be able to detect the need for related test cases.

9. Verifiability
A system requirements document is validated if, in the system requirements document, a particular
technique is present in order to quantifiably measure the degree to which the system meets each
requirement. For instance, a requirement expressing that the system should be easy to use isn't verifiable
and listing such requirements must be dodged.

10. Unambiguousness
If each requirement in the system requirements document has only a single interpretation, then the
system requirement document is unambiguous. If we want to avoid unambiguousness, we have to use
some modeling techniques such as proper reviews, ER diagrams, buddy checks, etc.

59
60