Chapter One

Basics of Software Requirements

Engineering

1 Introduction

It’s getting difficult to think the modern world without software. Almost all infrastructures and
utilities are controlled by computer-based systems and most electrical products include a computer
and controlling software. Now days, industrial manufacturing and distribution is completely com-
puterized, as is the finance system. Entertainment, including the music industry, computer games,
and film and television, is software intensive. Therefore, software engineering is essential and play
its core role for the functioning of national and international societies.

There are many different types of software systems, from simple embedded systems to complex,
worldwide information systems. Software systems are abstract and intangible. There are basic
differences in developing such diverse software, more importantly between professional and amateur
software development. If you are writing a program for yourself, no one else will use it and you don’t
have to worry about writing program guides, documenting the program design, and etc. However, if
you are writing software that other people will use and other engineers will change then you usually
have to provide additional information as well as the code of the program.

2 Terminologies and Concepts

• Software: Computer programs and associated documentation. Software products may be

developed for a particular customer or may be developed for general market.

• Software Engineering: An engineering discipline that is concerned with all aspects of soft-
ware production from the early stages of system specification through to maintaining the system
after it has gone into use. Software Engineering is not just concerned with the technical pro-
cesses of software development. It includes activities such as software project management and
the development of tools, methods and theories to support software production.

• Software Engineering Process: The systematic approach that is used in software engi-
Software Requirement Engineering, Ch-1

neering, sometimes called a software process, which includes a sequence of activities that leads
to the production of a software system. There are different ways to organize these activities
in phases. Each phase contains a prescribed set of activities conducted during the specified
period, the interrelationship among phases by expressing their order and frequency as well as
defining the deliverables of the project phase. Generally, there are five fundamental activities
that are common to all software processes.

• Software Engineering Techniques and Methods: It’s pointless to look for universal nota-
tion, methods and techniques for software engineering that are applicable for all of the software
development processes. It’s because different types of software require different approaches.
While all software projects have to be professionally managed and developed, different tech-
niques are appropriate to different types of system. Nevertheless, there are software engineering
fundamentals that apply all types of software systems:

1. They should be developed using a managed and understood development process. The

page 2 of 8
Software Requirement Engineering, Ch-1

organization developing the software should plan the development process and have clear
ideas of what will be produced and when it will be completed.

2. Dependability and performance are important for all types of systems. Software should
have as expected, without failures and should be available for use when it is required. The
system should perform efficiently and should not waste resources.

3. Understanding and managing the software specification and requirements are important.
You have to know what different customers and users of the system expect from it and
you have to manage their expectations so that a useful system can be delivered within
budget and to schedule.

4. You should make as effective use as possible of existing resources. This means that, where
appropriate, you should reuse software that has already been developed rather than write
new software.

• Software Engineering Challenges: Software systems are not constrained by the properties
of materials, governed by physical laws or manufacturing processes. However, because of the
lack of physical constraint, software systems become extremely complex, difficult to understand
and expensive to change. There are three general issues that affect different types of software
and software system.

– Heterogeneity - Increasingly, systems are to operate as distributed systems across networks

that include different types of computer and mobile devices. You often have to integrate
new software with older legacy systems written different programming languages. The
challenges here are to develop techniques for building dependable software that is flexible
enough to cope with this heterogeneity.

– Business and Social Change - Business and society are changing incredibly quickly as
emerging economies develop and new technologies became available. They need to be
able to change their existing software and rapidly develop new software. Software need to
evolve so that the time required for software to deliver value to its customer is reduced.

– Security and Trust - We have to make sure that malicious users cannot attack the software
and that information security is maintained.

• Software Engineering Ethics: Software engineering is carried out within a social and legal
framework that limits the freedom of people working in that area. So a software engineer,

page 3 of 8
Software Requirement Engineering, Ch-1

you must accept that your job involves wider responsibilities than simply the application of
technical skills. you must also have an ethical and normally responsible way if you are to be
respected as a professional engineer. You should uphold normal standards of honesty honesty
and integrity. You should not use your skills and abilities to behave in a dishonest way or in a
way that will bring disrepute to the software engineering profession. however, there are areas
where standards of acceptable behavior are not bound by laws but by the more tenuous notion
of professional responsibility.

• Requirement: Specifies what the customers wants and defines what a system should do and
the desirable qualities of that system

• Requirement Engineering: The process of determining the requirements, analyzing, vali-

dating and managing them in a set of systematic techniques throughout the project life cycle.

• Requirements Engineering Process: The process of determining the requirements for a

proposed system involves discussions with the relevant stakeholders to determine their needs
and to explicitly define what functionality the system should provide, as well as any hard-
ware and performance constraints. Generally, there are Four core activities of requirements
engineering: Elicitation, Documentation, Validation and Negotiation, and Management.

3 Requirements Engineering

3.1 Why Requirements Matter?

Requirements are the bridge between the real world, the world in which there are problems that
have to be addressed, and the software systems. Requirements are a translation of these real world
problems in the form that can be converted to a software system. Moreover, requirements reflect the
problems in real world in a way that can be utilize by software engineers. The principal problem areas
on software development and production are the requirement specification and the management of
customer requirements. The way the requirements of a system are handled is a significant cause for
project failures and/or time and budget over-runs.

page 4 of 8
Software Requirement Engineering, Ch-1

3.2 Why Requirements Engineering?

Difficulties with requirements are the key root-cause of the safety-related software errors that have
persisted until integration and system testing. According to the studies, 30% and 20% of the software
projects investigated in 1994 and 2006, respectively, failed. Approximately 60% of all errors in
system development projects originate during the phase of requirements engineering. These errors
, however, are often discovered only in later project phases or once the system has been deployed
because incorrect or incomplete requirements can be interpreted by developers in such a fashion that
they subjectively sound or subconsciously complete.

Missing requirements often remain undetected during design and realization because developers trust
requirements engineers to deliver high quality work. The later in the development project a defect
in the requirements is corrected, the higher are the costs associated with fixing it. For instance,
the effort to fix a requirements defect is up to 20 times higher if the correction is done during
programming as opposed to fixing the same defect during requirements engineering. If the defect is
fixed during acceptance testing, the effort involved may be up to a 100 times higher.

3.3 Source of Requirement

• Stakeholders: - are people or organizations that (directly or indirectly) influence the require-
ments of a system. Examples of stakeholders are users of the system, operators of the system,
developers, architects, customers, and testers.

• Documents: - often contain important information that can provide requirements. Examples
of documents are universal documents, such as standards and legal documents, as well as
domain- or organization-specific documents, such as requirements documents and error reports
of legacy systems.

• Existing Systems: - Systems in operation can be legacy or predecessor systems as well as

competing systems. By giving the stakeholders a chance to try the system out, they can gain
an impression of the current system and can request extensions or changes based on their
impressions.

• Domain/Business areas: - Allows to identify requirements that come from the application

page 5 of 8
Software Requirement Engineering, Ch-1

domain of the system that reflect the characteristics of that domain

3.4 Characteristics of Good Requirements

1. Each requirement is clear and unambiguous

2. Each requirement has a priority to indicate its importance

3. Each requirement may be implemented

4. Each requirement is testable

5. Each requirement is necessary

6. Any conflicts between the requirements are resolved

7. Each requirement is broken down as fully as possible

8. Each requirement is consistent with the project’s objectives

9. Each requirement is stated as a stakeholder need (i.e. premature design/solution or implemen-

tation information is not included)

10. The user (business) requirements are traceable (in both directions) throughout the development
cycle

11. The requirements are complete and consistent

3.5 Characteristics of poor requirements

1. High level of requirements creep during the project

2. Requirements changing regularly during the project

3. Missing requirements

4. Changes to the requirements are not controlled

5. Requirements accepted from any source

page 6 of 8
Software Requirement Engineering, Ch-1

6. High level of rework during the project

7. Design, implementation and test products inconsistently interpret the requirements

8. Deliverables are inconsistent with the requirements

9. Untestable requirements

10. Inability to demonstrate that the implementation satisfies the requirements

3.6 Results of Poor Requirements

• The system may be delivered late and cost more than originally expected

• The customer and end-users may not satisfied with the system

• They may not use its facilities or may even decide to scrap it altogether

• The system may be unreliable in use with regular system errors and crashes disrupting normal
operation

• If the system continues in use, the costs of maintaining and evolving the system are very high

3.7 Challenges in Requirements Engineering

• Stakeholders don’t know what they want from the new system

• Its very difficult to imagine how a future system might work

• Business operate in a rapidly changing environment so their requirements for system support
constantly changing

• Multiple stakeholders with different goals and priorities are involved in the requirements engi-
neering process

• System stakeholders don’t have clear ideas about what they need

• They can only describe their requirements in vague and ambiguous way

page 7 of 8
Software Requirement Engineering, Ch-1

• requirements are often influenced by political and organizational factors that stakeholders will
not admit to publicly

page 8 of 8
Software Requirement Engineering, Ch-1

Course Objectives:
After completion of this course, you will have the ability:

• Discover and elicit requirements using variety of techniques

• Organize and prioritize requirements

• Apply analysis techniques and validate requirements

• Negotiate with stakeholders and agree on set of requirements

• specify and measure quality attributes

• Write requirement Specification documents

page 9 of 8