SEN (AY 2023-24) Software Requirement Engineering

UNIT 2: SOFTWARE REQUIREMENT ENGINEERING

2.1 Software Engineering Practices and it importance
Definition:
Software Engineering practices includes- concepts, principles, methods and tools that must be
considered for planning and development of software system.
Importance:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

CORE PRINCIPLES OF SOFTWARE ENGINEERING

The First Principle: The Reason It All Exists

 A software system exists for one reason: to provide value to its users. If your
development is not going to add any value to its users then don‟t develop such system.

The Second Principle: Keep It Simple, Stupid!

 The software design must be simple, easy for understanding and easy to maintain

The Third Principle: Maintain the Vision

 A clear vision is essential to the success of a software project.
 Having a powerful architect who can hold the vision helps to ensure a very successful
software project.

The Fourth Principle: What You Produce, Others Will Consume

 Always specify, design, and implement by keeping in mind that someone else will have
to understand what you are doing.
 The audience for any product of software development is potentially large.
 Design, keeping the implementers in mind. Code with concern for those who will
maintain and extend the system.

The Fifth Principle: Be Open to the Future

 A system with a long lifetime has more value.
 Always ask “what if,” and prepare for all possible answers by creating systems that solve
the general problem.

The Sixth Principle: Plan Ahead for Reuse

 Reuse saves time and effort.
 The reuse of code and designs has a major benefit of using object-oriented technologies.
 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!

ZEBA SYED Page 1
SEN (AY 2023-24) Software Requirement Engineering

 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 a valuable experience.
 Applying the first six principles requires intense thought, for which the potential rewards
are enormous.

2.2 COMMUNICATION PRACTICES

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 contentious in your words or as a person is talking.

Principle 2. Prepare for communication. Spend the time to understand the problem before you
meet with others. If necessary, do some research to understand business domain. If you have
responsibility for conducting a meeting, prepare an agenda in advance of the meeting.

Principle 3. Have facilitator for communication. Every communication meeting should have a
leader (a facilitator) to keep the conversation moving in a productive direction, to mediate any
conflict that does occur, and to ensure that other principles are followed.

Principle 4. Have face-to-face communication.

Face to face communication is always makes sense. It is important to have effective
communication

Principle 5. Take notes and document decisions. Someone participating in the communication
should serve as a “recorder” and write down all important points and decisions.

Principle 6. Strive for collaboration.

Collaboration occurs when the collective knowledge of members of the team is used to describe
product or system functions or features. Each small collaboration serves to build trust among
team members and creates a common goal for the team.

Principle 7. Stay focused; modularize your discussion.

The more people involved in any communication, the more likely that discussion will bounce
from one topic to the next. The facilitator should keep the conversations modular; leaving one
topic only after it has been resolved.

Principle 8. If something is unclear, draw a picture: Verbal communication goes only so far.
A sketch or drawing can often provide clarity when words fail to do the job.

Principle 9. Move on: During the communication just move on by resolving the issues and by
understanding the things.

Principle 10. Negotiate: It works best when both parties win. There are many instances in which
you and other stakeholders must negotiate functions and features, priorities, and delivery dates. If
ZEBA SYED Page 2
SEN (AY 2023-24) Software Requirement Engineering

the team has collaborated well, all parties have a common goal. Still, negotiation will demand
compromise from all parties.

PLANNING PRACTICES PRINCIPLES

Principle 1. Understand the scope of the project. It‟s impossible to use a road map if you
don‟t know where you‟re going. Scope provides the software team with a destination.

Principle 2. Involve customer in the planning activity. Customers specify what they exactly
want from the software system. The developer can negotiate order of delivery, some unrealistic
functionalities, cost and so on. Hence, customers‟ involvement in the project is a must.

Principle 3. Planning activity should be iterative. As work begins, it is very likely that things
will change. As a consequence, the plan must be adjusted to accommodate these changes.

Principle 4. Make estimation based on the knowledge. 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. But it is always vague.

Principle 5. Consider risk as you define the plan. The project plan must be flexible enough to
accommodate one or more risks.

Principle 6. Be realistic. People don‟t work 100 percent of every day. Noise always enters into
any human communication. Omissions 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 according to the plan. Granularity refers to the level of detail
that is introduced as a project plan is developed. A “high-granularity” plan provides significant
work task detail that is planned over relatively short time increments. A “low-granularity” plan
provides broader work tasks that are planned over longer time periods.

Principle 8. Ensure the quality. The plan should identify how the software team intends to
ensure quality.

Principle 9. Describe the accommodated changes. The plan must help the software team to
induce required changes in their development.

Principle 10. Track the plan frequently and make changes as required.
Software projects fall behind schedule one day at a time. Therefore, it makes sense to track
progress on a daily basis, looking for problem areas and situations in which scheduled work does
not conform to actual work conducted. When slippage is encountered, the plan is adjusted
accordingly.

ZEBA SYED Page 3

SEN (AY 2023-24) Software Requirement Engineering

MODELLING PRACTICES PRINCIPLES

1. Analysis Modeling Principles

2. Design Modeling Principles

1. Analysis Modeling Principles

Principle 1: Information domain of the problem must be represented and
understood
It represents the data that flows in and out of the system.

Principle 2: Functions that the software performs must be defined

There are various types of the functionality that must be present in the system. Some
functions can be directly beneficial to the user. Some functions are control functions,
some for transforming the data.

Principle 3: Behavior of the software must be represented

By creating appropriate model the behavior of the computer system for the input
submitted by the user, interaction of the system with the external system are represented
by the software.

Principle 4: The model should be created in such a way that it represents the details
of the software in layered/ hierarchical manner
Software systems are usually created to solve the complex problems. The large and
complex problems are solved using divide and conquer strategy. Sub-problems are easy
to understand.

Principle 5: The analysis task must move from basic information to the
implementation of the concept
Before creating the analysis model the information gathered is from users‟ point of view.
This information should be transformed in such a way that the implementation of the
concept using the computer based system.

2. Design Modeling Principles

Principle 1: Analysis model must be used to create design model
The analysis model describes the information domain, system behavior, user visible
functionalities and so on. The design model translates this information into the system
architecture

Principle 2: Consider the architecture of the system to be built

The skeleton of the system should be prepared before creating the actual design of the
system. For creating such architecture the information present in the analysis model is
used.

Principle 3: Design of data is an important activity

It is important because it represents the flow of information.

ZEBA SYED Page 4

SEN (AY 2023-24) Software Requirement Engineering

Principle 4: Interfaces must be designed carefully

The interfaces are important for communication of two components and communication
with the external environment. Hence, these need to be designed carefully.

Principle 5: User interface design must be as per the users need

The user interface is the visible feature of the software. Users interact with the system via
user interfaces. Hence, user interface design must be by considering user needs.

Principle 6: Component level design must be functionally independent

Functional independence is a quality that indicates the single mindedness of software
component. Every component must focus on one functionality at a time. This is called
cohesiveness of components.

Principle 7: Components must be loosely coupled

If the components are tightly coupled then error propagation might get increased. The
maintaining such systems become difficult. This denotes low coupling property of
design.

Principle 8: Design models should be easy to understand

The software design is used to generate the code. Hence it must be easy to understand so
that implementation of the system can be done smoothly.

Principle 9: Design should be developed iteratively

The iterative development of the design model will refine the work and errors can be
corrected in each iteration.

CONSTRUCTION PRACTICES PRINCIPLES

I. Preparation Principles
1. Understand the problem for which the system is designed.
2. Know the basic design principles and concepts.
3. Choose appropriate programming language for coding.
4. Select such a programming environment which is convenient to work.
5. Prepare the set of unit tests for each component of the code.
II. Coding Principles
1. Adopt structured or modular programming approach for the algorithm
2. Choose the appropriate data structures.
3. Keep conditional logic very simple.
4. Create the nested loop in such a way that they can be tested easily.
5. Give meaningful variable names.
6. Make the code documented by adding appropriate comment statements within it.
III. Validation Principles
1. Review the code thoroughly.
2. Perform unit tests and correct the errors.
3. Refactor the code

ZEBA SYED Page 5

SEN (AY 2023-24) Software Requirement Engineering

DEPLOYMENT PRINCIPLE

1. Principle 1: Manage customer’s expectations.

It always happens that customer wants more than he has started earlier as his requirements. It
may be the case that customer gets disappointed, even after getting all his requirements satisfied.
Hence at time of delivery developer must have skills to manage customer„s expectations.

2. Principle 2: Assembly and test complete delivery package.

It is not the case that the deliverable package is ‗only software„. The customer must get all
supporting and essential help from developer„s side.

3. Principle 3: The support service must be ready before delivery of the software system.
Customer support is important factor in deployment phase. If proper support is not provided,
customer will not be satisfied. Hence support should be well planned and with record-keeping
mechanism.

4. Principle 4: Proper instructional material must be given to the end user.

Many times, developer thinks ―when project is successful deliverable part is only working
program‖. But realty is that working program is just part of software product. Actual project
delivery includes all documentations, help files and guidance for handling the software by user.

5. Principle 5: Don’t deliver defective (erroneous) or buggy software to the customer.

In incremental type of software, software organizations may deliver some defective software to
the customer by giving assurance that the defects will be removed in next increment.

2.3 REQUIREMENT ENGINEERING

Requirement Engineering Tasks: (7 Tasks)

Inception
It means specifying the beginning of software project. Most of the software projects get started
due to business requirements. There may be potential demand from the market for a particular
product and then the specific software project needs to be developed.
During inception a set of context free questions is discussed. The purpose of inception is to-
1. Establish the basic understanding of the project
2. Find out all possible solutions and to identify the nature of the solution
3. Establish an effective communication between developer and customer

Elicitation
Before the requirements can be analyzed and modelled they must undergo through the process of
elicitation. Requirements elicitation means requirements discovery.

Elaboration
Here the requirement is expanded and refined. This information is gained during inception and
elicitation. The goal of elaboration activity is to prepare a technical model of software functions,
features and constraints.
ZEBA SYED Page 6
SEN (AY 2023-24) Software Requirement Engineering

Negotiation
This phase will involve the negotiation between what user actual expects from the system and
what is actual feasible for the developer to build. Often it is seen that user always expect lot of
things from the system for lesser cost. But based on the other aspect and feasibility of a system
the customer and developer can negotiate on the few key aspect of the system and then they can
proceed towards the implementation of a system.

Specification
A specification can be a written document, mathematical or graphical model or may be a
prototype. There is a need to develop a standard specification in which requirements are
presented in consistent and understandable manner.
For a large system it is always better to develop the specification using natural language and in a
written document form.
Specification is a final work product of requirement engineering process. It describes the
functions, constraints and performance of computer based systems.

Validation
The work products produced as a consequence of requirements engineering are assessed for
quality during a validation step. Requirements validation examines the specification to ensure
that all software requirements have been stated unambiguously; that inconsistencies, omissions
and errors have been detected and corrected, and that the work products conform to the standards
established for the process, the project, and the product.

Requirement Management
Requirement Management is the process of managing changing requirements during the
requirement engineering process and system development.

TYPES OF REQUIREMENTS

Functional Requirements
It means, “a function that a system or component must be able to perform”. Functional
requirements describe the interaction of software with its environment and specify the inputs,
outputs, external interfaces and the functions that should be included in the software.
Functional requirements also specify the procedure by which the software should react to
particular inputs or behave in particular situations.

Non-functional Requirements
The non-functional requirements are also known as quality requirements relate to system
attributes such as reliability, usability, portability, efficiency, performance, response time, etc.
i. Product Requirements: Product requirements specify the behavior of the software.
a. Reliability Requirements: It describes the acceptable failure rate of software.
b. Usability Requirements: It describes the ease with which the users are able to operate
the software.
c. Efficiency Requirements: It describes the extent to which the software makes optimal
use of resources, the speed with which the system executes and the memory it consumes
for its operation.
ZEBA SYED Page 7
SEN (AY 2023-24) Software Requirement Engineering

d. Portability Requirements: It describes the ease with which the software can be
transferred from one platform to another.

ii. Organizational Requirements: These requirements are derived from the policies and
procedures of an organization.
a. Implementation Requirements: It describes programming language and design
method requirements.
b. Standards Requirements: It describes the process standards to be used during
software development. For eg. ISO, IEEE
c. Delivery Requirements: It specifies when the software and its documentation are to
be delivered to the user.

iii. External Requirements: It includes all the requirements that affect the software or its
development process externally.
a. Interoperability Requirements: It defines the way in which different computer-
based systems interact with each other in one or more organizations.
b. Legislative Requirements: It ensures that the software operates within legal
jurisdiction. For eg. Pirated software should not be sold.
c. Ethical Requirements: It specifies the rules and regulations of the software so that
they are acceptable to the users.

ELICITING REQUIREMENTS

1. Collaborative Requirements Gathering

Guideline for FAST (Facility Application Specification Technique) approach:
FAST is an approach in which joint team of customers and developers work together to
identify the problem, decide the elements of solution, negotiate different approaches and
prepare a specification for preliminary set of solutions

1. Meetings are conducted and attended by both software engineers and other customers.
The place of meeting should be a neutral site.
2. Rules for preparation and participation are established.
3. An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage the free flow of ideas.
4. A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
5. A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room, or virtual forum) is used.
The goal is to identify the problem, decide the elements of solution, negotiate different
approaches and prepare a specification for preliminary set of solutions

2. Quality Function Deployment

Quality function deployment (QFD) is a quality management technique that translates the needs
of the customer into technical requirements for software.

Under quality function deployment three types of requirements can be defined:

ZEBA SYED Page 8

SEN (AY 2023-24) Software Requirement Engineering

i. Normal requirements. The objectives and goals that are stated for a product or system
during meetings with the customer. If these requirements are present, the customer is
satisfied.
For Example, Handling mouse and keyboard events for any GUI based system

ii. Expected Requirements: These types of requirements are such requirements which
system must be having even if the customer did not mention about them. These are such
requirements that if they are not present then the system will be meaningless.
iii. Exciting Requirements: These features go beyond the customer‟s expectations and
prove to be very satisfying when present. These requirements are satisfied by the
software beyond customer‟s expectations.

3. Usage Scenarios
During requirement gathering overall vision for system functions and features get developed. In
order to understand how these functions and features are used by different classes of end users,
developers and users create a set of scenario. This set identifies the usefulness of the system to be
constructed. This set is called as use-cases.

4. Elicitation of Work Product

Following are some work products that get produced during requirement elicitation-
 A statement of feasibility study performed in order to find the need of the project.
 Statement for the scope of the system
 A list of various stakeholders such as customer, end-users, technical persons, and many
others who participate during requirement elicitation.
 A list of requirements and constraints
 A set of usage scenarios
 The prototype that may get developed for defining the requirements in better manner.

SOFTWARE REQUIREMENT SPECIFICATION

Definition: A software requirements specification (SRS) is a complete description of the

behavior of the system to be developed. It includes a set of use cases describe all of the
interactions that the users will have with the software.

In addition to use cases, the SRS contains functional requirements and nonfunctional
requirements. Functional requirements define the internal workings of the software: that is, the
calculations, technical details, data manipulation and processing, and other specific functionality
that shows how the use cases are to be satisfied. Non-functional requirements impose constraints
on the design or implementation (such as performance requirements, quality standards, or design
constraints).

NEED OF SRS

The need of SRS document is to provide-

ZEBA SYED Page 9

SEN (AY 2023-24) Software Requirement Engineering

1. SRS establishes an agreement between the client and developer about the nature of the
software product.
2. SRS can be used for validating the final product because the software requirements are
specified in SRS.
3. For producing high quality software SRS is produced.
4. SRS is a pre-requisite for high quality software.
5. Reduce the development effort

Format of SRS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
2. General Description
2.1 Product perspective
2.2 Product Features
2.3 User characteristics
2.4 Operating Environment
2.5 Design constraints
3. Functional Requirements
3.1 System feature 1
3.2 System feature 2
And so on
4. Interface Requirements
4.1 User Interface
4.2 Hardware Interface
4.3 Software Interface
4.4 Communication Interface
5. Other Non-Functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
6. Other Requirements
Glossary
Analysis Models
Issues List

Characteristics of SRS
Following are some characteristics of a good SRS
1. Correct
The SRS must be correct. It means all the requirements must be correctly mentioned.

2. Complete
To make the SRS complete, it should specify the purpose of SRS.

ZEBA SYED Page 10

SEN (AY 2023-24) Software Requirement Engineering

3. Verifiable
The SRS should be written in such a manner that the requirements that are specified within it
must be satisfied by the software.

4. Modifiable
Writing SRS is an iterative process. Even after specifying the requirements they can be
modified later on if there is a change in user requirements.

5. Traceable
If origin of requirement is properly given or references of the requirements are correctly
mentioned then such a requirement is called as traceable requirement.

ZEBA SYED Page 11