Chap 02: Software Engineering Practices and Software

Requirements Engineering
1. Software Engineering Practices:
Generic framework activities—communication, planning, modeling, construction, and
deployment—and umbrella activities establish a basic architecture for software engineering work.
Here, you will understand the generic concepts and principles that apply to framework activities.

1.1 The Essence of Practice

1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
Understand the problem.
Spend a little time answering a few simple questions:
 Who has a stake in the solution to the problem? That is, who are the stakeholders?
 What are the unknowns? What data, functions, and features are required to properly solve the
problem?
 Can the problem be compartmentalized? Is it possible to represent smaller problems that may be
easier to understand?
 Can the problem be represented graphically? Can an analysis model be created?
Plan the solution.
Before you begin coding, do a little design:
 Have you seen similar problems before? Is there existing software that implements the data,
functions, and features that are required?
 Has a similar problem been solved? If so, are elements of the solution reusable?
 Can sub problems be defined? If so, are solutions ready for the sub problems?
 Can you represent a solution in a manner that leads to effective implementation? Can a design
model be created?
Carry out the plan.
 Does the solution conform to the plan? Is source code traceable to the design model?
 Is each component part of the solution provably correct? Have the design and code been
reviewed, or better, have correctness proofs been applied to the algorithm?
Examine the result.
 Is it possible to test each component part of the solution? Has a reasonable testing strategy been
implemented?
 Does the solution produce results that conform to the data, functions, and features that are
required? Has the software been validated against all stakeholder requirements?

Subject: Software Engineering

 2. Core Principles of Software Engineering
The First Principle: The Reason It All Exists
 A software system exists for one reason: to provide value to its users. All decisions should be made
with this in mind.
 Before specifying a system requirement, system functionality, before determining the hardware
platforms, first determine, whether it adds value to the system.
The Second Principle: KISS (Keep It Simple, Stupid!)
 All design should be as simple as possible, but no simpler. This facilitates having a more easily
understood and easily maintained system.
 It doesn’t mean that features should be discarded in the name of simplicity.
 Simple also does not mean “quick and dirty.” In fact, it often takes a lot of thought and work over
multiple iterations to simplify.
The Third Principle: Maintain the Vision
 A clear vision is essential to the success of a software project.
 If you make compromise in the architectural vision of a software system, it will weaken and will
eventually break even the well-designed systems.
 Having a powerful architect who can hold the vision helps to ensure a very successful software
project.
The Fourth Principle: What You Produce, Others Will Consume
 Always specify, design, and implement by keeping in mind that someone else will have to
understand what you are doing.
 The audience for any product of software development is potentially large.
 Design (make design), keeping the implementers (programmers) in mind. Code (program) with
concern for those who will maintain and extend the system.
 Someone may have to debug the code you write, and that makes them a user of your code.
The Fifth Principle: Be Open to the Future
 A system with a long lifetime has more value.
 True “industrial-strength” software systems must last for longer.
 To do this successfully, these systems must be ready to adapt changes.
 Always ask “what if,” and prepare for all possible answers by creating systems that solve the
general problem.
The Sixth Principle: Plan Ahead for Reuse
 Reuse saves time and effort.
 The reuse of code and designs has a major benefit of using object-oriented technologies.
 Planning ahead for reuse reduces the cost and increases the value of both the reusable components
and the systems into which they are incorporated.

Subject: Software Engineering

The Seventh principle: Think!
 Placing clear, complete thought before action almost always produces better results.
 When you think about something, you are more likely to do it right. You also gain knowledge
about how to do it right again.
 If you do think about something and still do it wrong, it becomes a valuable experience.
 Applying the first six principles requires intense thought, for which the potential rewards are
enormous.
3. Communication Practices/Principles.
Software requirement always begins with communication between two or more parties.
In communication principles, the initial stage is to collect or gather requirement from customer.
Principle 1 Listen:
 Try to focus on the speaker‘s words, rather than formulating your response to those words.
 Ask for clarification if something is unclear, but avoid constant interruptions.
 Never become contentious in your words or actions (e.g., rolling your eyes or shaking your head) as a
person is talking.
Principle 2 Prepare before you communicate:
 Spend the time to understand the problem before you meet with others. If necessary, perform some
research to understand business domain.
 If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.
Principle 3 someone should facilitate the activity:
 Every communication meeting should have a leader (a facilitator)
(1) To keep the conversation moving in a productive direction,
(2) To mediate any conflict that does occur, and
(3) To ensure that other principles are followed.
Principle 4 Face-to-face communication is best:
 It usually works better when some other representation of the relevant information is present.
 For example, a participant may create a drawing /document that serve as a focus for discussion.
Principle 5 Take notes and document decisions:
 Someone participating in the communication should serve as a recorder and write down all important
points and decisions.
Principle 6 Strive for collaboration:
 Collaboration occurs when the collective knowledge of members of the team is used to describe product
or system functions or features.
 Each small collaboration builds trust among team members and creates a common goal for the team.
Principle 7 Stay focused; modularize your discussion:
 The more people involved in any communication, the more likely that discussion will bounce from one
topic to the next.
 The facilitator should keep the conversation modular; leaving one topic only after it has been resolved.
Principle 8 If something is unclear, draw a picture:
 Verbal communication goes only so far.
 A sketch or drawing can often provide clarity when words fail to do the job.

Subject: Software Engineering

Principle 9
(a) Once you agree to something, move on.
(b) If you can’t agree to something, move on.
(c) If a feature or function is unclear and cannot be clarified at the moment, move on.
 The people who participate in communication should recognize that many topics require discussion and
that moving on is sometimes the best way to achieve communication agility.
Principle 10 Negotiation is not a contest or a game: It works best when both parties win.
 There are many instances in which you and other stakeholders must negotiate functions and features,
priorities, and delivery dates.
 If the team has collaborated well, all parties have a common goal. Still, negotiation will demand
compromise from all parties.

4. Planning Practices
Planning activity establishes a plan for software engineering work that follows. Planning
describes the technical tasks to be conducted, the resources that will be required, and the risks
that are likely the work products to be produced.
Principle 1: Understand the scope of the project.
 It’s impossible to use a road map if you don’t know where you’re going.
 Scope provides the software team with a destination.
Principle 2: Involve stakeholders in the planning activity.
 Stakeholders define priorities and establish project constraints.
 To accommodate these realities, software engineers must often negotiate order of delivery,
time lines, and other project-related issues.
Principle 3: Recognize that planning is iterative.
 As work begins, it is very likely that things will change.
 As a consequence, the plan must be adjusted to accommodate these changes.
 In addition, iterative, incremental process models dictate replanning after the delivery of
each software increment based on feedback received from users.
Principle 4: Estimate based on what you know.
 The intent of estimation is to provide an indication of effort, cost, and task duration, based on
the team’s current understanding of the work to be done.
 If information is unreliable, estimates will be equally unreliable.
Principle 5: Consider risk as you define the plan.
 If you have identified risks that have high impact and high probability, contingency planning
is necessary.
 In addition, the project plan (including the schedule) should be adjusted to accommodate the
thought that one or more of these risks will occur.

Subject: Software Engineering

 Principle 6: Be realistic.
 People don’t work 100 percent of every day.
 Noise always enters into any human communication. Omissions and ambiguity are facts of
life. Change will occur. Even the best software engineers make mistakes.
 These and other realities should be considered as a project plan is established.
Principle 7: Adjust granularity as you define the plan.
 Granularity refers to the level of detail that is introduced as a project plan is developed.
 A “high-granularity” plan provides significant work task detail that is planned over short
time increments.
 A “low-granularity” plan provides broader work tasks that are planned over longer time
periods.
Principle 8: Define how you intend to ensure quality.
 The plan should identify how the software team intends to ensure quality.
 If technical reviews are to be conducted, they should be scheduled.
 If pair programming is to be used during construction, it should be explicitly defined
within the plan.
Principle 9: Describe how you intend to accommodate change.
 You should identify how changes are to be accommodated as software engineering work
proceeds.
 For example, can the customer request a change at any time? If a change is requested, is
the team ready enough to implement it immediately? How is the impact and cost of the
change assessed?
Principle 10: Track the plan frequently and make adjustments as required.
 Software projects fall behind schedule one day at a time.
 Therefore, it makes sense to track progress on a daily basis, looking for problem areas
and situations in which scheduled work does not conform to actual work conducted.

5. Modeling Principles
 We create models to gain a better understanding of the actual entity to be built.
 When entity to be built is software, our model must take a different form. It must be
capable of representing the information that software transforms, the architecture and
functions that enable the transformation to occur, the features that user desire, and the
behavior of the system as the transformation is taking place.
 Models must accomplish these objectives at different levels of abstraction: first
depicting the software from the customer’s viewpoint and later representing the software
at a more technical level.
 In software engineering work, two classes of models can be created: requirements
(analysis) models and design models.

Subject: Software Engineering

 5.1 Analysis Modeling Principles
Requirements models (also called analysis models) represent customer requirements by
depicting the software in three different domains:
 The information domain,
 The functional domain, and
 The behavioral domain.
Principle 1: The information domain of a problem must be represented and
understood.
 The information domain encompasses the data that flow into the system, the data that
flow out of the system, and the data stores that collect and organize persistent data
objects.
Principle 2: The functions that the software performs must be defined.
 Software functions provide benefit to end users and also provide internal support for
those features that are user visible. Some functions transform data that flow into the
system.
 Functions can be described at many different levels of abstraction, ranging from a
general statement of purpose to a detailed description of the processing elements
Principle 3: The behavior of the software (as a consequence of external events)
must be represented.
 The computer software shows its behavior by its interaction with the external environment.
 Input provided by end users, control data provided by an external system, or monitoring
data collected over a network all cause the software to behave in a specific way.
Principle 4: The models that depict information function and behavior must be
partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.
 Requirement modeling allows you to better understand the problem and establishes a basis
for the solution (design).
 Complex problems are difficult to solve as a whole.
 For this reason, you should use a divide-and-conquer strategy. A large, complex problem is
divided into sub problems until each sub problem is relatively easy to understand.
 This concept is called partitioning or separation of concerns, and it is a key strategy in
requirements modeling.
Principle 5: The analysis task should move from essential information toward
implementation detail.
 Requirement modeling begins by describing the problem from the end-user’s perspective.
 The “essence” of the problem is described without any consideration of how a solution will
be implemented.

Subject: Software Engineering

5.2 Design Modeling Principles
Design models represent characteristics of the software that help practitioners to construct it
effectively:
 The architecture,
 The user interface, and
 The component-level detail.

Principle 1: Design should be traceable to the requirements model.

 The analysis mode describes the information domain of the problem, user visible functions and various
things about system.
 The design model translates this information into architecture: a set of sub systems that implement
major functions, and a set of component level designs that are the realization of analysis classes.
Principle 2: Always consider the architecture of the system to be built.
 Software architecture is a skeleton of the system to be built. It affects interfaces, data structures,
program control flow and behavior, the manner in which testing can be conducted, the maintainability
of the resultant system and much more.
 For all these reasons, design should start with architectural considerations.
Principle 3: Design of data is as important as design of processing functions.
 Data design is an essential element of architectural design.
 The manner in which data objects are realized within the design cannot be left to chance.
 A well-structured data design helps to simplify program flow, makes the design and implementation of
software components easier, and makes overall processing more efficient.
Principle 4: Interfaces (both internal and external) must be designed with care.
 The manner in which data flows between the components of a system has much to do with processing
efficiency, error propagation, and design simplicity.
 A well designed interface makes integration easier and assists the tester in validating component
functions.
Principle 5: User interface design should be tuned to the needs of the end user.
 The user interface is the visible manifestation of the software.
 No matter how sophisticated its internal functions, no matter how comprehensive its data structures,
no matter how well designed its architecture, a poor interface design often leads to the perception that
the software is bad.
Principle 6: Component-level design should be functionally independent.
 The functionality that is delivered by a component should be cohesive – that is it should focus on one
and only one function or sub –function
Principle 7: Components should be loosely coupled to one another and to the external environment.
 Coupling is achieved in many ways – via a component interface, by messaging, through global data.
 As the level of coupling increases, the likelihood or error propagation also increases and the overall
maintainability of the software decreases.
Principle 8: Design representations (models) should be easily understandable.
 The purpose of design is to communicate information to practitioners who will generate code, to those
who will test the software, and to others who may maintain the software in the future.
 If the design is difficult to understand, it will not serve as an effective communication medium.

Subject: Software Engineering

Principle 9: The design should be developed iteratively. With each iteration, the designer should
strive for greater simplicity.
 Like almost all creative activities, design occurs iteratively.
 The first iterations work to refine the design and correct errors, but later iterations should strive to
make the design as simple as is possible.

6. Construction Principles
The construction activity encompasses a set of coding and testing tasks that lead to
operational software that is ready for delivery to the customer or end user.

6.1 Coding Principles

In modern software engineering work, coding may be
(1) The direct creation of programming language source code (e.g., Java),
(2) The automatic generation of source code using an intermediate design-like representation of
the component to be built (e.g. Microsoft front end where code is automatically generated),
or
(3) The automatic generation of executable code using a “fourth-generation programming
language” (e.g., Visual C++).
Preparation principles: Before you write one line of code, be sure you
 Understand of the problem you’re trying to solve.
 Understand basic design principles and concepts.
 Pick a programming language that meets the needs of the software to be built and the
environment in which it will operate.
 Select a programming environment that provides tools that will make your work easier. (E.g.
TC, JRE etc.).
 Create a set of unit tests that will be applied once the component you code is completed.
Programming principles: As you begin writing code, be sure you
 Constrain your algorithms by following structured programming practice.
 Consider the use of pair programming.
 Select data structures that will meet the needs of the design.
 Understand the software architecture and create interfaces that are consistent with it.
 Keep conditional logic as simple as possible.
 Create nested loops in a way that makes them easily testable.
 Select meaningful variable names and follow other local coding standards
 Write code that is self-documenting. (e.g. Comments)
 Create a visual layout (e.g., indentation and blank lines) that aids understanding.

Validation Principles: After you’ve completed your first coding pass, be sure you
 Conduct a code walkthrough when appropriate.
 Perform unit tests and correct errors you’ve uncovered.
 Refactor the code.

Subject: Software Engineering

 6.2 Testing Principles
Testing objectives:
 Testing is a process of executing a program with the intention of finding an error.
 A good test case is one that has a high probability of finding an undiscovered error.
 A successful test is one that uncovers an undiscovered error.
Levels of Testing:
The initial focus of testing is at the component level, often called unit testing
The other levels of testing include:
1. Integration Testing (conducted as the system is constructed).
2. Validation Testing (assesses whether requirements have been met for the complete
system or software increment).
3. Acceptance Testing (conducted by the customer in an effort to check all required
features and functions)
Principle 1: All tests should be traceable to customer requirements.
 The objective of software testing is to uncover errors.
 It follows that the most severe defects (from the customer’s point of view) are those that cause the
program to fail to meet its requirements.
Principle 2: Tests should be planned long before testing begins.
 Test planning can begin as soon as the requirements model is complete.
 Detailed definition of test cases can begin as soon as the design model has been made.
 Therefore, all tests can be planned and designed before any code has been generated.
Principle 3: The Pareto principle applies to software testing.
 In this context the Pareto principle implies that 80 percent of all errors uncovered during testing will
likely to be coming from 20 percent of all program components.
 The problem, of course, is to isolate these suspect components and to thoroughly test them.
Principle 4: Testing should begin “in the small” and progress toward testing “in the large.”
 The first tests planned and executed generally focus on individual components.
 As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components
and ultimately in the entire system.
Principle 5: Exhaustive testing is not possible.
 The number of path permutations (possible combinations) for even a moderately sized program is
exceptionally large.
 For this reason, it is impossible to execute every combination of paths during testing.
 However, it is possible, to adequately cover program logic and to ensure that all conditions in the
component-level design have been tested.

Subject: Software Engineering

 Deployment Principles
Concept of Delivery Cycle, Support Cycle & feedback Cycle:

 The deployment activity encompasses three actions: delivery, support, and feedback.
 Because modern software process models are evolutionary or incremental in nature, deployment
happens not once, but a number of times as software move toward completion.
 Each delivery cycle provides the customer and end users with an operational software increment
that provides usable functions and features.
 Each support cycle provides documentation and human assistance for all functions and features
introduced during all deployment cycles to date.
 Each feedback cycle provides the software team with important guidance that result in
modifications to the functions, features, and approach taken for the next increment.

Principles:
Principle 1: Customer expectations for the software must be managed.
 Too often, the customer expects more than the team has promised to deliver, and
disappointment occurs immediately. This results in feedback that is not productive.
 Software engineer must be careful about sending the customer conflicting messages (e.g.,
promising more than you can reasonably deliver in the time frame provided or delivering more
than you promise for one software increment and then less than promised for the next).
Principle 2: A complete delivery package should be assembled and tested.
 A CD-ROM or other media (including Web-based downloads) containing all executable
software, support data files, support documents, and other relevant information should be
assembled and thoroughly beta-tested with actual users.
 All installation scripts and other operational features should be thoroughly exercised.
Principle 3: A support regime must be established before the software is delivered.
 When a problem or question arises at end user’s side, he/she expects responsiveness and
accurate information.
 If support is ad hoc or nonexistent, the customer will become dissatisfied immediately. Support
should be planned, support materials should be prepared, and appropriate recordkeeping
mechanisms should be established so that the software team can conduct an assessment of the
kinds of support requested.

Principle 4: Appropriate instructional materials must be provided to end users.

 The software team delivers more than the software itself.
 Appropriate training aids (if required) should be developed; troubleshooting guidelines should
be provided

Principle 5: Buggy software should be fixed first, delivered later.

 Under time pressure, some software organizations deliver low-quality increments with a
warning to the customer that bugs “will be fixed in the next release.” Customer gets
disappointed by this.
 Hence it is necessary to fix the bug before the product is delivered to the customer.

Subject: Software Engineering

7. Requirements Engineering
From software process perspective, requirements engineering is a major software engineering action that
begins during the communication activity and continues into the modeling activity. It must be adapted to
the needs of the process, the project, the product, and the people doing the work.
Need of Requirement Engineering:-
Requirements engineering tools assist in requirements gathering, requirements modeling, requirements
management, and requirements validation.
Subtasks included in Requirement Engineering:-
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements management
7.1 Requirement Engineering Tasks
Requirement Engineering encompasses seven distinct tasks: inception, elicitation, elaboration,
negotiation, specification, validation, and management.
1. Inception
 Most projects begin when a business need is identified or a potential new market or service is
discovered.
 Stakeholders from the business community (e.g., business managers, marketing people, and product
managers) define a business case for the idea, try to identify the breadth and depth of the market, do a
rough feasibility analysis, and identify a working description of the project’s scope.
 At project inception, you establish a basic understanding of the problem, the people who want a
solution, the nature of the solution that is desired, and the effectiveness of preliminary communication
and collaboration between the customer and the software team.
2. Elicitation
 Elicitation means to define what is required.
 Requirement engineer asks the customer, user and others:
1) what the objectives for the system or product are
2) what is to be accomplished
3) how the system or product fits into the needs of the business,
4) how the system or product is to be used on a day-to-day basis
Requirement elicitation is difficult because numbers of problems are encountered:
 Problems of scope:
The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail
that may confuse, rather than clarify, overall system objectives.
 Problems of understanding:
The customers/users:
o are not completely sure of what is needed
o have a poor understanding of the capabilities and limitations of their computing environment,

Subject: Software Engineering

 o don’t have a full understanding of the problem domain,
o have trouble communicating needs to the system engineer,
o Omit information that is believed to be “obvious,”
o Specify requirements that conflict with the needs of other customers/users, or specify requirements
that are ambiguous (unclear) or untestable.
 Problems of volatility:
The requirements change over time.
3. Elaboration.
 The information obtained from the customer during inception and elicitation is expanded and
refined during elaboration.
 This task focuses on developing a refined requirements model that identifies various aspects of
software function, behavior, and information.
 Elaboration is driven by the creation and refinement of user scenarios that describe how the end
user (and other actors) will interact with the system.
 Each user scenario is parsed to extract analysis classes—business domain entities that are visible to
the end user.
 The attributes of each analysis class are defined, and the services that are required by each class
are identified.
 The relationships and collaboration between classes are identified, and a variety of supplementary
diagrams are produced.
4. Negotiation
 It isn’t unusual for customers and users to ask for more than that can be achieved, with limited
business resources.
 Requirement engineer must reconcile these conflicts through a process of negotiation.
 Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts
in priority.
 Risks associated with each requirement are identified and analyzed.
 Rough estimates of development effort are made and are used to assess the impact of each
requirement on project cost and delivery time.
 Using an iterative approach, requirements are eliminated, combined, and/or modified so that each
party achieves some measure of satisfaction.
5. Specification.
 A specification can be a written document, a set of graphical models, a formal mathematical
model, and a collection of usage scenarios, a prototype, or any combination of these.
 For large systems, a written document, combining natural language descriptions and graphical
models may be the best approach.
 Specification is the final work product produced by the requirement engineer.
 It describes the function and performance of a computer based system and the constraints that will
be imposed while its development.

Subject: Software Engineering

 6. Validation
 The work products produced as a consequence of requirements engineering are assessed for quality
during a validation step.
 Requirements validation examines the specification to ensure that all software requirements have
been stated clearly; that inconsistencies, omissions, and errors have been detected and corrected;
and that the work products conform to the standards established for the process, the project, and
the product.
 The primary requirements validation mechanism is the technical review.
 The review team that validates requirements includes software engineers, customers, users, and
other stakeholders who examine the specification looking for errors in content or interpretation,
areas where clarification may be required, missing information, inconsistencies (a major problem
when large products or systems are engineered), conflicting requirements, or unrealistic
(unachievable) requirements.
7. Requirements management
 Requirements management is a set of activities that help the project team identify, control, and
track requirements and changes to requirements at any time as the project proceeds.
 Many of these activities are identical to the software configuration management (SCM) techniques.

9. Software Requirements Specification

9.1 Concept:
 A software requirements specification (SRS) is a document that is created when a detailed
description of all aspects of the software to be built that must be specified before the project is
to commence.
 It is a primary document for development of software.
 It is written by Business Analysts who interact with client and gather the requirements to build
the software.
9.2 Need/Importance of SRS:
 It establishes the basis for agreement between the customers and the suppliers on what the
software product is to do.
The complete description of the functions performed by the software specified in the SRS will assist the
users to determine if the software meets their needs.
 Reduces the development effort.
The preparation of the SRS forces the concerned groups to consider all of the requirements before
design begins and reduces later redesign, recoding, and retesting.
 Provide a basis for estimating cost and schedules.
The description of the product to be developed given in SRS is a realistic basis for estimating
project costs and prices.
 Provide a baseline for verification and validation.
Organizations can develop their validation and verification plans much more productively from a
good SRS.

Subject: Software Engineering

  Facilitate Transfer.
The SRS makes it easier to transfer the software product to new users or new machines.
 Serve as basis for enhancement.
Because the SRS discusses the product but not just the project that is developed, the SRS serves as
a basis for later enhancement of the finished product.

Msbte Questions:
1. What are the core principles of software engineering (W14-4M,W15-8M)
Or
Enlist core principles of software engineering practice. (S15-4M)
2. Describe communication principles statements. (W13-4M,W15-4M)
3. Describe eight principles of good planning. (S15-8M)
4. What are the modeling practices in software engineering? Explain their principles. (W14-
4M)
5. What is software coding? State three principles of code validation. (S16-4M,W15-4M)
6. Explain deployment principle. (S15-4M,W15-4M)
Or
What is software deployment? State the principles to be followed while preparing to
deliver the software increment. (S16, 8M)
7. What is requirement engineering? What is its need? What are different subtasks included
in it? (W14-4M)
Or
List seven task of requirement engineering. (S15-4M)
Or
With reference to requirement engineering, explain
(i) Inception and (ii) Elicitation (W15-4M)
Or
What is Requirements Elicitation? What are the problems faced in eliciting requirements?
(S16-4M)
8. What is SRS? (S15-4M) or Explain the importance of SRS. (S16-4M)
Or
What is SRS? Explain the importance of SRS. (S16-4M)
(Asked 2 times in the same paper)

Subject: Software Engineering

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

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.

Types of Feasibility:

00:17/11:06
16M
250
Triggers in SQL (Hindi)

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.

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.

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