Software Engineering

UNIT-1

Chapter-2 (Software requirements)

Requirement Analysis, Analysis principle, Software prototyping Specification,

Characteristics and components of SRS, Data modeling, Functional modeling
and information flow, behavioral modeling, Mechanics of structural modeling,
Data dictionary.

Prepared By: Er. Inderjeet Singh(e8822) Page 1

 Software Engineering

Chapter-2
(SOFTWARE REQUIREMENTS)
Experienced developers take considerable time to understand the exact
requirements of the customer and to meticulously document those. They know
that without a clear understanding of the problem and proper documentation of
the same, it is impossible to develop a satisfactory solution.

An overview of requirements analysis and specification phase

The requirements analysis and specification phase starts after the feasibility
study stage is complete and the project has been found to be financially viable and
technically feasible.

The requirements analysis and specification phase ends when the requirements
specification document has been developed and reviewed. The requirements
specification document is usually called as the software requirements
specification (SRS) document. The goal of the requirements analysis and
specification phase can be stated in a nutshell as follows.

The goal of the requirements analysis and specification phase is to clearly

understand the customer requirements and to systematically organise the
requirements into a document called the Software Requirements Specification
(SRS) document.

Prepared By: Er. Inderjeet Singh(e8822) Page 2

 Software Engineering

REQUIREMENTS GATHERING AND ANALYSIS

The complete set of requirements are almost never available in the form of a
single document from the customer. In fact, it would be unrealistic to expect the
customers to produce a comprehensive document containing a precise
description of what he wants. Further, the complete requirements are rarely
obtainable from any single customer representative. Therefore, the
requirements have to be gathered by the analyst from several sources in bits
and pieces.

We can conceptually divide the requirements gathering and analysis activity into
two separate tasks:

• Requirements gathering
• Requirements analysis

Requirements Gathering

The primary objective of the requirements gathering task is to collect the

requirements from the stakeholders.

Requirements gathering may sound like a simple task. However, in practice it is

very difficult to gather all the necessary information from a large number of
stakeholders and from information scattered across several pieces of
documents. Gathering requirements turns out to be especially challenging if there
is no working model of the software being developed.
Prepared By: Er. Inderjeet Singh(e8822) Page 3
 Software Engineering

Suppose a customer wants to automate some activity in his organisation that is

currently being carried out manually. In this case, a working model of the system
(that is, the manual system) exists. Availability of a working model is usually of
great help in requirements gathering.

For example, if the project involves automating the existing accounting

activities of an organisation, then the task of the system analyst becomes a lot
easier as he can immediately obtain the input and output forms and the details
of the operational procedures.

However, if a project involves developing something new for which no working

model exists, then the requirements gathering activity becomes all the more
difficult.

Typically even before visiting the customer site, requirements gathering activity is
started by studying the existing documents to collect all possible information
about the system to be developed.

During visit to the customer site, the analysts normally interview the end-users
and customer representatives, carry out requirements gathering activities such
as questionnaire surveys, task analysis, scenario analysis, and form analysis.

In the following, we briefly discuss the important ways in which an experienced

analyst gathers requirements:

1. Studying existing documentation: The analyst usually studies all the

available documents regarding the system to be developed before visiting
Prepared By: Er. Inderjeet Singh(e8822) Page 4
 Software Engineering

the customer site. Customers usually provide statement of purpose

(SoP) document to the developers. Typically these documents might discuss
issues such as the context in which the software is required, the basic purpose,
the stakeholders, features of any similar software developed elsewhere, etc.
2. Interview: Typically, there are many different categories of users of a
software. Each category of users typically requires a different set of features
from the software. Therefore, it is important for the analyst to first identify
the different categories of users and then determine the requirements of
each. For example, the different categories of users of a library
automation software could be the library members, the librarians, and
the accountants. The library members would like to use the software to query
availability of books and issue and return books. The librarians might like to
use the software to determine books that are overdue, create member
accounts, delete member accounts, etc.
To systematise this method of requirements gathering, the Delphi
technique can be followed. In this technique, the analyst consolidates the
requirements as understood by him in a document and then circulates it
for the comments of the various categories of users. Based on their
feedback, he refines his document.
3. Task analysis: The users usually have a black-box view of a software and
consider the software as something that provides a set of services
(functionalities). A service supported by a software is also called a task.
We can therefore say that the software performs various tasks of the users.

Prepared By: Er. Inderjeet Singh(e8822) Page 5

 Software Engineering

The analyst tries to identify and understand the different tasks to be

performed by the software. For each identified task, the analyst tries to
formulate the different steps necessary to realise the required functionality in
consultation with the users. For example, for the issue book service, the
steps may be—authenticate user, check the number of books issued
to the customer and determine if the maximum number of books that
this member can borrow has been reached etc.
Summary: Task analysis helps the analyst to understand the nitty-
gritty(important facts) of various user tasks and to represent each task as a
hierarchy of subtasks.

4. Scenario analysis: A task can have many scenarios of operation. The

different scenarios of a task may take place when the task is invoked under
different situations. For different types of scenarios of a task, the behaviour of
the software can be different. For example, the possible scenarios for the
book issue task of a library automation software may be:
• Book is issued successfully to the member and the book issue slip is
printed.
• The book is reserved, and hence cannot be issued to the member.
• The maximum number of books that can be issued to the member is
already reached, and no more books can be issued to the member.

5. Form analysis: Form analysis is an important and effective requirements

gathering activity that is undertaken by the analyst, when the project involves
Prepared By: Er. Inderjeet Singh(e8822) Page 6
 Software Engineering

automating an existing manual system. During the operation of a manual

system, normally several forms are required to be filled up by the
stakeholders, and in turn they receive several notifications (usually
manually filled forms). In form analysis the exiting forms and the formats
of the notifications produced are analysed to determine the data input to
the system and the data that are output from the system.

Requirements Analysis

After requirements gathering is complete, the analyst analyses the gathered

requirements to form a clear understanding of the exact customer
requirements and to weed out any problems in the gathered requirements. It is
natural to expect that the data collected from various stakeholders to contain
several contradictions, ambiguities, and incompleteness, since each stakeholder
typically has only a partial and incomplete view of the software. Therefore, it is
necessary to identify all the problems in the requirements and resolve them
through further discussions with the customer.

The main purpose of the requirements analysis activity is to analyse the

gathered requirements to remove all ambiguities, incompleteness, and
inconsistencies from the gathered customer requirements and to obtain a clear
understanding of the software to be developed.

Prepared By: Er. Inderjeet Singh(e8822) Page 7

 Software Engineering

During requirements analysis,the analyst needs to identify and resolve three main
types of problems in the requirements:

• Anomaly
• Inconsistency
• Incompleteness

1. Anomaly: It is an anomaly is an ambiguity in a requirement. When a

requirement is anomalous, several interpretations of that requirement are
possible. Any anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous requirement can be
interpreted in the several ways during development.
Example: While gathering the requirements for a process control
application, the following requirement was expressed by a certain
stakeholder: When the temperature becomes high, the heater should be
switched off. Please note that words such as “high”, “low”, “good”, “bad” etc.
are indications of ambiguous requirements as these lack quantification and can
be subjectively interpreted.
2. Inconsistency: Two requirements are said to be inconsistent, if one of the
requirements contradicts the other.
Example: Consider the following two requirements that were collected from
two different stakeholders in a process control application development
project.

Prepared By: Er. Inderjeet Singh(e8822) Page 8

 Software Engineering

• The furnace should be switched-off when the temperature of the

furnace rises above 500 C.
• When the temperature of the furnace rises above 500 C, the water
shower should be switched-on and the furnace should remain on.
3. Incompleteness: An incomplete set of requirements is one in which some
requirements have been overlooked. The lack of these features would be felt
by the customer much later, possibly while using the software. Often,
incompleteness is caused by the inability of the customer to visualise the
system that is to be developed and to anticipate all the features that would
be required. An experienced analyst can detect most of these missing
features and suggest them to the customer for his consideration and approval
for incorporation in the requirements.
Example: In a chemical plant automation software, suppose one of the
requirements is that if the internal temperature of the reactor exceeds
200 C then an alarm bell must be sounded. However, on an examination
of all requirements, it was found that there is no provision for resetting
the alarm bell after the temperature has been brought down in any of the
requirements. This is clearly an incomplete requirement.
Or

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,

Prepared By: Er. Inderjeet Singh(e8822) Page 9

 Software Engineering

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.

Steps of 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. The context diagram of student result management
system is given below:

Prepared By: Er. Inderjeet Singh(e8822) Page 10

 Software Engineering

Development of a Prototype (optional): One effective way to find out what the
customer wants is to construct a prototype, something that looks and preferably acts
as part of the system they say they want.

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.

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.

Prepared By: Er. Inderjeet Singh(e8822) Page 11

 Software Engineering

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

Software Requirement Specifications

After the analyst has gathered all the required information regarding the software
to be developed, and has removed all incompleteness, inconsistencies, and
anomalies from the specification, he starts to systematically organise the
requirements in the form of an SRS document. The SRS document usually
contains all the user requirements in a structured though an informal form.

Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to
write. One reason for this difficulty is that the SRS document is expected to cater
to the needs of a wide variety of audience.

Users of SRS Document

Users, customers, and marketing personnel: These stakeholders need to refer to

the SRS document to ensure that the system as described in the document will

Prepared By: Er. Inderjeet Singh(e8822) Page 12

 Software Engineering

meet their needs. Remember that the customer may not be the user of the
software, but may be some one employed or designated by the user.

• Software developers: The software developers refer to the SRS document to

make sure that they are developing exactly what is required by the
customer.
• Test engineers: The test engineers use the SRS document to understand
the functionalities, and based on this write the test cases to validate its
working. They need that the required functionality should be clearly
described, and the input and output data should have been identified
precisely.
• User documentation writers: The user documentation writers need to read
the SRS document to ensure that they understand the features of the product
well enough to be able to write the users‟ manuals.
• Project managers: The project managers refer to the SRS document to
ensure that they can estimate the cost of the project easily by referring to
the SRS document and that it contains all the information required to plan the
project.
• Maintenance engineers: The SRS document helps the maintenance
engineers to under- stand the functionalities supported by the system.

Prepared By: Er. Inderjeet Singh(e8822) Page 13

 Software Engineering

Characteristics of a Good SRS Document

The skill of writing a good SRS document usually comes from the experience
gained from writing SRS documents for many projects. However, the analyst
should be aware of the desirable qualities that every good SRS document should
possess. IEEE Recommended Practice for Software Requirements
Specifications[IEEE830] describes the content and qualities of a good software
requirements specification (SRS). Some of the identified desirable qualities of an
SRS document are the following:

• Concise: The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant
descriptions reduce readability and also increase the possibilities of errors in
the document.
• Implementation-independent: The SRS should be free of design and
implementation decisions unless those decisions reflect actual
requirements. It should only specify what the system should do and refrain
from stating how to do these. This means that the SRS document
should specify the externally visible behaviour of the system and not
discuss the implementation issues. This view with which a requirements
specification is written, has been shown in Figure 4.1.
Observe that in Figure 4.1, the SRS document describes the output produced
for the different types of input and a description of the processing required to
produce the output from the input

Prepared By: Er. Inderjeet Singh(e8822) Page 14

 Software Engineering

• Traceable: It should be possible to trace a specific requirement to the

design elements that implement it and vice versa. Similarly, it should be
possible to trace a requirement to the code segments that implement it
and the test cases that test this requirement and vice versa. Traceability is
also important to verify the results of a phase with respect to the previous
phase and to analyse the impact of changing a requirement on the design
elements and the code.
• Modifiable: Customers frequently change the requirements during the
software development due to a variety of reasons. Therefore, in practice the
SRS document undergoes several revisions during software
development. Also, an SRS document is often modified after the project
completes to accommodate future enhancements and evolution. To cope up
with the requirements changes, the SRS document should be easily
modifiable. For this, an SRS document should be well-structured. A well
structured document is easy to understand and modify.
Prepared By: Er. Inderjeet Singh(e8822) Page 15
 Software Engineering

• Identification of response to undesired events: The SRS document

should discuss the system responses to various undesired events and
exceptional conditions that may arise.
• Verifiable: All requirements of the system as documented in the SRS
document should be verifiable. This means that it should be possible to
design test cases based on the description of the functionality as to
whether or not requirements have been met in an implementation. A
requirement such as “the system should be user friendly” is not verifiable. On
the other hand, the requirement—“When the name of a book is entered, the
software should display whether the book is available for issue or it has been
loaned out” is verifiable. Any feature of the required system that is not
verifiable should be listed separately in the goals of the implementation
section of the SRS document.

Attributes of Bad SRS Documents

SRS documents written by novices frequently suffer from a variety of problems.

As discussed earlier, the most damaging problems are incompleteness,
ambiguity, and contradictions. There are many other types problems that a
specification document might suffer from. By knowing these problems, one can try
to avoid them while writing an SRS document. Some of the important
categories of problems that many SRS documents suffer from are as follows:

Prepared By: Er. Inderjeet Singh(e8822) Page 16

 Software Engineering

• Over-specification: It occurs when the analyst tries to address the “how to”
aspects in the SRS document. For example, in the library automation
problem, one should not specify whether the library membership records
need to be stored indexed on the member’s first name or on the library
member’s identification (ID) number. Over-specification restricts the
freedom of the designers in arriving at a good design solution.
• Forward references: One should not refer to aspects that are discussed much
later in the SRS document. Forward referencing seriously reduces
readability of the specification.
• Wishful thinking: This type of problems concern description of aspects
which would be difficult to implement.
• Noise: The term noise refers to presence of material not directly relevant to
the software development process. For example, in the register
customer function, suppose the analyst writes that customer registration
department is manned by clerks who report for work between 8am and
5pm, 7 days a week. This information can be called noise as it would hardly
be of any use to the software developers and would unnecessarily clutter
the SRS document, diverting the attention from the crucial points.

Summary: The SRS document should describe the system to be developed as a

black box, and should specify only the externally visible behaviour of the system.
For this reason, the SRS document is also called the black-box specification of
the software being developed.

Prepared By: Er. Inderjeet Singh(e8822) Page 17

 Software Engineering

Important Categories of Customer Requirements

A good SRS document, should properly categorize and organise the

requirements into different sections [IEEE830].

An SRS document should clearly document the following aspects of a software:

• Functional requirements
• Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
• Goals of implementation.

Functional requirements

The functional requirements capture the functionalities required by the users

from the system. Consider a software as offering a set of functions {f i} to the user.
These functions can be considered similar to a mathematical function f: I → O,
meaning that a function transforms an element (ii) in the input domain (I) to a
value (oi) in the output (O). This functional view of a system is shown schematically
in Figure 4.1.

Each function fi of the system can be considered as reading certain data ii, and
then transforming a set of input data (ii) to the corresponding set of output data
(oi). The functional requirements of the system, should clearly describe each
Prepared By: Er. Inderjeet Singh(e8822) Page 18
 Software Engineering

functionality that the system would support along with the corresponding input
and output data set.

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

Prepared By: Er. Inderjeet Singh(e8822) Page 19

 Software Engineering

How to Document the Functional Requirements?

Once all the high-level functional requirements have been identified and the
requirements problems have been eliminated, these are documented. A
function can be documented by identifying the state at which the data is to be
input to the system, its input data domain, the output data domain, and the type
of processing to be carried on the input data to obtain the output data.

Let us first try to document the withdraw-cash function of an automated teller

machine (ATM) system in the following. The withdraw-cash is a high-level
requirement. It has several sub-requirements corresponding to the different user
interactions. These user interaction sequences may vary from one invocation from
another depending on some conditions. These different interaction sequences
capture the different scenarios. To accurately describe a functional requirement,
we must document all the different scenarios that may occur.

Example 4.7 (Withdraw cash from ATM): An initial informal description of a

required functionality is usually given by the customer as a statement of purpose
(SoP). An SoP serves as a starting point for the analyst and he proceeds with the
requirements gathering activity after a basic understanding of the SoP.

R.1: Withdraw cash

Description: The withdraw cash function first determines the type of account
that the user has and the account number from which the user wishes to withdraw
cash. It checks the balance to determine whether the requested amount is
Prepared By: Er. Inderjeet Singh(e8822) Page 20
 Software Engineering

available in the account. If enough balance is available, it outputs the required

cash, otherwise it generates an error message.

R.1.1: Select withdraw amount option

Input: “Withdraw amount” option selected

Output: User prompted to enter the account type

R.1.2: Select account type

Input: User selects option from any one of the followings—

savings/checking/deposit.

Output: Prompt to enter amount

R.1.3: Get required amount Input: Amount to be withdrawn in integer values

greater than 100 and less than 10,000 in multiples of 100.

Output: The requested cash and printed transaction statement. Processing: The
amount is debited from the user’s account if sufficient balance is available,
otherwise an error message displayed.

Non-functional requirements

The non-functional requirements are non-negotiable obligations that must be

supported by the software. The non-functional requirements capture those
requirements of the customer that cannot be expressed as functions (i.e.,
accepting input data and producing output data). Non-functional

Prepared By: Er. Inderjeet Singh(e8822) Page 21

 Software Engineering

requirements usually address aspects concerning external interfaces, user

interfaces, maintainability, portability, usability, maximum number of
concurrent users, timing, and throughput (transactions per second, etc.). The
non-functional requirements can be critical in the sense that any failure by the
developed software to achieve some minimum defined level in these
requirements can be considered as a failure and make the software
unacceptable by the customer.

• Example of nonfunctional requirement, “how fast does the website load?”

They deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

Example:

N.1: Database: A data base management system that is available free of cost in
the public domain should be used.

N.2: Platform: Both Windows and Unix versions of the software need to be
developed.
Prepared By: Er. Inderjeet Singh(e8822) Page 22
 Software Engineering

N.3: Web-support: It should be possible to invoke the query book functionality

from any place by using a web browser.

In the following subsections, we discuss the different categories of non-functional

requirements that are described under three different sections:

Design and implementation constraints: Design and implementation

constraints are an important category of non-functional requirements describe
any items or issues that will limit the options available to the developers. Some
of the example constraints can be—corporate or regulatory policies that needs to
be honoured; hardware limitations; interfaces with other applications; specific
technologies, tools, and databases to be used; specific communications
protocols to be used; security considerations; design conventions or
programming standards to be followed, etc. Consider an example of a
constraint that can be included in this section—Oracle DBMS needs to be used
as this would facilitate easy interfacing with other applications that are already
operational in the organisation.

External interfaces required: Examples of external interfaces are— hardware,

software and communication interfaces, user interfaces, report formats, etc. To
specify the user interfaces, each interface between the software and the users
must be described. The description may include sample screen images, any GUI
standards or style guides that are to be followed, screen layout constraints,

Prepared By: Er. Inderjeet Singh(e8822) Page 23

 Software Engineering

standard buttons and functions (e.g., help) that will appear on every screen,
keyboard shortcuts, error message display standards, and so on.

Other non-functional requirements: The description of non- functional

requirements that are neither design constraints and nor are external interface
requirements. An important example is a performance requirement such as
the number of transactions completed per unit time. Besides performance
requirements, the other non-functional requirements to be described in this
section may include reliability issues, accuracy of results, and security issues.

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

Prepared By: Er. Inderjeet Singh(e8822) Page 24

 Software Engineering

Goals of implementation

The ‘goals of implementation’ part of the SRS document offers some general
suggestions regarding the software to be developed. These are not binding on the
developers, and they may take these suggestions into account if possible. For
example, the developers may use these suggestions while choosing among
different design solutions.

A goal, in contrast to the functional and non-functional requirements, is not

checked by the customer for conformance at the time of acceptance testing.

The goals of implementation section might document issues such as easier

revisions to the system functionalities that may be required in the future, easier
support for new devices to be supported in the future, reusability issues, etc.
These are the items which the developers might keep in their mind during
development so that the developed system may meet some aspects that are not
required immediately.

Prepared By: Er. Inderjeet Singh(e8822) Page 25

 Software Engineering

Functional Requirements Non-functional requirements

Functional requirements help to understand They help to understand the system's
the functions of the system. performance.
It concentrates on the expectation and
It concentrates on the user's requirement.
experience of the user.
It helps us to verify the software's It helps us to verify the software's
functionality. performance.
These requirements are specified by the
These requirements are specified by the user. software developers, architects, and technical
persons.
There is functional testing such as API testing, There is non-functional testing such as
system, integration, etc. usability, performance, stress, security, etc.
Examples of the non-functional requirements
Examples of the functional requirements are -
are -
Authentication of a user on trying to log in to
The background color of the screens should be
the system.
light blue.
These requirements are important to system These are not always the important
operation. requirements, they may be desirable.
Completion of Functional requirements allows
While system will not work only with non-
the system to perform, irrespective of meeting
functional requirements.
the non-functional requirements.
Example Example
1) Authentication of user whenever he/she 1) Emails should be sent with a latency of no
logs into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be
3) A Verification email is sent to user done within 10 seconds
whenever he/she registers for the first time on 3) The site should load in 3 seconds when the
some software system. number of simultaneous users are > 10000

Prepared By: Er. Inderjeet Singh(e8822) Page 26

 Software Engineering

Techniques for Representing Complex Logic

There are two main techniques available to analyse and represent complex
processing logic—decision trees and decision tables. Once the decision
making logic is captured in the form of trees or tables, the test cases to validate
these logic can be automatically obtained. It should, however, be noted that
decision trees and decision tables have much broader applicability than just
specifying complex processing logic in an SRS document.

Decision tree

A decision tree gives a graphic view of the processing logic involved in decision
making and the corresponding actions taken. Decision tables specify which
variables are to be tested, and based on this what actions are to be taken
depending upon the outcome of the decision making logic, and the order in which
decision making is performed.

The edges of a decision tree represent conditions and the leaf nodes
represent the actions to be performed depending on the outcome of testing the
conditions. Instead of discussing how to draw a decision tree for a given
processing logic, we shall explain through a simple example how to represent the
processing logic in the form of a decision tree.

Example 4.10 A library membership management software (LMS) should support

the following three options—new member, renewal, and cancel membership.
When the new member option is selected, the software should ask the member’s
Prepared By: Er. Inderjeet Singh(e8822) Page 27
 Software Engineering

name, address, and phone number. If proper information is entered, the software
should create a membership record for the new member and print a bill for the
annual membership charge and the security deposit payable.

If the renewal option is chosen, the LMS should ask the member’s name and his
membership number and check whether he is a valid member. If the member
details entered are valid, then the membership expiry date in the membership
record should be updated and the annual membership charge payable by the
member should be printed. If the membership details entered are invalid, an
error message should be displayed.

If the cancel membership option is selected and the name of a valid member is
entered, then the membership is cancelled, a choke for the balance amount due
to the member is printed and his membership record is deleted. The decision tree
representation for this problem is shown in Figure 4.3.

Prepared By: Er. Inderjeet Singh(e8822) Page 28

 Software Engineering

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

Disadvantages

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

Decision table

A decision table shows the decision making logic and the corresponding actions
taken in a tabular or a matrix form. The upper rows of the table specify the
variables or conditions to be evaluated and the lower rows specify the actions to
be taken when an evaluation test is satisfied. A column in the table is called a

Prepared By: Er. Inderjeet Singh(e8822) Page 29

 Software Engineering

rule. A rule implies that if a certain condition combination is true, then the
corresponding action is executed.

The decision table for the LMS problem of Example 4.10 is as shown in Table 4.1.

Decision table versus decision tree

 Readability: Decision trees are easier to read and understand when the
number of conditions are small. On the other hand, a decision table causes the
analyst to look at every possible combination of conditions which he might
otherwise omit.
 Explicit representation of the order of decision making: In contrast to the
decision trees, the order of decision making is abstracted out in decision
tables. A situation where decision tree is more useful is when multilevel

Prepared By: Er. Inderjeet Singh(e8822) Page 30

 Software Engineering

decision making is required. Decision trees can more intuitively represent

multilevel decision making hierarchically, whereas decision tables can only
represent a single decision to select the appropriate action for execution.
 Representing complex decision logic: Decision trees become very
complex to understand when the number of conditions and actions increase. It
may even be to draw the tree on a single page. When very large number of
decisions are involved, the decision table representation may be preferred.

S. Decision Table Decision Tree

No.
1. Decision Tables are a tabular Decision Trees are a graphical
representation of conditions and representation of every possible outcome
actions. of a decision.
2. We can derive a decision table We can not derive a decision tree from
from the decision tree. the decision table.
3. It helps to clarify the criteria. It helps to take into account the possible
relevant outcomes of the decision.
4. In Decision Tables, we can In Decision Trees, we can not include
include more than one „or‟ more than one „or‟ condition.
condition.
5. It is used when there are small It is used when there are more number of
number of properties. properties.
6. It is used for simple logic only. It can be used for complex logic as well.
7. It is constructed of rows and It is constructed of branches and nodes.
tables.
8. The goal of using a decision table A decision tree‟s objective is to provide
is the generation of rules for an effective means to visualize and
structuring logic on the basis of understand a decision‟s available
data entered in the table. possibilities and range of possible
outcomes.

Prepared By: Er. Inderjeet Singh(e8822) Page 31

 Software Engineering

Formal Specification

A formal technique is a mathematical method to specify a hardware and/or

software system, verify whether a specification is realisable, verify that an
implementation satisfies its specification, prove properties of a system without
necessarily running the system, etc. The mathematical basis of a formal
method is provided by its specification language. More precisely, a formal
specification language consists of two sets—syn and sem, and a relation sat
between them. The set syn is called the syntactic domain, the set sem is called the
semantic domain, and the relation sat is called the satisfaction relation. For a given
specification syn, and model of the system sem, if sat (syn, sem), then syn is said
to be the specification of sem, and sem is said to be the specificand of syn.

In general, formal techniques can be used at every stage of the system

development activity to verify that the output of one stage conforms to the
output of the previous stage.

Example: The level of rigor used should be tailored to fit the specific project w.r.t
System critical level, budget, schedule, technical environments

Syntactic domains

The syntactic domain of a formal specification language consists of an alphabet of

symbols and a set of formation rules to construct well-formed formulas from the
alphabet. The well-formed formulas are used to specify a system.

Prepared By: Er. Inderjeet Singh(e8822) Page 32

 Software Engineering

Semantic domains

Formal techniques can have considerably different semantic domains. Abstract

data type specification languages are used to specify algebras, theories, and
programs. Programming languages are used to specify functions from input to
output values. Concurrent and distributed system specification languages are
used to specify state sequences, event sequences, state-transition sequences,
synchronisation trees, partial orders, state machines, etc.

Advantages:

o Well-defined semantics, no scope for ambiguity

o Automated tools can check properties of specifications
o Executable specification
o The development of a formal specification provides insights and
understanding of the software requirements and the software
design.
o 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.
o Formal specification may be automatically processed. Software tools can
be built to assist with their development, understanding, and debugging.

Disadvantages:

 Formal methods are difficult to learn and use.

Prepared By: Er. Inderjeet Singh(e8822) Page 33
 Software Engineering

 The basic incompleteness results of first-order logic suggest that it is

impossible to check absolute correctness of systems using theorem proving
techniques.
 Formal techniques are not able to handle complex problems. This
shortcoming results from the fact that, even moderately complicated problems
blow up the complexity of formal specification and their analysis. Also, a
large unstructured set of mathematical formulas is difficult to comprehend.

Model versus property-oriented methods

Formal methods are usually classified into two broad categories—the so-called
model-oriented and the property-oriented approaches.

In a model-oriented style, one defines a system’s behaviour directly by

constructing a model of the system in terms of mathematical structures such as
tuples, relations, functions, sets, sequences, etc.

In the property-oriented style, the system’s behaviour is defined indirectly by

stating its properties, usually in the form of a set of axioms that the system must
satisfy. Let us consider a simple producer/consumer example. In a property-
oriented style, we would probably start by listing the properties of the system
like—the consumer can start consuming only after the producer has produced an
item, the producer starts to produce an item only after the consumer has

Prepared By: Er. Inderjeet Singh(e8822) Page 34

 Software Engineering

consumed the last item, etc. Two examples of property-oriented specification

styles are axiomatic specification and algebraic specification.

It is alleged that property-oriented approaches are more suitable for

requirements specification, and that the model-oriented approaches are more
suited to system design specification.

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.

Prepared By: Er. Inderjeet Singh(e8822) Page 35

 Software Engineering

Or

Data modelling in analysis is the process of creating a visual representation ,

abstraction of data structures, relationships, and rules within a system or
organization. Determining and analysing the data requirements required to support
business activities within the bounds of related information systems in organisations
is another process known as data modelling.

The main objective of data modelling is to provide a precise and well-

organized framework for data organisation and representation, since it enables
efficient analysis and decision-making.

Types of Data Modeling

These are the 5 different types of data models:

Hierarchical Model: The structure of the hierarchical model resembles a tree. The
remaining child nodes are arranged in a certain sequence, and there is only one root
node—or, alternatively, one parent node. However, the hierarchical approach is no
longer widely applied. approach connections in the actual world may be modelled
using this approach.

For Example , For example, in a college there are many courses, many professors
and students. So college became a parent and professors and students became its
children.

Prepared By: Er. Inderjeet Singh(e8822) Page 36

 Software Engineering

Relational Model: Relational Mode represent the links between tables by

representing data as rows and columns in tables. It is frequently utilised in database
design and is strongly related to relational database management systems
(RDBMS).

Object-Oriented Data Model: In this model, data is represented as objects,

similar to those used in object-oriented programming ,Creating objects with
stored values is the object-oriented method. In addition to allowing data
abstraction, inheritance, and encapsulation, the object-oriented architecture
facilitates communication.

Network Model :We have a versatile approach to represent objects and the
relationships among these things thanks to the network model. One of its features
is a schema, which is a graph representation of the data. An item is stored
within a node, and the relationship between them is represented as an edge. This
allows them to generalise the maintenance of many parent and child records.

Prepared By: Er. Inderjeet Singh(e8822) Page 37

 Software Engineering

ER-Model: A high-level relational model called the entity-relationship model (ER

model) is used to specify the data pieces and relationships between the entities in a
system. This conceptual design gives us an easier-to-understand perspective on the
facts. An entity-relationship diagram, which is made up of entities, attributes, and
relationships, is used in this model to depict the whole database.

A relationship between entities is called an association. Mapping cardinality many

associations like:

 one to one

 one to many

 many to one

 many to many

Functional modelling and Information Flow modelling

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 (i.e., be manufactured). In a series of iterations, more and
more functional detail is given, until all system functionality is fully represented.

Prepared By: Er. Inderjeet Singh(e8822) Page 38

 Software Engineering

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. The transformation (s) or
function may be composed of a single logical comparison, a complex numerical
method, or a rule- the invention approach of an expert system. The output can
light an LED or provide a 200 page report. Instead, we can create a model or flow
model for any computer- based system, regardless of size and complexity.

Structural analysis started as an Information Flow Modelling technique. A

computer-based system can be modeled as an information transform function as
shown in figure.

A rectangle represents an external unit. That is, a system element, such as a

hardware, a person or another system that provides information for transformation
by the software or receives information provided by the software. A circle is used
to represent a process or transform or a function that is applied to data and
changes it in some way. An arrow is used to represent one or more data items.

Prepared By: Er. Inderjeet Singh(e8822) Page 39

 Software Engineering

All arrows should be labeled in a DFD. The double line is used to represent data
store. There may be implicit procedure or sequence in the diagram but explicit
logical details are generally delayed until software design.

Behavioral Model is specially designed to make us understand behavior and

factors that influence behavior of a System. Behavior of a system is explained and
represented with the help of a diagram. This diagram is known as State Transition
Diagram. It is a collection of states and events. It usually describes overall states
that a system can have and events which are responsible for a change in state of a
system.
Prepared By: Er. Inderjeet Singh(e8822) Page 40
 Software Engineering

They consist of the following:

• Activity diagrams
• Interaction diagrams
• Use case diagrams

So, on some occurrence of a particular event, an action is taken and what action
needs to be taken is represented by State Transition Diagram.

Example :
Consider an Elevator. This elevator is for n number of floors and has n number of
buttons one for each floor.
Elevator‟s working can be explained as follows :

1. Elevator buttons are type of set of buttons which is there on elevator. For
reaching a particular floor you want to visit, “elevator buttons” for that
particular floor is pressed. Pressing, will cause illumination and elevator will
start moving towards that particular floor for which you pressed “elevator
buttons”. As soon as elevator reaches that particular floor,
illumination gets canceled.
2. Floor buttons are another type of set of buttons on elevator. If a person is on
a particular floor and he wants to go on another floor, then elevator button for
that floor is pressed. Then, process will be same as given above. Pressing, will
cause illumination and elevator to start moving, and when it reaches on
desired floor, illumination gets canceled.
3. When there is no request for elevator, it remains closed on current floor.
Prepared By: Er. Inderjeet Singh(e8822) Page 41
 Software Engineering

Advantages :

 Behavior and working of a system can easily be understood without any

effort.
 Results are more accurate by using this model.
 This model requires less cost for development as cost of resources can be
minimal.
 It focuses on behavior of a system rather than theories.

Prepared By: Er. Inderjeet Singh(e8822) Page 42

 Software Engineering

Disadvantages :

 This model does not have any theory, so trainee is not able to fully understand
basic principle and major concept of modeling.
 This modeling cannot be fully automated.
 Sometimes, it‟s not easy to understand overall result.
 Does not achieve maximum productivity due to some technical issues or any
errors.

Structural Modelling

Modeling means creating a diagram for a system that includes identifying the
elements that are important to your particular module. The structural modeling
gives a structural view of a system that highlights the structure of the objects
including their classifiers, relationships, attributes and operations. These
elements form the vocabulary of the system you are modeling. For example, if you
are going to buy a car, things like wheels, frame size, color, lights, and engine are
some things that will be worthful to you in understanding about the car; these
things are properties of the car. In UML, all of these things are modelled as classes.
Cars have external and internal structure, only important properties of car are
visible and the rest are hidden. This feature is called abstraction. A class is an
abstraction of the things that are a part of your vocabulary. For creating a
structural model, you have to collect key data contained in the problem domain.

Prepared By: Er. Inderjeet Singh(e8822) Page 43

 Software Engineering

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

Prepared By: Er. Inderjeet Singh(e8822) Page 44

 Software Engineering

Classes

A class describes a group of objects which have common attributes or properties,

operations or behavior, relationships and semantics. Classes are an essential
structure of any object-oriented system.

Prepared By: Er. Inderjeet Singh(e8822) Page 45

 Software Engineering

Relationships

Relationships define how classes communicate with each other. There are three
basic types of relationships in UML- Dependencies, Generalization and
Associations for connecting or communicating classes to each other.

Dependency describes the relationships among classes in which one class is

dependent on another class. It means that if you make changes in one class, it will
affect the other class. For example, class Vehicle uses the properties and
operations of another class (say Bodyshop) but not necessarily the reverse.

Generalization is a “a-kind-of” relationship. It creates relationships between

superclass(base class) and subclass, enabling inheritance of attributes and
operations. It defines a base( parent) class with some properties functions. A new
class will be derived from this base class and it is called child or sub class of the
base class. The child class can use the properties and operations of the superclass.

Prepared By: Er. Inderjeet Singh(e8822) Page 46

 Software Engineering

As you can see in figure-2.5, vehicle class is super class or base or parent class and
Car, Bus are child class or sub class.

Association is “a-part-of” relationships between classes. It refers to relationships

between classes in which objects of one class are connected to other class objects
for communicating data as you can see in figure-2.6.

When you connect just two classes is called a binary association. Associations can
also have more than two classes, which will be known as n-ary associations. One
more form of association is called aggregation that specifies a whole-part
relationship between the aggregate (whole) and the component part. For

Prepared By: Er. Inderjeet Singh(e8822) Page 47

 Software Engineering

example, paragraph is part of word document. Each association can have a name,
role, multiplicity and aggregation.

Data Dictionary

Data Dictionary is the major component in the structured analysis model of the
system. It lists all the data items appearing in DFD. A data dictionary in Software
Engineering means a file or a set of files that includes a database‟s metadata (hold
records about other objects in the database), like data ownership, relationships of
the data to another object, and some other data. This article focuses on discussing
data dictionaries in detail.

What is a Data Dictionary?

Prepared By: Er. Inderjeet Singh(e8822) Page 48

 Software Engineering

The data dictionary is a centralized repository of information about data. It provides

a detailed description of the data, including its meaning, relationship to other data,
usage, and format.

1. These are important in database management, data modeling, and software

development.

2. It helps to ensure consistency, clarity, and efficient data management.

3. It helps to ensure that everyone in the organization understands the data, how
it should be used, and how it should be managed.

4. It is essential for maintaining data quality and facilitating effective data

governance.

Components of Data Dictionary

In Software Engineering, the data dictionary contains the following information:

1. Data Elements: This includes the attributes of the data element such as
Name, Description, Type, Length, Default Value, and Constraints.

2. Data Structure: This includes Tables, Fields, Keys, and Indexes.

3. Relationships: This includes information about the Relationships and

Dependencies.

4. Usage and Access Information: This includes Access Permissions, Usage,

and Update Frequency.
Prepared By: Er. Inderjeet Singh(e8822) Page 49
 Software Engineering

5. Data Quality Metrics: This includes information regarding Accuracy,

Completeness, Consistency, and Timelines about data.

6. Data Lineage: Information about the Source, Transformation, and

Destination of data is included.

7. Versioning and History: Version and History of the data element definition
are recorded.

8. Technical Metadata: Storage Information and Storage Format are also

recorded.

9. Business Metadata: Business Rules and the Business Context in which the
data is used are included.

How to Create a Data Dictionary?

Here is a brief overview of the steps involved in creating a data dictionary:

1. Define Scope and Objectives: This involves identifying the objective of the
data dictionary and the data elements it will cover.

2. Gather Metadata: Collect detailed information about each data element.

3. Organize Information: Structure the collected metadata in a clear and

accessible format.

4. Implement Standard Naming Conventions: Ensure consistency in how data

elements are named and described.
Prepared By: Er. Inderjeet Singh(e8822) Page 50
 Software Engineering

5. Create and Enter Data in Data Dictionary: Use software tools to build the
data dictionary and enter the data.

6. Review and Validate: Ensure the accuracy and completeness of the data
dictionary.

7. Maintain and Update Regularly: Keep the data dictionary up to date with
ongoing updates and changes.

Uses of Data Dictionary

Here are some of the key uses of a data dictionary:

1. Data Consistency: Data dictionary ensures that all the elements are
consistently defined and used across the organization.

2. Improved Data Quality: It helps to maintain detailed information about the

data sources, lineage, etc, thus helping in identifying and addressing data
quality issues.

3. Support for Data Analytics: A Data dictionary offers detailed metadata that
helps analysts understand the context and meaning of the data they are
working with.

4. Improved Communication: Data dictionary acts as a common reference

point for all the teams and departments, thus facilitating better
communication.

Prepared By: Er. Inderjeet Singh(e8822) Page 51

 Software Engineering

5. Efficient Data Integration: It provides a centralized source of understanding

of how data elements from different systems relate to each other.

Benefits of Using Data Dictionary

Here are some benefits of using a data dictionary:

1. Improved Data Quality: Data dictionary reduces discrepancies and errors,

leading to higher quality data and more reliability for decision-making.

2. Enhanced Data Understanding: Data dictionary provides clear definitions

and descriptions of data elements, thus making it easier for users to
understand the data.

3. Facilitates Data Interoperability: Standardized data definitions and formats

in a data dictionary enhance interoperability between systems and make it
easier to combine and analyze data from different parts of the organization.

4. Increased Efficiency in Data Utilization: A data dictionary improves the

efficiency of data-related tasks such as data analysis, data reporting, and
system development, ultimately saving time and resources.

5. Support for Data Compliance: A data dictionary helps enforce data

governance policies, which is crucial for ensuring compliance with regulatory
requirements.

Limitations of Data Dictionary

Prepared By: Er. Inderjeet Singh(e8822) Page 52

 Software Engineering

Data dictionaries are highly beneficial but they also come with certain limitations.
Here are some limitations of the data dictionary:

1. Implementation and Maintenance Costs: Implementing and maintaining a

data dictionary can be costly, requiring significant resources in terms of time,
money, and personnel.

2. Data Dictionary Complexity: A data dictionary can be complex and difficult

to manage, particularly in large organizations with multiple systems and data
sources.

3. Resistance to Change: Some stakeholders may be resistant to using a data

dictionary, either due to a lack of understanding or because they prefer to use
their terminology or definitions.

4. Data Security: A data dictionary can contain sensitive information, and

therefore, proper security measures must be in place to ensure that
unauthorized users do not access or modify the data.

5. Data Governance: A data dictionary requires strong data governance

practices to ensure that data elements and attributes are managed effectively
and consistently across the organization.

Prepared By: Er. Inderjeet Singh(e8822) Page 53