Unit : 2

Software Requirement Engineering

Marks = 16
 2.1 Software Engineering Practices - Definition,
Importance, Essence
• Definition :- “Practice” is collection of concept, principles, methods
and tools those are consider while planning & developing software.

• Importance of practices:-
• Software engineering practices play very important role in
development of software product.
• The most important thing is that customer satisfaction, Software
engineering practices helps in achieving expected goals.
• These practices help in delivering best product & sustain in market
long time.
• Practices help at every stage of the development.
• It is also provide guidelines related to maintenance.
 Essence of practice:
• 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?

• 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 sub problems be defined and are solutions available for the
• Sub problems?
• 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?
• 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?
 2.2 Core Principles of Software Engineering

• 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 then Act.
• 1. 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.

2. 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.
• 3. 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.
• 4. What You Produce, Others Will Consume
• 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. Making their job
easier adds value to the system.
• 5. 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.
• 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.

6. 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. Planning ahead for
reuse reduces the cost and increases the value of
both the reusable components and the systems into
which they are incorporated.
• 7. Think then Act
• 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.
Applying the first six Principles requires intense
thought, for which the potential rewards are
enormous.
 Communication Practices
1. Listen Carefully
2.Prepare before you communicate
3. Someone should facilitate the activity.
4. Face-to-face communication is best.
5. Take notes and document decisions.
6. Strive for collaboration.
7. Stay focused, modularize your discussion.
8. If something is unclear, draw a picture.
9.move on
10. Negotiation is Successful when both parties agree.
 Principle 1. Listen Carefully.

• 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.
Principle 2. Prepare before you communicate.

• Spend the time to understand the Problem

before you meet with others.
• If necessary, do 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.

• Face to face communication is always makes

sense.

• It usually works better when some other

representation of the relevant information is
present.
 Principle 5. Take notes and document decisions.

• Things have a way of falling into the cracks.

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 serves to build 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 conversations

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.

• Communication, like any software engineering

activity, takes time. Rather than iterating endlessly,
the people who participate should recognize that
many topics require discussion and that “moving
on” is sometimes the best way to achieve
communication agility.
 Principle 10. Negotiation is Successful when both
parties agree.

• 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.
 2.4 Planning Practices
1. Understand the scope of the project.
2. Involve stakeholders in the planning activity.
3. Recognize that planning is iterative.
4. Estimate based on what you know.
5. Consider risk as you define the plan.
6. Be realistic.
7. Adjust granularity as you define the plan.
8. Define how you intend to ensure quality.
9. Describe how you intend to accommodate change.
10.Track the plan frequently and make adjustments as
required.
• 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.
• 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
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 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, 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 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.
 Modeling Practices
• Models are useful for better understanding of actual entity to be
built or design.
• There are two classes of models are created:-
• 1) Analysis model
• 2) Design model
• Analysis Model: – Represent the customer requirement, which
includes algorithmic specifications of program or process.
Analysis model includes three different domains
• a) Information domain
• b) Functional domain
• c) Behavioral domain
• Analysis Modeling principles:- 
• 1)      The information domain of problem must be
clearly represented: – Analysis model uses “data
flow diagram “to show information domain which
includes following detail input flow into system,
output flow in system, data collection by data store
to collect data in system.

• 2)The function of software must be defined

clearly:-function are process those transform input
flow to output flow so specification must be
clearly defined.
3)Behavior of system must be defined clearly:-
Analysis model uses state transition diagram to
represent the behavior of system clearly.

4) The clear hierarchy among information function

and behavior must be shown: – information, function
and behavior of system must be represented by using
proper hierarchy which leads to easy design.

5)Analysis should be clear enough to convert it into

design model: – it analysis of requirement is clear and
simple then it will be easy for design.
 Design Modeling Principles
• 1. Design must be traceable to analysis Model
analysis model describe the information
domain of the problem, User visible functions,
System behavior, and the set of analysis classes
that package business object with the methods
that service them
The design model translate this information Into an
Architecture: A set of subsystems that implement
major function and set of component level design
• 2.Always consider architecture
S/W architecture is the skeleton of the To be
built. Only after the architecture is built the
component level issue should be considered

• 3. Focus on the design of data It is as

important as a Design
Data design is an essential element of the
architectural design
• 4. Interfaces (both user and internal) must be
designed
Well designed interfaces makes integration easier
And assist the tester in validating component
functions.

• 5. User interface design should be tuned to the

needs of the end user
“ Ease of use”
• 6. Component level design should be exhibit
functional independence.
The functionality that is delivered by a
component should be cohesive: It should focus
on one and only one function.

• 7. Components should be loosely coupled to

one another and to the external environment.
Complaints should be kept as low as possible.
As the level of coupling increases, error
Propagation also increases and the overall
maintainability of the software decreases
• 8. Design representation (models) should be
easily understood
The design models should be developed
iteratively with each situation of the designer
should strive for greater simplicity
 Construction Practices

 Construction activity included coding &

testing activity
1.Coding :
 Coding activity is related to programming
language.
 Design details are implemented using
appropriate programming language.
 It include Preparation, Actual coding,
Validation phases.
 1.Preparation principle
 These are the principles are followed before
starting the coding
A. Understand the exact problem to which you are
trying.
B. Understand the basic design principles.
C. Select appropriate programming language.
D. Select the programming environment that will be
suitable for writing the code
E. Create set of unittests that will be applied once
the component you code is completed
 2.Actual coding principles
 These are the principles to be followed while
writing the coding

A. Use suitable data structures those are fit for

coding.
B. Keep minimum nested condition
C. Keep minimum nested loop.
D. The variable names should be meaningful &
as per standards.

E. Code must be self-documented, i.e. provide

help comments for all the steps.
 3.Validation principles

 These are the principles to be followed after complimenting

the first coding pass

A. Conduct the unit test. Test whether the module is producing

exact output.

B. Refactor the code if necessary.

( program reorganizing its internal structure without altering
its external behavior ).

C. Conduct a code walkthrough when appropriate.

 2. Testing
 Testing is carried out for the purpose

A. To check whether the flow of coding is

correct.
B. To check out the errors of the program
C. To check whether the program is giving the
expected output as per input specification.
 PRINCIPLES
• 1.Test must be conducted to validate customer’s
requirement.

 The basic aim of testing is to find the defects from

the developed modules.
 These defects are considered from customer’s point
of view. I.e. what customer wants exactly as output?
 Hence testing must validate customer’s
requirements.
2.Tests should be well planed before starting
testing work

 Testing plan can be started as soon as analysis

module is completed.
 Detailed definition of test case can be started
as soon as design module reaches to final
stage.
 Hence all the test can planed before starting
actual coding.
 3.Testing should begin “in the small” and
progress towards testing “in the large”

 Testing should start from individual units and

finally go towards testing of complete system
as whole.
 Software is always divided in to small size and
independent components called as modules.
 As modules are small in size they are easy to
understand, easy to test, easy to debug and
easy to modify.
 These modules are called as units. Hence
software testing always starts from unit
testing.
 These units are then integrated i.e. combined
as per design specification.
 And finally system is tested as a whole.
 4. Accept that “testing of every combination
of paths is not possible”

• Each software modules as unit contains to many

conditions and nested conditions.

• Hence it is not possible to check out coming results

satisfying every combination of inputs.

• E.g. it is not possible to check every if- else

combination of systems.
 Software Deployment

• The software is delivered to the customers who evaluates the delivered

product and provides feedback based on the evaluation.

• 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.
 Principle of Software Deployment
• 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.
• 2. Assembled 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.
• 3.Record-keeping mechanism must be established for customer
support.
• Customer support is important factor in deployment phase. If proper
support is not provided, customer will not be satisfied. Hence support
should be well planned and with record-keeping mechanism.
• 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.

• 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.
Types of requirements
• Functional Requirements:
• These are the requirements that the end user specifically
demands as basic facilities that the system should offer.
• All these functionalities need to be necessarily
incorporated into the system as a part of the contract.
These are represented or stated in the form of input to
be given to the system, the operation performed and the
output expected. They are basically the requirements
stated by the user which one can see directly in the final
product, unlike the non-functional requirements.
• For example, in a hospital management system, a doctor
should be able to retrieve the information of his
patients.
• Non-functional requirements: These are basically the
quality constraints that the system must satisfy according
to the project contract. The priority or extent to which
these factors are implemented varies from one project to
other.
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
• Domain requirements:
• Domain requirements are the requirements which are
characteristic of a particular category or domain of
projects.
• The basic functions that a system of a specific domain
must necessarily exhibit come under this category.
• For instance, in an academic software that maintains
records of a school or college, the functionality of
being able to access the list of faculty and list of
students of each grade is a domain requirement.
• These requirements are therefore identified from that
domain model and are not user specific.
 2.8 Requirements Engineering
Requirements Engineering uses following 7
functions for Requirement gathering
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements management
• 1. Inception: -

• Inception means beginning. It is usually said that well

beginning is half done.

• Requirement engineering is a communication intensive

activity. The customer and developer meet and they Will
decode 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.
• 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.
 Software Requirements Specification (SRS)

• A software requirements specification (SRS) is a document that

captures complete description about how the system is expected to
perform.

• It is usually signed off at the end of requirements engineering

phase.

• A software requirements specification (SRS) is a detailed

description of a software system to be developed with its functional
and non-functional requirements. The SRS is developed based the
agreement between customer and contractors. It may include the
use cases of how user is going to interact with software system.
 Need of SRS
•  A software requirements specification is the basis
for your entire project.

• It lays the framework that every team involved in

development will follow.

• It's used to provide critical information to

multiple teams development, quality assurance,
operations, and maintenance
 Characteristics of an SRS 
• Characteristics of an SRS Software requirements
specification should be
• Unambiguous
• Accurate
• Complete
• Efficient

• An SRS is said to be of high quality when the developer

and user easily understand the prepared document.