SEN-22413-Unit 2-Software Requirement Engineering

Unit No II
Software Requirement Engineering [14 Marks]

Software Engineering Practices:

Software Engineering is a systematic process of developing software. Software engineering
practice is a set of principles, concepts, methods, and tools that are used by software
practitioners on day to day basis for developing software product. Principles that guide practice
establish a foundation from which software engineering is conducted.
Software engineering

Essence of the practice:

Essence of the Software Engineering practice is as follows:
1. Understand the problem (communication and analysis)
 Who has a stake in the solution to the problem?
 What are the unknowns (data, function, behavior)?
 Can the problem be compartmentalized?
 Can the problem be represented graphically?
2. Plan a solution (planning, modeling and software design)
 Have you seen similar problems like this before?
 Has a similar problem been solved and is the solution reusable?
 Can subproblems be defined and are solutions available for the subproblems?
3. Carry out the plan (construction; code generation)
 Does the solution conform to the plan? Is the source code traceable back to the
design?
 Is each component of the solution correct? Has the design and code been reviewed?
4. Examine the results for accuracy (testing and quality assurance)
 Is it possible to test each component of the solution?
 Does the solution produce results that conform to the data, function, and behavior that
are required?

Q1: What are the core principles of software engineering? Explain. OR Enlist core
principles of software engineering practice.
Ans:
David Hooker has proposed seven core principles for software engineering practice. These are
as follows:
1. The reason it all exists.
2. Keep it simple stupid
3. Maintain the vision
4. What you produce, others will consume
5. Be open to the future
6. Plan ahead for reuse
7. Think

Mrs. M. P. Patil (DYP POLY, KOP) Page 1

 SEN-22413-Unit 2-Software Requirement 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, before noting a piece of system
functionality, before determining the hardware platforms or development processes, ask yourself
questions such as: "Does this add real VALUE to the system?" If the answer is "no", don't do it.
All other principles support this one.

The Second Principle: KISS (Keep It Simple, Stupid!)

There are many factors to consider in any design effort. All design should be as simple as
possible, but no simpler. This facilitates having a more easily understood, and easily maintained
system.

The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project. Without one, a project almost
unfailingly ends up being "of two [or more] minds" about itself. Compromising the architectural
vision of a software system weakens and will eventually break even the most well designed
systems. Having an empowered Architect who can hold the vision and enforce compliance helps
ensure a very successful software project.

The Fourth Principle: What You Produce, Others Will Consume.

Rarely is an industrial-strength software system constructed and used in a vacuum. In some way
or other, someone else will use, maintain, document, or otherwise depend on being able to
understand your system. So, always specify, design, and implement knowing someone else will
have to understand what you are doing. The audience for any product of software development is
potentially large. Specify with an eye to the users. Design, keeping the implementers in mind.
Code with concern for those that must maintain and extend the system. Someone may have to
debug the code you write, and that makes them a user of your code. Making their job easier adds
value to the system.

The Fifth Principle: Be Open to the Future

A system with a long lifetime has more value. In today's computing environments, where
specifications change on a moment's notice and hardware platforms are obsolete when just a few
months old, software lifetimes are typically measured in months instead of years. However, true
"industrial-strength" software systems must endure far longer. To do this successfully, these
systems must be ready to adapt to these and other changes. Systems that do this successfully are
those that have been designed this way from the start. Never design yourself into a corner.
Always ask "what if ", and prepare for all possible answers by creating systems that solve the
general problem, not just the specific one. This could very possibly lead to the reuse of an entire
system.

The Sixth Principle: Plan ahead for Reuse

Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to
accomplish in developing a software system. The reuse of code and designs has been proclaimed
as a major benefit of using object-oriented technologies. However, the return on this investment
is not automatic. To leverage the reuse possibilities that OO programming provides requires
forethought and planning. There are many techniques to realize reuse at every level of the system

Mrs. M. P. Patil (DYP POLY, KOP) Page 2

 SEN-22413-Unit 2-Software Requirement Engineering

development process. Those at the detailed design and code level are well known and
documented. New literature is addressing the reuse of design in the form of software patterns.
However, this is just part of the battle. Communicating opportunities for reuse to others in the
organization is paramount. How can you reuse something that you don't know exists? Planning
ahead for reuse reduces the cost and increases the value of both the reusable components and the
systems into which they are incorporated.

Seventh Principle: Think!

This last Principle is probably the most overlooked. 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 valuable experience. A side effect of thinking
is learning to recognize when you don t know something, at which point you can research the
answer. When clear thought has gone into a system, value comes out. Applying the first six
Principles requires intense thought, for which the potential rewards are enormous.

Q2. State and describe principles of communication practices.

Ans: Communication Practices Effective communication among the technical peers, customers
and other stakeholders, project managers etc. is among the most challenging activities that
confront software engineers. Before customers requirements can be analyzed, modeled are
specified they must be gathered through a communication. Effective communication is among
the most challenging activities that you will confront.

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)
 To keep the conversation moving in a productive direction,
 To mediate any conflict that does occur, and
 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.

Mrs. M. P. Patil (DYP POLY, KOP) Page 3

 SEN-22413-Unit 2-Software Requirement Engineering

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

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.

OR
Communication practice is two way communications between the client and the developer,
hence it is also known as requirement elicitation.
1. Listen carefully
i. To collect lots of data from the client, the developer team has to listen carefully.
ii. Maximum information with respect to requirement and the specifications should be collected
before the implementation and the designing of the software.

Mrs. M. P. Patil (DYP POLY, KOP) Page 4

 SEN-22413-Unit 2-Software Requirement Engineering

2. Prepare before you communicate

i. A proper agenda or the guidelines for the meetings should be prepared before the start of the
meeting.
ii. Complete detail and the description about the clients and their work area should be gathered to
deliver the software up to the best expectation.
3. Have a facilitator for any communication meeting
i. The requirement gathering and the specification are important for any software development,
hence the communication should continue till the requirement gathering is over.
4. Face-to-face communication is best
i. It is always better to sit across the table and have discussion on the requirement on the software
development by the client and the developer.
5. Take notes and document decisions
i. The important points discussed should also be recorded.
ii. Proper notes and the documentation is important for the successful completion and
deployment of the project.
6. Strive for collaboration
i. Collaboration in terms of teamwork is required for the successful completion of the software.
ii. The collective knowledge of the team members should be implemented in the development.
7. Stay focused and modularize your discussion
i. As the development is the working of many team members, so the possibility of the discussion
going from one topic to the other topic is quite possible.
ii. As a good software developer it is required that the discussion remains focused on the
specified area.
8. Draw a picture if something is unclear
i. Drawing flowcharts, E-R diagrams and other supporting graphical representations give clarity
to the discussion and the documentation.
9. Move on once you agree, move on when you can't agree, move on if something unclear
can't be clarified at the moment
i. Healthy discussion leads to the final conclusion of successful implementation of the software.
ii. Once reached to final statement recorded should move to the next step.
iii. If no conclusion is reached than that point should be left and move ahead with new
implementation which is cost effective.
10. Negotiation is not a contest or game
i. Negotiation should be mutual not to put someone down or make them feel to be the loser.

Q3: Describe in detail principles of good planning. OR Explain principles of planning

practices in software engineering.
Ans:
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.

Mrs. M. P. Patil (DYP POLY, KOP) Page 5

 SEN-22413-Unit 2-Software Requirement Engineering

Principle 3. Recognize that planning is iterative. A project plan is never engraved in stone. 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 re-planning 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 vague or unreliable, estimates will be equally unreliable.
Principle 5.Consider risk as you defines 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 likelihood that one or more of
these risks will occur.
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 defines 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 relatively short time increments (so that tracking and control
occur frequently). A ―low-granularity‖ plan provides broader work tasks that are planned over
longer time periods. In general, granularity moves from high to low as the project time line
moves away from the current date. Over the next few weeks or months, the project can be
planned in significant detail. Activities that won‘t occur for many months do not require high
granularity (too much can change).
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. Even the best planning can be
obviated by uncontrolled 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 obliged 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. When slippage is encountered, the plan is adjusted accordingly.

Q4. What are the modeling practices in software engineering? Explain their principles.
Ans: At a technical level, software engineering begins with a series of modeling tasks that lead
to complete specification of requirements and a comprehensive design representation for the
software to be built. The analysis model is a set of models which is nothing but the technical
representation of system. When entity is software, your model must take a different form. At
technical levels, software engineering begins with series of modeling tasks that lead to a

Mrs. M. P. Patil (DYP POLY, KOP) Page 6

 SEN-22413-Unit 2-Software Requirement Engineering

complete specification of requirements and a comprehensive design representation for the

software to be built.
The two dominating analysis modeling techniques are: 1.‖structured analysis‖ 2.‖Object-Oriented
analysis‖

In software engineering two types of models are created as:

i) Analysis models: They represent the customers/users requirements depicting the
software in 3 domains:
a) Information domain
b) Function domain
c) Behavioral domain

ii) Design models: They represent characteristics of the software that help practitioners
to construct it effectively.
a) The architecture
b) The user interface and
c) Component-levels details.
Following are various Analysis Modeling Principles
1. The information domain of a problem must be represented and understood. – Define
data objects – describe data attributes – establish data relationships
2. The functions that the software is to perform must be defined. – Identify functions that
transform data objects
3. The behavior of the software (as a consequence of external events) must be represented.
– Indicate different states of the system – specify events that cause the system to change state
4. The models that depict information function and behavior must be partitioned in a
manner that uncovers detail in a layered (or hierarchical) fashion. – Refine each model to
represent lower levels of abstraction – refine data objects – create a functional hierarchy
represent behavior at different levels of detail
5. The analysis process should move from essential information toward
implementationRequirements 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.

Following are various Design Modeling Principles

Principle #1:- Design should be traceable to an analysis 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.
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

Mrs. M. P. Patil (DYP POLY, KOP) Page 7

 SEN-22413-Unit 2-Software Requirement Engineering

program flow, makes the design and implementation of software components easier, an d makes
overall processing more efficient.
Principle #4: - Interfaces 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 In every
case it should stress ease of 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 le ads to
the perception that the software is bad.
Principle #6: - Component level design should be functionally independent. Functional
independence is a measure of the ―single mindedness‖ of a software component. 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: - Component 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 representation 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.
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 works to refine the design and correct errors, but later iterations
should strive to make the design as simple as possible.

Q5: Describe principles of analysis modelling.

Ans: The analysis model is a set of models which is nothing but the technical representation of
system. When entity is software, your model must take a different form. At technical levels,
software engineering begins with series of modeling tasks that lead to a complete specification of
requirements and a comprehensive design representation for the software to be built.
Analysis models: They represent the customers/users requirements depicting the software in 3
domains: A) Information domain b) Function domain c) Behavioral domain

Following are various Analysis Modeling Principles

Principle 1.The information domain of a problem must be represented and understood.
The information domain encompasses the data that flow into the system (from end users, other
systems, or external devices), the data that flow out of the system (via the user interface, network
interfaces, reports, graphics, and other means), and the data stores that collect and organize
persistent data objects (i.e., data that are maintained permanently).

Mrs. M. P. Patil (DYP POLY, KOP) Page 8

 SEN-22413-Unit 2-Software Requirement Engineering

Principle 2.The functions that the software performs must be defined.

Software functions provide direct 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. In other
cases, functions effect some level of control over internal software processing or external system
elements. 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 that must be
invoked.

Principle 3.The behavior of the software (as a consequence of external events) must be
represented.
The behavior of computer software is driven 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.
Requirements modeling are the first step in software engineering problem solving. It allows you
to better understand the problem and establishes a basis for the solution (design). Complex
problems are difficult to solve in their entirety. For this reason, you should use a divide-and-
conquer strategy. A large, complex problem is divided into subproblems until each subproblem
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. A 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. For example, a video game requires that the player “instruct” its
protagonist on what direction to proceed as she moves into a dangerous maze. That is the essence
of the problem. Implementation detail (normally described as part of the design model) indicates
how the essence will be implemented. For the video game, voice input might be used.
Alternatively, a keyboard command might be typed, a joystick (or mouse) might be pointed in a
specific direction, or a motion-sensitive device might be waved in the air.

Q6. Describe principles of design modelling.

Ans: The software design model is comparable to an architect’s plans for a house. It begins by
representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house)
and slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing
layout). Similarly, the design model that is created for software provides a variety of different
views of the system.
Principle 1. Design should be traceable to the requirements model.
The requirements model describes the information domain of the problem, user-visible functions,
system behavior, and a set of requirements classes that package business objects with the
methods that service them. The design model translates this information into an architecture, a
set of subsystems that implement major functions, and a set of components that are the
realization of requirements classes. The elements of the design model should be traceable to the
requirements model.

Mrs. M. P. Patil (DYP POLY, KOP) Page 9

 SEN-22413-Unit 2-Software Requirement Engineering

Principle 2. Always consider the architecture of the system to be built.

Software architecture (Chapter 9) is the 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 of these reasons,
design should start with architectural considerations. Only after the architecture has been
established should component-level issues be considered.

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.
However, in every case, it should stress ease of use. 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.

Functional independence is a measure of the “single-mindedness” of a software component. The
functionality that is delivered by a component should be cohesive—that is, it should focus on one
and only one function or subfunction.

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 of error propagation also increases and the
overall maintainability of the software decreases. Therefore, component coupling should be kept
as low as is reasonable.

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.

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.

Mrs. M. P. Patil (DYP POLY, KOP) Page 10

 SEN-22413-Unit 2-Software Requirement Engineering

Q7. Briefly describe the principles of coding.

Ans: 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.
The principles that guide the coding task are closely aligned with programming style,
programming languages, and programming methods.
However, there are a number of fundamental principles that can be stated:
 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.
• 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.
• 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.

Q8. Describe principles of testing.

Ans: If testing is conducted successfully (according to the objectives stated previously), it will
uncover errors in the software. As a secondary benefit, testing demonstrates that software
functions appear to be working according to specification and that behavioral and performance
requirements appear to have been met.

A set of testing principles6 that have been adapted for use:

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.

Mrs. M. P. Patil (DYP POLY, KOP) Page 11

 SEN-22413-Unit 2-Software Requirement Engineering

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 solidified. 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 be traceable to 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 for even a moderately sized program is exceptionally large.
For this reason, it is impossible to execute every combination of paths during testing. It is
possible, however, to adequately cover program logic and to ensure that all conditions in the
component-level design have been exercised.
OR
Testing is an activity that is used to discover errors and correct them, so that we are able to create
a defect free product for the customer. Software testing is a process of executing a program or
software with the intent of finding an error. Testing begins at the component level and works
“outward” toward the integration of the entire computer-based system. Different testing
techniques are appropriate for different software engineering approaches and at different points
in time. Testing is conducted by the developer of the software and (for large projects) an
independent test group.

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.
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 solidified. Therefore, all tests can be planned and designed before any code has
been generated.
3. The Pareto principle applies to software testing. Stated simply, the Pareto principle implies
that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all
program components. The problem, of course, is to isolate these suspect components and to
thoroughly test them.
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.
5. Exhaustive testing is not possible. The number of path permutations for even a moderately
sized program is exceptionally large. For this reason, it is impossible to execute every
combination of paths during testing. It is possible, however, to adequately cover program logic
and to ensure that all conditions in the component-level design have been exercised.

Mrs. M. P. Patil (DYP POLY, KOP) Page 12

 SEN-22413-Unit 2-Software Requirement Engineering

6. To be most effective, testing should be conducted by an independent third party. By most

effective, we mean testing that has the highest probability of finding errors (the primary
objective of testing). The software engineer who created the system is not the best person to
conduct all tests for the software.

Q9. Describe the principles of deployment. OR What is Software deployment? State the
principles to be followed while preparing to deliver the software increment.
Ans:
Principle 1: Manage customer’s expectations.
It always happens that customer wants more than he has started earlier as his requirements. It
may be the case that customer gets disappointed, even after getting all his requirements satisfied.
Hence at time of delivery developer must have skills to manage customer‘s expectations.
Principle 2: Assembly and test complete delivery package.
It is not the case that the deliverable package is only software‘. The customer must get all
supporting and essential help from developer‘s side.

Principle 3: Record-keeping mechanism must be established for customer support.

Customer support is important factor in deployment phase. If proper support isnot provided,
customer will not be satisfied. Hence support should be well planned and with record-keeping
mechanism.
Principle 4: Provide essential instructions, documentations and manual.
Many times, developer thinks ―when project is successful deliverable part is only working
program‖. But realty is that working program is just part of software product. Actual project
delivery includes all documentations, help files and guidance for handling the software by user.
Principle 5: Don’t deliver any defective or buggy software to the customer.
In incremental type of software, software organizations may deliver some defective software to
the customer by giving assurance that the defects will be removed in next increment.
OR
Software Deployment: Deployment occurs as each software increment is presented to the
customer and encompasses delivery, support, and feedback. As 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. The delivery of a software increment represents an important milestone for
any software project. Deployment Principles:
1. Principle 1: Customer expectations for the software must be managed: It always happens
that customer wants more than he has started earlier as his requirements. It may be the case that
customer gets disappointed, even after getting all his requirements satisfied. Hence at time of
delivery developer must have skills to manage customer’s expectations.
2. Principle 2: A complete delivery package should be assembled and tested: A CD-ROM or
other media 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 in as many

Mrs. M. P. Patil (DYP POLY, KOP) Page 13

 SEN-22413-Unit 2-Software Requirement Engineering

different computing configurations (i.e., hardware, operating systems, and peripheral devices,
networking arrangements) as possible.
3. Principle 3: A support regime must be established before the software is delivered: An
end user expects responsiveness and accurate information when a question or problem arises. If
support is ad hoc, or worse, 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 a categorical
assessment of the kinds of support requested.
4. Principle 4: Appropriate instructional materials must be provided to end users:
Appropriate training aids (if required) should be developed; troubleshooting guidelines should be
provided, and when necessary, a ―what‘s different about this software increment‖ description
should be published
5. Principle 5: Buggy software should be fixed first, delivered later: In incremental type of
software, software organizations may deliver some defective software to the customer by giving
assurance that the defects will be removed in next increment. This is a mistake. Buggy software
should not be delivered.
OR
Software Deployment:
The deployment phase includes 3 actions namely 1. Delivery 2.Support 3. Feedback
1. The delivery cycle provides the customer and the end user with an operational software
increment that provides usable functions and features.
2. The support cycle provides documentation, human assistance for all functions and features
introduced during all deployment cycles to date.
3. Each feedback cycle provides the software team with useful inputs. The feedback can help in
modifications to the functions, features and even the approach for the next increments.

The delivery of the software increment is an important milestone of any software project. A
number of key principles should be followed as the team prepares to deliver an increment.
1. Customer expectations for the software must be managed
Before the software delivery the project team should ensure that all the requirements of the users
are satisfied.
2. A complete delivery package should be assembled and tested
The system containing all executable software, support data files, tools and support documents
should be provided with beta testing at the actual user side.
3. A support regime must be established before the software is delivered
This includes assigning the responsibility to the team members to provide support to the users in
case of problem.
4. Appropriate instructional materials must be provided to end users
At the end of construction various documents such as technical manual, operations manual, user
training manual, user reference manual should be kept ready. These documents will help in
providing proper understanding and assistance to the user.
5. Buggy software should be fixed first, delivered later.
Sometimes under time pressure, the software delivers low-quality increments with a warning to
the customer that bugs will be fixed in the next release. Customers will forget you delivered a
high-quality product a few days late, but they will never forget the problems that a low quality
product caused them. The software reminds them every day.
Mrs. M. P. Patil (DYP POLY, KOP) Page 14
 SEN-22413-Unit 2-Software Requirement Engineering

Q 10: What is requirement engg. ? What is its need? What are different subtasks included
in it?
Ans: Requirement Engineering:-
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 Requirement Engineering:-

 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements management

Requirements engineering tasks

1. Inception: - Inception means beginning. It is usually said that requirement engineering is
a―communication intensive activity. The customer and developer meet and they the overall
scope and nature of the problem statements. By having proper inception phase the developer
will have clear idea about the system and as a result of that better understanding of a system
can be achieved. Once the system is clear to the developer they can implement a system with
better efficiency.

2. Elicitation: - Elicitation task will help the customer to define the actual requirement of a
system. To know the objectives of the system or the project to be developed is a critical job.
This phase will help people to determine the goal of a system and clear idea about the
system can be achieved.
3. Elaboration: - The information obtained from the customer during inception and elicitation is
expanded and refined during elaboration. This requirement engineering activity focuses on
developing a refined technical model of software functions, features and constraints.

Mrs. M. P. Patil (DYP POLY, KOP) Page 15

 SEN-22413-Unit 2-Software Requirement Engineering

4. Negotiation: - This phase will involve the negotiation between what user actual expects from
the system and what is actual feasible for the developer to build. Often it is seen that user
always expect lot of things from the system for lesser cost. But based on the other aspect and
feasibility of a system the customer and developer can negotiate on the few key aspect of the
system and then they can proceed towards the implementation of a system
5. Specification: - A specification can be a re-written document, a set of graphical models, a
formal mathematical model, a collection of usage scenario, a prototype, or any combinations
of these.
The specification is the final work product produced by the requirement engineers. It serves
as the foundation for subsequent software engineering activities. It describes the function
and performance of a computer based system and the constraints that will govern its
development.
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 unambiguously; 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.

7. Requirements management: - Requirement management begins with identification. Each

requirement is assigned a unique identifier. Once requirement have been identified,
traceability tables are developed.

Q11: What is SRS? Explain importance of SRS.

Ans: A software requirements specification (SRS) is a complete description of the behavior of
the system to be developed. It includes a set of use cases describe all of the interactions
that the users will have with the software. In addition to use cases, the SRS contains
functional requirements and nonfunctional requirements. Functional requirements
define the internal workings of the software: that is, the calculations, technical details,
data manipulation and processing, and other specific functionality that shows how the
use cases are to be satisfied. Non-functional requirements impose constraints on the
design or implementation (such as performance requirements, quality standards, or
design constraints).
The purpose of SRS document is providing a detailed overview of software product, its
parameters and goals. SRS document describes the project's target audience and its user
interface, hardware and software requirements. It defines how client, team and audience
see the product and its functionality.
The importance of standard template for SRS documents:
Establish the basis for agreement between the customers and the suppliers on what the
software product is to do. The complete description of the functions to be performed by
the software specified in the SRS will assist the potential users to determine if the
software specified meets their needs or how the software must be modified to meet their
needs. Reduce the development effort. The preparation of the SRS forces the various
concerned groups in the customer's organization to consider rigorously all of the

Mrs. M. P. Patil (DYP POLY, KOP) Page 16

 SEN-22413-Unit 2-Software Requirement Engineering

requirements before design begins and reduces later redesign, recoding, and retesting.
Careful review of the requirements in the SRS can reveal omissions, misunderstandings,
and inconsistencies early ip the development cycle when these problems are easier to
correct.
Provide a basis for estimating costs and schedules. The description of the product to be
developed as given in the SRS is a realistic basis for estimating project costs and can be
used to obtain approval for bids or price estimates. .
Provide a baseline for validation and verification. Organizations can develop their
validation and Verification plans much more productively from a good SRS. As a part
of the development contract, the SRS provides a baseline against which compliance can
be measured.
Facilitate transfer. The SRS makes it easier to transfer the software product to new users
or new machines. Customers thus find it easier to transfer the software to other parts of
their organization, and suppliers find it easier to transfer it to new customers.
Serve as a basis for enhancement. Because the-SRS discusses the product but not the
project that developed it, the SRS serves as a basis for later enhancement of the finished
product. The SRS may need to be altered, but it does provide a foundation for continued
production evaluation.
OR
A Software requirements specification (SRS), a requirements specification for a software
system, is a description of the behavior of a system to be developed and may include a set of
use cases that describe interactions the users will have with the software. In addition it also
contains non- functional requirements. Non-functional requirements impose constraints on the
design or implementation (such as performance engineering requirements, quality standards,
or design constraints).
Software requirements specification establishes the basis for agreement between customers
and contractors or suppliers (in market-driven projects, these roles may be played by the
marketing and development divisions) on what the software product is to do as well as what it
is not expected to do. Software requirements specification permits a rigorous assessment of
requirements before design can begin and reduces later redesign. It should also provide a
realistic basis for estimating product costs, risks, and schedules.
The software requirements specification document enlists enough and necessary requirements
that are required for the project development. To derive the requirements we need to have
clear and thorough understanding of the products to be developed or being developed. This is
achieved and refined with detailed and continuous communications with the project team and
customer till the completion of the software.
OR
The importance of SRS documents are:
Establish the basis for agreement: SRS helps in establishing agreement between the
customers and the suppliers on what the software product is to do. The complete description of
the functions to be performed by the software specified in the SRS will assist the potential
users to determine if the software specified meets their needs or how the software must be
modified to meet their needs. Reduce the development effort. The preparation of the SRS
forces the various concerned groups in the customer's organization to consider rigorously all of
the requirements before design begins and reduces later redesign, recoding, and retesting.
Mrs. M. P. Patil (DYP POLY, KOP) Page 17
 SEN-22413-Unit 2-Software Requirement Engineering

Careful review of the requirements in the SRS can reveal omissions, misunderstandings, and
inconsistencies early ip the development cycle when these problems are easier to correct.
Provide a basis for estimating costs and schedules. The description of the product to be
developed as given in the SRS is a realistic basis for estimating project costs and can be used to
obtain approval for bids or price estimates. .
Provide a baseline for validation and verification. Organizations can develop their
validation and Verification plans much more productively from a good SRS. As a part of the
development contract, the SRS provides a baseline against which compliance can be measured.
Facilitate transfer. The SRS makes it easier to transfer the software product to new users or
new machines. Customers thus find it easier to transfer the software to other parts of their
organization, and suppliers find it easier to transfer it to new customers.
Serve as a basis for enhancement. Because the-SRS discusses the product but not the project
that developed it, the SRS serves as a basis for later enhancement of the finished product. The
SRS may need to be altered, but it does provide a foundation for continued production
evaluation.

Q12. Explain general format of Software Requirement Specification (SRS).

Ans: Software requirements specification (SRS) is a document that is created when a detailed
description of all aspects of the software to be built must be specified before the project is to
commence. It is important to note that a formal SRS is not always written. In fact, there are
many instances in which effort expended on an SRS might be better spent in other software
engineering activities. However, when software is to be developed by a third party, when a
lack of specification would create severe business issues, or when a system is extremely
complex or business critical, an SRS may be justified. Karl Wiegers has developed a
worthwhile template that can serve as a guideline for those who must create a complete SRS.
A topic outline follows:
1. Introduction
1.1 Purpose
1.2. Document Conventions
1.3. Intended Audience and Reading Suggestions
1.4. Project Scope
1.5. References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. System Features
3.1 System Feature1
3.2 System Feature 2 (and soon)

Mrs. M. P. Patil (DYP POLY, KOP) Page 18

 SEN-22413-Unit 2-Software Requirement Engineering

4. External Interface Requirements

4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Nonfunctional Requirements
5.1. Performance Requirements
5.2. Safety Requirements
5.3. Security Requirements
5.4. Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis models
Appendix C: Issues List

Chapter 04: Software Requirement Engineering (Review Questions)

1. What are the core principles of software engineering? Explain. OR Enlist core principles of
software engineering practice.
2. State and describe principles of communication practices.
3. Describe in detail principles of good planning. OR Explain principles of planning practices
in software engineering.
4. What are the modeling practices in software engineering? Explain their principles.
5. Describe principles of analysis modelling.
6. Describe principles of design modelling.
7. Briefly describe the principles of coding
8. Describe principles of testing.
9. Describe the principles of deployment. OR What is Software deployment? State the
principles to be followed while preparing to deliver the software increment.
10. What is requirement engg. ? What is its need? What are different subtasks included in it?
11. What is SRS? Explain importance of SRS.
12. Explain general format of Software Requirement Specification (SRS).

Mrs. M. P. Patil (DYP POLY, KOP) Page 19