S. E.

Computer
210253: Software Engineering
Course Objectives:

• To learn and understand the principles of Software

Engineering
• To be acquainted with methods of capturing, specifying,
visualizing and analyzing software requirements.
• To apply Design and Testing principles to S/W project
development.
• To understand project management through life cycle of
the project.
 S. E. Computer
210253: Software Engineering
Course Outcomes:

• Analyze software requirements and formulate design solution for a software.

• Design applicable solutions in one or more application domains using software
engineering approaches that integrate ethical, social, legal and economic
concerns.
• Apply new software models, techniques and technologies to bring out innovative
and novelistic solutions for the growth of the society in all aspects and evolving
into their continuous professional development.
• Model and design User interface and component-level.
• Identify and handle risk management and software configuration management.
• Utilize knowledge of software testing approaches, approaches to verification and
validation.
• Construct software of high quality – software that is reliable, and that is
reasonably easy to understand, modify and maintain efficient, reliable, robust
and cost-effective software solutions.
 Unit II:
Software Requirements Engineering
& Analysis Modeling

Reference:
• Roger S Pressman “Software Engineering : A Practitioner’s
Approach “ 7th Edition Mcgraw-Hill ISBN:0073375977

Slides prepared by: Mr. Amol J. Gosavi

for SE Computer Engineering
Overview :

 Requirements Engineering,
 Establishing the Groundwork,
1. Identifying Stakeholders,
2. Recognizing Multiple Viewpoints,
3. working toward Collaboration,
4. Asking the First Questions,
 Eliciting Requirements,
1. Collaborative Requirements Gathering,
2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation Work Products,
 Developing Use Cases
 Building the Requirements Model,
1. Elements of the Requirements Model
 Negotiating Requirements,
 Validating Requirements.
1-4
 REQUIREMENTS ENGINEERING
 What is Requirements?
 Who does it?

 Why it is Important?

 What are the Steps?

5
 What is work product?

 How do I ensure that I’ve done it right?

 REQUIREMENTS ENGINEERING
 What is Requirements?
 Who does it? Software / System Engineers

 Why it is Important?

 What are the Steps?

6
Inception-Define Scope and Nature of Problem
Elicitation-Define what is required
Elaboration-Refined and Modify basic requirements
Negotiation-Priorities, Essential, when required
Specification-Function, Constraints and Performance
Validation- Quality Assessment
Management- Identify, Control, Track and Changes
 What is work product?
Usage Scenarios, Functions, Feature list, Models
 How do I ensure that I’ve done it right?
 REQUIREMENTS ENGINEERING
 Designing and Building an elegant computer program
that solves the wrong problem serves no one’s needs.

 That’s why it’s important to understand what the

customer wants before you begin to design and

7
build a computer-based system.

 The broad spectrum of tasks and techniques that lead

to an understanding of requirements is called
Requirements Engineering.
 REQUIREMENTS ENGINEERING
 Requirements Engineering begins during the
communication activity and continues into the
modeling activity.

8
 It must be adapted to the needs of the process, the
project and the people doing the work.

 Requirement Engineering is the process of

1. Establishing the services that customer requires from
system
2. The Constraints under which it operate and is
developed
 REQUIREMENTS ENGINEERING
o The intent of requirements engineering is to
provide all parties with a written understanding of
the problem.

9
o This can be achieved though a number of work
products:

o Usage Scenarios,
o Functions and Features lists,
o Requirements models, or
o Specification.

Requirement engineering establishes a solid base for design

and construction. Without it, the resulting software has a
high probability of not meeting customers need
 REQUIREMENTS ENGINEERING

 Requirements Engineering builds a bridge to design and

construction.

10
 Requirements Engineering (Goals) provides the
appropriate mechanism for understanding
 What the customer wants?
 Analyzing Needs,
 Assessing Feasibility,
 Negotiating a reasonable solution,
 Specifying the solution Unambiguously,
 Validating the specification,
 Managing all the Requirements,
 Transformed into an operational system and
construction.
REQUIREMENTS ENGINEERING
TASKS

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. (Requirements) management
Inception
Elicitation
Elaboration

12
Negotiation
Specification
Validation
Requirements
Management
 1) INCEPTION:
 Inception: Specifying the beginning of the software
project

 How does a software project get started?

13
 Most projects begin when a business need is
identified or a potential new market or service is
discovered.
 Stakeholders* from the business community (e.g.,
business managers, marketing people, product
managers) define a business case for the idea, try to
identify the breadth and depth of the market, do a
rough feasibility analysis, and identify a working
description of the project’s scope.
* Stakeholders: an entity that takes active participation in project development (Feasibility study and scope of project)
 1) INCEPTION:
 All of this information is subject to change, but it is
sufficient to precipitate discussions with the software
engineering organization.

 To establish a basic understanding of the problem,

14
the people who want a solution, the nature of the
solution that is desired, and the effectiveness of
preliminary communication and collaboration between
the other stakeholders and the software team.

Purpose:
 Basic understanding of project.

 Solutions and Nature of finding solutions

 Communication between developers and customers .

 2) ELICITATION:
 Elicit : To obtain / extract (answers)
 Requirement discovery

15
 2) ELICITATION:
 Ask the customer, the users, and others
o The objectives for the system or product are,
o What is to be accomplished,
o How the system or product fits into the needs of the

16
business,
o How the system or product is to be used on a day-to-
day basis.

But it isn’t simple—it’s very hard.

 2) ELICITATION:
Why it is difficult to gain a clear understanding of what
the customer wants?

17
 Christel and Kang identify a number of problems that
are encountered as elicitation occurs.

Issues in Elicitation :

 1. Problems of scope
 2. Problems of understanding
 3. Problems of volatility
 2.1 PROBLEMS OF SCOPE:

 The boundary of the system is ill-defined or the

customers / users specify unnecessary
technical detail that may confuse, rather than
clarify, overall system objectives.

18
 2.2 PROBLEMS OF UNDERSTANDING
 The customers/users
1. Not completely sure of what is needed?

2. Poor understanding of the capabilities and

limitations of their computing environment,

19
3. Don’t fully understanding the problem domain,

4. Trouble communicating needs to the system

engineer, Omit information that is believed to be
“obvious,”

5. Specify requirements that conflict with the needs of

other customers / users, or specify requirements that
are ambiguous or untestable.
2.3 PROBLEMS OF VOLATILITY
The requirements change over time.

20
 3. ELABORATION
 The information obtained from the customer during inception and
elicitation is expanded and refined during elaboration.

 Focuses on developing a refined requirements model that identifies

21
various aspects of software function, behavior, and information.

 Elaboration is driven by the creation and refinement of user

scenarios that describe how the end user (and other actors) will
interact with the system.

 Each user scenario is parsed to extract analysis classes—

business domain entities that are visible to the end user.
 The attributes of each analysis class are defined, and the
services that are required by each class are identified.

 The relationships and collaboration between classes are

identified, and a variety of supplementary diagrams are

22
produced.

 GOAL: Prepare technical model of software

function, features and constraints .
4. NEGOTIATION
 It isn’t unusual for customers and users to ask for
more than can be achieved, given limited business
resources.

23
 It’s also relatively common for different customers to
propose conflicting requirements

 You have to reconcile these conflicts through a process of

negotiation.

 Customers, users, and other stakeholders are asked to

rank requirements and then discuss conflicts in
priority.
 Using an iterative approach that
 prioritizes requirements,

 assesses their cost and risk,

24
 addresses internal conflicts,

 requirements are eliminated, combined, and/or

modified so that each party achieves some measure
of satisfaction.
5. SPECIFICATION
 A specification can be a written document, a
set of graphical models, a formal
mathematical model, a collection of usage

25
scenarios, a prototype, or any combination of
these.

 It describes software function, constraints

and performance of system.
6. VALIDATION
 The work products produced are assessed for quality
during a validation step.

26
 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.

 FTR
 The primary requirements validation mechanism is the
technical review.

 The review team that validates requirements includes

1. software engineers,
2. customers,

27
3. users, and
4. other stakeholders

 who examine the specification looking for errors in

content or interpretation, areas where clarification may
be required, missing information, inconsistencies
 7. REQUIREMENTS MANAGEMENT
 Requirements for computer-based systems change, and
the desire to change requirements persists throughout
the life of the system.

 Requirements management is a set of activities that help

28
the project team identify, control, and track
requirements and changes to requirements at any time
as the project proceeds. (Software Configuration
Management Techniques)

 Process of managing changing requirements during the

requirements engineering process and system
development.
 Beginning
Identify
Stakeholders
Multiple
Inception viewpoints
Initiate
Communication
Elicitation
Explanation

29
Elaboration •

Analyzing Phase
Negotiation

Specification
Extraction

Validation
Problem of Problem of Problem of
scope understanding Volatility
Requirements
Management
 Inception

Elicitation

30
Elaboration

Negotiation Cooperation

Final Work SRS Specification

Product

Errors Detected in SRS has to be Validation

corrected

Requirements
Management
 SCM

31
SOFTWARE REQUIREMENTS
o Description of services which a software will provide to
the end user.

o Constraints which we will imposed on the services are

32
also part of the requirements.

User of any software will be the company for which you

developed the software
End User the person who is actually using the software
sitting in front of the computer.
ESTABLISHING THE GROUNDWORK
o Requirements engineering is simply a matter of
conducting meaningful conversations with colleagues who
are well-known members of the team.

33
Customer(s) or end users
1. May be located in a different city or country,
2. May have only a vague idea of what is required,
3. May have conflicting opinions about the system to be
built,
4. May have limited technical knowledge, and
5. May have limited time to interact with the requirements
engineer
ESTABLISHING THE GROUNDWORK
o Steps required to establish the ground work for an
understanding of software requirements to get the project
started in a way that will keep it moving forward toward
a successful solution.

34
1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions
 ELICITING REQUIREMENTS
• Requirements elicitation (also called requirements
gathering) combines elements of

problem solving,
elaboration,

35
negotiation, and
Specification.

• Requirements elicitation is the activity during which

software requirements are discovered, articulated and
revealed from stakeholders or derived from system
requirements.

• Sources: SRD, Customers, end-users, domain specialist

or market analysis.
 ELICITING REQUIREMENTS
• Requirements elicitation Process:

1. Identify stakeholders (users, customers and domain

experts)

36
2. Questionaries' ( Understanding problem, issues and
constraints)

3. Analyze information (conflicts, ambiguities,

inconsistencies, problems or unresolved issues)

4. Confirm understanding requirements with stakeholders.

5. Create requirement statements

 ELICITING REQUIREMENTS PRESSMAN 128

1. COLLABORATIVE REQUIREMENTS GATHERING

37
2. QUALITY FUNCTION DEPLOYMENT

3. USAGE/ USER SCENARIOS

4. ELICITATION WORK PRODUCTS

 1. COLLABORATIVE
REQUIREMENTS GATHERING

Collaboration- ….

38
Basic Guidelines
• Meetings are conducted and attended by both software
engineers, customers, and other interested stakeholders.

• Rules for preparation and participation are

established.

39
• An " agenda " is suggested that is formal enough to cover
all important points but informal enough to encourage the
free flow of ideas.

• A “ facilitator " (customer, developer, or outsider) controls

the meeting.

• A " definition mechanism " is used such as work sheets,

flip charts, wall stickers, electronic bulletin board, chat
room, or some other virtual forum
THE GOAL IS TO:

1. IDENTIFY THE PROBLEM,

2. PROPOSE ELEMENTS OF THE SOLUTION,

40
3. NEGOTIATE DIFFERENT APPROACHES

4. SPECIFY A PRELIMINARY SET OF SOLUTION REQUIREMENTS

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.

41
QFD “concentrates on maximizing customer
satisfaction from the software engineering process”.

Needs Technical Requirements

QFD : TYPES OF REQUIREMENTS
1. NORMAL REQUIREMENTS

2. EXPECTED REQUIREMENTS

42
3. EXCITING REQUIREMENTS
 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.

 Examples:
 Requested types of graphical displays,
 Specific system functions
 Defined levels of performance.
 EXPECTED REQUIREMENTS

 These requirements are implicit to the product or system

and may be so fundamental that the customer does not
explicitly state them.

 Their absence will be a cause for significant dissatisfaction.

 Examples:

 Ease of human/machine interaction,

 Overall operational correctness and reliability,
 Ease of software installation
 EXCITING REQUIREMENTS

 These features go beyond the customer’s

expectations and prove to be very satisfying when
present.

 Examples :
 word processing software:
 Basic features are always provided by default.
 Advanced Graphical Features are exciting
 QUALITY FUNCTION DEPLOYMENT

 QFD uses raw data for the requirements gathering

activity
 customer interviews
 Observation
 Surveys
 examination of historical data (e.g., problem reports)

 These data are then translated into a table of

requirements called the customer voice table that is
reviewed with the customer and other stakeholders.
 3. USAGE / USER SCENARIOS

• Difficult to understand how functions and features will be

used by different classes of end users.

• Developers and users create a set of scenarios that identify a

47
thread of usage for the system to be constructed.

*Use cases..
 4. ELICITATION WORK PRODUCTS
• A STATEMENT OF NEED AND FEASIBILITY.

• A BOUNDED STATEMENT OF SCOPE FOR THE SYSTEM OR PRODUCT.

• A LIST OF CUSTOMERS, USERS, AND OTHER STAKEHOLDERS WHO

PARTICIPATED IN REQUIREMENTS ELICITATION.

48
• A DESCRIPTION OF THE SYSTEM’S TECHNICAL ENVIRONMENT.

• A LIST OF REQUIREMENTS (PREFERABLY ORGANIZED BY FUNCTION) AND

THE DOMAIN CONSTRAINTS THAT APPLY TO EACH.

• A SET OF USAGE SCENARIOS THAT PROVIDE INSIGHT INTO THE USE OF THE
SYSTEM OR PRODUCT UNDER DIFFERENT OPERATING CONDITIONS.

• ANY PROTOTYPES DEVELOPED TO BETTER DEFINE REQUIREMENTS

END OF ELICITING REQUIREMENTS

 DEVELOPING USE CASES
• A use case captures a contract ... [that] describes the
system’s behavior under various conditions as the
system responds to a request from one of its
stakeholders . . .

• A use case tells a stylized story about how an end

user (playing one of a number of possible roles)
interacts with the system under a specific set of
circumstances.

• The story may be narrative text, an outline of tasks or

interactions, a template-based description, or a
diagrammatic representation.

• A use case depicts the software or system from the end1-49

user’s point of view.
 USE CASES
• Fundamental units of modeling language, in which
functionalities are distinctly presented.

• Scenario based technique.

• Help to identify individual interaction with the system.

• Extensively used for requirement elicitation.

• Proper use case identifies the major requirements.

• Typical Notation: Next page

• Extend is used when a use case adds steps to another first-class use case.
• Include is used to extract use case fragments that are duplicated in
1-50
multiple use cases.
 USE CASES
• Use cases are a useful tool for software product managers
and their development teams when establishing
requirements.

• By creating use cases and sharing them with clients, the

project has more definite guidelines, and development
tasks become more organized and elaborate.

• Use case diagrams are high-level, visual representations

outlining all the tasks supported by the product being
created.
• Actors and their respective uses cases are also
represented.
• Overall, the diagram should show the entire product,
tasks that may be undertaken while engaging with 1-51 the
product, and roles supported by the product.
USE CASES

1-52
 USE CASES
• The first step in writing a use case is to define the set of “actors”
that will be involved in the story.

• Actors are the different people (or devices) that use the system or
product within the context of the function and behavior that is to
be described.

• Actors represent the roles that people (or devices) play as the
system operates.

• An actor is anything that communicates with the system or

product and that is external to the system itself.

• Every actor has one or more goals when using the system
1-53
 USE CASES
• Primary actors interact to achieve required system function and
derive the intended benefit from the system.

• They work directly and frequently with the software.

• Secondary actors support the system so that primary actors can do

their work.

• Once actors have been identified, use cases can be developed

1-54
 USE CASES
• Jacobson suggests a number of questions12 that should be
answered by a use case.
1. Who is the primary actor, the secondary actor(s)?
2. What are the actor’s goals?
3. What preconditions should exist before the story begins?
4. What main tasks or functions are performed by the actor?
5. What exceptions might be considered as the story is
described?
6. What variations in the actor’s interaction are possible?
7. What system information will the actor acquire, produce, or
change?
8. Will the actor have to inform the system about changes in
the external environment?
9. What information does the actor desire from the system?
10. Does the actor wish to be informed about unexpected 1-55

changes?
USE CASES

1-56
 BUILDING THE REQUIREMENT MODEL
• The intent of the analysis model is to provide a description of the
required informational, functional, and behavioral domains for
a computer-based system.

• The model changes dynamically as you learn more about the

system to be built, and other stakeholders understand more about
what they really require.

• As the requirements model evolves, certain elements will become

relatively stable, providing a solid foundation for the design
tasks that follow.

• Other elements of the model may be more volatile, indicating that

stakeholders do not yet fully understand requirements for the
system. 1-57
 ELEMENTS OF THE REQUIREMENTS MODEL
• Scenario-based elements: The system is described from the
user’s point of view using a scenario-based approach.

• Class-based elements: Each usage scenario implies a set of

objects that are manipulated as an actor interacts with the system.

• Behavioral elements: The behavior of a computer-based system

can have a profound effect on the design that is chosen and the
implementation approach that is applied.

• Flow-oriented elements: Information is transformed as it flows

through a computer-based system. The system accepts input in a
variety of forms, applies functions to transform it, and produces
output in a variety of forms 1-58
 ELEMENTS OF ANALYSIS MODEL
Manipulation
How , relationship
user between
interact object and
with collaboration
system between
classes

How
Ext.
events
System as
change
information
state of
transform.
system
(Data object)

• Each element of requirement model presents the problem from

different point of view. Chapter 6 Pressman 59
 NEGOTIATING REQUIREMENTS
• An ideal requirements engineering context, the inception,
elicitation, and elaboration tasks determine customer
requirements in sufficient detail to proceed to subsequent
software engineering activities.

• The intent of this negotiation is to develop a project plan that

meets stakeholder needs while at the same time reflecting the
real-world constraints (e.g., time, people, budget) that have been
placed on the software team.

1. Identification of the system or subsystem’s key stakeholders.

2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile
them into a set of win-win conditions for all concerned 1-60
(including the software team).
 VALIDATING REQUIREMENTS
• The requirements represented by the model are prioritized by the
stakeholders and grouped within requirements packages that will
be implemented as software increments.

• When I review requirements, what questions should I ask?

1. Is each requirement consistent with the overall objectives for the

system/product?

2. Have all requirements been specified at the proper level of

abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?

3. Is the requirement really necessary or does it represent an add-

on feature that may not be essential to the objective of the 1-61
system?
4. Is each requirement bounded and unambiguous?
 VALIDATING REQUIREMENTS
5. Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?

6. Do any requirements conflict with other requirements?

7. Is each requirement achievable in the technical environment that

will house the system or product?

8. Is each requirement testable, once implemented?

9. Does the requirements model properly reflect the information,
function, and behavior of the system to be built?
10. Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system?
11. Have requirements patterns been used to simplify the 1-62
requirements model? Have all patterns been properly validated?
Are all patterns consistent with customer requirements?
 63
UNIT II END
 64
EXTRA SLIDES
(IMPORTANT FOR READING)
 65
REQUIREMENTS ELICITATION
PROCESS (ADDITIONAL INFO.)
1. REQUIREMENTS ELICITING AND ANALYSIS
1. STAKEHOLDERS

2. REQUIREMENT ELICITATION AND ANALYSIS PROCESS

1. REQUIREMENT DISCOVERY
2. CLASSIFICATION AND DISCOVERY
3. PRIORITIZATION
4. DOCUMENTATION

3. REQUIREMENT DISCOVER

66
1. INTERVIEWING
2. VIEW POINT
3. USE CASES
4. ETHOGRAPHY

1. REQUIREMENT VALIDATION
• TECHNIQUIES
1. REQUIREMENT REVIEWS
2. PROTOTYPING
3. TEST CASE GENERATION

2. REQUIREMENT MANAGEMENT
1. ENDURING AND VOLATILE REQUIREMENT
2. REQUIREMENT MANAGEMENT PLANNING
3. REQUIREMENT CHANGE MANAGEMENT
 STAKEHOLDERS

1-67

Fig. List of Problems encountered in understanding the requirements of the

system.
 REQUIREMENT ELICITATION AND
ANALYSIS PROCESS

1-68
Fig. Requirement elicitation and analysis process
 MULTIPLE VIEWPOINT

• Marketing Group: Interested in Functions and Features

• Business Managers: Interested in Features within

budget to meet market window.

• End Users: Wants Familiar functions, easy to learn and

use.

• Software Engineers: Concerned with Functions invisible

to non technical stakeholders , Enables infrastructure that
support marketable functions and features.

• Support Engineers: Focus on maintainability

1-69
 VIEW POINT
Provides perspective to the system and requirements discovering,
useful in classifying stakeholders.

Indirect : Not using system directly.

Interactor : Interaction between systems.
Domain : GUI 1-70

Fig. View point for library management system.

 ETH(N)OGRAPHY
• Is a technique of observation which is used to understand
social and organizational requirements.

• System analyst imagines himself as a part of working

environment and observes day-to-day activities.

• Noted the needs and tasks required, Finds implicit

requirements.

• To understand the relationship between work done by

people with organization, ethnographic technique used.
Ethnographic Focused
Meeting
analysis Etnography

Prototype
Complete Evaluation 1-71
system
development System
Prototype
1-72
 SRS
SOFTWARE REQUIREMENTS SPECIFICATION
Problems without SRS :

Goals :
Feedback to Customer,

73

 Problem decomposition,
 Input to design specification,
 Production Validation Check

Useful in:
 Estimation Cost
 Planning Team Activity
 Performing Task
 Tracking Team Progress throughout development.
 WHO ARE USING SRS ?

74
 Who Writes SRS? System Architects and Programmers
 75
Templates can be helpful for presenting statements and managing their traceability.
 SOFTWARE REQUIREMENTS SPECIFICATION
TEMPLATE (IEEE 87, IEEE 94)
 1. Introduction
 1.1 Purpose
 1.2 Scope
 1.3 Definition, Acronyms and Abbreviations

76
 1.4 References
 1.5 Overview
 2. Overall (General) Description
 2.1 Product Perspective
 System Interfaces
 Interfaces

 Hardware Interfaces

 Software Interfaces

 Communication

 Memory constraints

 Operations

 Site Adaptation Requirements

SOFTWARE REQUIREMENTS SPECIFICATION
TEMPLATE (IEEE 87, IEEE 94)
 2.2 Product Functions
 2.3 User Characteristics
 2.4 Constraints
 2.5 Assumptions and Dependencies

77
 2.6 Apportioning of Requirements

 3. Specific Requirements
 3.1 External Interfaces
 3.2 Functions Requirments
 3.3 Performance Requirements
 3.4 Logical Database Requirements
 3.5 Design Constraints
 Standard Compliances
 Hardware Limitations
SOFTWARE REQUIREMENTS SPECIFICATION
TEMPLATE (IEEE 87, IEEE 94)
 3.6 Software System Attributes
 Reliability
 Availability

 Security

78
 Maintainability

 Portability

 3.7 Organizing the Specific Requirements

 System Mode
 User Class

 Objects

 Features

 Stimulus

 Response

 Functional Hierarchy

 3.8 Additional Comments

SOFTWARE REQUIREMENTS SPECIFICATION
TEMPLATE (IEEE 87, IEEE 94)
 4. Change Management Process
 5. Document Approvals
Approver’s Name, Signature and Date

79


 6. Supporting Information
 Table of content
 Index
 Appendices
 References

 Typically software designers use IEEE STD 830-1998 as

the basic for entire software specifications.
WAYS OF WRITING A SRS
 Structured & Tabular SRS
e.g. an insulin pump case study,

STATUS CONDITION ACTION

Sugar level falling L3 < L2 Dose d=0

80
Sugar level stable L3 = L2 Dose d=0

Sugar level increasing & (L3 - L2) < (L2 < L1) Dose d=0
rate of increasing is
decreasing
Sugar level increasing & (L3 - L2) >= (L2 < L1) Dose
rate of increasing is d= Round[(L3 - L2) /4]
stable or increasing If Rounded result = 0
Dose d=min_Dose
 STRUCTURED SRS
 Purpose: Compute Insulin dose to maintain level
 Problem description : current sugar level in safe zone
then compute required insulin.
 I/P: Previous(L1,L2),Current (L3)

 O/P: D (Appropriate dose)

 Source : Current and from memory

 Destination: Main control loop

 Action: status..

 Requirements :Previous(L1,L2)

 Pre-condition: single dose in pump

 Post-condition: L1L2,L2L3

 Side Effects: None 1-81

Structured SRS

1-82
Tabular SRS

1-83
 CHARACTERISTICS OF SRS
 Correctness: Every requirements in final system
 Completeness : what s/w designer want to create a s/w.
Focusing on problems, goals and objective. Fulfill Scope
and boundaries
 Consistent : ref. to functionalities identified, correct

84
results across the system.
 Modifiable : structure & style

 Testability :confirm specifications and requirements

 Unambiguous: one and only one interpretation.

 Verifiable: exists cost effective process

 Traceable : Backward and Forward Traceability

 Valid :

 Accurate :

 Ranking :
REQUIREMENTS ENGINEERING
o Description of the system services and constraints.
o It can range from a high level abstract statement of a
service to a detail mathematical functional specification.

o Types:

85
1. User Requirements: Natural Language statements by
customer, for customers.
2. System Requirements: Structured document detailed
description of system services. Functions Service,
Constraints. structured document, serves as contract
between customer and developer.
3. Software Requirements: Detailed software description
that serves as a basis for design or implementation by
developer.
4. **Interface Specification: Application Programming
Interfaces(API) are specifies SRS. What kind of interfaces
customer desires
USER AND SYSTEM REQUIREMENTS

86
FUNCTIONAL , NON FUNCTIONAL REQUIREMENTS
&

87
GOALS OF IMPLEMENTATION

[PARTS OF SRS DOCUMENTS ]

 FUNCTIONAL REQUIREMENTS:
 “What the System should do”.

 This is the list of the actual services which a system

will provide,

88
 This is the list of the services/ Functions which a
user wants from the software,

 Are those that describe the system’s functionality.

 Depict the system’s behavior when given a specific input.

 Is the core set of requirements, which enables the

system to function
EX: IDENTIFYING AND DOCUMENTING
FUNCTIONAL REQUIREMENTS
Example:
 Features of software which the client demands.

 Business rules of the particular organization for which

89
developing software.

 ATM System or Library system?

Functional Requirements:
Enlist Facilities provided by ATM……
 NON FUNCTIONAL REQUIREMENTS
 How a system should behave while performing the
operations.

 These are the constraints on the services which

system is offering e.g. Timing of operations, way to
response in particular condition.

90
 Sometimes called as Quality Attributes.

 Describe the system’s properties or constraints. {implied

too, behavior NOT affected directly}
Goals of implementation
 Documents some general suggestions regarding
development
 Guide to design goals.
Examples:
 Response Time ,
 User Friendliness ,
 Performance Requirements,
 Aesthetics,
 Security Requirements,
 Software Quality,

91
 Recoverability,

Importance of Non Functional Requirements

 These are not ignorable requirements you can’t say as these are
non-functional so we should not worry about it.
 More critical than functional requirements.
 These requirements are something which user do not explain most of
the time but want in the system.
 These requirements are directly related to the using experience
of user and end user,
 1-92
Classification Of Non-Functional Requirements
 PERFORMANCE REQUIREMENTS
AND TYPES & METRICS
 Performance or Durability of functioning.
 Metrics used to specify Non Functional Requirments
measured during testing.

93
Property Metrics
Speed (speed of the processed Events per response time processed
transactions) transaction per second.
Size Kilobytes
Reliability MTTF, Rate of failure, Occurrence
availability
Robustness Time to recover after failure,
Probability of events causing failure

Portability, Ease of Use Number of target statements

 DOMAIN REQUIREMENTS
 Requirements derived from Application Domain.

 Use specific Domain Terminologies.

 Specialized so Difficult to Co-relate with System

94
Requirements.

 If not satisfied, System may be unworkable.

 e.g. Domain requirements for the Library system,

academic software.

 User interfaces for handling databases and UI

accordingly international standards.
 Copyright restrictions on some documents.
 REQUIREMENTS ENGINEERING PROCESS

95
Fig. Requirements Engineering process :

Discovery, Analysis, Validation of system requirements.

SPIRAL VIEW OF REQUIREMENTS ENGINEERING

 Feasibility Study

96
 Requirements Elicitation & Analysis

 Requirements Specification

 Requirements Validation
 Generic Activities
1. Requirement Elicitation
2. Requirement Analysis
3. Requirement Validation

97
4. RequirementManagement

Fig. A Spiral view of Requirements Engineering process

 DEVELOPING WEBSITE
 In developing the web application for the auto car shop,
some of the Functional Requirements could include:

 The web application shall accept customer orders.

98
 The web application shall be able to cash a sale.

 The web application shall produce a receipt detailing a

customers’ purchase information and include name of customer,
items purchased, cost of each item and total cost.

 The web application shall be able to produce weekly, monthly

and yearly reports about sales.
 DEVELOPING WEBSITE
Non Functional requirements :

 The web application shall be easy to use by all employees

including sales representatives and managers.

99
 The web application shall be available in several languages.

 The web application shall allow several sales to be made at the

same time without downgrading performance
VALIDATING REQUIREMENTS
 Pressman 5.7

100
 TECHNIQUIES
1. REQUIREMENT REVIEWS
2. PROTOTYPING
3. TEST CASE GENERATION
 REQUIREMENTS VALIDATION TECHNIQUES
 Requirement Reviews:
 Manual Analysis of system.
 Involvement of Stakeholders.
 Formal or Informal Reviews.
 Healthy communication.

101
 Prototyping:
 Check requirements by Executable model of system

 Test Case Generation:

 Verifiability
 Comprehensibility
 Traceability
 Adaptability
 QUESTIONS TO ASK WHEN VALIDATING REQUIREMENTS
[REVIEW]

 Is each requirement consistent with the overall objective for

the system/product?

Have all requirements been specified at the proper level of

102

abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?

 Is the requirement really necessary or does it represent an

add-on feature that may not be essential to the objective of the
system?

 Is each requirement bounded and unambiguous?

 Does each requirement have attribution? That is, is a

source (generally, a specific individual) noted for each
requirement?
 QUESTIONS TO ASK WHEN VALIDATING REQUIREMENTS
[REVIEW]

 Do any requirements conflict with other requirements?

 Is each requirement achievable in the technical environment

103
that will house the system or product?

 Is each requirement testable, once implemented?

 Does the requirements model properly reflect the

information, function, and behavior of the system to be
built?

 Has the requirements model been “partitioned” in a way that

exposes progressively more detailed information about the
system?
REQUIREMENTS MANAGEMENT
 Process of managing changing requirements during the
requirement engineering process and system development.

ENDURING AND VOLATILE REQUIREMENT

104
1. Enduring:
 Stable requirements derived from core activity of organization.

 Depend upon Application Domain

e.g. banking system – online transfer

2. Volatile:
 Requirements may get changes

 Mutable Requirements
 Consequential
 Emergent
 Compatible
REQUIREMENTS MANAGEMENT
REQUIREMENT MANAGEMENT PLANNING

 Traceability is concerned with relationship between

requirements their sources and the system design.
 Using Traceability the requirements finding gets easy

105
 Traceability Types
 Source Traceability
 Requirements Traceability
 Design Traceability
 REQUIREMENTS MANAGEMENT
 After the requirements are finalized, a Traceability Table is
developed.
 Features Traceability Table
 Software Traceability Table
 Dependency Traceability Table

106
 Subsystem Traceability Table
 Interface Traceability Table
 REQUIREMENTS MANAGEMENT

 Product features and ensure how it is closely related to

customer requirements.

 Identifies the source of each requirement.

107
 Observes the relationships between the requirements.

 Classifies requirements as per the subsystem they

belong.

 Indicates internal & external interfaces as per given

requirement.
GENERIC TRACEABILITY TABLE

A01 A02 A03 A04

R01

108
R02
R03
R04
 REQUIREMENT CHANGE MANAGEMENT
 Requirements may get changed.

 Three Stages of requirement change management

process

109
1. Problem Analysis and Change Specification
2. Change Analysis and Costing
3. Change Implementation
 CASE STUDY : MENTAL HEALTH CARE PATIENT
MANAGEMENT SYSTEM (MHC-PMS)
System Description:
 Information system
 Centralized database
 Online or Offline connectivity

110
 Interact or exchange data with other clinical Information System

Goal of MHC-PMS:
 Provide the Information
 Generate management information

Functionality:
 Individual Care Management
 Patient Monitoring
 Administrative Reporting
 REQUIREMENTS ANALYSIS over……

111
 DEVELOPING USE CASES

 Step One – Define the set of actors that will be involved in

the story

112
 Step Two – Develop use cases, where each one answers a
set of questions

(More on next slide)

 QUESTIONS COMMONLY ANSWERED
BY
A USE CASE

 Who is the primary actor(s), the secondary actor(s)?

113
 What are the actor’s goals?

 What preconditions should exist before the scenario begins?

 What main tasks or functions are performed by the actor?

 What exceptions might be considered as the scenario is

described?

Continue…
 What variations in the actor’s interaction are
possible?

 What system information will the actor acquire,

produce, or change?

114
 Will the actor have to inform the system about
changes in the external environment?

 What information does the actor desire from the

system?

 Does the actor wish to be informed about

unexpected changes?
 115
Fig. UML use case diagram for SafeHome home security function.
 Primary Actor
 Secondary Actor

116
117
 2020-21 (SEMESTER 2)
SUBJECT: SOFTWARE ENGINEERING

THEORY ASSIGNMENT 2
S.E. COMPUTER
UNIT II

Course Outcome: 02
Date of giving Assignment: / /2021
Submission Date: / /2021
Q1.Explain the Importance of Requirements Engineering and list the
tasks involved.

Q2. Explain structure of SRS? What are characteristics of good SRS ?.

Q3. State and explain different methods of Elicitation with limitation

119
Q4.What are Functional and non functional requirements of
software.

Q5. Discuss Case study of Insulin Pump with Tabular SRS and Structured
SRS

Q6.Difference between requirement elicitation and requirement inception?

Why requirement elicitation is difficult?

Q7. Explain various categories of non functional requirements and

importance?

Q8. Explain general process model of requirement elicitation and analysis

process.