1

Chapter 2
Software engineering practices And Software requirements Engineering

⚫ Software engineering practice is a collection of concepts, principals,

methods and tools that a software engineer calls upon on daily basis.
⚫ Practice allows managers to manage software projects and software
engineers to build computer programs.

01. Essence of practice-

1.Understand the problem (communication and analysis)
2. Plan a solution (modelling and software design)
3.Carry out the plan (code generation)
4.Examine the result for accuracy (testing and quality assurance)

02. Understand the problem-

• Who are the stakeholder?
• What data, functions, features and behaviour are required to properly solve the
problem?
• Is it possible to represent smaller problems that may be easier to understand?
• Can the problem be represented graphically?
03. Plan a solution-
• Have you seen similar problems before?
• Has a similar problem been solved?
• Can sub-problems be defined?
• Can you represent a solution in a manner that leads to effective
implementation?
• Can a design model be created?
04. Carry out the plan-
• Does the solution conform to the plan?
• Is each component part of the solution provably correct?
• Has the design and code been reviewed?
05. Examine the result-
• Is it possible to test each component part of the solution?
• Has a reasonable testing strategy been implemented?
• Has the software been validated against all stakeholder requirements?
06. Core principles of Software Engineering-
1. The Reason It All Exists.
2. Keep It Simple, Stupid!
3. Maintain The Vision.

Downloaded By: www.ravibaba18.blogspot.com

 2

4. What you produce-others will Consume.

5. Be Open to The Future.
6. Plan Ahead for Reuse
7. Think!
07. The First Principle: The Reason It All Exists-
• The software exists for one reason: to provide value to its users.
• Before specifying system requirement, functionality, hardware platform,
development process ask question such as: “Dose this add real value to the
system?”
• If answer is no, don't do it.
08. The Second Principle: Keep It Simple, Stupid-
• All design should be as simple as possible, but no simpler.
• This facilitates having a more easily understood and easily maintained system.
• Simple does not mean that features should be discarded in the name of
simplicity.
• Indeed, the more elegant designs are usually the more simple ones.
09. The Third Principle: Maintain The Vision-
• A Clear vision is essential to the success of a software project.
• Compromising the architectural vision of a software system weakens and will
eventually break even a well designed system.
• Having an empowered architect who can hold the vision and enforce
compliance helps ensure a very successful software project.
10. The Fourth Principle: What you produce ,Others will
Consume-
• Always specify design and implement knowing someone else will have to
understand what you are doing.
• 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.
11. The Fifth Principle: Be open to the Future-
• A system with a long lifetime has more value.
• Software lifetimes are typically measured in months instead of years.
• System should be ready to adapt changes.
• System that adapt changes have been designed this way from start.
• Never design yourself to a corner.
• Always keep asking “what if?” and prepare for all possible answers.
12. 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.

Downloaded By: www.ravibaba18.blogspot.com

 3

13. The Seventh Principle: Think-

• Placing clear, complete thought before action almost always produces better
results.
• When you think about something, you are more likely to do it right.
• You also gain knowledge about how to do it right again.
• When clear thoughts has gone into system, value comes out.
14. Communication Practices-
• Before customer requirements can be analyzed, modeled, or specified they
must be gathered through a communication activity.
• Effective communication is among the most challenging activities that confront
a software engineer.
15. Principles-
01. Principle #1: Listen. Try to focus on speakers words. If something is unclear, ask for
clarification.
02. Principle #2: Prepare before you communicate. Spend some time to understand the
problem before you meet with others. If you have responsibilities for conducting a
meeting, prepare an agenda in advance of the meeting.
03. Principle #3: Someone should facilitate the activity. Every communication meeting
should have a leader to keep conversation moving in a productive direction
04. Principle #4: Face to face communication is best. Works better when some other
representation of the relevant information is present. For example, a participant
may create a drawing.
05. Principle #5: Take notes and document decisions. Someone participating in the
communication should serve as a “recorder”.
06. Principle #6: Strive for collaboration. trust among team members and creates a
common goal for the team.
07. Principle #7: Stay focused, modularize your discussion. discussion will bounce from
one topic to the next Principles.
08. Principle #8: Draw a picture to clear your idea: A sketch or drawing can often
provide clarity when words fail to do the job.
09. Principle #9: Keep the discussion to “ move on ” 1. once there is an agreement to do
something . 2. If you cannot agree to something. 3. If a feature of function is not
clear. Principle #10:Negotiation is successful when both parties win.
16. Planning practices-
• Good planning leads to successful result.
• The planning activity encompasses a set of management and technical practices
that enable the software team to define a road map as it travels towards its
strategic goal and tactical objectives.
• Planning includes complete cost estimation, resources, scheduling and also risk
analysis.

01. Principle 1: Understand the scope of the project-

It’s impossible to use a road map if you don't know where you are going. Scope provides
the software team with destination.

Downloaded By: www.ravibaba18.blogspot.com

 4

02. Principle 2: Involve the customer in the planning activity.-

The customer defines priorities and establishes project constraints. To accommodate
these realities software engineers must often negotiate order of delivery, time lines and
other project related issues.
03. Principle 3: Recognize that planning is iterative.
04. Principle 4: Estimate based on what you know
05. Principle 5: Consider risk as you define the plan
06. Principle 6: Be realistic.
07. Principle 7: Adjust granularity as you define the plan.
08. Principle 8: Define how you intend to ensure Quality.
09. Principle 9: Describe how you intend to accommodate change.
10. Principle 10: Track the plan frequently and make adjustment as required.
17. Modelling Practice-
• Models are created for better understanding of the actual entity to be built or
design.
• When the entity is a physical thing, we can build model that is identical in form
and shape but smaller in scale.
• When entity is software our model must take different form. It must be
capable of representing information, Architecture, functions ,features and
behaviour of the system.

In SE work, two classes of model is created.

1. Analysis Model.
2. Design Model.
I. Principle 1: The information domain of problem must be clearly represented.
Information domain encompasses the data that flow into the system(from end user,
external devices),data that flow out of the system(via user interface, n/w interface,
graphics), data stores collection of objects(data i.e. maintained permanently).
ii. Principle 2: The function of the software must be defined clearly. Functions are the
processes those transform the I/p flow to the o/p flow. The process specification for
example algorithms provides function details. The specification must be clearly defined.
iii. Principle 3: The Behavior of the software must be defined clearly.  Analysis model
uses state transition diagrams to represent the behavior of the system clearly. It shows
how the system makes transition from one state to another on occurrence of some
external event
iv. Principle 4: The clear hierarchy among information, functions and behavior must be
shown. The proper hierarchy of analysis model leads to easy design. Hence information,
functions and behaviour of the system must be represented using proper hierarchy i.e.
levels or layers.
v. Principle 5: analysis should be clear enough to convert it into design model.  If
analysis of requirements is clear and simple then it will be easy for design and
implementation in construction step. Hence requirement analysis should be clear
enough.

Downloaded By: www.ravibaba18.blogspot.com

 5

18. Design modelling-

01. Principle 1: Design should be traceable from analysis model.
02. Principle 2: Consider the architecture of the system to be built.
03. Principle 3: Design of data is as important as design of function.
04. Principle 4: Internal as well as external interfaces must be designed.
05. Principle 5: user interface design must satisfy all need of end user.
06. Principle 6: Component level design should be functionally independent.

Downloaded By: www.ravibaba18.blogspot.com

 6

07. Principle 7: Components should be loosely coupled to one another and to the
external environment.
08. Principle 8: designed modules should be easy to understand.
09. Principle 9: Accept that design behaviour is Iterative.

19. Construction Practices-

▪ 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 initial focus of testing is at the component level, often called unit testing.
Other levels of testing include integration testing, validation testing and
acceptance testing.
20. Coding Principles & Concepts-
Preparation Principles: Before you write one line of code, be sure you,
1.Understand the problem you're trying to solve.
2.Understand basic design principles & concepts.
3.Pick a programming language that meets the needs of the software to be built & the
environment in which it will operate.
4.Select a programming environment that provides tools that will make you 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 writing code, be sure you: 1. Constrain your
algorithms by following structured programming practice.
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 that aids
understanding.
21. Validating principles-
After you've completed your first coding pass, be sure you:
1.Conduct a code walk through when appropriate. 2.Perform unit tests and correct
errors you've uncovered. 3.Re-factor the code.
22. Testing principles-
Testing rules or objectives:
• Testing is a process of executing a program with the intent of finding an error.
• A good test is one that has a high probability of finding an as yet undiscovered error.
• A successful test is one that uncovers an as yet undiscovered error.
Principle #1: All tests should be traceable to customer requirements.
Principle #2: Tests should be planned long before testing begins.
Principle #3: The Pareto principle applies to software testing.
Principle #4: Testing should begin “in the small” and progress toward testing “in the
large”.
Principle #5: Exhaustive testing is not possible.

Downloaded By: www.ravibaba18.blogspot.com

 7

23. Deployment-
01. The deployment activity encompasses 3 actions: delivery, support and feedback. 
02. Modern software process models are evolutionary in nature, deployment happens not
once, but a number of times as software moves towards completion. 
03. Each delivery cycle provides the customer and end users with an operational software
increment that provides usable functions and features.
04. Each support cycle provides documentation & human assistance for all functions and
features introduced during all deployment cycles to date.
05. Each feedback cycle provides the software team with important guidance that results in
modifications to the functions, features and approach taken for the next increment.
Principle #1: Customer expectations for the software must be managed.
Principle #2: A complete delivery package should be assembled and tested.
Principle #3: A support regime must be established before the software is delivered.
Principle #4: Appropriate instructional materials must be provided to end users.
Principle #5: Buggy software should be fixed first, delivered later.

24. Requirement Engineering-

▪ Requirements engineering, like all other software engineering activities, must be
adapted to the needs of the process, the project , the product, and the people
doing the work.
▪ Software process perspective, requirements engineering is a software
engineering action that begins during the communication activity and continues
into the modelling activity.
25. The requirements engineering process is accomplished
through the execution of seven distinct functions:
1.Inception

2.Elicitation

3.Elaboration

4.Negotiation

5.Specification

6.Validation

7.Management Incept

01. Inception:
▪ Inception-Starting point, beginning.
▪ At project inception, software engineers ask a set of context free question.
▪ The intent is to establish a basic understanding of the problem
▪ The people who want a solution,
▪ The nature of the solution that is desired and  effectiveness of preliminary
communication and collaboration between the customers and the
developer.

Downloaded By: www.ravibaba18.blogspot.com

 8

02. Elicitation:
▪ Collecting intelligence information
▪ Ask the customer, the user and others
▪ what is objectives for the system?
▪ What is to be accomplished?
▪ How the system fits into the needs of the business?
▪ How the system or product is to be used on a day to day basis?
▪ Christel and Kang identified a number of problems that help us understand
why requirements elicitation is difficult
▪ 1. Problem of scope.
▪ 2. Problem of understanding
▪ 3. Problem of volatility
03. Elaboration:
▪ It means to work out in detail.
▪ The information obtained from the customer during inception and
elicitation is expanded and refined in elaboration.
▪ S/w engineering- focuses on developing a refined technical model of
software functions, features and constraints. 
▪ It describes how the end user will interact with the system.
▪ The end result is an analysis model that defines the informational,
functional, behavioral domain of the problem.
04. Negotiation:
▪ The requirements engineer must reconcile conflicts through process of
negotiation.
▪ Customers, users & stakeholders are asked to rank requirements and
discuss conflicts in priority.
▪ Risks associated with each requirements are identified and analyzed.
▪ Rough “guesstimates” of development effort are made and used to assess
the impact of each requirement on project cost and delivery time.
▪ Using an iterative approach, requirements are eliminated, combined, and
/or modified so that each party achieves some measure of satisfaction.
05. Specification: “Standard template” should be developed and used for a
specification, arguing that this leads to requirements that are presented in a
consistent and therefore more understandable manner. The specification is a final
work product produced by the requirements engineer. It serves as the foundation
for subsequent software engineering activities.
06. 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. The review team that validates requirements includes
software engineers, customers, users and other stakeholders.
07. Requirements: Management Requirements management is a set of activities that
help the project team identify, control and track requirements and changes to
requirements at any time as the project proceeds. Requirement management begins
with identification. Each requirement is assigned a unique identifier. Once
requirements have been identified, traceability table are developed. Each
traceability relates requirements to one or more aspects of the system.

Downloaded By: www.ravibaba18.blogspot.com

 9

26. Software requirements specification (SRS)-

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

02. SRS format There is no single precise template for writing good Software
Requirement Specifications. The contents of an SRS document depends on the
software product being developed and also on the expertise of the people doing
the requirement elicitation. 1.Project scope section 2.Functional requirements
3.Requirement analysis models 4.External interface requirements 5.Non
functional requirements

03. The importance of SRS documents 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 to determine if the software specified meets their needs or how the
software must be modified to meet their needs. Reduce the development effort.
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.
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 theSRS
discusses the product but not the project that developed it, the SRS serves as a
basis for later enhancement of the finished product.

Downloaded By: www.ravibaba18.blogspot.com