UNIT-2

Software Requirements Engineering

Time: 10 hrs Marks: 14

2.1 Software Engineering Practices and its Importance,

core principal

1. Software Engineering Practices Definition:

 Software engineering is a systematic process of

developing software.
 Practice is a collection of concepts, Principles, methods
and tools these are considered while planning and
developing the software.

Importance:

The Software Engineering Code of Ethics focuses on

providing high-quality software. They are committed to
analyzing, specifying, designing, developing, testing, and
maintaining software that is beneficial and effective for the
company or client.
# Core Principles of Software Engineering (Statements
& Meaning of each Principle)

There are Seven Core Principles for Software Engineering

1) Remember the reason that the software exists

• The software should provide value to its users and satisfy
the requirements
2) Keep it simple, stupid (KISS)
• All design and implementation should be as simple as
possible
3) Maintain the vision of the project
• A clear vision is essential to the project’s success
4) Others will consume what you produce
• Always specify, design, and implement knowing that
someone else will later have to understand and modify
what you did
5) Be open to the future
• Never design yourself into a corner, build software that
can be easily changed and adapted
6) Plan ahead for software reuse
• Reuse of software reduces the long-term cost and
increases the value of the program and the reusable
components
7) Think and then act
• Placing clear, complete thought before action will almost
always produce better results

2.2 Five Practices of Software Engineering

1. Communication practices
2. Planning practices
3. Modeling practices
(Analysis modeling and Design modeling)
4. Construction practices
5. Deployment practices

1. Communication Practice:
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
customer’s 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.

Communication Principles
Principle #1: Listen.
Listen to the speaker and concentrate on what is being
said
Principle #2: Prepare before you communicate.
Prepare before you meet by researching and understanding
the problem

Principle #3: Someone should facilitate the activity.

Someone should facility the meeting and have an agenda

Principle #4: Face–to-face communication is best.

Face-to-face communication is best, but also has a
document or presentation to focus the discussion
Principle #5: Take notes and documentation decisions:
Things have a way of falling into the cracks. Someone
participating in the communication should serves to build
trust among team members and creates a common goal for
the team.
Principle #6: Stay focused, modularize your discussion.
The more the 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 to the next. The facilitator
should keep the conversation modular, leaving one topic
only after it has been resolved.
Principle #7: 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 #8: (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 #9: Negotiation is not a contest or a game. It

works best when both parties win.
There are many instances in which the software
engineer and the customer must negotiate functions and
features, priorities, and delivery dates. If the team has
collaborated well, all parties have a common goal.
Therefore, negotiation will demand compromise from all
parties.
 2. Planning Practices (Defining a Road Map)

Planning Principles

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.

Principle #2: Involve the customer in planning

activity.
The customer defines priorities and establishes the project
constraints.

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 and incremental
process models dictate re-planning based on feedback
received from user.

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.
Principle #5: Consider risk as you define the plan.
If the team has defined risks that have high impact and
high probability, contingency planning is necessary.

Principle #6: Be realistic. People don’t work 100

percent every day.
Noise always enters into any human communication.
Omission 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 “fine granularity” plan
provides significant work detail that is planned over
relatively short time increments.

Principle #8: Define how you intend to ensure quality.

The plan should identify how the software team intends to
ensure quality. If formal technical reviews are to be
conducted, they should be scheduled.
Principle #9: Describe how you intend to accommodate
change.
Even the best planning can be obviated by uncontrolled
change. The software team should identify how changes
are to be accommodated as software engineering work
proceeds.

Principle #10: Track the plan frequently and make

adjustments are required.
Software project falls behind schedule one day at a time.
Therefore, it makes sense to track progress on a daily
basis, looking for a problem areas and situation in which
scheduled work does not confirm to actual work
conducted. When slippage is encountered, the plan is
adjusted accordingly.

3. Modeling Practices (Analysis and Design)

The models are created to gain better understanding of

actual entity to be built. When the entity is a physical
thing, we can build a model that is identical in form of
shape but smaller in scale. However, when the entity 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’s desire,
and the behavior of the system as the transformation is
taking place.

Two classes of models are crated: Analysis models and

design models. Analysis models represent the customer
requirements by dividing the software in three different
domains: the information domain, the functional domain,
and the behavioral domain. Design models represent
characteristics of the software that help practitioners to
construct it effectively.

 Analysis Modeling Principles

A large number of analysis modeling methods have been
developed. Each analysis methods has unique point of
view. However, all analysis methods are related by a set of
operational principles.
Principle #1: The information domain of a problem
must be represented and understood.
The information domain compasses the data that flow into
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 direct benefit to visible end-
user. 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.

Principle #3: The behavior of the software 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 fashion.
Analysis modeling is the first step in software engineering
problem solving. It allows the practitioner to understand
the problem better and establishes a basis for the solution
(design). Complex problems are difficult to solve in their
entirety. For this reason, we 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, and it is a
key strategy in analysis modeling.

Principle #5: The analysis task should move from

essential information toward implementation detail.
Analysis modeling begins by describing the problem from
the end-user’s perspective. The “essence” of a problem is
described without any consideration of how a solution will
be implemented.

 Design Modeling Practices

The design model created for software provides a variety of
different views of system. There is no shortage of methods
for deriving various elements of a software design. Some
methods are data-driven, allowing the data structure to
dictate the program architecture and the resultant
processing component. Others are pattern-driven, using
information about the problem domain (the analysis
model) to develop architectural styles and processing
patterns- a set of design principles that can be applied
regardless of the method that is used.
  Design Modeling Practices

Principle #1: Design should be traceable to the analysis

model.
The analysis model describes the information domain of
the problem, uses visible functions, system behavior, and
a set of analysis classes that package business objects
with the methods that service them. The design model
translates this information into architecture, a set of
subsystems that implement major functions, and a set of
component- level designs that realize analysis classes.

Principle #2: Always consider the architecture of the

system to be built.
Software architecture is the skeleton of the system to be
built. It affects interfaces, data structures, program control
flow behavior, the manner in which testing can be
conducted and the maintainability of resultant system.

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 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 flow between the components of
a system has much to do with processing efficiency, error
propagation, and design simplicity, A well designed
interface integration easier and assists the tester in
validating components functions.

Principle #5: User interface design should be tuned the

needs of the end-user.
However, in every case, it should be stress free and easy to
use. The user interface is the visible manifestation of the
software. A poor interface design often leads to the
perception that the software is “bad”.

Principle #6: Components should be functionally

independent.
Functional independence is a measure of the “single-
mindedness” of a software component. The functionally
that is delivered by a component should be cohesive- that
is, it should focus on one and only on 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 component inter-
face, by messaging and 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 reasonably possible.

Principle #8: Design representation (model) 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 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 most of the creative activities, design
occurs iteratively. The first iteration works to refine the
design and correct errors, but later iterations should strive
to make the design as simple as is possible.

4. Construction Practices (Coding and Testing):

Coding Principles (Preparation before coding)

1) Understand the problem you are trying to solve
2) Understand basic design principles and concepts
3) Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate
4) Select a programming environment that provides tools
that will make your work easier
5) Create a set of unit tests that will be applied once the
component you code is completed

Coding Principles (As you begin coding)

1) Constrain your algorithms by following structured
programming practices
2) Select data structures that will meet the needs of the
design
3) Understand the software architecture and create
interfaces that are consistent with it
4) Keep conditional logic as simple as possible
5) Create nested loops in a way that makes them easily
testable
6) Select meaningful variable names and follow other local
coding standards
7) Write code that is self-documenting 8) Create a visual
layout (e.g., indentation and blank lines) that aids code
understanding

Coding Principles (After completing the first round of

code)
1) Conduct a code walkthrough
2) Perform unit tests (black-box and white-box) and correct
errors you have uncovered
3) Refactor the code

Testing Concept
• Testing in a process of executing with the intent of finding
an error.
• A good test case is one that has a high probability of
finding as as-yet undiscovered error.
• A successful test is one that uncovers an as- yet –
undiscovered error.
Testing Principles

Principle #1: All tests should be traceable to customer

requirements.
The objective of software testing is to uncover errors. It
follows that the most server defects (from the customer’s
point of view) are those that cause the program to fail to
meet its requirements/goals.

Principle #2: Tests should be planned long before

testing begins.
Test planning can begin as soon as the analysis 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.
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.
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 error 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.

5. Deployment Practices
The deployment activity encompasses three actions
delivery, support, and feedback. Because modern software
process models are evolutionary in nature, deployment
happens not once, but a number of times as software move
towards completion. Each delivery cycle provides the
customer and end-users with an operational software
increment that provides usable functions and features.
Deployment Principles

Principle #1: Customer expectations for the software

must be managed.
The customer expects more than the team has promised to
deliver and disappointment occurs immediately. This
results in feedback that is not productive and which ruins
team morale.

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 document, and other
relevant information must be assembled and thoroughly
beta- tested with actual users.

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. Support
should be planned, support material should be prepared,
and appropriate record keeping mechanism should be
established so that the software team can conduct a
categorical assessment of the kinds of support requested
required.

Principle # 4: Appropriate instructional materials must

be provided to end-users.
The software team delivers more than the software itself.
Appropriate training aids should be developed, trouble-
shooting guidelines should be provided and a “what’s-
different about- this-software-increment” description
should be published.

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”. This is a
mistake. There’s a saying in the software business:
“Customer will forget you delivered a high- quality product
a few days late, but they will never the problems that a
low-quality product caused them. The software reminds
them everyday.”