SOFTWARE ENGINEERING NOTES

SOFTWARE ENGINEERING
UNIT-1
Software Engineering – Introduction, Program Versus Software, Software Engineering, Software
Development Process and its Stages, Generic Software Development Process Models, Code of Ethics and
Professional Practice, Software Development and Maintenance Cost Breakup.
Requirement Engineering Processes – Requirement Engineering Process, Feasibility Study, Cost and
Benefit Analysis, Requirement Specification, Characteristics of a Good Requirement and Validation
Techniques, Requirements Management Planning, Process of Requirement Change Management.
Software Requirement Specifications – Introduction, Stakeholder Analysis, Software Requirements
Document, IEEE Standard of Software Requirement Specifications, Organizing Functional Requirements,
Traceability and Validation of Specifications.

1.1.Introduction:
Software: Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be 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.
Software engineering: It is an engineering branch associated with development of software product using
well-defined scientific principles, methods and procedures. The outcome of software engineering is an
efficient and reliable software product.
1.2. Program versus Software:

Program
Source Object
Code Code

Document Operation
Program ation Procedure

Software
Program:
✓ Program is Subset of Software
✓ A Program can be viewed as
1. Set of instructions written for a specific by an individual
2. Small in size with Limited Functionality

Program = Source Code + Object Code

Software:

1 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

✓ Software is a Superset of program

1. User Friendly
2. Portable
3. Error or Risk force
4. Maintainable
5. Cost effective

Software = Program + Documentation + Operation Procedure

Procedure
1.3. Software Engineering:

Definition: Software engineering is 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.
The demand of software engineering also emerged to cater to the immense rate of change in user
requirements and environment on which application is supposed to be working.

Characteristics of a software
✓ Software should achieve a good quality in design and meet all the specifications of the customer.
✓ Software does not wear out i.e. it does not lose the material.
✓ Software should be inherently complex.
✓ Software must be efficient i.e. the ability of the software to use system resources in an effective and
efficient manner.
✓ Software must be integral i.e. it must prevent from unauthorized access to the software or data.
System Engineering: System is a set of parts interconnected in such a way as to achieve a common
objective. System Engineering begins by defining world view, subsequently focusing on a specific domain
such as business or product. Domain is further sub-divided into elements where technical activities are
undertaken using relevant engineering disciplines. If the domain is business then technical activities are
undertaken using software engineering. On the other hand, if the domain is construction then technical
activities are undertaken using civil engineering. Thus, System Engineering is a wider term.

It is clear that system engineering integrates people, processes, and products and constitutes a structured
development process that starts from conceptualization and goes till operation. It considers business and
technical requirements of all the stakeholders and proceeds further with the goal to provide a quality product
which meet their requirements. The processes of system engineering are as shown in Fig

2 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

Fig: Processes of system engineering

Software Development Myths:

Myths are misleading attitudes which bring serious problems in Software Development. The myths are
prevailing at three levels – Software management level, Software customer level, and Software developer
level. It is described here that they are false and how they add to problems.
Myths at Software Management Level:
There are three myths related to Software management and they are as given as follows:
1. Documentation standards can solve development issues: The organizations have developed
organization specific and standards of documentation. But generally, they are not adopted by the
developers since they are incomplete and difficult to grasp.
2. State of the art tools can solve development issues: tools can automate operations, but they are not
magic wand which can solve development issues. Development is a problem solving task. it require a
deep understanding of processes and tools.
3. Placing additional manpower can control project schedule derailment: It is a trivial and illogical
solution that if workload is high, put additional manpower. On the contrary, adding manpower
increase communication gap among the members. The old members of the team have to train and
share information about the project with new members; it results in taking their time. Large teams
have large communication hierarchy, it retards the project progress.
3 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]
 SOFTWARE ENGINEERING NOTES

Myths at Software Customer Level: There are two myths at this level and their impact on the entire is quite
serious. Customer underestimate the software development efforts, marketing people further strengthen their
misconception.
1. Software is malleable so changes can be done effortlessly: It I true that software can be modified but
changes in the operational software need a lot of effort.
2. A high level statement of requirement is good enough: It is required to start program development
work. It is a myth, the fact is developers need complete contextual details, functional, and
nonfunctional requirements to begin development work.
Myths at Software Developer Level: There are three myths at the level of developers. They generally think
that they are artists. It is not true, development is engineering. However the other myths are as follows.
1. Delivery of source code marks the end of project: It is untrue, successful software remain in use for
several decades. The developers have to maintain them by adding new requirements, repairing
existing bugs and preventing breakdowns. System maintenance can be 70% of the development cost.
2. Quality of the program code decides project success:
Programs alone do not decide quality of software. In maintenance phase, documentation and
configuration information are also required, besides, comments in programs. Developers also need
design documents and test results maintain software.
3. Quality cannot be judged till program starts running: It is not true. There are static techniques to
evaluate qualities of software. Review and walkthrough can be performed to check the quality of
software. It involves checking the software requirements specification document, design document,
test cases, and code.
1.4. Software Development Process and its Stages:

Fig: Software Development Life Cycle

4 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]
 SOFTWARE ENGINEERING NOTES

Planning: This is the first phase in the systems development process. It identifies whether or not there is the
need for a new system to achieve a business’s strategic objectives. This is a preliminary plan (or a feasibility
study) for a company’s business initiative to acquire the resources to build on an infrastructure to modify or
improve a service. The company might be trying to meet or exceed expectations for their employees,
customers and stakeholders too. The purpose of this step is to find out the scope of the problem and
determine solutions. Resources, costs, time, benefits and other items should be considered at this stage.
Requirements: The second phase is where businesses will work on the source of their problem or the need
for a change. In the event of a problem, possible solutions are submitted and analyzed to identify the best fit
for the ultimate goal(s) of the project. This is where teams consider the functional requirements of the project
or solution. It is also where system analysis takes place or analyzing the needs of the end users to ensure the
new system can meet their expectations. Systems analysis is vital in determining what a business’s needs are,
as well as how they can be met, who will be responsible for individual pieces of the project, and what sort of
timeline should be expected.
Design: The third phase describes, in detail, the necessary specifications, features and operations that will
satisfy the functional requirements of the proposed system which will be in place. This is the step for end
users to discuss and determine their specific business information needs for the proposed system. It’s during
this phase that they will consider the essential components (hardware and/or software) structure (networking
capabilities), processing and procedures for the system to accomplish its objectives.

Development: The fourth phase is when the real work begins—in particular, when a programmer, network
engineer and/or database developer are brought on to do the major work on the project. This work includes
using a flow chart to ensure that the process of the system is properly organized. The development phase
marks the end of the initial section of the process. Additionally, this phase signifies the start of production.
The development stage is also characterized by instillation and change. Focusing on training can be a huge
benefit during this phase.
Testing: The fifth phase involves systems integration and system testing (of programs and procedures)—
normally carried out by a Quality Assurance (QA) professional—to determine if the proposed design meets
the initial set of business goals. Testing may be repeated, specifically to check for errors, bugs and
interoperability. This testing will be performed until the end user finds it acceptable. Another part of this
phase is verification and validation, both of which will help ensure the program’s successful completion.
Implementation: The sixth phase is when the majority of the code for the program is written. Additionally,
this phase involves the actual installation of the newly-developed system. This step puts the project into
production by moving the data and components from the old system and placing them in the new system via
a direct cutover. While this can be a risky (and complicated) move, the cutover typically happens during off-
peak hours, thus minimizing the risk. Both system analysts and end-users should now see the realization of
the project that has implemented changes.
5 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]
 SOFTWARE ENGINEERING NOTES

1.5. Generic Software Development Process Models:

Process:
“A Process is series of steps involving activities, constraints and resources that produce an intend output”
Software Process: Building software product is actually known as software process.
Software Process Models:
A software process model is a simplified representation of a software process. Each model represents a
process from a specific perspective.
Types of process models:
1. Waterfall Model
2. Prototyping Model
3. RAD Model
4. Incremental or Iterative Model
5. Spiral Model
1. Waterfall Model:
Waterfall Model is also called Linear Sequential Model. The waterfall model is a classical model used in
system development life cycle to create a system with a linear and sequential approach. It is termed as
waterfall because the model develops systematically from one phase to another in a downward fashion. This
model is divided into different phases and the output of one phase is used as the input of the next phase.
Every phase has to be completed before the next phase starts and there is no overlapping of the phases.

Fig: Waterfall Model

1. Requirement Gathering- All possible requirements are captured in product requirement
documents.
2. System Design -- Based on analysis design the software architecture.
3. Implementation Development of the software in the small units with functional testing.

6 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

4. Integration and Testing Integrating of each unit developed in previous phase and post
integration test the entire system for any faults.
5. Maintenance Fixing issues and release new version with the issue patches as required.
Advantages:
✓ Simple to implement and manage
✓ Works well for smaller projects where requirements are very clear
✓ Process and output of each phase are clearly mentioned in the document.
Disadvantages:
✓ Risk and uncertainty are high.
✓ Not advisable for complex and object-oriented projects.
✓ Changing requirements can't be accommodated in any phase.
2. Prototyping Model:
The Prototyping Model is a systems development method (SDM) in which a prototype (an early
approximation of a final system or product) is built, tested, and then reworked as necessary until an
acceptable prototype is finally achieved from which the complete system or product can now be developed.
This model works best in scenarios where not all of the project requirements are known in detail ahead of
time. It is an iterative, trial-and-error process that takes place between the developers and the users.

Fig: Prototyping Model

Advantages:
✓ The software designer and implementer can obtain feedback from the users early in the project.
✓ The client and the contractor can compare if the software made matches the software specification,
according to which the software program is built.
✓ It also allows the software engineer some insight into the accuracy of initial project estimates and
whether the deadlines and milestones proposed can be successfully met.
Disadvantages:
✓ Lack of process visibility
✓ The developers may lose focus on the real purpose of the prototype and compromise the quality of the
product. For example, they may employ some of the inefficient algorithms or inappropriate

7 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

programming languages used in developing the prototype. This mainly due to laziness and an over
reliance on familiarity with seemingly easier methods.
3. RAD Model (Rapid Application Development):
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the
components or functions are developed in parallel as if they were mini projects. The developments are time
boxed, delivered and then assembled into a working prototype. This can quickly give the customer
something to see and use and to provide feedback regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are needed
for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business information
flow to achieve some specific business objective. Description are identified and created for CRUD of data
objects.
Application generation: Automated tools are used to convert process models into code and the actual
system.
Testing and turnover: Test new components and all the interfaces.
Advantages:
• Reduced development time.

8 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

• Increases reusability of components

• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
Disadvantages:
• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
4. Incremental or Iterative Model:
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which can then be reviewed
in order to identify further requirements. This process is then repeated, producing a new version of the
software for each cycle of the model.
For example:

In the diagram above when we work iteratively we create rough product or product piece in one iteration,
then review it and improve it in next iteration and so on until it’s finished. As shown in the image above, in
the first iteration the whole painting is sketched roughly, then in the second iteration colors are filled and in
the third iteration finishing is done. Hence, in iterative model the whole product is developed step by step.
Diagram of Iterative model:

Advantages:
➢ In iterative model less time is spent on documenting and more time is given for designing.
➢ In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of
the product to users for their feedback, we are effectively asking them to imagine how the product
will work.
9 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]
 SOFTWARE ENGINEERING NOTES

➢ In iterative model we are building and improving the product step by step. Hence we can track the
defects at early stages. This avoids the downward flow of the defects.
Disadvantages:
➢ Each phase of an iteration is rigid with no overlaps
➢ Costly system architecture or design issues may arise because not all requirements are gathered up
front for the entire lifecycle
5. Spiral Model:
Spiral Model is a combination of a waterfall model and iterative model. Each phase in spiral model begins
with a design goal and ends with the client reviewing the progress.
The development team in Spiral-SDLC model starts with a small set of requirement and goes through each
development phase for those set of requirements. The development team adds functionality for the additional
requirement in every-increasing spirals until the application is ready for the production phase.

Spiral Model of SDLC spans into four phases:

• Planning: 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
• Risk Analysis: Identification of potential risk is done while risk mitigation strategy is planned and
finalized
• Engineering: It includes testing, coding and deploying software at the customer site

10 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

• Evaluation: Evaluation of software by the customer. Also, includes identifying and monitoring risks
such as schedule slippage and cost overrun
Advantages:
• Additional functionality or changes can be done at a later stage
• Cost estimation becomes easy as the prototype building is done in small fragments
• Continuous or repeated development helps in risk management
• Development is fast and features are added in a systematic way
• There is always a space for customer feedback
Disadvantages:
• Risk of not meeting the schedule or budget
• It works best for large projects only also demands risk assessment expertise
• For its smooth operation spiral model protocol needs to be followed strictly
• Documentation is more as it has intermediate phases
• It is not advisable for smaller project, it might cost them a lot
1.6. Code of Ethics and Professional Practice:
Need for Code of Ethics:
To ensure, as much as possible, that software engineers efforts will be used for good
Software engineers must commit themselves to making software engineering a beneficial and respected
profession
In accordance with that commitment, software engineers shall adhere a Code of Ethics and Professional
Practice
The Code contains eight Principles related to the behaviour of and decisions made by professional software
engineers.

Fig: 8 Key Principles

11 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

1. PUBLIC: – Software engineers shall act consistently with the public interest
➢ Accept full responsibility for their own work.
➢ Moderate the interests of the software engineer, the employer, the client and the users with the public
good
➢ Approve software only if they believe that it is safe, meets specifications, passes appropriate tests
➢ Be fair and avoid deception in all statements, particularly public ones
➢ Consider issues of physical disabilities and allocation of resources
➢ Be encouraged to volunteer professional skills to good causes
2. CLIENT AND EMPLOYER: – Software engineers shall act in a manner that is in the best interests of
their client and employer, consistent with the public interest.
➢ Provide service in their areas of competence
➢ Not knowingly use software that is obtained or retained either illegally or unethically.
➢ Use the property of a client or employer only in ways properly authorized
➢ Identify, document, collect evidence and report to the client or the employer promptly if, a project is
likely to fail or to violate intellectual property law
3. PRODUCT: – Software engineers shall ensure that their products and related modifications meet the
highest professional standards possible
➢ Strive for high quality and acceptable cost
➢ Ensure proper and achievable goals and objectives for any project
➢ Ensure that they are qualified for any project they work on
➢ Ensure that an appropriate method is used for any project
➢ Work to follow professional standards
➢ Strive to fully understand the specifications for software
➢ Ensure adequate testing, debugging, documentation and review of software
➢ Treat all forms of software maintenance with the same professionalism as new development.
4. JUDGMENT: – Software engineers shall maintain integrity and independence in their professional
judgment
➢ Temper all technical judgments by the need to support and maintain human values.
➢ Only endorse documents if prepared under supervision
➢ Maintain professional objectivity with respect to any software
➢ Not engage in deceptive financial practices such as double billing, or other improper financial
practices.
➢ Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or
escaped.

12 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

5. MANAGEMENT:
– Software engineering managers and leaders shall subscribe to and promote an ethical approach to the
management of software development and maintenance
➢ Ensure good management for any project on which they work
➢ Ensure that software engineers are informed of standards before being held to them.
➢ Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any
project
➢ Provide for due process in hearing charges of violation of an employer's policy or of this Code.
➢ Not ask a software engineer to do anything inconsistent with this Code
➢ Not punish anyone for expressing ethical concerns about a project.
6. PROFESSION:
– Software engineers shall advance the integrity and reputation of the profession consistent with the public
interest
➢ Help develop an organizational environment favourable to acting ethically
➢ Promote public knowledge of software engineering
➢ Support, as members of a profession, other software engineers striving to follow this Code.
➢ Not promote their own interest at the expense of the profession, client or employer.
➢ Take responsibility for detecting, correcting, and reporting errors in software
➢ Report significant violations of this Code to appropriate authorities
7. COLLEAGUES:
– Software engineers shall be fair to and supportive of their colleagues
➢ Encourage colleagues to adhere to this Code
➢ Assist colleagues in professional development
➢ Credit fully the work of others and refrain from taking undue credit
➢ Assist colleagues in being fully aware of current standard work practices
➢ Not unfairly intervene in the career of any colleague
8. SELF:
– Software engineers shall participate in lifelong learning regarding the practice of their profession and shall
promote an ethical approach to the practice of the profession
➢ Further their knowledge of recent developments
➢ Improve their ability to create safe, reliable, and useful quality software
➢ Improve their ability to produce accurate, informative, and well-written documentation
➢ Improve their knowledge of relevant standards
➢ Not influence others to undertake any action that involves a breach of this Code

13 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

1.7. Software Development and Maintenance Cost Breakup:

Different Models use different cost in different stages of software development life cycle. They are shown
below in Fig.

The Software maintenance cost for 10 years project is 3 the software development cost as shown in Fig
below.
Software Professionals build the software for different problem domains library management system,
university management system, Ticket reservation system, etc. They get access to entire information
contained in the system. Virtually they run the operation of the system so they are expected to maintain high
code of moral ethical and professional practices to inculcate confidence in the customers.

14 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

2. Requirements Engineering Processes:

2.1. Requirements Engineering Process:
The Prime aim of Requirement Engineering Process is to prepare and maintain system requirement
documents. The Requirement Engineering Process encompasses of requirement elicitation, requirement
validation. Initially, most of the time is spent in understanding the high level business requirements,
functional and non-functional requirements. At final stages, the effort is spent in requirements engineering
and system modeling. Here, structured analysis method such as object analysis by applying use case models,
a graphical system model is prepared. System model is used for writing system specification, since, it
describes the behavior of a system. Additional information is annotated in the model to describe
performance or response time or uptime.

Feasibility Study

Requirement
Requirement Validation
Elicitation & Analysis
Requirement
Management Planning

Fig: Requirements Engineering Process and its Components

The Requirement Engineering consists of Four Sub Processes which are as follows
1. Feasibility Study
2. Requirement Elicitation & Analysis
3. Requirement Validation
4. Requirement Management Planning
2.2. Feasibility Study:
The Requirement Engineering Process for new system begins with feasibility study; input for feasibility
study is a set of business requirements. It is a preliminary description of system as to how it would support
the business functionality of the organization.

15 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

This feasibility study is focused towards goal of the organization. This study analyzes whether the software
product can be practically materialized in terms of implementation, contribution of project to organization,
cost constraints and as per values and objectives of the organizations. It explores technical aspects of the
project and product such as usability, maintainability, and productivity and integration ability.
The output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.
2.3. Cost and Benefit Analysis:
Cost and benefits analysis is the key component of feasibility study report. It is done to estimate the cost and
benefits which will accrue in electronic enablement of organizational services. Suppose government wishes
to provide e-services to the citizens. So money has to be spent in procuring information and communication
technology, developing and maintaining application. But it is also estimated that a number of applications
which are being processed manually at present can increase by 30% in an automated system. It is
recommended that the government should charge nominal fee from the citizens for electronic enabled
services, so that it can recover the cost and plant it back into the system to meet its everyday operational
expenses.
Eg: Cost and benefit analysis for e-enablement of government services.
Cost Analysis: Assuming that the entire investment cost made in the project can be recovered in first three
years after “Go Live” date. Further assuming that there is an increase in earning, half of this increased
amount will be used to recover the maintenance cost of the system and remaining amount will result in profit.
Further, government will accrue several benefits such as increase in revenue by checking revenue leakages,
frauds, increase in efficiency, reduced travel cost of citizens, bribery, corruption, and delivery of services in
defined time frame right from day one of “Go Live” date of new system. The real question is how to measure
these benefits so to answer this question: following indicators and metrics are defined:
Benefit Analysis:
It is estimated that the electronic enablement of government services will result in following benefits. So,
several forms to measure the benefits are presented here.
. Increase in Profit: This dimension can be measured by comparing the earnings of last years with those
accrued after the launch of a new system.
. Increase in Productivity: This indicator can be checked by comparing the number of transactions
delivered by each employee per month done before and after the launch of new system. If the system is web-
based then total number of transactions can be compared before and after the launch of new system to
appreciate the increase in number of transactions.

16 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

2.4. Requirement Specification:

There are two steps to capture the requirements, first to articulate initial functional requirements
specifications as customer gives it to software development agency and second to start the process of
requirement elicitation as software development agency. Both the steps are very critical for the success of
project.
Functional Requirement Specification:
When customer decide to go in for computerization of their business needs, they are expected to write their
functional requirements after talking to various stakeholders and invite bids from software development
agencies based on it. They can use standard template to express their requirements, one such template to
express functional requirements, First the template is given, later it is shown how to fill it up by taking the
example of E-ticket Railway System.
As per IEEE 610, a requirement that specifies a function that a component or system must perform is known
as functional requirement.
Requirement Elicitation and Analysis:
The system analysts or IT consultants work with different stakeholders to find out the services, performance
levels expected from the proposed system, and hardware constraints. The stakeholders include top
management, business managers, domain experts, end users, and even the system engineers developing and
maintaining similar system, as well as all those people who will be affected by the system. Requirements
discovery, their classification, organization, and prioritization are the key activities involved in this process.
The output of this stage is the production of formal requirement specification document.

17 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

Requirement discovery:
Requirement gathering begins by going through the documentation of the organization, taking stakeholders
interviews, allowing them to elicit the systems requirements through scenarios and use cases. The elicitation
process starts by knowing the viewpoints of different stakeholders; each viewpoint presents a subset of the
total requirements of the system. The perspectives can be fresh or overlapping or multiple, this is what makes
viewpoint-oriented analysis as one of the important activities of requirement discovery process. It also act as
a framework for discovering conflicts in the requirements proposed by different stakeholders.
Classification and Organization of requirements:
Unstructured collection of requirements is studied, organized into groups and coherent clusters so that related
requirements can be found at the same place.
Prioritization of requirements and negotiations:
Several stakeholders have expectations from the new system so conflicts are likely to arise. So requirements
are prioritized after negotiations with stakeholders, under this activity.
Requirement Documentation:
Requirements are documented and distributed among the stakeholders for review. The requirements are
refined on the basis of feedback received from them.
Requirement Discovery Techniques: Thus, it is clear that the process of requirement elicitation and
analysis primarily and fundamentally depends upon requirement discovery activity and other activities
follow. Several techniques are applied to discover the requirements. Four such techniques are as follows:
1. Viewpoints
2. Holding interviews
3. Use Cases
4. Scenario generation

18 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

1. View Points:
It means the opinions which the different stakeholders of the system hold about the system. The viewpoints
of five types of stakeholders are presented here.
✓ Viewpoints of End Users:
It includes viewpoints of users who will interact with the system directly. In E-Reservation of Indian
Railways, the passengers are end users and IRCTC staff that interact with the accounting database.
✓ Viewpoint of domain:
It includes enforcement of viewpoint which is prevalent in the problem domain through domain
characteristics, principles, standards, and other constraints.
For example, in National Governance programme of India, each government application must follow
E-Governance standards, use the IT infrastructure provided in Government built State Data Centres,
and obtain security certification as part of domain characteristics.
✓ Viewpoint of engineers:
The Software engineers, who have worked on similar projects, may have some requirements to
suggest for smooth running of system. Similarly, support and maintenance engineers those who will
maintain the system may have certain requirements which help in managing the change smoothly and
bring down the cost. So their requirements must be forced in the total system requirements landscape
to make the system agile and flexible.
✓ Viewpoint of marketing department:
The inclusion of viewpoints of marketing department is very important as it may suggest that certain
features put into the product or displayed or marketed over the internet can make the product more
marketable.
2. Holding Interviews:
The business analyst circular the questions to stakeholders about existing and the proposed system by posing
questions to stakeholders. The requirements are derived through the answers provided for these questions.
Interviews help the system analysts to know what activities the stakeholders carry out, how they interact with
the system, and what problems they face in performing them. The interviews can be closed Structured,
Unstructured and Hybrid.
1. Structured Interviews:
Here stakeholders provide answers to predetermined and predecided set of questions. The sample
questionnaire of the interview is shown

19 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

Fig: Questionnaire for conducting structured interview

2. Unstructured interviews:
It is the opposite of closed interviews, here requirement engineering team discusses on a wide range
of topics with the stakeholders, gains an in depth knowledge of their system, requirement, and needs.
But it should be made clear that complete open ended interviews rarely yield good results, so the
team should pose specific queries and remain focused about the system it wants to develop.
3. Hybrid interviews:
Hybrid interviews begin with preplanned questions and during the course of interview, related
questions are also asked spontaneously to get complete and coherent picture of requirements.
3. Scenario Generation:
IT consultants when interact with stakeholders, the stakeholders come out with scenarios to explain the
problems or their activities they perform in the organization. The IT consultants should utilize the
information which the stakeholders provide in the example to articulate the requirements for proposed
system. The description of scenario is extremely useful in annotating, adding, and expanding the details of
the requirement which are defined very briefly. Another advantage of scenario is that each scenario covers
one or more user’s interaction with the system.

20 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

4. Use Cases:
Use Cases, a fundamental feature of UML notation, is a de facto standard of object oriented
modeling, it is being used for requirement elicitation.
It is a scenario based technique that captures the viewpoints of stakeholders and actors involved in a scenario.
Actors in the use case diagram are represented as a named eclipse. The eclipse is called as Use Case. The use
cases are documented with text to describe the scenario in detail in requirement specification document.
Sequence diagrams, another UML notation, are used to add details in a use case.

21 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

Eg:

2.5. Characteristics of a Good Requirement and Validation Techniques: The analysts must ensure that
requirement collected by them meet the characteristics of a good requirement, i.e. they are factually correct,
complete, consistent real, verifiable and contain validation checks so that the problems in defining
requirements can be diagnosed at this stage itself.
✓ Validity Checks: The customers specify only what functionality they need of the system. But for
implementing that function, additional functionality may be required, so adequate checks must be built
in the requirements to ensure that additional requirements besides main requirement are also included.
Thus, such checks must be included by reviewers to ensure that additional requirements are included
in the requirement document.
✓ Consistency Checks: The requirement given in the document should not contradict the constraints
and descriptions given at different places in the same document for achieving same functionality.
2.6. Requirements Management Planning: The Software development agency takes the functional
requirement specification document, formally studies the existing environment, interacts with various
stakeholders, and develops the software requirement specification document. During this interaction, the
requirement of large system change. Since there were some requirements which could not be defined when
functional requirement specification document was made, now as the software process progresses, increase,
the customers desire the changed view of the requirement must be reflected. This is an example of

22 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

requirement change, and there are several other reasons which demand changes in already collected
requirements. Some of them are listed as follows:
Reasons for Emerging Changes: The Software development agency discovers the new needs and priorities.
The other reasons for emerging new requirements are as follows:
✓ Diverse user sets: Large systems have diverse set of end users, the requirements which finally
emerge; they are the common minimum denominator of the requirements of all users. But in due
course of time, the balance thus arrived in defining the requirements change for different set of users.
✓ Conflicting goals of management and staff: The management pays for the cost of application so it
tries to control budget by curtailing some of the requirements whereas these are required by the end
users. After delivery, when it is found the system is not meeting its goal, then it becomes necessary to
add the new features.
Process of Requirement Management: The requirements collection is an enormous effort and time
consuming exercise, on top of it, different stakeholders start demanding changes so it is suggested that the
requirements must be managed carefully for each project.
The following are the two techniques of managing the requirements effectively:
✓ Requirements identification: Each requirement must be given a unique number so that it can be
cross referenced in other requirements. Unique number assigned to the requirements helps in tracing
the stakeholder who assigned it, where it comes in design specification and function.
✓ Traceability matrix: It captures the three types of relationship between requirements. First,
relationship is called as Source Traceability. It defines stakeholders who proposed these
requirements. The second relationship is called as Requirement traceability, it defines the
interdependency relationship is known as design traceability, it defines where the requirements
appear in the design specifications. Thus, it is evident that the traceability matrix is an index to locate
the requirement in the related documents.
Types of Traceabilities:
Traceability: The document which enables readers to identify related items in documentation and
software, such as requirements with associated tests.
Vertical traceability: The tracing of requirements through the layers of development documentation to
software components.
Horizontal traceability: The tracing of requirements in the layers of test documentation such as in test
plan, test design specification, test case specification and test procedure specification or test script.

23 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]

 SOFTWARE ENGINEERING NOTES

2.7. Process of Requirement Change Management:

Business, technical and organizational changes force that software system should be changed. So
requirement gathering process should be done in such a way so that impact of making a change can be
assessed and accommodated easily. So, a change management process is described here. It should be applied
to all the proposed changes in requirements. The benefit of applying a formal process to a change ensures all
the changes are treated consistently and changes made get reflected in the documents in a controlled way.
It is an official document initiating modification in existing features, requirements or functions or requesting
for new functionality. It should contain details of the current solution, justification for a change an suggested
solution.
The key stages of a change management process are as given below.
1. Problem Analysis and Change Specification: The trigger to this stage is identification of a problem that
comes as a proposal from the customers. The change can either be a normal change or urgent change. Urgent
changes are applied immediately. The normal changes are studied as mentioned below.
✓ The specify problem is analysed to ensure its validity
✓ The analysis of the change is given back to the requestor
2. Change Analysis and its Costing: The purpose of carrying out analysis is manifold. It is done precisely
to assess the following.
✓ Its effect on rest of the system using traceability matrix and general knowledge about the system
✓ Impact of making the change in terms of both time and cost by assessing the modifications
required in documents, design specifications and code implementation.
✓ The results of the change analysis are given to customer for his approval.
3. Change Implementation: After receiving concurrence of customer, the changes are done, tested, and
given to Quality Assurance Group for their approval.
✓ The requirements document, design specifications, and code are modified at this stage as part of
configuration management.
✓ All the artefacts – requirement document, design specifications, and code should be organized and
designed in modular fashion so that changes can be done in localized way without affecting the other
parts of all artefacts.
✓ On the other hand if the change is urgent, the changes can be done first without following the above
three steps, modify all the artefacts.

24 PREPARED BY K.KISHORE , MCA, M.Tech [ PRAGNYA INSTITUTIONS,CHANDANAGAR ]