University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE

& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Requirement analysis

• Requirement gathering

• Analysis Principles

• Software Prototyping

2
 REQUIREMENT ANALYSIS AND
SPECIFICATION
• Many projects fail:
• Because they start implementing the system.
• Without determining whether they are building what the customer really
wants.
• It is important to learn:
• Requirements analysis and specification techniques carefully.
• Goals of requirements analysis and specification phase:
• Fully understand the user requirements.
• Remove inconsistencies, anomalies, etc. from requirements.
• Document requirements properly in an SRS document.
3
 REQUIREMENT ANALYSIS AND
SPECIFICATION
• Requirements analysis consists of two main activities:
• Requirements gathering
• Analysis of the gathered requirements
• Analyst gathers requirements through:
• Observation of existing systems,
• Studying existing procedures,
• Discussion with the customer and end-users,
• Analysis of what needs to be done, etc.
4
REQUIREMENT ANALYSIS
• Requirement analysis is significant and essential activity after elicitation.
• We analyze, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements.
• This activity reviews all requirements and may provide a graphical view of
the entire system.
• After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
• Here, we may also use the interaction with the customer to clarify points of
confusion and to understand which requirements are more important than
others.

5
Requirement Analysis

Fig 1 Steps of requirement analysis

6
Example

7
REQUIREMENT ANALYSIS
• Draw the context diagram: The context diagram is a simple model that
defines the boundaries and interfaces of the proposed systems with the
external world. It identifies the entities outside the proposed system that
interact with the system.

• Development of a Prototype (optional):One effective way to find out what

the customer wants is to construct a prototype. We can use their feedback
to modify the prototype until the customer is satisfied continuously. Hence,
the prototype helps the client to visualize the proposed system and
increase the understanding of the requirements. When developers and
users are not sure about some of the elements, a prototype may help both
the parties to take a final decision.

8
REQUIREMENT ANALYSIS
• Model the requirements: This process usually consists of various
graphical representations of the functions, data entities, external
entities, and the relationships between them. The graphical view may
help to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow diagram, Entity-
Relationship diagram, Data Dictionaries, State-transition diagrams,
etc.

9
REQUIREMENT ANALYSIS
• Finalize the requirements: After modeling the requirements, we will
have a better understanding of the system behavior. The
inconsistencies and ambiguities have been identified and corrected.
The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the
system. Now we finalize the analyzed requirements, and the next step
is to document these requirements in a prescribed format.

10
 REQUIREMENT GATHERING
• Gathering relevant data:
• usually collected from the end-users through interviews and
discussions.
• For example, for a business accounting software:
• interview all the accountants of the organization to find out their
requirements.

11
 ANALYSIS PRINCIPLES
• Main purpose of requirements analysis:
• Clearly understand the user requirements,
• Detect inconsistencies, ambiguities, and incompleteness.
• Incompleteness and inconsistencies:
• Resolved through further discussions with the end-users and the
customers.
• Some part of the requirement:
• contradicts with some other part.

12
Analysis Principle
• Over the past two decades, a large number of analysis modeling
methods have been developed.
• Investigators have identified analysis problems and their causes and
have developed a variety of notations and corresponding sets of
heuristics to overcome them.
• Each analysis method has a unique point of view.

13
Analysis principle
• The information domain of a problem must be represented and
understood.
• The functions that the software is to perform must be defined.
• The behavior of the software must be represented.
• The models that depict information, function, and
• The models that depict information function and behavior must be
partitioned in a manner that uncovers details in a layered fashion.
• The analysis process should move from essential information toward
implementation detail.

14
Analysis Principle
• In addition to these operational analysis principles for requirements
engineering:
• Understand the problem before you begin to create the analysis
model.
• Develop prototype that enable a user to understand how
human/machine interaction will occur.
• Record the origin of and the reason for every requirement.
• Use multiple views of requirements.
• Rank requirements.
• Work to eliminate ambiguity
15
 Software Prototyping
• Development of a preliminary version of a software system in order to
allow certain aspects of that system to be investigated.
• Often the primary purpose of a prototype is to obtain feedback from
the intended users; the requirements specification for the system can
then be updated to reflect this feedback, and so increase confidence in
the final system.
• A prototype may for example be developed with no concern for its
efficiency or performance, and certain functions of the final system
may be entirely omitted.

16
Software Prototyping
• Additionally a prototype can be used to investigate particular problem
areas, or certain implications of alternative design or implementation
decisions.
• The intention with a prototype is normally to obtain the required
information as rapidly as possible and with the minimum investment
of resources, and it is therefore common to concentrate on certain
aspects of the intended system and completely ignore others.
• It must however be realistic in those aspects specifically under
investigation.

17
SOFTWARE REQUIREMENT SPECIFICATION
• Main aim of requirements specification:
• Systematically organize the requirements arrived during requirements
analysis.
• Document requirements properly.

• The SRS document is useful in various contexts:

• Statement of user needs
• Contract document
• Reference document
• Definition for implementation

18
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
Image References:
https://www.tutorialspoint.com/software_testing_dictionary/software_requirement_specification.htm

19
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Software requirement Specification

• SRS document

• Functional and non functional requirement

22
SOFTWARE REQUIREMENT SPECIFICATION
• Main aim of requirements specification:
• Systematically organize the requirements arrived during requirements
analysis.
• Document requirements properly.

• The SRS document is useful in various contexts:

• Statement of user needs
• Contract document
• Reference document
• Definition for implementation

23
 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) behaviour is documented.
• SRS document concentrates on:
• What needs to be done
• Carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• Between development team and the customer.
• Should be carefully written

24
SRS Document
• A software requirements specification (SRS) is a document that
captures complete description about how the system is expected to
perform. It is usually signed off at the end of requirements
engineering phase.
• 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.

25
SRS Document
• It may include the use cases of how user is going to interact with
software system.
• The software requirement specification document consistent of all
necessary requirements required for project development.
• To develop the software system we should have clear understanding
of Software system.
• To achieve this we need to continuous communication with
customers to gather all requirements.

26
SRS Document
• A good SRS defines the how Software System will interact with all
internal modules, hardware, communication with other programs and
human user interactions with wide range of real life scenarios.
• Using the Software requirements specification (SRS) document on QA
lead, managers creates test plan.
• It is very important that testers must be cleared with every detail
specified in this document in order to avoid faults in test cases and its
expected results.

27
 Qualities of SRS
• Correctness of SRS should be checked : Since the whole testing phase
is dependent on SRS, it is very important to check its correctness.
There are some standards with which we can compare and verify.
• Ambiguity should be avoided. Sometimes in SRS, some words have
more than one meaning and this might confused testers making it
difficult to get the exact reference. It is advisable to check for such
ambiguous words and make the meaning clear for better
understanding.

28
Qualities of SRS
• Requirements should be complete. When tester writes test cases,
what exactly is required from the application, is the first thing which
needs to be clear. For e.g. if application needs to send the specific
data of some specific size then it should be clearly mentioned in SRS
that how much data and what is the size limit to send.
• Consistent requirements.The SRS should be consistent within itself
and consistent to its reference documents. If you call an input “Start
and Stop” in one place, don’t call it “Start/Stop” in another. This sets
the standard and should be followed throughout the testing phase.

29
Qualities of SRS
• Verification of expected result: SRS should not have statements like
“Work as expected”, it should be clearly stated that what is expected
since different testers would have different thinking aspects and may
draw different results from this statement.
• Testing environment: some applications need specific conditions to
test and also a particular environment for accurate result. SRS should
have clear documentation on what type of environment is needed to
set up.

30
Qualities of SRS
• Pre-conditions defined clearly: one of the most important part of test
cases is pre-conditions. If they are not met properly then actual result
will always be different expected result. Verify that in SRS, all the pre-
conditions are mentioned clearly.
• Requirements ID: these are the base of test case template. Based on
requirement Ids, test case ids are written. Also, requirements ids
make it easy to categorize modules so just by looking at them, tester
will know which module to refer. SRS must have them such as id
defines a particular module.

31
Qualities of SRS
• Security and Performance criteria: security is priority when a software is tested
especially when it is built in such a way that it contains some crucial information
when leaked can cause harm to business.
• Assumption should be avoided: sometimes when requirement is not cleared to
tester, he tends to make some assumptions related to it, which is not a right way
to do testing as assumptions would go wrong and hence, test results may vary.
• Deletion of irrelevant requirements: there are more than one team who work on
SRS so it might be possible that some irrelevant requirements are included in SRS.
Based on the understanding of the software, tester can find out which are these
requirements and remove them to avoid confusions and reduce work load.
• Freeze requirements: when an ambiguous or incomplete requirement is sent to
client to analyze and team gets a reply, that requirement result will be updated in
the next SRS version and client will freeze that requirement. Freezing here means
that result will not change again until and unless some major addition or
modification is introduced in the software.
32
 Properties of a good SRS document

• Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions decrease readability and also increase error possibilities.
• Structured: It should be well-structured. A well-structured document
is simple to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the user requirements.
Often, user requirements evolve over a period of time. Therefore, to
make the modifications to the SRS document easy, it is vital to make
the report well-structured.

33
Properties of a good SRS document

• Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS
document should define the external behavior of the system and not
discuss the implementation issues. The SRS report should view the
system to be developed as a black box and should define the
externally visible behavior of the system. For this reason, the SRS
report is also known as the black-box specification of a system.

34
Properties of a good SRS document

• Conceptual integrity: It should show conceptual integrity so that the

reader can merely understand it. Response to undesired events: It
should characterize acceptable responses to unwanted events. These
are called system response to exceptional conditions.
• Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to
decide whether or not requirements have been met in an
implementation.

35
 FUNCTIONAL REQUIREMENTS
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions
• For each high-level requirement:
• Every function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set from the input data set.

36
 NON FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be expressed as functions:
• Maintainability,
• Portability,
• Usability, etc.
• Non functional 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.

37
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

38
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered
• Functional and non functional requirement

• Decision tree

• Decision table

• Data Modeling

• Functional Modeling

• Behavioral Modeling

41
 FUNCTIONAL REQUIREMENTS
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions
• For each high-level requirement:
• Every function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set from the input data set.

42
FUNCTIONAL REQUIREMENTS
• A Functional Requirement is a description of the service that the
software must offer.
• It describes a software system or its component.
• A function is nothing but inputs to the software system, its behavior,
and outputs.
• It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform.
• Functional Requirements are also called Functional Specification.

43
FUNCTIONAL REQUIREMENTS
• In software engineering and systems engineering, a Functional
Requirement can range from the high-level abstract statement of the
sender's necessity to detailed mathematical functional requirement
specifications.
• Functional software requirements help you to capture the intended
behavior of the system.

44
FUNCTIONAL REQUIREMENTS : EXAMPLE

45
Functional requirement should include:
• Details of operations conducted in every screen
• Data handling logic should be entered into the system
• It should have descriptions of system reports or other outputs
• Complete information about the workflows performed by the system
• It should clearly define who will be allowed to create/modify/delete
the data in the system
• How the system will fulfill applicable regulatory and compliance
needs should be captured in the functional document

46
Benefits of Functional Requirement

• Helps you to check whether the application is providing all the

functionalities that were mentioned in the functional requirement of that
application
• A functional requirement document helps you to define the functionality of
a system or one of its subsystems.
• Functional requirements along with requirement analysis help identify
missing requirements. They help clearly define the expected system service
and behavior.
• Errors caught in the Functional requirement gathering stage are the
cheapest to fix.
• Support user goals, tasks, or activities

47
Types of Functional Requirements

• Transaction Handling
• Business Rules
• Certification Requirements
• Reporting Requirements
• Administrative functions
• Authorization levels
• Audit Tracking
• External Interfaces
• Historical Data management
• Legal and Regulatory Requirements

48
 NON FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be expressed as functions:
• Maintainability,
• Portability,
• Usability, etc.
• Non functional 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.

49
NON FUNCTIONAL REQUIREMENTS
• NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality
attribute of a software system.
• They judge the software system based on Responsiveness, Usability,
Security, Portability and other non-functional standards that are
critical to the success of the software system.
• Example of nonfunctional requirement, “how fast does the website
load?”
• Failing to meet non-functional requirements can result in systems
that fail to satisfy user needs.

50
NON FUNCTIONAL REQUIREMENTS
• Non-functional Requirements allows you to impose constraints or
restrictions on the design of the system across the various agile
backlogs.
• Example, the site should load in 3 seconds when the number of
simultaneous users are > 10000.

51
TYPES OF NON-FUNCTIONAL REQUIREMENTS
• Usability requirement
• Serviceability requirement
• Manageability requirement
• Recoverability requirement
• Security requirement
• Data Integrity requirement
• Capacity requirement
• Availability requirement
• Scalability requirement
• Interoperability requirement
• Reliability requirement
• Maintainability requirement
• Regulatory requirement
• Environmental requirement

52
Examples of Non-functional requirements

• Users must change the initially assigned login password immediately after
the first successful login. Moreover, the initial should never be reused.
• Employees never allowed to update their salary information. Such attempt
should be reported to the security administrator.
• Every unsuccessful attempt by a user to access an item of data shall be
recorded on an audit trail.
• A website should be capable enough to handle 20 million users with
affecting its performance
• The software should be portable. So moving from one OS to other OS does
not create any problem.
• Privacy of information, the export of restricted technologies, intellectual
property rights, etc. should be audited.

53
Advantages of Non-Functional Requirement

• The nonfunctional requirements ensure the software system follow

legal and compliance rules.
• They ensure the reliability, availability, and performance of the
software system
• They ensure good user experience and ease of operating the
software.
• They help in formulating security policy of the software system.

54
Disadvantages of Non-functional requirement

• None functional requirement may affect the various high-level

software subsystem
• They require special consideration during the software
architecture/high-level design phase which increases costs.
• Their implementation does not usually map to the specific software
sub-system,
• It is tough to modify non-functional once you pass the architecture
phase.

55
Functional Vs Non Functional requirements

56
 Representation of complex processing logic

• Decision trees
• Decision tables

57
Decision Tree
• A decision tree is a map of the possible outcomes of a series of
related choices.
• It allows an individual or organization to weigh possible actions
against one another based on their costs, probabilities, and benefits.
• They can be used either to drive informal discussion or to map out an
algorithm that predicts the best choice mathematically.
• A decision tree typically starts with a single node, which branches into
possible outcomes. Each of those outcomes leads to additional nodes,
which branch off into other possibilities. This gives it a treelike shape.

58
Decision Tree
• There are three different types of nodes: chance nodes, decision
nodes, and end nodes.
• A chance node, represented by a circle, shows the probabilities of
certain results.
• A decision node, represented by a square, shows a decision to be
made, and an end node shows the final outcome of a decision path.

59
Decision Tree Symbols

60
Decision Tree
• A Decision Tree offers a graphic read of the processing logic
concerned in a higher cognitive process and therefore the
corresponding actions are taken.
• The perimeters of a choice tree represent conditions and therefore
the leaf nodes represent the actions to be performed looking on the
result of testing the condition.

61
Example
• For example, consider Library Membership Automation Software (LMS)
where it ought to support the following three options: New member,
Renewal, and Cancel membership. These are explained as following below.
1. New Member Option:
• Decision:
Once the ‘new member’ possibility is chosen, the software system asks
details concerning the member just like the member’s name, address,
number, etc.
• Action:
If correct info is entered then a membership record for the member is
made and a bill is written for the annual membership charge and the
protection deposit collectible.
62
Example
2 Cancel Membership Option:
• Decision:
If the ‘cancel membership’ possibility is chosen, then the software system asks for
member’s name and his membership range.
• Action:
The membership is off, a cheque for the balance quantity because of the member is
written and at last the membership record is deleted from the information.
3 Renewal Option:
• Decision:
If the ‘renewal’ possibility is chosen, the LMS asks for the member’s name and his
membership range to test whether or not he’s a sound member or not.
• Action:
If the membership is valid then membership ending date is updated and therefore the
annual membership bill is written, otherwise, a slip-up message is displayed.

63
Example

Fig 1 Example of decision tree

64
Advantages
The advantages of decision tree are as follow:
• They are easy to understand
• They can be useful with or without hard data, and any data requires
minimal preparation
• New options can be added to existing trees
• Their value in picking out the best of several options

65
Disadvantages
• When dealing with categorical data with multiple levels, the
information gain is biased in favor of the attributes with the most
levels.
• Calculations can become complex when dealing with uncertainty and
lots of linked outcomes.
• Conjunctions between nodes are limited to AND, whereas decision
graphs allow for nodes linked by OR.

66
 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.
• 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.

67
 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.

68
Decision Table
• Decision table is a brief visual representation for specifying which
actions to perform depending on given conditions.
• The information represented in decision tables can also be
represented as decision trees or in a programming language using if-
then-else and switch-case statements.
• A decision table is a good way to settle with different combination
inputs with their corresponding outputs and also called cause-effect
table.
• Reason to call cause-effect table is a related logical diagramming
technique called cause-effect graphing that is basically used to obtain
the decision table.
69
Importance of Decision Table
• Decision tables are very much helpful in test design technique.
• It helps testers to search the effects of combinations of different inputs and
other software states that must correctly implement business rules.
• It provides a regular way of stating complex business rules, that is helpful
for developers as well as for testers.
• It assists in development process with developer to do a better job. Testing
with all combination might be impractical.
• A decision table is basically an outstanding technique used in both testing
and requirements management.
• It is a structured exercise to prepare requirements when dealing with
complex business rules.
• It is also used in model complicated logic.

70
Example: How to make Decision Base Table for
Login Screen
• Let's create a decision table for a login screen.

71
Example
• The condition is simple if the user provides correct username and
password the user will be redirected to the homepage. If any of the
input is wrong, an error message will be displayed.

72
Example
• Notations
• T – Correct username/password
• F – Wrong username/password
• E – Error message is displayed
• H – Home screen is displayed
• Interpretation:
• Case 1 – Username and password both were wrong. The user is shown an error message.
• Case 2 – Username was correct, but the password was wrong. The user is shown an error
message.
• Case 3 – Username was wrong, but the password was correct. The user is shown an error
message.
• Case 4 – Username and password both were correct, and the user navigated to
homepage

73
Advantages and Disadvantages
• Advantages
• When the system behavior is different for different input and not same for a range of
inputs, both equivalent partitioning, and boundary value analysis won't help, but
decision table can be used.
• The representation is simple so that it can be easily interpreted and is used for
development and business as well.
• This table will help to make effective combinations and can ensure a better coverage for
testing
• Any complex business conditions can be easily turned into decision tables
• In a case we are going for 100% coverage typically when the input combinations are low,
this technique can ensure the coverage.
• Disadvantages
• The main disadvantage is that when the number of input increases the table will become
more complex

74
Comparison

75
 Formal specification
• A formal specification technique is a mathematical method to:
• Accurately specify a system.
• Verify that implementation satisfies specification.
• Prove properties of the specification. A formal software specification is
a statement expressed in a language whose vocabulary, syntax, and
semantics are formally defined.
• The need for a formal semantic definition means that the
specification languages cannot be based on natural language; it must
be based on mathematics.

76
Formal Specification
• Advantages:
• Well-defined semantics, no scope for ambiguity
• Automated tools can check properties of specifications
• Executable specification
• The development of a formal specification provides insights and
understanding of the software requirements and the software design.
• Given a formal system specification and a complete formal
programming language definition, it may be possible to prove that a
program conforms to its specifications.
• Formal specification may be automatically processed. Software tools
can be built to assist with their development, understanding, and
debugging.

77
Formal Specification
• Depending on the formal specification language being used, it may be
possible to animate a formal system specification to provide a
prototype system.
• Formal specifications are mathematical entities and may be studied
and analyzed using mathematical methods.
• Formal specifications may be used as a guide to the tester of a
component in identifying appropriate test cases.

78
 Formal specification
• Disadvantages of formal specification techniques:
• Difficult to learn and use
• Not able to handle complex systems

• Mathematical techniques used include:

• Logic-based
• set theoretic
• algebraic specification
• finite state machines, etc.
79
Formal Specification
• Formal specifications sometimes are not used because:
• Software management is conservative and unwilling to adopt new
techniques whose payoff is not immediately obvious.
• Most software engineers have not been trained in formal
specification techniques.
• Some classes of systems are difficult to specify using existing
specification techniques. Interactive and interrupt driven systems
might be examples.

80
 APPLICATIONS
• Managing clients requirements in industry.
• Generating software for noticing health activities with novel smart
technologies.
• Content Management and to analyzing Fraud detection and Prevention
• Advertisements Targeting Platforms Managing content, posts, images and
videos on social media platforms
• Analyzing customer data in real-time for improving business performance
• Public sector fields such as intelligence, defense, cyber security and
scientific research

81
 Data Modeling
• A data model can be thought of as a flowchart that illustrates the relationships
among data.
• It enables stakeholders to identify errors and make changes before any
programming code has been written.
• Alternatively, models can be introduced as part of reverse engineering efforts that
extract models from existing systems, as seen with NoSQL data.
• Data modelers often use multiple models to view the same data and ensure that all
processes, entities, relationships and data flows have been identified.
• Data modeling stages roughly break down into creation of logical data models that
show specific attributes, entities and relationships among entities and the physical
data model.

82
 Functional Modeling

• In the Functional Model, software converts information. and to accomplish this,

it must perform at least three common tasks- input, processing and output.

• When functional models of an application are created, the software engineer

emphasizes problem specific tasks. The functional model begins with a single

reference level model

83
 Functional Modeling

• In a series of iterations, more and more functional detail is given, until all system

functionality is fully represented.

• Information is converted because it flows from a computer-based system.

• The system takes input in various forms; Hardware, software, and human elements

are applied to replace it; And produces in various forms.

84
 Behavioral Modeling

• Behavioral model describes the interaction in the system. It represents

the interaction among the structural diagrams. Behavioral modeling
shows the dynamic nature of the system. They consist of the
following:
• Activity diagrams
• Interaction diagrams
• Use case diagrams

85
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

Reference Website
1. https://www.geeksforgeeks.org/computer-organization-and-architecture-tutorials/

86
THANK YOU
 University Institute of Engineering
DEPARTMENT OF COMPUTER SCIENCE
& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Structural Modeling

• Data Dictionary

89
 Structural Modeling
• Structural modeling captures the static features of a system. They
consist of the following −
• Classes diagrams
• Objects diagrams
• Deployment diagrams
• Package diagrams
• Composite structure diagram
• Component diagram

90
 Structural Modeling
• Structural model represents the framework for the system and this
framework is the place where all other components exist.
• Hence, the class diagram, component diagram and deployment
diagrams are part of structural modeling.
• They all represent the elements and the mechanism to assemble them.

91
 Structural Modeling
• Structural models of software display the organization of a system in
terms of the components that make up that system and their
relationships.
• Structural models may be static models, which show the structure of
the system design, or dynamic models, which show the organization
of the system when it is executing.
• You create structural models of a system when you are discussing and
designing the system architecture.

92
 Structural Modeling
• Structural models of software display the organization of a system in
terms of the components that make up that system and their
relationships.

• Structural models may be static models, which show the structure of

the system design or dynamic models, which show the organization of
the system when it is executing.

93
 Data Dictionary

• A data dictionary is a file or a set of files that includes a database's

metadata.
• The data dictionary hold records about other objects in the database,
such as data ownership, data relationships to other objects, and other
data.
• The data dictionary is an essential component of any relational
database.
• Ironically, because of its importance, it is invisible to most database
users.

94
 Data Dictionary

• The data dictionary, in general, includes information about the following:

• Name of the data item
• Aliases
• Description/purpose
• Related data items
• Range of values
• Data structure definition/Forms

95
 Data Dictionary

• Data flows capture the name of processes that generate or receive the
data items.
• If the data item is primitive, then data structure form captures the
physical structures of the data item.
• If the data is itself a data aggregate, then data structure form capture
the composition of the data items in terms of other data items.

96
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
1. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and
Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
2. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

Reference Website
1. https://www.geeksforgeeks.org/computer-organization-and-architecture-tutorials/

97
THANK YOU