UNIT-II

Fundamentals of Software Engineering Principles

There are many fundamentals of software engineering – so many that some will get
lost over time. Every software engineer has his or her own set of “fundamentals”
that they will pass on – fundamentals that even as technology changes, are still
appropriate for everyday building.

 Do not work for the future is one of the basic fundamentals of software
engineering. It is great to think ahead and plan for a future, but that is often
just a waste of time and resources. Focus on building reliable, effective code
that you can use in the present.
 You don’t want to repeat yourself. Code is reusable, which is why it has
been around for so long. One of the great parts about it is that if you have a
problem with the code somewhere and you fix it, you can repeat that fix
everywhere. If you try out a new piece of code in one place and it works
great, it doesn’t take long to move that code throughout your application.
The fundamentals of software engineering make it so that you can change
things quickly and easily without having to do too much extra work.
 Remember open source. One of the biggest time wasters in software
engineering is building code to do something that someone has probably
already written. This is something simple that is fundamental to the
operations of your application. There are so many open source options out
there. When you have tools that can check your code and keep your software
up to date, you will be able to use code from everywhere without having to
worry that it will cause a break somewhere.
 Think services. If you write code that does one thing really well, you have
succeeded. Do not try to do too much with your code or you will go against
the software engineering best practices – and have quite a mess on your
hands if it does ever break down. Remember that while complex code might
look better, readable code is always better. The member of your software
engineering team that wrote the code might not be there when you get an
 alert that something is going wrong, so you want to make everything self-
explanatory.

These fundamentals of software engineering aren’t in place to make things easier

for you in the present day, though they do that as well. They are in place so that
when you need to make changes somewhere down the line, you will have a team
that understands everything and can focus on them.

Software Engineering Practices and Software Modeling

Practices topics:

» Software Engineering Practice

» Core Principles

» Communication Practices

» Planning Practices

» Modeling Practice

» Construction Practice

Software Engineering Practice

In this part of “software engineering; a practitioner’s approach” you’ll learn about

the principles, concepts, and methods that comprise software engineering practice.
These questions are addressed in the chapters that follows:
• What concepts and principles guide software engineering practice?
• How does system engineering lead to effective engineering?
• What is requirements engineering, and what are the underlying concepts that lead
to good requirements analysis?
• How is thee analysis model created, and are its elements?
• What is design engineering, and what are the underlying concepts that lead to
good design?
• What concepts, models and methods are used to create architectural, interface,
and component level designs?
• What strategies are applicable to software testing?
• What methods are used to design effective test cases?
• What measures and metrics can be used to assess the quality of analysis and
design models, source code and test cases?

What is it? Practice is a broad array of concepts, principles, methods, and tools
that you must consider as software planned and developed. It represents the details-
the technical considerations and how to—that are below the surface of the software
process: the things that you’ll need to actually build high-quality computer
software.
Who does it? The practice of software engineering is applied by software
engineers and their managers.
Why is it important? The software process provides everyone involved in the
creation of a computer-based system or product with a road map for getting to a
destination successfully. Practice provides you with the detail you’ll need to drive
along the road. It tells you where the bridges, the roadblocks, and the forks are
located. It helps you understand the concepts and principles that must be
understood and followed to drive safely and rapidly. It instructs you on how to
drive, where to slow down, and where to speed up. In the context of software
engineering, practice is what you do day in and day out as software evolves from
an idea to a reality.
What are the steps? Three elements of practice apply regardless of the process
models that is chosen. They are: concepts, principles, and methods. A fourth
element of practice—tools—supports the application of methods.

Core Principles

The dictionary defines the word principle as “an important underlying law or
assumption required in a system of thought.” Here, principles at many different
levels of abstraction. Some focus on software engineering as a whole, others
consider a specific generic framework activity (e.g., customer communication),
and still others focus on software engineering actions (e.g., architectural design) or
technical tasks (e.g., write a usage scenario). Regardless of their level of focus,
principles help us establish a mind set for software engineering practice. They are
important for that reason.
David Hooker has proposed seven core principles that focus on software
engineering practice as a whole. They are reproduced below.

The First Principle: The Reason It All Exists

A software system exists for one reason: to 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)

Software design is not a haphazard process. There are many factors to consider in
any design effort. All design should be as simple as possible, but no simpler. This
facilities having a more easily understood, and easily maintained system. This is
not to say that features, even internal features, should be discarded in the name of
simplicity. Indeed, the more elegant designs are usually the simple ones. Simple
also does not mean “quick and dirty.” In fact, it often, it often takes a lot of thought
and works over multiple iterations to simplify. The pay-off is software that is more
maintainable and less error-prone.

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.
Without conceptual integrity, a system threatens to become a patchwork of
incompatible designs, held together by the wrong kind of screws…
Compromising the architectural vision of a software system weakens and will
eventually break even a well-designed the system. 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
Seldom 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 who 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 principles: 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 after just a few months, 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 on. Note: This advice can be
dangerous if it is taken to extremes. Designing for the “general problem”
sometimes requires performance compromises and can require more project effort.
This could very possibly lead to the reuse of an entire system.
The Sixth Principle: plan Ahead for Reuse
Reuse saves time and effort. Author’s not: Although this is true for those who
reuse the software on future projects, reuse can be expensive for those who must
design and build reusable components. Studies indicate that designing and building
reusable components can cost between 25to 200 percent more than targeted
software. In some cases, the cost difference cannot be justified. Achieving a high
level of reuse is arguably the hardest goal to accomplish in developing a software
system. The reuse of code and design 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 object-oriented [or conventional]
programming provides, requires forethought and planning. There are many
techniques to realize reuse at every level of the system 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 just part of the battle. Communicating opportunities for ruse 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.
The 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.
If every software engineer and every software team simply followed hooker’s
seven principles, many of the difficulties we experience in building complex
computer based systems would be eliminated.

Communication Practices

Before customer requirements can be analyzed, modeled, or specified they must be

gathered through a communication (also called requirements elicitation) activity. A
customer has a problem that may be amenable to a computer- based solution. A
developer responds to the customer’s request for help. Communication has begun.
But the road from communication to understanding is often full of potholes.
Effective communication (among technical peers, with the customer and other
stakeholders, and with project managers) is among the most challenging activities
that confront software engineer. Here, we discuss communication principles that
apply equally to all forms of communication that occur within a software project.
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 contentions 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, do some research to understand business domain jargon. 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 (facilitator)
(1) to keep the conversation moving in a productive direction
(2) to mediate any conflict that does occur
(3) to ensure that other principles are followed
Principle #4: Face–to-face communication is best.
But it usually works better when some other representation of the relevant
information is present. For example, a participant may create a drawing or a
“strawman” document that serves as a focus for 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 (however,
see principle #9).
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 (see principle #2) 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.

The Different Between Customers and End-users

Software engineers communicate with many different stakeholders, but customers

and end-users have the most significant impact on the technical work that follows.
In some cases the customer and the end-user are one and the same, but for many
projects, the customer and the end-user different people, working for different
managers in different business organizations.
A customer is the person or group who:
(1) originally requested the software to be built;
(2) defines overall business objectives for the software;
(3) provides basic product requirements;
(4) coordinates funding for the project.
In a product or system business, the customer is often the marketing department.
In an IT environment, the customer might be a business component or department.
And end-user is the person or group who:
(1) will actually use software that is built to achieve some business purpose, and
(2) will define operational details of the software so that the business purpose can
be achieved.

Planning Practices

The communication activity helps a software team to define its overall goals and
objectives (subject, of course, to change as time passes). However, understanding
these goals and objectives is not the same as defining a plan for getting there. The
planning activity encompasses a set of management and technical practices that
enable the software tam to define a road map as it travels towards its strategic goal
and technical objectives.
What to do? On many projects, over planning is time consuming and fruitless (too
many things change), but under planning is a recipe for chaos. Like most things in
life, planning should be conducted in moderation, enough to provide useful
guidance for the team- no more, no less. Regardless of the rigor with which
planning is conducted, the following principles always apply.
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 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.
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.
Why is the system being developed? All parties should assess the validity of
business reasons for the software work. Stated in another way, does the business
purpose justify the expenditure of people, time, and money?
What will be done? Identify the functionality to be built, and by implication, the
task required to get the job done.
When will it be accomplished? Establish a workflow and timeline for key project
tasks and identify the milestones required by the customer.
Who is responsible for a function? The role and responsibility of each member of
the software tam must be defined.
Where they are organizationally located? Not all roles and responsibilities
reside within the software tam itself. The customer, users, and other stakeholders
also have responsibilities.
How will the job be done technically and managerially? Once product scope is
established, a management and technical strategy for the project must be defined.
How much of each resource is needed? The answer to this question is derived by
developing estimates based on answers to earlier questions. The answers to the
above questions are important regardless of the size of complexity of a software
project. But how does the planning process begin?

Modeling Practice

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 depicting 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 Principles

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.
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 an
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.
Construction Practice
The construction activity encompasses a set of coding and testing task that lead
operational software that is ready for delivery to the customer or end-user. In
modern software engineering work, coding may be:
(1) the direct creation of programming language source code;
(2) the automatic generation of source code using an intermediate design-like
representation of the component to be built;
(3) the automatic generation of executable code using a fourth generation
programming language.

Coding Principle and Concepts

The principles and concepts that guide the coding task are closely aligned
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:
1. Understand the problem you’re trying to solve.
2. Understand basic design principles and concepts.
3. Pick a programming language that meets the needs of the software to the hilt 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 writing code, be sure you:
1. Constraint your algorithm by following structured programming practice.
2. Select data structure that will meet the needs of the design.
3. Understand the software architecture and create interfaces that are consistent.
4. Keep conditional statement 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.
Validation principles: After you’ve completed your first coding pass, be sure you:
1. Build architectural infrastructure,
 Review the architectural design.
 Code and test the components that enable architectural infrastructure.
 Acquire reusable architectural patterns.
 Test the infrastructure to ensure interface integrity.
2. Build a software component.
 Review the component- level design.
 Create a set of unit tests for the component.
 Code components data structures and interface.
 Code internal algorithms and related processing functions.
 Review code as it is written.
 Look for correctness.
 Ensure that coding standards have been maintained.
 Ensure that the code is self- documenting.
3. Unit test the components.
 Conduct all unit tests.
 Correct errors uncovered.
 Reapply unit tests.
4. Integrate completed components into the architectural infrastructure.
Testing Principles:
In a classic book on software testing, Glen Myers states a number of rules that can
serve well as testing objectives:
• 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.
These objectives imply a dramatic change in viewpoint for some software
developers. They move counts to the commonly held view that a successful test is
one in which no errors are found. Our objective is to design tests that
systematically uncover different classes of errors and to do with a minimum
amount of time and effort. These errors can be corrected subsequently.

Davis suggests a set of testing principles 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 thee 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 began 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 pare to 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.
Deployment

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 moves towards
completion. Each delivery cycle provides the customer and end-users with an
operational software increment that provides usable functions and features. The
delivery of a software increment represents an important milestone for any
software project. A number of key principles should be followed as the team
prepares to deliver an increment:
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.”

Computer Based System

Introduction to Computer Based System

The computer based system has been introduced in the market, many years ago. It
has made its powerful place in some decades of time. That the applications were
very general like Airline reservation. As time pass by such systems are becoming an
essential and important part of every task of any organization. The system engineers
associated with such system contributed a lot to make them a great success.

As we that the computer based system don t exist in a vacuum. They contain a lot of
components to be built. Generally when the software and hardware are kept together
in a form f a system. They must interact with human, with software tasks, hardware
tasks, databases etc. But as time pass out their use has gradually expanded and now
it’s seen that the computer has almost covered each and every area and related
applications of that field of any organization. Small to small or big to big all the
works are directly done by the various applications of computer based system. The
definition of computer based system given by Webster dictionary is.

A set or arrangement of elements that are organized to accomplish some method.

Procedure or control by processing information. So, the computer based systems are
the collection of its various elements, as shown in figure below.
There are total six main elements of any computer based system. A computer
based system may be the combination of all or some of these elements. They are
described below:

1. Software: Software may be any computer program, data structure or any

associated document to accomplish a required task.

2. Hardware: Hardware, element may be any electronic device like CPU,

memory keyboard, VDU, IC etc.

3. Human: Human factor may be the user or operator of the system.

4. Database: A large, organized collection of information which is associated

with the software and can be accessed through software.

5. Documentation: Report form manual or other descriptive material which

describes the various tasks of the system.

6. Procedures; A method or a sequence of steps, to be followed which describes the

specific use of each system element or the system itself.

It is not necessary that all of these elements should be collectively combined in a

particular manner; rather they can be combined in many ways.

One property of the computer based systems is that even an element can act as a
macro element of the large system , means it can act as a small part of a large
system. So this is the system engineer task to define the elements of the computer
based system.

The System Engineering Hierarchy

System Engineering encompasses a collection of top- down and methods to

navigate the hierarchy. The system engineering process usually begins with a
“world view”. That is, the entire business or product domain is examined to ensure
that the proper business or technology context can be established. The world view
is refined to focus more fully on a specific domain of interest. Within a specific
domain, the need for targeted system elements is analyzed. Finally, the analysis,
design, and construction of a targeted system elements are initiated. At the top of
the hierarchy, a very broad context is established and, at the bottom, detailed
activities, performed by the relevant engineering disciplines are conducted. The
world view (WV) is composed of a set of domains (D1), which can each be a
system or system of systems in its own right

WV = {D1 D2 D3……… Dn }

Each domain is composed of specific elements (Ej) each of which serves some role
in accomplishing the objective and goals of the domain and component:

Di = {E1 E2 E3 …… Em}

Finally, each element is implemented by specifying the technical components (Ck)

that achieve the necessary function for an element:

Ej = {C1, C2 C3 …….. C k}

In the software context, a component could be a computer program, a reusable

program component, a module, a class or object, or even a programming language
statement.

Business Process Engineering

The goal of business process engineering is to define architectures that will enable
a business to use information effectively. When taking a world view of a
company’s information technology needs, there is little doubt that system
engineering is required. Not only is the specification of the appropriate computing
architecture required. But the software architecture that populates the
organization’s unique configuration of computing resources must be developed.
Business process engineering is one approach for creating an overall plan for
implementing the computing architecture.

The different architectures must be analyzed and designed within the context of
business objectives and goals:

• Data architecture

• Applications architecture

• Technology infrastructure

The Data Architecture provides a framework for the information needs of a

business or business function. The individual building blocks of the architecture
are the data objects that are used the business. A data object contains a set of
attributes that define some aspect. Quality, characteristic, or descriptor of the data
that are being described.

Once set of data objects is defined, their relationships are identified. A relationship
indicates how objects are connected to one another. As an example, consider the
objects: customer and product A. The two objects can be connected by the
relationship purchases; that is, a customer purchases product A or product is
purchased by customer. The data objects (there may be hundreds or even thousands
for a major business activity) flow between business functions, are organized
within a database, and are transformed to provide information that serves the needs
of the business.
The Application Architecture encompasses those elements of a system that
transform objects within the data architecture for some business purpose. In the
context of this book, we consider the application architecture to be the system of
programs (software) that performs this transformation. However, in a broader
context, the application architecture might incorporate the role of people (who are
information transformers and users) and business procedures that have not been
automated.

The Technology Infrastructure provides the foundation for the data and
application architectures. The infrastructure encompasses the hardware and
software that are used to support the applications and data. This includes
computers, operating systems, networks, telecommunication links, storage
technologies, and the architecture (e.g., client/ server) that has been designed to
important these technologies.

Product Engineering
Creating an end-to-end software product is a complicated process that involves a
cycle of actions and decisions. Sometimes you have an idea for a product but no
clue where to go with it. A Software Development Company, with the help of
Product Engineering Services, can help you to evaluate your idea, suggest quickest
implementation scenarios, and create a map for product development.

Software Product Engineering is a service that involves all stages of product

creation: design, development, testing, deploying. But, the goal of Product
Engineering is more challenging than simply delivering the final product – it’s to
ensure that the product is functional and satisfies the needs of its end-user. Product
Engineer is concerned with establishing whether the product will survive in the
real world after the launch, which they determine by analyzing how it complies
with the market requirements. Within the IT context, the product can be a piece of
software, an app, or a business system. Product Engineering is dealing with the
following specifics of the product:

 Quality
 Usability
 Functionality
 Durability

Requirements Engineering
Requirements Engineering (RE) refers to the process of defining, documenting,
and maintaining requirements in the engineering design process. Requirement
engineering provides the appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility, negotiating a reasonable
solution, specifying the solution clearly, validating the specifications and managing
the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and
notation to describe a proposed system's intended behavior and its associated
constraints.
A bridge to Design and Construction
Designing and building computer software is challenging creative. Building
software is compelling that many software developers want to jump right in before
they have a clear understanding of what is needed. Requirement engineering must
be adapted to the needs of the process, the project, the product and the people
doing the work. Requirement engineering is a software engineering action that
begins during the communication activity and continues into the modeling activity.
Requirement engineering establishes a solid base for design and construction.
Without it the resulting software has a probability of not meeting customers need.
Requirement engineering builds a bridge to design and construction. It begins at
the feet of the project stakeholders (managers, customers, users), where business
need is defined, user scenarios are described, functions and features are delineated
and project constraints are identified. It begins with a broader system definition
where software is one component of the larger system domain. The next step
towards the bridge allows us above allowing the software team to examine the
context of the software work to be performed, the specific needs that design and
construction must address, the priorities that guide the order in which work is to be
completed and the information, functions and behaviors that will have a profound
impact on the resultant design.

Requirement Engineering Process

Requirement Engineering is the process of defining, documenting, and maintaining

the requirements. It is a process of gathering and defining services provided by the
system. There are several steps in the requirements engineering process.

Steps in requirements engineering process

 Requirements elicitation

It is related to the various ways used to gain knowledge about the project domain
and requirements. The various sources of domain knowledge include customers,
business manuals, the existing software of the same type, standards, and other
stakeholders of the project. The techniques used for requirements elicitation
include interviews, brainstorming, task analysis, Delphi technique, prototyping,
etc.
  Requirements specification

This activity is used to produce formal software requirement models. All

functional and non-functional requirements and the constraints are specified by
these models in totality.
During specification, more knowledge about the problem may be required which
can again trigger the elicitation process. iv. The models used at this stage include
ER diagrams, Data Flow Diagrams (DFDs), Function Decomposition Diagrams
(FDDs), data dictionaries, etc.

 Requirements verification and validation

Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that
has been built is traceable to customer requirements.
If requirements do not validate, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.

 Requirements management

Requirement management is the process of analyzing, documenting, tracking,

prioritizing, and agreeing on the requirement and controlling the communication to
relevant stakeholders. This stage takes care of the changing nature of requirements.
It should be ensured that the SRS is as modifiable as possible so as to incorporate
changes in requirements specified by the end-users at later stages too.
Use of Requirement Engineering Process
1. Determining the feasibility of producing a particular product as part of the
product line.
2. Determining the production, testing, and deployment of the particular product.
3. Determining the evolution of the product line that results from that product
development.

Requirement engineering consists of seven different tasks as follow:

1. Inception
 Inception is a task where the requirement engineering asks a set of questions
to establish a software process.
 In this task, it understands the problem and evaluates with the proper
solution.
 It collaborates with the relationship between the customer and the
developer.
 The developer and customer decide the overall scope and the nature of the
question.

2. Elicitation
Elicitation means to find the requirements from anybody.
The requirements are difficult because the following problems occur in
elicitation.

Problem of scope: The customer give the unnecessary technical detail rather than
clarity of the overall system objective.

Problem of understanding: Poor understanding between the customer and the

developer regarding various aspect of the project like capability, limitation of the
computing environment.

Problem of volatility: In this problem, the requirements change from time to time
and it is difficult while developing the project.

3. Elaboration
 In this task, the information taken from user during inception and
elaboration and are expanded and refined in elaboration.
 Its main task is developing pure model of software using functions, feature
and constraints of a software.

4. Negotiation
  In negotiation task, a software engineer decides the how will the project be
achieved with limited business resources.
 To create rough guesses of development and access the impact of the
requirement on the project cost and delivery time.

5. Specification
 In this task, the requirement engineer constructs a final work product.
 The work product is in the form of software requirement specification.
 In this task, formalize the requirement of the proposed software such as
informative, functional and behavioral.
 The requirement are formalize in both graphical and textual formats.

6. Validation
 The work product is built as an output of the requirement engineering and
that is accessed for the quality through a validation step.
 The formal technical reviews from the software engineer, customer and
other stakeholders helps for the primary requirements validation
mechanism.

7. Requirement management
 It is a set of activities that help the project team to identify, control and track
the requirements and changes can be made to the requirements at any time
of the ongoing project.
 These tasks start with the identification and assign a unique identifier to
each of the requirement.
 After finalizing the requirement traceability table is developed.
 The examples of traceability table are the features, sources, dependencies,
subsystems and interface of the requirement.

Eliciting Requirements

Eliciting requirement helps the user for collecting the requirement

Eliciting requirement steps are as follows:

1. Collaborative requirements gathering

 Gathering the requirements by conducting the meetings between developer
and customer.
 Fix the rules for preparation and participation.
 The main motive is to identify the problem, give the solutions for the
elements, negotiate the different approaches and specify the primary set of
solution requirements in an environment which is valuable for achieving
goal.

2. Quality Function Deployment (QFD)

 In this technique, translate the customer need into the technical requirement
for the software.
 QFD system designs a software according to the demands of the customer.

QFD consist of three types of requirement:

Normal requirements
 The objective and goal are stated for the system through the meetings with
the customer.
 For the customer satisfaction these requirements should be there.

Expected requirement
 These requirements are implicit.
 These are the basic requirement that not be clearly told by the customer, but
also the customer expect that requirement.

Exciting requirements
 These features are beyond the expectation of the customer.
  The developer adds some additional features or unexpected feature into the
software to make the customer more satisfied.
For example, the mobile phone with standard features, but the developer
adds few additional functionalities like voice searching, multi-touch screen
etc. then the customer more exited about that feature.

3. Usage scenarios
 Till the software team does not understand how the features and function are
used by the end users it is difficult to move technical activities.
 To achieve above problem the software team produces a set of structure that
identify the usage for the software.
 This structure is called as 'Use Cases'.

4. Elicitation work product

 The work product created as a result of requirement elicitation that is
depending on the size of the system or product to be built.
 The work product consists of a statement need, feasibility, statement scope
for the system.
 It also consists of a list of users participate in the requirement elicitation.

Developing a Use Case

When developing use cases you should start with a functional partition—a listing
of the major functional categories of the application. This will help identify what
areas need to be focused on.
Step 1: Identify who is going to be using the system directly. These are the
Actors.

The main component of use case development is actors. An actor is a specific

role played by a system user and represents a category of users that demonstrates
similar behaviors when using the system. The actors may be people or computer
systems. A primary actor is one having a goal requiring the assistance of the
system. A secondary actor is one from which the system needs assistance to
satisfy its goal. One of the actors is designated as the system under discussion. A
person can play several roles and thereby represent several actors, such as
computer-system operator or end user.

Step 2: Pick one of those Actors.

To identify a target system’s use case, we identify the system actors. A good
starting point is to check the system design and identify who it is supposed to
help.

Step 3: Define what that Actor wants to do with the system. Each of these
things that the actor wants to do with the system become a Use Case.

The things that the actors want to do with the system become goals. The goal is
the end outcome of the actions of the user. There are two types of goals. The
first type is a rigid goal. This goal must be completely satisfied and describes a
target system’s minimum requirement. The second type of goal is a soft goal.
This usually describes a desired property for a target system and does not need
to be completely satisfied. To identify use cases, we can read the requirement
specification from an actor’s perspective and carry on discussions with those
users who will function as actors. By defining everything that every actor will
be able to do in interaction with the system, the complete functionality of the
system is defined.
 Step 4: For each of those Use Cases decide on the most usual course when
that Actor is using the system. What normally happens.

A use case has one basic course and several alternative courses. The basic
course is the simplest course, the one in which a request is delivered without
any difficulty. There may be alternative courses that describe variants of the
basic course and the errors that can occur. These are documented as extensions
to the use case.

Step 5: Describe that basic course in the description for the use case.

The use scenario is written from the user’s perspective in view in easy to
understand language. This step is very similar to documenting a process flow.
The steps necessary to achieve the identified goal are written out.

Step 6: Once you’re happy with the basic course now consider the
alternatives and add those as extending use cases.

The extensions are written in the same manner as the original use case but they
provide alternatives to the simplest path.

Analysis Modelling in Software Engineering

Analysis Model is a technical representation of the system. It acts as a link

between system description and design model. In Analysis Modelling, information,
behavior, and functions of the system are defined and translated into the
architecture, component, and interface level design in the design modeling.

Objectives of Analysis Modelling:

 It must establish a way of creating software design.

 It must describe the requirements of the customer.
  It must define a set of requirements that can be validated, once the
software is built.

Elements of Analysis Model:

 Data Dictionary:
It is a repository that consists of a description of all data objects used or
produced by the software. It stores the collection of data present in the
software. It is a very crucial element of the analysis model. It acts as a
centralized repository and also helps in modeling data objects defined
during software requirements.

 Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting
data modeling activities. The attributes of each object in the Entity-
Relationship Diagram can be described using Data object description. It
provides the basis for activity related to data design.

 Data Flow Diagram (DFD):

It depicts the functions that transform data flow and it also shows how
data is transformed when moving from input to output. It provides the
additional information which is used during the analysis of the
information domain and serves as a basis for the modeling of function. It
also enables the engineer to develop models of functional and
 information domains at the same time.

 State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows
the transitions from one state to another state in the system. It also
provides the details of how the system behaves due to the consequences
of external events. It represents the behavior of a system by presenting its
states and the events that cause the system to change state. It also
describes what actions are taken due to the occurrence of a particular
event.

 Process Specification:
It stores the description of each function present in the data flow diagram.
It describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced. It also shows
regulations and barriers imposed on the performance characteristics that
are applicable to the process and layout constraints that could influence
the way in which the process will be implemented.

 Control Specification:
It stores additional information about the control aspects of the software.
It is used to indicate how the software behaves when an event occurs and
which processes are invoked due to the occurrence of the event. It also
provides the details of the processes which are executed to manage
events.

 Data Object Description:

It stores and provides complete knowledge about a data object present
and used in the software. It also gives us the details of attributes of the
data object present in the Entity Relationship Diagram. Hence, it
incorporates all the data objects and their attributes.

Negotiating requirements and Validating Requirements

Negotiating requirements

Contradictory requirements cause conflicts:

If there is no consent among the stakeholders regarding the requirements and thus
the requirements cannot be implemented collectively in the system, a conflict
arises between the contradictory requirements as well as between the stakeholders
that demand contradictory requirements. For example, one stakeholder could
demand the system to shut down in case of a failure, whereas another stakeholder
could require the system to restart.

Risks and opportunities of conflicts:

The acceptance of a system is threatened by unresolved conflicts because
unresolved conflicts cause the requirements of at least one group of stakeholders to
not be implemented. In the worst case, a conflict causes stakeholder support to
cease, causing the development project to fail. Other than posing risks, conflicts
can also be an opportunity for requirements engineering because conflicts between
stakeholders require a solution that can potentially help discover new ideas for
development and can illustrate different options. Therefore, treating and resolving
conflicts openly during requirements engineering can increase acceptance.

Goal of requirements negotiation:

The goal of negotiation is to gain a common and agreed-upon understanding of the
requirements of the system to be developed among all relevant stakeholders.

Reducing costs and risks in late phases:

Requirements validation and negotiation is an activity that must be performed (to a
varying degree of intensity) throughout the entirety of requirements engineering.
The validation and negotiation of requirements therefore causes additional effort
and therefore additional costs. However, the advantages gained by performing
requirements validation and negotiation as (reduction of overall cost, increase in
acceptance, supporting creativity and innovations) is usually significantly higher
than the costs that arise due to the increased effort.

Validating Requirement
During the requirements engineering activity, it is necessary to review the quality
of the requirements developed. Among others, the requirements are presented to
the stakeholders with the goal to identify deviations between the requirements
defined and the stakeholders’ actual wishes and needs.

Approving requirements:
During requirements validation, the decision of whether a require- Approving
requirements ment possesses the necessary level of quality is made and whether
the requirement can be approved to be used for further development activities
(such as design, implementation, and testing). This decision should be made on the
basis of predefined acceptance criteria.

Goal of validation:
The goal of requirements validation is therefore to discover errors in Goal of
validation the documented requirements. Typical examples of errors in
requirements are ambiguity, incompleteness, and contradictions

Principles of Requirements Validation Considering the following six principles of

requirements validation increases the quality of the validation results:

Principle 1: Involvement of the correct stakeholders

Principle 2: Separating the identification and the correction of errors
Principle 3: Validation from different views
Principle 4: Adequate change of documentation type
Principle 5: Construction of development artifacts
Principle 6: Repeated validation

Principle 1: Involvement of the Correct Stakeholders

The choice of stakeholders for requirements validation depends on the goals of the
validation as well as the requirements that are to be audited. When assembling the
auditing team, at least the following two aspects ought to be considered. Generally,
it should be avoided that the author of a requirement is also the person to validate
it. The author will make use of his or her prior knowledge when reading or
reviewing the requirement. This prior knowledge can negatively influence the
identification of errors because potential erroneous passages of the requirements
documentation or the requirements are implicitly and subconsciously amended by
the author’s own knowledge and can thus easily be overlooked.
Suitable auditors can be identified within or outside of the developing Internal vs.
external auditors organization. Internal audits are performed by stakeholders that
are members of the developing organization and can be used to validate
intermediate results or preliminary requirements. An internal validation is easy to
coordinate and organize because the stakeholders are available from within the
organization. An external audit requires a higher degree of effort because it
identifies auditors and (potentially) hires them for payment. In addition, external
auditors have to become familiar with the context of the system to be developed.
Due to the high effort, an external audit should be performed only on requirements
that exhibit a high level of quality.

Principle 2: Separating the Identification and the Correction of Errors

Separation between identifying errors and actually fixing them has proven itself in
the domain of software quality assurance. The same principle can be applied to
requirements validation. During validation, the flaws identified are documented
immediately. After that, each flaw identified is double-checked to determine
whether it really is an error .
Separating error identification and error correction allows auditors to concentrate
on the identification. Measures to correct the errors are taken only after
identification measures have been completed. This has the advantages that the
resources available for error correction can be used purposefully, that premature
error identification does not create additional errors, and that no alleged error is
fixed that did not need fixing because further investigation of the error may result
in the fact that an alleged error is in fact no error at all. That way, potentially
present significant errors are less likely to be overlooked because the auditor is
concentrating on fixing a previous error instead of identifying new ones.

Principle 3: Validation from Different Views

Validating requirements from different views is another principle that has proven
itself in practice. In this principle, requirements are validated and agreed upon
from different perspectives (e.g., by different people). Comparable methods are
used in other disciplines as well. For instance, in a legal trial, circumstances are
often reported from the perspective of different people so that a sound overall
picture can be gained.
Principle 4: Adequate Change of Documentation Type
Changing the documentation type during requirements validation uses the strengths
of one documentation type to balance out the weaknesses of other documentation
types. For instance, good understandability and expressiveness are strengths of
natural language texts. However, their weakness is potential ambiguity and
difficulty in expressing complex circumstances. Graphic models are able to depict
complex circumstances rather well, but the individual modeling constructs are
restricted in expressiveness.
Transcribing a requirement that is already documented in another form of
documentation simplifies finding errors. For instance, ambiguities in natural
language requirements can be identified much easier by transcribing them into a
model-based representation.
Principle 5: Construction of Development Artifacts
Constructing development artifacts aims at validating the quality of requirements
that are meant to be the basis of creating design artifacts, test artifacts, or the user
manual. During the course of the validation, the activities usually carried out
during subsequent phases to construct respective development artifacts are carried
out for small samples. For instance, the auditor intensively deals with a
requirement by creating a test case. This way, errors (e.g., ambiguity) can be
identified in the requirement. This kind of validation, however, demands a lot of
resources because subsequent development activities must be executed at least in
part.
Principle 6: Repeated Validation
Validation occurs at a distinct point in time during the development process and
relies on the level of knowledge of the auditors at that point in time. During
requirements engineering, the stakeholders gain additional knowledge about the
planned system. Therefore, a positive validation of requirements does not
guarantee that requirements are still valid at a later point in time. Requirements
validation should occur multiple times in the following cases (among others):
 Lots of innovative ideas and technology used in the system
 Significant gain of knowledge during requirements engineering
 Long-lasting projects
 Very early requirements validation
 Unknown domain
 Requirements that are to be reused.