SOFTWARE ENGINEERING
SEN-22413
UNIT-II
SOFTWARE REQUIREMENT
ENGINEERING
Mr. Naresh A. Kamble
22-04-2021
POINTS TO BE COVERED
• SOFTWARE ENGINEERING • CONSTRUCTION PRACTICES
PRACTICES AND ITS • SOFTWARE DEPLOYMENT
IMPORTANCE
• REQUIRMENT ENGINEERING
• CORE PRINCIPLES
• SOFTWARE REQUIREMENT
• COMMUNICATION
SPECIFICATION (SRS)
PRACTICES
• PLANNING PRACTICES
• MODELING PRACTICES
22-04-2021
SOFTWARE ENGINEERING PRACTICES
• Definition
• Software engineering practices includes – concepts,
principles, methods and tools that must be considered for
planning and development of software system.
• IMPORTANCE
• Involvement of all entities in software development process.
• It provides detail insight for software development process.
• Provides different principles that must be used during the
software development process.
22-04-2021
REASONS
IT ALL
EXISTS
KEEP IT
THINK SIMPLE,
STUPID
CORE
PLAN
AHEAD PRINCIPLES MAINTAIN
THE
FOR
VISION
REUSE
PRODUCE
OPEN TO
&
FUTURE
CONSUME
COMMUNICATION PRACTICES
Communication is carried out in order to
understand the customer requirements.
22-04-2021
HAVE FACILITATOR
PREPARE FOR
LISTEN COMMUNICATION
FOR
COMMUNICATION
TAKE NOTES AND
HAVE FACE-TO-FACE STRIVE FOR
DOCUMENT THE
COMMUNICATION COLLABORATIONS
DECISIONS
MAKE PICTORIAL
STAY FOCUSED
REPRESENTATION MOVE ON
NEGOTIATE
PLANNING PRACTICES
Planning is an activity that includes the set of
management and technical practices that
software has to follow in definite direction.
22-04-2021
SCOPE OF PLANNING BY ITERATIVE
INVOLVING PLANNING
PROJECT CUSTOMER ACTIVITY
ESTIMATION RISK WHILE
BASED ON THE DEFINING THE BE REALISTIC
KNOWLEDGE PLAN
ADJUST
ENSURE THE DESCRIPTION OF
GRANULARITY
ACCOMODATED
ACCORDING TO QUALITY CHANGES
PLAN
TRACKING OF
PLAN
MODELING PRACTICES
Models are created for understanding the system.
During software development, there are 2 kinds of
models that are developed – analysis model and
design model
22-04-2021
INFORMATION
DOMAIN
BASIC
INFORMATION TO
FUNCTIONALITY
THE
IMPLEMENTATION
ANALYSIS
MODELING
PRINCIPLE
DETAILS IN
LAYERED OR
HIERARCHICAL BEHAVIOR
MANNER
DESIGN MODELING PRINCIPLES
CREATE
BUILT
DESIGN ARCHITECTURE
DESIGN DATA
MODEL
DESIGN DESIGN USER COMPONENT
INTERFACES INTERFACE LEVEL DESIGN
LOOSLEY ITERATIVE
EASE OF DESIGN
COUPLED REPRESENTATION
DESIGN
COMPONENTS DEVELOPMENT
CONSTRUCTION PRACTICES
Construction practices are based on preparation
principles, coding principles and validation
principles.
22-04-2021
UNDERSTAND
PROBLEM
BASIC
UNIT
DESIGN
TESTING
PRINCIPLES
PREPARATION
PRINCIPLES
PROGRAMMING PROGRAMMING
ENVIORNMENT LANGUAGE
CODING PRINCIPLES
MODULAR DATA
PROGRAMMING INTERFACES
STRUCTURES
MEANINGFUL
SIMPLE LOGIC NESTED LOOP VARIABLE
NAMES
COMMENT INDENTATION &
STATEMENTS BLAINK LINES IN
IN CODE CODE
VALIDATION
PRINCIPLES
REVIEW THE PERFORM UNIT
REFACTOR THE
CODE TEST & CORRECT
CODE
THOROUGHLY THE ERRORS
SOFTWARE DEPLOYMENT
• Software Deployment means to hand over the finalized
product (software) to the customer.
• During software deployment of software component three
activities are carried out
• DELIVERY
• SUPPORT
• FEEDBACK
22-04-2021
CUSTOMER
EXPECTATIONS
ASSEMBLED
QUALITY
& TESTED
PRODUCT
SOFTWARE PACKAGE
DEPLOYMENT
PRINCIPLES
SUPPORT
INSTRUCTIONAL
MATERIAL SERVICE
READY
REQUIREMENT ENGINEERING
• REQUIREMENT GATHERING & ANALYSIS
• TYPES OF REQUIREMENTS
• ELICITING REQUIREMENTS
• DEVELOPING USE CASES
• BUILDING REQUIREMENT MODELS
• SOFTWARE REQUIREMENT SPECIFICATION (SRS)
22-04-2021
REQUIREMENT GATHERING & ANALYSIS
Requirement Engineering is the process of establishing
the services that the customer requires from a system.
22-04-2021
REQUIREMENT GATHERING & ANALYSIS
• REQUIREMENT ENGINEERING TASKS
• GOALS to achieve
• Understanding customer requirements and their needs.
• Analyzing the feasibility of the requirement.
• Negotiating the reasonable solutions.
• Specification of an unambiguous solution.
• Managing all the requirement into the operational systems.
• Transforming the requirements into the operational systems.
22-04-2021
INCEPTION
ELICITATION
REQUIRMENT ENGINEERING
TASK ELABORATION
NEGOTIATION
SPECIFICATION
VALIDATION
REQUIREMENT
MANAGEMENT
TYPES OF REQUIREMENTS
• There are mainly 2 types of requirements
• FUNCTIONAL REQUIREMENTS
• NON-FUNCTIONAL REQUIREMENTS
22-04-2021
TYPES OF REQUIREMENTS
• FUNCTIONAL REQUIREMENTS
• They describe all required functionality or system services.
• These are provided by the customer which indicates behavior
of system using particular inputs.
• These requirements are heavily dependent upon the type of
software, expected users and the type of system where the
software is used.
22-04-2021
TYPES OF REQUIREMENTS
• PROBLEMS ASSOCIATED WITH REQUIREMENTS
• REQUIREMENTS IMPRECISION
• USER INTENTION
• DEVELOPER INTERPRETATION
• REQUIREMENTS COMPLETENESS & CONSISTENCY
22-04-2021
TYPES OF REQUIREMENTS
• NON-FUNCTIONAL REQUIREMENTS
• They define system properties and constraints.
• They are more critical than functional requirements.
• Properties of a system can be:
• Reliability
• Response Time
• Storage Requirements
22-04-2021
TYPES OF NON-FUNCTIONAL REQUIREMENTS
Example : Enlist various functional and non functional requirements for the Bank
ATM system.
1. There should be the facility for the customer to insert a card.
2. The system should first validate card and PIN.
3. The system should allow the customer to deposit amount in the bank.
4. The system should dispense the cash on withdrawal.
5. The system should provide the printout for the transaction.
6. The system should make the record of the transactions made by particular
customer.
7. On invalid PIN entry for three times the card should be retained by the system.
8. The cash withdrawal is allowed in multiple of 100.
9. The cash deposition is allowed in multiple of 100.
10. The customer is allowed to transfer amount between the two accounts.
11. The customer is allowed to know the balance enquiry.
12. The customer is allowed to get the printout for desired transaction.
ELICITING REQUIREMENTS
Requirements Elicitation is the process to find out the
requirements for an intended software system by
communicating with client, end users, system users and others
who have a stake in the software system development.
22-04-2021
ELICITING REQUIREMENTS
• VARIOUS WAYS BY WHICH REQUIREMENT ELICITATION CAN
BE DONE ARE :-
• Collaborative Requirement Gathering
• Quality Function Deployment
• Use Scenarios
• Elicitation Work Product
22-04-2021
ELICITING REQUIREMENTS
• COLLABORATIVE REQUIREMENT GATHERING
• Collaborative requirement gathering is done using
collaborative, team-oriented approach.
• Facility Application Specification Technique (FAST) is an
approach in which joint team of customers and developers
work together to identify the problem, propose element
solution, negotiate different approaches and prepare a
specifications for preliminary set of solution requirements.
22-04-2021
ELICITING REQUIREMENTS
• QUALITY FUNCTION DEPLOYMENT
• Quality function deployment is a quality management
technique which translates the customer needs into technical
requirements.
• This technique was introduced in Japan.
22-04-2021
QFD REQUIREMENTS
NORMAL
REQUIREMENTS
EXPECTED
REQUIREMENTS
EXCITED
REQUIREMENTS
22-04-2021
ELICITING REQUIREMENTS
• USE SCENARIOS
Scenarios are created to understand working of features and
functions used by different classes of end-users. These scenarios
are represented by means of use-case diagrams.
22-04-2021
ELICITING REQUIREMENTS
• ELICITATION WORK PRODUCT
• Feasibility Study.
• Scope of system.
• List of stakeholders.
• Technical environment.
• Usage scenarios.
• Prototype.
22-04-2021
DEVELOPING USE CASES
• USE CASE DIAGRAM
• The purpose of use case diagram is to capture the dynamic
aspect of a system.
• Use case diagrams are used to gather the requirements of a
system including internal and external influences.
• These requirements are mostly design requirements.
• Hence, when a system is analyzed to gather its functionalities,
use cases are prepared and actors are identified.
22-04-2021
DEVELOPING USE CASES
• The purposes of use case diagrams can be said to be as
follows −
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors influencing the
system.
• Show the interaction among the requirements and actors.
22-04-2021
DEVELOPING USE CASES
• HOW TO DRAW A USE CASE DIAGRAM ?
• When we are planning to draw a use case diagram, we should
have the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
22-04-2021
DEVELOPING USE CASES
• After identifying the above items, we have to use the following
guidelines to draw an efficient use case diagram
• The name of a use case is very important. The name should be
chosen in such a way so that it can identify the functionalities
performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships, as the main purpose
of the diagram is to identify the requirements.
• Use notes whenever required to clarify some important points.
22-04-2021
Example 1 : Draw a use case diagram for a Bank Management System.
Example 2: Draw a use case diagram for Music Systems.
Example 3 : Draw a use case diagram for taking “photocopy of ans books
from MSBTE” website.
Example 4 : Draw a use case diagram for Ticket Reservation System.
Example 5 : Draw a use case diagram for Soda Machine.
BUILDING REQUIREMENT MODELS
• Requirement Analysis is an intermediate phase between
system engineering & software design.
• Requirement analysis produces a software specifications.
ANALYSIS DESIGN
MODEL MODEL
SYSTEM REQUIREMENT SOFTWARE
ENGINEERING ANALYSIS DESIGN
BUILDING REQUIREMENT MODELS
HOW IS REQUIREMENT ANALYSIS HELPFUL ?
ANALYST DESIGNER
DEVELOPER
BUILDING REQUIREMENT MODELS
WHAT ARE REQUIREMENT ANALYSIS EFFORTS ?
PROBLEM EVALUATION &
RECOGNITION SYNTHESIS
MODELLING SPECIFICATIONS
REVIEW
SOFTWARE REQUIREMENT SPECIFICATIONS
(SRS)
• DEFINITION
• A Software Requirements Specification (SRS) is a document
that is created when a detailed description of all aspects of
the software to be built that must be specified before the
project is to commence.
22-04-2021
SOFTWARE REQUIREMENT SPECIFICATIONS
(SRS)
• NEED OF SRS
• It establishes the basis for agreement between the customers
and the suppliers on what the software product is to do.
• Reduces the development effort.
• Provide a basis for estimating cost and schedules.
• Provide a baseline for verification and validation.
• Facilitate Transfer.
• Serve as basis for enhancement.
22-04-2021
SOFTWARE REQUIREMENT SPECIFICATIONS
(SRS)
• CHARACTERISTICS OF SRS
• CORRECT
• COMPLETE
• UNAMBIGUOUS
• CONSISTENT
22-04-2021
SOFTWARE REQUIREMENT SPECIFICATIONS
(SRS)
• FORMAT OF SRS • OTHER NON FUNCTIONAL
• INTRODUCTION ATTRIBUTES
• GENERAL DESCRIPTION • OPERATIONAL SCENARIOS
• FUNCTIONAL REQUIREMENTS • PRELIMANARY SCHEDULE
• INTERFACE REQUIREMENTS • PRELIMANARY BUDGET
• PERFORMANCE REQUIREMENTS • APPENDICES
• DESIGN CONSTRAINTS
22-04-2021