Course: Software Engineering (SEN)

Course Code: 22413

Unit 2
Software Requirement Engineering
(14 Marks)
 Software Engineering Practice

• Collection of principles, concepts, methods and tools required for software development.
Software engineering practice is a collection of concepts, principals, methods and tools that a
software engineer calls upon on daily basis.

• Practice allows managers to manage software projects and software engineers to build
computer programs.

• Importance of Software Engineering Practices:

• Understand the problem

• Plan the solution

• Follow the plan

• Examine the result

 Software Engineering Practice

• Importance of Software Engineering Practices:

• Understand the problem
•Who are the stakeholder?
•What data, functions, features and behavior are required to properly solve the problem?
•Is it possible to represent smaller problems that may be easier to understand?
•Can the problem be represented graphically?

•Plan the solution

•Have you seen similar problems before?
•Has a similar problem been solved?
•Can sub-problems be defined?
•Can you represent a solution in a manner that leads to effective implementation?
•Can a design model be created?
 Software Engineering Practice
• Follow the plan
 Does the solution conform to the plan?
 Is each component part of the solution provably correct?
 Has the design and code been reviewed?

• Examine the result

 Is it possible to test each component part of the solution?
 Has a reasonable testing strategy been implemented?
 Has the software been validated against all stakeholder requirements?
 Core Princ ip les of Software Engineering

• P1: The reason it all exists

 The software exists for one reason: to provide value to its users.
 Before specifying system requirement, functionality, hardware
platform, development process ask question such as:
“Dose this add real value to the system?”
 If answer is no, don't do it.

 P2: Keep it simple

 All design should be as simple as possible, but no simpler.
 This facilitates having a more easily understood and easily maintained
system.
 Simple does not mean that features should be discarded in the name of
simplicity.
 Indeed, the more elegant designs are usually the more simple ones.
 Core Princ ip les of Software Engineering

• P3: Maintain the Vision

 A Clear vision is essential to the success of a software project.
 Compromising the architectural vision of a software system weakens
and will eventually break even a well designed system.
 Having an empowered architect who can hold the vision and enforce
compliance helps ensure a very successful software project.

• P4: What you produce, other will consume

 Always specify design and implement knowing someone else will have
to understand what you are doing.
 Someone may have to debug the code you write, and that makes them
a user of your code.
 Making their job easier adds value to the System.
 Core Princ ip les of Software Engineering

• P5: Be open to the future (design for long lifetime)

 A system with a long lifetime has more value.
 Software lifetimes are typically measured in months instead of years.
 System should be ready to adapt changes.
 System that adapt changes have been designed this way from start.
 Never design yourself to a corner.
 Always keep asking “what if?” and prepare for all possible answers.

• P6: Plan ahead to reuse (saves time and efforts)

 Reuse saves time and effort.
 Achieving a high level of reuse is arguably the hardest goal to
accomplish in developing a software system.
 The reuse of code and designs has been proclaimed as a major benefit
of using object oriented technologies.

• P7: Think (think before action)

 Core Princ ip les of Software Engineering

• P7: Think (think before action)

 Placing clear, complete thought before action almost always produces
better results.
 When you think about something, you are more likely to do it right.
 You also gain knowledge about how to do it right again.
 When clear thoughts has gone into system, value comes out.
 Communication Practices
Communication means discuss the problem with end user and
gather the requirements to develop the software.
•P1: Listen carefully (understand requirements from customer)
•P2: Preparation before communication (prepare agenda)
•P3: Face-to-face communication
•P4: Take notes and document decision
•P5: Strive for collaboration (team work by collaboration in
members)
•P6: Be focused (discuss the relevant topics)
•P7: Graphical representation
•P8: No Negotiation (quality, time)
 Communication Practices
•P1: Listen carefully (understand requirements from customer)
Try to focus on speakers words. If something is unclear, ask for clarification.
•P2: Preparation before communication (prepare agenda)
Spend some time to understand the problem before you meet with others.
If you have responsibilities for conducting a meeting, prepare an agenda in
advance of the meeting.
•P3: Face-to-face communication
Works better when some other representation of the relevant information
is present.
For example, a participant may create a drawing
•P4: Take notes and document decision
Someone participating in the communication should
serve as a “recorder”
 Communication Practices
•P5: Strive for collaboration (team work by collaboration in
members)
Trust among team members and creates a common goal for the team.
•P6: Be focused (discuss the relevant topics)
Discussion will bounce from one topic to the next.
•P7: Graphical representation
A sketch or drawing can often provide clarity when words fail to do the job.
•P8: No Negotiation (quality, time)
 Planni ng Practices
 Good planning leads to successful result.
 The planning activity encompasses a set of management and technical
practices that enable the software team to define a road map as it
travels towards its strategic goal and tactical objectives.
 Planning includes complete cost estimation, resources, scheduling and
also risk analysis.

•P1: Understand the scope of project

Its impossible to use a road map if you don't know where you are
going. Scope provides the software team with destination.
• P2: Involve the customer in planning activity
The customer defines priorities and establishes project constraints.
To accommodate these realities software engineers must often
negotiate order of delivery,time lines and other project related issues
 Planni ng Practices
• P3: Recognize that planning is iterative.
• P4: Estimate based on what you know
• P5: Consider risk as you define the plan
• P6: Be realistic.
• P7: Adjust granularity as you define the plan.
• P8: Define how you intend to ensure Quality.
• P9: Describe how you intend to accommodate change.
• P10: Track the plan frequently and make adjustment as
required.
 Modeling Practices

Models are created for better understanding of the actual entity to be built
or design.
• When the entity is a physical thing, we can build model that is identical in
form and shape but smaller in scale.
• When entity is software our model must take different form. It must be
capable of representing information, Architecture, functions ,features and
behavior of the system.

• Analysis Model:

• Design Model:
 Modeling Practices

• Analysis Model:
Principle 1: The information domain of problem must be clearly
represented.
Information domain encompasses the data that flow into the
system(from end user, external devices),data that flow out of the
system(via user interface, n/w interface, graphics), data stores
collection of objects(data i.e. maintained permanently).

Principle 2: The function of the software must be defined clearly.

 Functions are the processes those transform the I/p flow to the
o/p flow.
 The process specification for example algorithms provides
function details. The specification must be clearly defined.
 Modeling Practices

• Analysis Model:
Principle 3: The Behavior of the software must be defined clearly.
 Analysis model uses state transition diagrams to represent the
behavior of the system clearly.
 It shows how the system makes transition from one state to
another on occurrence of some external event.

Principle 4: The clear hierarchy among information, functions and

behavior must be shown.
 The proper hierarchy of analysis model leads to easy design.
Hence information, functions and behavior of the system must be
represented using proper hierarchy i.e. levels or layers.
 Modeling Practices

• Analysis Model:
Principle 5: analysis should be clear enough to convert it into
design model.
 If analysis of requirements is clear and simple then it will be easy
for design and implementation in construction step. Hence
requirement analysis should be clear enough.
 Modeling Practices

• Design Model:
Principle 1: Design should be traceable from analysis model.
Principle 2: Consider the architecture of the system to be built.
Principle 3: Design of data is as important as design of function.
Principle 4: Internal as well as external interfaces must be designed.
Principle 5: user interface design must satisfy all need of end user.
Principle 6: Component level design should be functionally
independent.
Principle 7: Components should be loosely coupled to one another
and to the external environment.
Principle 8: designed modules should be easy to understand.
Principle 9: Accept that design behavior is Iterative.
 Construction Practices

 The construction activity encompasses a set of coding and testing

tasks that lead to operational software that is ready for delivery to

the customer or end user.

 The initial focus of testing is at the component level, often called

unit testing. Other levels of testing include integration testing,

validation testing and acceptance testing.

 Coding Principles & Concepts
Preparation Principles:
Before you write one line of code, be sure you,
1.Understand the problem you're trying to solve.
2.Understand basic design principles & concepts.
3.Pick a programming language that meets the needs of the
software to be built & the environment in which it will operate.
4.Select a programming environment that provides tools that will
make you work easier.
5.Create a set of unit tests that will be applied once the component
you code is completed.
 Coding Principles & Concepts
Coding Principles:
As you begin writing code, be sure you:
1. Constrain your algorithms by following structured programming
practice.
2. Select data structures that will meet the needs of the design.
3. Understand the software architecture and create interfaces that
are consistent with it.
4. Keep conditional logic as simple as possible.
5. Create nested loops in a way that makes them easily testable.
6. Select meaningful variable names and follow other local coding
standards.
7. Write code that is self documenting.
8. Create a visual layout that aids understanding.
 Validating Principles
After you've completed your first coding pass, be sure you:

1. Conduct a code walk through when appropriate.

2. Perform unit tests and correct errors you've uncovered.
3. Re-factor the code.
 Testing Principles
Testing rules or objectives:
• Testing is a process of executing a program with the intent of
finding an error.
• A good test is one that has a high probability of finding an as yet
undiscovered error.
• A successful test is one that uncovers an as yet undiscovered
error.
 Testing Principles

Principle #1: All tests should be traceable to customer requirements.

Principle #2: Tests should be planned long before testing begins.

Principle #3: The Pareto principle applies to software testing.

Principle #4: Testing should begin “in the small” and progress toward

testing “in the large”.

Principle #5: Exhaustive testing is not possible.

 Deployment
 The deployment activity encompasses 3 actions: Delivery,
Support and Feedback.
 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.
 Each support cycle provides documentation & human
assistance for all functions and features introduced during all
deployment cycles to date.
 Each feedback cycle provides the software team with important
guidance that results in modifications to the functions, features
and approach taken for the next increment.
 Deployment
Principle #1: Customer expectations for the software must be
managed.
Principle #2: A complete delivery package should be assembled and
tested.
Principle #3: A support regime must be established before the
software is delivered.
Principle #4: Appropriate instructional materials must be provided to
end users.
Principle #5: Buggy software should be fixed first, delivered later.
 Requirement Engineering

• Requirement Engineering is the process of defining. documenting

and maintaining the requirements. It is a process of gathering and
defining service provided by the system.
• The information which describes the user's expectation about the
system performance is call requirement. The requirement must be
clear & some requirement definition has to face problem of lack of
clarity.
• Requirements Engineering Process consists of the following
main activities: -
Requirement Inception
Requirements elicitation
Requirements Analysis Negotiation
System Modeling
Requirements Specification
Requirement Validation
Requirement Management
 Requirement Engineering

Requirement 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 & evaluates the proper
solution.
• Requirements Elicitation: It is related to the various ways used to
gain knowledge about the project domain and requirements.
• Requirement Analysis Negotiation: Requirements are identified
(including new one if the development is iterative) & conflicts with
stakeholders are solved.
• System Modeling: Some engineering fields or specific situations
require the product to be completely designed & modelled before the
construction or fabrication starts & therefore, the design phase must
be performed in advance.
• Requirements specification: Requirement are documented in a
formal artifact called Requirement Specification (RS). This activity is
used to produce formal software requirement models.
 Requirement Engineering

• Requirement Verification & Validation:

• Verification is the process of checking that a software achieves its
goal without any bugs. It is the process to ensure whether the
product that is developed is right or not.
• Validation is the process of checking whether the software
product is up to the mark or in other words product has high level
requirements. It is the process of checking the validation of
product i.e. it checks what we are developing is the right product.
it is validation of actual and expected product.

• Requirements Management: Requirement management is the

process of analyzing. documenting. tracking. prioritizing and
agreeing on the requirement and controlling the communication to
relevant stakeholders.
 Requirement Engineering

• Characteristics of Requirements Engineering:

• Requirement should be unambiguous: It means single word
more than one meaning. If requirement contain ambiguity then it is
difficult to fulfill the requirements correctly.
• Requirement should be Testable (Verifiable): Tester should be
the requirement whether they are implemented successfully or
not.
• Requirement should be clear
• Requirement should be understandable
• Requirement should be feasible (realistic, possible)
• Requirement should be Consistent (Compatible)
 Requirement Engineering

Requirement Gathering & Analysis:

• Requirement elicitation(getting information from someone) is the
procedure of finding the requirements for desired software system
through communication with customer. end user. system users &
others who have indirect or direct benefits from software system
development.
• There are different ways to identify customer requirements:
 Interviews
 Survey
 Questionaries'
 Task Analysis
 Domain Analysis
 Brainstorming
 Prototyping
 Observation
 Requirement Engineering
• Interview: Interviews of stakeholders and users are critical to creating the
great software.
• Survey: Organization may perform surveys of different stakeholders by
questioning them about their requirements & expectation from the
proposed software system.
• Questionnaires: Questionaries' are a document which contains in built
set of activities that based on questions & their options.
• Task Analysis: In this techniques team of software developers &
engineers may identify the functional specification for which the new
system is needed to develop.
• Domain Analysis: Each software put into some domain strategy. The
experienced person in that domain can be great support to study general
and specific requirements.
 Requirement Engineering

• Brainstorming: Brainstorming is used in requirement gathering to get as

many ideas as possible from group of people.
• Prototyping: Prototyping is a relatively modern technique for gathering
requirements. In which we create user interface without including detail
functionality for user to interpret features of desired software product. It
supports providing details about requirement.
• Observation:
By observing users, an analyst can identify a process flow, steps, pain
points and opportunities for improvement
 Requirement Engineering
• Types of Requirement:
• Requirements help to understand the behavior of a system, which is
described by various tasks of the system.

• The requirements, which are commonly considered, are classified into

three categories, namely, functional requirements, non-functional
requirements, and domain requirements.

1. Functional Requirements:
• IEEE defines the functional requirements as a "a function that a system
or components must be able to perform'.
• It describes the interaction of software with its environment & specifies
the inputs, outputs, external interfaces & the function that should be
included in the software.
 Requirement Engineering
2. Non Functional Requirements:
• These are basically the quality constraints that the system must satisfy
according to the project contract.
• The priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioural requirements.
• They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability and Flexibility
 Requirement Engineering
Following are the Types of Non Functional Requirements:
 Product Requirement
 Organizational Requirement
 External Requirement

3. Domain Requirements:
• Domain requirements are the requirements which are characteristic of a
particular category or domain of project.
• The basic functions that a system of a specific domain must necessarily
exhibit come under this category.
 Requirement Engineering
Developing Use-cases:
• Use case is a term used in system analysis to determine. clarify &
integrate all system requirements. It describes how user interacts with
the system to achieve certain goal.
• It describes various business activities carried out by a system. Use case
consist of following three main components:
Use Case: A use case is a software and system engineering term that
describes how a user uses a system to accomplish a particular goal. A
use case acts as a software modeling technique that defines the features
to be implemented and the resolution of any errors that may be
encountered.
Actor: Actors are the type of users that interact with the system.
System Boundary: System boundary define the scope of system or
limit of system. It is representation of entire system as described in
problem statements
 Requirement Engineering
Use-case Example:
 Requirement Engineering
Requirement Negotiation Validation:
• To negotiate the requirements of a system to be developed. it is necessary
to identify conflicts and to resolve those conflicts.
• This is done by means of systematic conflict management. The conflict
management in requirements engineering comprises the following four
tasks:
• Conflict Identification
• Conflict Analysis
• Conflict Resolution
Agreement
Compromise
Voting
Definition of Variants
Overruling (Reject or Disallowed)
 Requirement Engineering
Documentation of the conflict Resolution
• Handling Conflicts Repeatedly
• Inappropriate Conflict resolution
Software Requirement Specification: Need, Format
& Its Characteristics
• A software requirements specification (SRS) is a detailed description of a
software system to be developed with its functional and non-functional
requirements.
• The SRS is developed based the agreement between customer and
contractors. It may include the use cases of how user is going to interact
with software system.
• IEEE defines SRS as. 'a document that clearly & precisely describes
each of the essential requirements (function, performance, design
constraints & quality attributes) of the software & the external interfaces.
The outcome of the requirement gathering & analysis phase of the SDLC
is SRS. It also called as Requirement Document.
 Characteristics of SRS
Following are the characteristics of SRS:
Correct: SRS is correct when all the requirement of user are described in
the requirement document.
Complete: SRS is complete when the requirements are undoubtedly
specified that which work the software product is required to perform.
Unambiguous: SRS does not contain any confusion when each specified
requirement has single interpretation.
Verifiable: SRS is testable when the stated requirements can be tested with
a cost effective procedure to verify whether the final software fulfills those
requirement.
Ranked for importance and/or stability: Each & every requirement has
not same importance, so every requirement is recognized to make
differentiation between requirements.
 Characteristics of SRS
Following are the characteristics of SRS:
Modifiable: The requirement given by the user are changeable, so
requirement document must be generated in such way that those
modification can be included easily in SRS by preserving consistently the
structure & style of the SRS.

Traceable: SRS is observable when the source of every requirement is

unambiguous(clear) & facilitates the description of requirement in future.
Forward & backward tracing method are used for this purpose.
SRS Format: Library Mgt. System
Layer 1: Stakeholders Layer 2: Goals Layer 3: Sub Goals Layer4:Non-Functional Requirements

Student Login - -+---- Se cu r y

Login Employee Login - -+---- Security

Publisher Login - -+--- Securfy

Usability, Performance

1. Member Search Book Search by Author - -+--- Usability, Performance

Search IJy ISBN UsalJility, Performance

u sability
Borrow Book

Get Book Usability, Performance

Provide details u sability

Re1urn Book
Usability

Add Student Flexibility

Add Member Add Employee FlexilJilily

Flexibility

Usability

2. Librarian Usability

Usability

Reliabilfy

Issue Book - - -+-- - - Usability , Performance

Update Account Reliability Safety

Get details Usabiltty

Receive book

Update Account Safety, RelialJility

THANK YOU