Requirements Analysis

and Specification (Lecture 3)

Prof. S. K. Swain
School of CE, KIIT,
Bhubaneswar

1
 Organization of this
Lecture
●
Introduction
●
Requirements analysis
●
Requirements specification
●
SRS document
●
Decision table
●
Decision tree
●
Summary
2
What are Requirements ?
A condition or capability needed by
a user to solve a problem or achieve
an objective.
 A condition or capability that must

be met or possessed by a system to

satisfy a contract, standard,
specification, or other formally
imposed document.
 Software requirements specify what

the software must do to meet the

business needs.

3
Requirements CONT…

●
It is the analyst's job to understand
these requirements and provide an
appropriate solution.
●
To be able to do this, the analyst
– Must understand the client's business
domain
– Who are all the stakeholders,
– How they affect the system,
– What are the constraints,
– What are the alterable, etc.

4
 Requirements
Definition/Specification
●
Requirements Definition
– Customer-oriented descriptions of the
system’s functions and constraints on its
operation.
– Written for customers.
●
Requirements Specification
– Precise and detailed descriptions of the
system’s functionality and constraints.
– Written as a contract between client and
contractor.

5
 Goals of Requirements
Analysis and Specification

– Fully understand the user

requirements.
– Remove inconsistencies,
anomalies, etc. from requirements.
– Document requirements properly
in an SRS document.

6
 Who Carries Out
Requirements Analysis
and Specification?
●
The person who undertakes
requirements analysis and specification:
– Known as systems analyst:
– Collects data pertaining to the product
(Also known as requirements elicitation)
– Analyzes collected data:
●
To understand what exactly needs to be
done.
– Writes the Software Requirements
Specification (SRS) document.
7
 Requirements Elicitation
●
is a critical step in software development,
where the needs and constraints of
stakeholders are gathered to define the
software requirements.

●
This process ensures that the final product
meets user needs and expectations.

●
Effective requirements elicitation sets the
foundation for successful software
development by ensuring that the end product
aligns with user needs and expectations 8
 Best Practices in
Requirements Elicitation
●
Involve stakeholders throughout the
process
●
Clear Communication: Use clear and
understandable language.
●
Iterative Approach: Continuously refine
requirements based on feedback.
●
Documentation: Keep detailed records of elicited
requirements.
●
Validation: Regularly validate requirements with
stakeholders to ensure accuracy and completeness.
●
Prioritization: Identify and prioritize requirements
based on their importance and feasibility.
9
 Elicitation Techniques
1. Collaborative Requirements Gathering
– It is a team oriented approach (stakeholders
& developers) to requirements gathering.

– The team work together to

●
Identify the problem
●
Propose elements of the solutions
●
Negotiate different approaches
●
Specify a preliminary set of solution
requirements.

– A facilitator (can be a customer or a

developer, or an outsider) controls the
meeting. 10
Elicitation Techniques CONT…

2. Quality Function Deployment

– It is a technique that translates the needs
of the customer into technical
requirements for the software.

– QFD concentrates on the maximizing

customer satisfaction from software
process.

– QFD emphasizes an understanding of what

is valuable to the customer and then
deploy these values throughout the
engineering process.
11
Quality Function Deployment CONT…
●
QFD identifies three types of
requirements:
– Normal requirements
●
Reflects objectives & goals
●
E.g. type of graphical display, specific system
functions and defined level of performance.
– Expected requirements
●
Are implicit to the product or system
(customer does not explicitly specify)
●
Their absence will cause a significant
dissatisfaction to the customer.
●
E.g. human/machine interaction, overall
operational correctness and reliability, easy
of software installation.
12
Quality Function Deployment CONT…

– Exciting requirements
●
Reflects features that go beyond the
customer’s expectation and prove to be very
satisfying when present.

●
E.g. word processing software attached to
the software for word processing.

13
 Challenges in Requirements
Elicitation
●
Ambiguity: Requirements can be unclear or
open to interpretation.
●
Changing Requirements: Stakeholder
needs may evolve over time.
●
Stakeholder Conflicts: Different
stakeholders may have conflicting requirements.
●
Communication Barriers:
Misunderstandings due to language, technical
jargon, or cultural differences.

14
 Requirements Gathering
Activities
●
1. Studying the existing documentation
(Document Analysis)
●
2. On-Site Observation
●
3. Interview (face to face, workshop, Seminar,
Group Discussion, Brain storming)
●
4. Surveys and Questionnaires
●
5. Scenario analysis (how users will interact with
the system through use cases and scenarios)
●
6. Story Boarding (Creating visual representations of
how users will interact with the system-helps in understanding user
interfaces)
●
7. Mind Mapping (Creating diagrams to visually organize
15
information and show relationships between different requirements)
 Requirements Gathering
(CONT.)

●
Some desirable attributes of
a good system analyst:
– Good interaction skills,
– Discussion with the customer and
end-users,
– Imagination and creativity,
– Experience.

– Analysisof what needs to be

16
done, etc.
 Case Study: Automation of
Office Work at SCE Dept.
●
The academic, inventory, and financial
information at the SCE department:
– Being carried though manual processing
by two office clerks, a store keeper, and
two attendants.
●
Considering the low budget he had at
his
●
Disposal:
– The DG entrusted the work to a team of
student volunteers.

17
Case Study: Automation of
Office Work at CSE Dept.
●
The team was first briefed by the
DG about the specific activities to
be automated.
●
The analyst first discussed with the
two clerks:
– Regarding their specific
responsibilities (tasks) that were to be
automated.
●
The analyst also interviewed
student and faculty representatives
who would also use the software.
18
Case Study: Automation of
Office Work at CSE Dept.
●
For each task, they asked:
– About the steps through
which these are performed.
– They also discussed various
scenarios that might arise for
each task.
– The analyst collected all
types of forms that were
being used.
19
Analysis of the Gathered
Requirements(CONT.)
●
Several things about the project
should be clearly understood by the
analyst:
– What is the problem?
– Why is it important to solve the problem?
– What are the possible solutions to the
problem?
– What complexities might arise while
solving the problem?

20
 Analysis of the Gathered
Requirements
●
Main purpose of requirements
analysis:
●
Clear and in-depth understanding of the user
requirements,
●
Detect inconsistencies, ambiguities, and
incompleteness.
●
Incompleteness and inconsistencies:
– Resolved through further discussions with the
end-users and the customers.
– Remove all ambiguities and inconsistencies
from the initial customer perception of the
problem. 21
 Inconsistent
Requirement
●
Some part of the requirement:
– contradicts with some other part.
●
Example:
– One customer says turn off heater
and open water shower when
temperature > 100 C
– Another customer says turn off
heater and turn ON cooler when
temperature > 100 C

22
 Incomplete Requirement
●
Some requirements have been
omitted:
– Possibly due to oversight.
●
Example:
– The analyst has not recorded:
when temperature falls below 90 C
●
heater should be turned ON
●
water shower turned OFF.

23
 Software analysis
principles
●
Software analysis principles focus on
understanding and defining the requirements
and specifications of a software system.
●
guide the analysis process to ensure the
software system meets the needs of its users
and stakeholders.
●
By adhering to these principles and best
practices, software engineers can conduct
effective software analysis,
●
Serve as a solid foundation for successful
software development. 24
 Software analysis
principles
1. Understandability
– Ensure that the requirements and system specifications
are clear and understandable to all stakeholders.
– Use simple language and avoid technical jargon when
possible.

2. Correctness and Completeness

●
Ensure that all requirements accurately represent the
needs of the stakeholders.
●
Cover all aspects of the system, leaving no requirement or
scenario unaddressed.
3. Consistency
●
Ensure that there are no conflicting requirements or
specifications.
●
Maintain a consistent level of detail across all requirements.
25
 Software analysis
principles
4. Relevance
– Focus on gathering requirements that are relevant and
necessary for the system.
– Avoid including unnecessary features that do not add
value.

5. Traceability
– Maintain the ability to trace each requirement back to its
origin.
– Ensure that every requirement can be linked to business
goals, stakeholder needs, or regulatory standards.

7. Modularity
– Break down the system into smaller, manageable modules
or components.
– Facilitate easier understanding, development, and
maintenance of the system. 26
 Software analysis
principles
8. Abstraction
●
Focus on the essential features of the system while ignoring
lower-level details initially.
●
Use high-level models to represent the system’s
functionality and structure.
10. User Involvement
●
Actively involve users and stakeholders throughout the
analysis process.
●
Ensure their needs, preferences, and feedback are
incorporated into the requirements.
11. Iterative Refinement
●
Refine and elaborate requirements iteratively based on
feedback and evolving understanding.
●
Continuously improve the accuracy and detail of the
27
requirements.
 Software analysis
principles
12. Formalization
●
Where appropriate, use formal methods to specify and
analyze requirements.
●
Use precise mathematical models to reduce ambiguity and
ensure correctness.
13. Validation
●
Continuously validate requirements with stakeholders to
ensure they meet their needs.
14. Risk Management
●
Identify and mitigate potential risks early in the analysis
process.
15. Documentation
28
Analysis of the Gathered
Requirements(CONT.)
●
After collecting and analyzing
all data regarding the system
to be developed,
– Systematically organize
requirements into a Software
Requirements Specification (SRS)
document.

29
 Software Requirements
Specification
●
Main aim of requirements
specification:
– Systematically organize the
requirements arrived during
requirements analysis.
– Document requirements properly.
– A Software Requirements Specification
(SRS) is a document containing a
complete description of what the
software will do without describing how
it will do it.
30
 Software Requirements
Specification
●
The SRS document is useful in
various contexts:
– Statement of user needs
– Contract document
– Reference document
– Definition for implementation

31
 Software Requirements
Specification: A Contract
Document

●
SRS document is a contract
between the development team and
the customer.
– Once the SRS document is approved
by the customer,
●
Any subsequent controversies are settled
by referring the SRS document.

32
 Review and
management of user
needs
●
crucial steps to ensure that the
developed software meets the
expectations and requirements of its
users.

●
Effective review and management of user
needs in requirement analysis ensure
that the final software product is aligned
with user expectations, reducing the risk
of project failures and increasing user
satisfaction.

33
 Review of User Needs
●
Stakeholder Identification:
– Identify all the potential stakeholders, including end-users,
clients, managers, and other relevant parties.
– Understand their roles, needs, and expectations from the
software.

●
Requirement Documentation:
– Document the gathered requirements clearly and
concisely.
– Use requirement specification documents, user stories, and
use cases to represent the requirements.

34
 Review of User Needs
Cont..
●
Requirement Validation:
– Validate the requirements with stakeholders to
ensure accuracy and completeness.
– Conduct review sessions, walkthroughs, and
inspections with stakeholders to verify the
documented needs.
●
Prioritization:
– Prioritize the requirements based on their
importance, feasibility, and impact on the project.
– Use techniques like MoSCoW (Must have, Should
have, Could have, and Won't have) prioritization.

35
 Management of User
Needs
●
Requirement Traceability:
– Maintain traceability of requirements throughout the
software development lifecycle.
– Use traceability matrices to map requirements to design,
implementation, and testing phases.

●
Change Management:
– Establish a process for managing changes to requirements.
– Use a change control board (CCB) to review and approve
changes.
– Document and communicate changes to all relevant
stakeholders.

●
Requirement Analysis:
– Analyze the requirements to understand their implications
on design, development, and testing.
– Identify potential conflicts, dependencies, and ambiguities
in the requirements. 36
 Management of User
Needs
●
Prototyping and Modeling:
– Create prototypes or models to visualize and refine user
requirements.

●
User Involvement:
– Involve users throughout the development process to gather
continuous feedback.

●
Documentation and Communication:
– Keep all requirement-related documents updated and easily
accessible.
– Communicate requirements clearly to all team members and
stakeholders.
– Use collaboration tools and platforms to facilitate effective
communication. 37
 Management of User
Needs
●
Quality Assurance:
– Ensure the requirements are testable and
measurable.
– Work closely with the QA team to develop
test plans and cases based on requirements.
●
Project Management Integration:
– Integrate requirement management with
project management activities.
– Use project management tools to track
requirement progress and ensure alignment
with project goals.

38
 SRS Document
●
The SRS document is known as black-
box specification:
– The system is considered as a black box whose
internal details are not known.
– Only its visible external (i.e. input/output)
behavior is documented.

●
SRS document concentrates on:
– What needs to be done
– Carefully avoids the solution (“how to do”)
aspects.
●
Should be carefully written
39
 Properties of a Good
SRS Document
●
It should be concise
– at the same time should not be ambiguous.
●
It should specify what the system
must do
– not say how to do it.
●
Easy to change.,
– i.e. it should be well-structured.
●
It should be consistent.
●
It should be complete.
40
 Properties of a Good
SRS Document (cont...)
●
It should be traceable
– You should be able to trace which
part of the specification corresponds
to which part of the design, code, etc
and vice versa.
●
It should be verifiable
– e.g. “system should be user friendly”
is not verifiable

41
 Organization of SRS
Document
SRS document, normally
contains three important
parts:
●
Functional requirements
●
Nonfunctional Requirements
– External interface requirements
– Performance requirements
– Goals of Implementation.
42
 SRS Document (CONT.)

●
It is desirable to consider every
system:
– Performing a set of functions {fi}.
– Each function fi considered as:
– Transforming a set of input data to
corresponding output data.

Input Data Output Data

fi

43
 Example: Functional
Requirement
●
F1: Search Book
– Input:
●
an author’s name:
– Output:
●
details of the author’s books and the
locations of these books in the library.

Author Name Book Details

f1

44
 Example:
Withdraw Cash from ATM
●
R1: Withdraw Cash

 R1.1: select withdraw amount option

 R1.2: select amount type
 R1.3: get required amount

45
45
 Functional
Requirements
●
For each high-level
requirement:
– Everyfunction is described in
terms of:
●
Input data set
●
Output data set
●
Processing required to obtain the
output data set from the input data
set.
46
 Nonfunctional
Requirements
●
Characteristics of the
system which can not be
expressed as functions:
●
Maintainability,
●
Portability,
●
Usability, etc.

47
 Nonfunctional
Requirements
●
Nonfunctional requirements include:
– Reliability issues,
– Performance issues:
●
Example: How fast the system can produce
results
– so that it does not overload another
system to which it supplies data, etc.
– Human-computer interface issues,
– Interface with other external systems,
– Security, maintainability, etc.

48
 Non-Functional
Requirements
●
Hardware to be used,
●
Operating system
– or DBMS to be used
●
Capabilities of I/O devices
●
Standards compliance
●
Data representations
– by the interfaced system

49
 Goals of Implementation
●
Goals describe things that are
desirable of the system:
– But, would not be checked for
compliance.
– For example,
●
Reusability issues
●
Functionalities to be developed in future

50
 Example Functional
Requirements
●
List all functional requirements
– with proper numbering.
●
Req. 1:
– Once the user selects the “search”
option,
●
he is asked to enter the key words.
– The system should output details of all
books
●
whose title or author name matches any of
the key words entered.
●
Details include: Title, Author Name,
Publisher name, Year of Publication, ISBN
Number, Catalog Number, Location in the
Library.
51
 Example Functional
Requirements
●
Req. 2:
– When the “renew” option is selected,
●
The user is asked to enter his
membership number and password.
– After password validation,
●
The list of the books borrowed by him
are displayed.
– The user can renew any of the books:
●
By clicking in the corresponding renew
box.

52
 Req. 1:
●
R.1.1:
– Input: “search” option,
– Output: user prompted to enter the key
words.
●
R1.2:
– Input: key words
– Output: Details of all books whose title or
author name matches any of the key words.
●
Details include: Title, Author Name, Publisher
name, Year of Publication, ISBN Number, Catalog
Number, Location in the Library.
– Processing: Search the book list for the
keywords
53
 Req. 2:
●
R2.1:
– Input: “renew” option selected,
– Output: user prompted to enter his
membership number and password.
●
R2.2:
– Input: membership number and password
– Output:
●
list of the books borrowed by user are displayed.
User prompted to enter books to be renewed or
●
user informed about bad password
– Processing: Password validation, search
books issued to the user from borrower list
and display.

54
 Req. 2:
●
R2.3:
– Input: user choice for renewal of the
books issued to him through mouse
clicks in the corresponding renew box.
– Output: Confirmation of the books
renewed
– Processing: Renew the books selected
by the in the borrower list.

55
 Examples of Bad SRS
Documents
●
Unstructured Specifications:
– Narrative essay --- one of the
worst types of specification
document:
●
Difficult to change,
●
Difficult to be precise,
●
Difficult to be unambiguous,
●
Scope for contradictions, etc.

56
 Examples of Bad SRS
Documents
●
Noise:
– Presence of text containing
information irrelevant to the problem.
●
Silence:
– aspects important to proper solution
of the problem are omitted.

57
 Examples of Bad SRS
Documents
●
Overspecification:
– Addressing “how to” aspects
– For example, “Library member names should
be stored in a sorted descending order”
– Overspecification restricts the solution space
for the designer.
●
Contradictions:
– Contradictions might arise
●
if the same thing described at several places in
different ways.

58
 Examples of Bad SRS
Documents
●
Ambiguity:
– Literary expressions
– Unquantifiable aspects, e.g. “good user
interface”
●
Forward References:
– References to aspects of problem
●
defined only later on in the text.
●
Wishful Thinking:
– Descriptions of aspects
●
for which realistic solutions will be hard to find.

59
 The Product: SRS
●
Standards:
– IEEE / ANSI 830-1984
– DoD 2167A / DI-MCCR-80025A (SRS)
– NASA SFW-DID-08 (SRS)
– company internal standards?

60
 IEEE 830-1998 Standard
– of SRS
●
Title
●
Table of Contents
●
1. Introduction
●
2. Overall Description
●
3. Specific Requirements
●
Appendices
●
Index

61
 IEEE Std 830-1984
1. Introduction
1.1 Purpose of SRS
1.2 Scope of product
1.3 Definitions, acronyms,
abbreviations
1.4 Overview

62
 IEEE Std 830-1984
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies

63
 IEEE Std 830-1984
3. Specific requirements
3.1 Functional requirements
3.2 External interface
requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Attributes
3.6 Other requirements
Alternatives!

64
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Func Req 1
3.1.1.1 Introduction
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
3.1.2 Func Req 2
…
3.2 External Interface Requirements
3.2.1 User Interface
3.2.2 Hardware Interfaces
3.2.3 Software Interfaces
3.2.4 Communication Interfaces
3.3 Performance Requirements
3.4 Design Constraints
3.4.1 Standards Compliance
3.4.2 Hardware Limitations
3.5 Attributes
3.5.1 Security 65
IEEE 830
3.5.2 Maintainability
IEEE 830-1998 Standard
– Structure of the SRS
●
Section 4 & 5 of IEEE 830

– Additional information such as

appendixes and index, if necessary

66

66
 IEEE 830-1998 Standard
– Section 1 of SRS
●
Title
●
Table of Contents
●
1. Introduction •Describe purpose of this SRS
– 1.1 Purpose •Describe intended audience

– 1.2 Scope •Identify the software product

•Enumerate what the system will and will not do
•Describe user classes and benefits for each
– 1.3 Definitions. Acronyms, and Abbreviations
– 1.4 References •Define the vocabulary of the SRS
(may reference appendix)
– 1.5 Overview
•List all referenced documents including sources
●
2. Overall Description (e.g., Use Case Model and Problem Statement; Experts in
the field)
●
3. Specific Requirements
•Describe the content of the rest of the SRS
●
Appendices •Describe how the SRS is organized

●
Index 67
 IEEE 830-1998 Standard –
Section 2 of SRS
•Present the business case and operational concept of the system
●
Title •Describe how the proposed system fits into the business context
•Describe external interfaces: system, user, hardware, software,
●
Table of Contents communication
•Describe constraints: memory, operational, site adaptation
●
1. Introduction
●
2. Overall Description
– 2.1 Product Perspective
– 2.2 Product Functions •Summarize the major functional capabilities
•Include the Use Case Diagram and supporting narrative
– 2.3 User Characteristics (identify actors and use cases)
•Include Data Flow Diagram if appropriate
– 2.4 Constraints •Describe and justify technical skills and
capabilities of each user class
– 2.5 Assumptions and Dependencies
●
3. Specific Requirements
4. Appendices
•Describe other constraints that will limit developer’s options;
●
e.g., regulatory policies; target platform, database, network
software and protocols, development standards requirements
●
5. Index
States assumptions about availability of certain 68
resources that, if not satisfied, will alter system
requirements and/or effect the design.
 IEEE 830-1998 Standard
– Section 3 of SRS (1)
●
1. Introduction Specify software requirements in sufficient
detail to enable designers to design a system to
●
2. Overall Description satisfy those requirements and testers to verify
requirements

●
3. Specific Requirements State requirements that are externally
perceivable by users, operators, or externally
– 3.1 External Interfaces connected systems

Requirements should include, at a minimum, a

– 3.2 Functions description of every input (stimulus) into the
system, every output (response) from the system,
– 3.3 Performance Requirements and all functions performed by the system in
response to an input or in support of an output

– 3.4 Logical Database Requirements

(a) Requirements should have characteristics of
high quality requirements

3.5 Design Constraints

(b) Requirements should be cross-referenced to
– their source.
(c) Requirements should be uniquely
– 3.6 Software System Quality Attributes identifiable
(d) Requirements should be organized to
maximize readability
– 3.7 Object Oriented Models
●
4. Appendices 69
●
5. Index
 IEEE 830-1998 Standard
– Section 3 of SRS (2)
●
1. Introduction
•Detail all inputs and outputs
●
2. Overall Description (complement, not duplicate, information presented in section 2)
•Examples: GUI screens, file formats
●
3. Specific Requirements
– 3.1 External Interfaces

– 3.2 Functions •Include detailed specifications of each use

case, including collaboration and other
diagrams useful for this purpose
– 3.3 Performance Requirements
•Include:
– 3.4 Logical Database Requirements a) Types of information used
b) Data entities and their relationships

– 3.5 Design Constraints

•Should include:
– 3.6 Software System Quality Attributes a) Standards compliance
b) Accounting & Auditing procedures
– 3.7 Object Oriented Models
•The main body of requirements organized in a
variety of possible ways:
a) Architecture Specification
●
4. Appendices b) Class Diagram
70
c) State and Collaboration Diagrams
●
5. Index d) Activity Diagram (concurrent/distributed)
 IEEE 830-1993 SRS Table
of Contents
1. Introduction 2.1.6. Memory constraints
1.1. Purpose 2.1.7. Operations
1.2. Scope 2.1.8. Site adaptation
1.3. Definitions, acronyms requirements
& abbreviations 2.2. Product functions
1.4. References 2.3. User characteristics
1.5. Overview 2.4. General Constraints
2. Overall description 2.5. Assumptions and
2.1. Product perspective dependencies
2.1.1. System interfaces 2.6. Apportioning of
2.1.2. User interfaces requirements
2.1.3. Hardware interfaces 3. Specific requirements
2.1.4. Software interfaces 4. Supporting information
2.1.5. Communications
71
interfaces
 Requirements
engineering
Requirements engineering is the process of establishing

the services that the customer requires from a system

the constraints under which it operates and is developed.

Requirements
The descriptions of the system
services and constraints
•Requirements
that are generated during the
engineering helps software
requirements engineering
engineers to better
process.
understand the problem
they will work to solve.

72
Requirement Analysis
Requirements Engineering-
●
Task
Inception—ask a set of context-free
questions that establish …
– basic understanding of the problem
– the people who want a solution
– the nature of the solution that is desired,
and
– the effectiveness of preliminary
communication and collaboration between
the customer and the developer
●
Elicitation—elicit requirements from
all stakeholders
(Elicitation is the act of obtaining language
data from another person.)
73
Requirement Analysis
Requirements Engineering-
Task CONT…
●
Elaboration— The data collected in
inception & elicitation is expanded
and refined during elaboration.
– create an analysis model that identifies
data, function and behavioral
requirements.
●
Negotiation—agree on a deliverable
system that is realistic for
developers and customers.

74
Requirement Analysis
 Requirements Engineering-
Task CONT…
●
Specification—can be any one (or more) of the
following:
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios (use-cases)
– A prototype
●
Validation—a review mechanism that looks for
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large
products or systems are engineered)
– conflicting or unrealistic (unachievable)
requirements.
75
Requirement Analysis
 Requirements Engineering-
Task CONT…
●
Requirements Management
– It is a set of activities that help the project
team to identify, control, and track
requirements and changes to requirements
at any time the project proceeds.
– Many activities are similar to configuration
management.

76
Requirement Analysis
 Steps required for “Initiating”
The Requirements Engineering
Process
1. Identifying the Stakeholders

2. Recognizing Multiple Viewpoints

3. Working towards Collaboration

4. Asking the First Questions

 Focuses on
●
Customers & stakeholders
●
Overall goals
●
benefits
77
 Representation of complex
processing logic:
●
Decision trees
●
Decision tables

78
 Decision Trees
●
Decision trees:
– Edges of a decision tree represent
conditions
– Leaf nodes represent actions to be
performed.
●
A decision tree gives a graphic view
of:
– Logic involved in decision making
– Corresponding actions taken.

79
 Example: LMS
●
A Library Membership
automation Software (LMS)
should support the following
three options:
– New member,
– Renewal,
– Cancel membership.

80
 Example: LMS
●
When the new member option
is selected,
– The software asks details about
the member:
●
name,
●
address,
●
phone number, etc.

81
 Example(cont.)
●
If proper information is entered,
– A membership record for the
member is created
– A bill is printed for the annual
membership charge plus the
security deposit payable.

82
 Example(cont.)
●
If the renewal option is chosen,
– LMS asks the member's name and his
membership number
●
checks whether he is a valid member.
– If the name represents a valid member,
●
the membership expiry date is updated
and the annual membership bill is printed,
●
otherwise an error message is displayed.

83
 Example(cont.)
●
If the cancel membership option
is selected and the name of a
valid member is entered,
– The membership is cancelled,
– A cheque for the balance amount
due to the member is printed
– The membership record is deleted.

84
 Decision Tree
- Get details
- Create record
- Print bills
New member
- Get Details
User Renewal - Update record
- Print bills
input
Cancel - Get Details
- Print Cheque
- Delete record
Invalid
option
- Print error message

85
 Decision Table
●
Decision tables specify:
– Which variables are to be
tested
– What actions are to be taken
if the conditions are true,
– The
order in which decision
making is performed.

86
 Decision Table
●
A decision table shows in a tabular
form:
– Processing logic and corresponding actions
●
Upper rows of the table specify:
– The variables or conditions to be evaluated
●
Lower rows specify:
– The actions to be taken when the
corresponding conditions are satisfied.

87
 Decision Table
●
In technical terminology,
–a column of the table is called
a rule:
–A rule implies:
●
if a condition is true, then
execute the corresponding
action.

88
 Example:
●
Conditions
Valid selection NO YES YES YES
New member -- YES NO NO
Renewal -- NO YES NO
Cancellation -- NO NO YES
●
Actions
Display error message -- -- --

Ask member's name etc.

Build customer record -- -- --
Generate bill -- --
Ask membership details --
Update expiry date -- -- --
Print cheque -- -- --
Delete record -- -- --
89
 Comparison of Decision
Tree and Decision Table
●
Both decision tables and decision trees
– Can represent complex program logic.
●
Decision trees are easier to read and
understand
– When the number of conditions are small.
●
Decision tables help to look at every
possible combination of conditions.

90
 Formal Specification
●
A formal specification
technique is a mathematical
method to:
– Accurately specify a system.
– Verifythat implementation
satisfies specification.
– Prove properties of the
specification.

91
 Formal Specification
●
Advantages:
– Well-defined
semantics, no
scope for ambiguity
– Automated tools can check
properties of specifications
– Executable specification

92
 Formal Specification
●
Disadvantages of
formal specification
techniques:
– Difficult to learn and use
– Not
able to handle
complex systems
93
 Formal Specification
●
Mathematical techniques
used include:
– Logic-based

– set theoretic
– algebraic specification
– finite state machines, etc.

94
 Software Change
●
Management
refers to the process of managing changes in
software applications and systems.
●
It ensures that changes are introduced in a
controlled and coordinated manner, minimizing
disruptions and maintaining system integrity.
●
This process is crucial for maintaining software
quality and reliability, especially in complex and
large-scale systems.
●
helps organizations adapt to new requirements, fix
bugs, and improve system functionality while
minimizing risks and ensuring system stability.
●
It is a crucial part of software development and IT
operations, particularly in environments that require
high reliability and security. 95
 Key aspects of Software Change
Management
●
Change Request: originate from various sources,
such as customers, developers, or stakeholders. It typically
describes the desired change, its purpose, and any expected
benefits.
●
Change Evaluation: Before implementation,
changes are evaluated based on their impact, feasibility, and
risks. This step often involves a review by a change control
board (CCB)
●
Prioritization and Scheduling: Approved
changes are prioritized and scheduled based on factors like
urgency, impact, and available resources. This helps in
efficient resource allocation and planning.
●
Implementation: The actual implementation of
changes involves modifying the software code, configuration,
or infrastructure.
Testing and Validation:
96
●
Changes are thoroughly
 Key aspects of Software
Change Management
●
Documentation: Proper documentation is crucial for
understanding the changes made, including the reason for the
change, and the expected outcome. This helps in future
maintenance and audits.
●
Monitoring and Review: After deployment, the
changes are monitored to ensure they operate as expected.
Any issues that arise are addressed promptly.
●
Rollback and Contingency Planning: In case
a change causes issues, a rollback plan should be in place.
●
Communication and Training: Stakeholders,
including end-users, developers, and support teams, should be
informed about the changes. Clear communication ensures
everyone is aware of new features, or new procedures.

97
 Software Configuration
Management (SCM)
●
SCM is a discipline within software engineering that
focuses on controlling and managing changes to
software products throughout their lifecycle. It
ensures the integrity, traceability, and reproducibility
of software configurations.
●
SCM is crucial in maintaining consistency, preventing
conflicts, and enabling efficient collaboration among
development teams.
●
SCM is an essential practice in modern software
development, especially in environments that
require frequent updates, multiple developers, and
complex software systems. It supports effective
project management, reduces risks, and improves
the overall quality and reliability of software 98
 Key Components of SCM
1. Configuration Identification
– Definition: Identifying configurations, cofiguration items and baselines.
This includes source code files, libraries, documentation, and
configuration files.
– Configuration item (CI) refers to the fundamental structural unit of a
configuration management system
– Baselines: It is an agreed description of the attributes of a product, at a
point in time, which serves as a basis for defining change. A change is a
movement from this baseline state to a next state. The identification of
significant changes from the baseline state is the central purpose of
baseline identification. A baseline is a reference point.
2. Configuration Control
– Definition: The process of managing changes to the software
configuration, ensuring that only approved changes are made. This
involves:
●
Change Request: Proposals for changes are submitted, documented,
and reviewed.
●
Change Control Board (CCB): A group or commitee of stakeholders
responsible for approving or rejecting change requests (based on99their
impact, necessity, and feasibility) that are sent against any baseline.
 Key Components of SCM
3. Configuration Status Accounting
– Definition: The process of recording and reporting the status
of configuration items (CIs) throughout the lifecycle. This
includes tracking changes, versions, and baselines.
– Reporting: Provides information on what changes have been
made, by whom, when, and why, helping in audits and
compliance.
4. Version Control
– Definition: Version control systems (VCS) track and manage
changes to software code and associated documentation.
– Types: There are two main types of version control systems:
●
Centralized Version Control Systems (CVCS), which have a single,
central repository.
●
Distributed Version Control Systems (DVCS): full copy of the
repository, including its entire history.

100
 Key Components of SCM
5. Configuration Audits
– Definition: The process of verifying that the software configuration
items are consistent with their documentation and meet specified
requirements.
– Types:
●
Functional Configuration Audit (FCA): Ensures that the software
performs the functions described in its specifications.
●
Physical Configuration Audit (PCA): Verifies that the software and
its documentation are complete and accurate.
6. Build Management
– Definition: The process of compiling and linking source code into
executable software. This involves automating the build process,
managing build scripts, and ensuring that the correct versions of
source code and dependencies are used.
– Continuous Integration (CI): An SCM practice where developers
frequently integrate their code changes into a shared repository,
followed by automated builds and tests. This helps in detecting
issues early in the development process.
101
 Key Components of SCM
7. Release Management
– Definition: The process of managing, planning, and scheduling the
deployment of software releases. It includes preparing release
notes, packaging the software, and deploying it to the production
environment.
– Versioning: Assigning version numbers to releases to identify
different stages of the software's evolution (e.g., alpha, beta,
release candidates, final releases).
8. Environment Management
– Definition: The management of different environments
(development, testing, production) in which the software operates.
9. Backup and Recovery
– Definition: Implementing strategies for backing up software
configurations and ensuring that they can be recovered in case of
data loss or corruption.

102
 Benefits of SCM
●
Consistency: Ensures that all developers are working
with the same versions of software components.
●
Traceability: Provides the ability to trace changes
back to their origins, understanding who made changes and
why.
●
Collaboration: Facilitates collaboration among
multiple developers and teams, reducing the chances of
conflicts.
●
Quality Assurance: Helps maintain the quality of
the software by ensuring that changes are properly reviewed
and tested before being integrated.
●
Compliance: Assists in meeting regulatory and
compliance requirements by maintaining accurate records of
software configurations and changes.
103
 Key Differences of Software Change
Management and cofiguration
management
●
Scope: SCM has a broader scope, covering all aspects of
managing software artifacts, while Software Change
Management focuses specifically on changes to the software.

●
Activities: SCM includes configuration identification,
control, status accounting, and audit. Software Change
Management deals specifically with the process of handling
change requests, impact analysis, approval, implementation,
and verification.

●
Goal: The goal of SCM is to maintain the integrity and
traceability of the software throughout its lifecycle. The goal
of Software Change Management is to ensure that changes
are introduced smoothly, with minimal disruption and
maximum benefit.
104
 Key Differences of Software Change
Management and cofiguration
management
●
In summary, Software Change Management is a
component of the broader Software Configuration
Management process. Software Change Management is a
subset of Software Configuration Management.

●
Software Change Management focused specifically on
managing the process of making changes to software
systems. It deals with the identification, assessment, and
implementation of changes to the software. Change
Management focuses on the controlled introduction of
changes to those artifacts. While SCM ensures overall
consistency and integrity of software artifacts,

105