5(re dfd-erd-data dictionay)

1. Requirements Engineering
Lecture @LPU

2. Course Contents
Introduction
Understanding Requirements
Functional and Non –Functional Requirements
Other Classifications
Modelling Requirements
Overview
Data Flow Diagram
Entity Relationship Diagram
Data Dictionary
Decision tree and Decision tables
Structured English
State Transition Diagram
Conclusion

3. Introduction
The objectives of this module are
To establish the importance / relevance of requirement specifications in
software development
To bring out the problems involved in specifying requirements
To illustrate the use of modelling techniques to minimize problems in
specifying requirements
Requirements can be defined as follows:
A condition or capability needed by a user to solve a problem or achieve an
objective.
A condition or capability that must be met or possessed by a system to satisfy a
contract, standard, specification, or other formally imposed document

4. High Level Requirements
High level, requirements can be classified as user/client requirements and
software requirements.
Client requirements are usually stated in terms of business needs.
Software requirements specify what the software must do to meet the business
needs.
For example, a stores manager might state his requirements in terms of efficiency
in stores management.
A bank manager might state his requirements in terms of time to service his
customers.
It is the analyst's job to understand these requirements and provide an
appropriate solution.

5. Understand the client’s business domain
To be able to do this, the analyst must understand the client's business
domain:
Who are all the stake holders,
How they affect the system,
What are the constraints,
What is the adjustable, etc?
The analyst should not blindly assume that only a software solution will
solve a client's problem.
He should have a broader vision. Sometimes, re-engineering of the
business processes may be required to improve efficiency and that may
be all that is required.
After all this, if it is found that a software solution will add value, then a
detailed statement of what the software must do to meet the client's
needs should be prepared. This document is called Software
Requirements Specification (SRS) document.

6. Understanding Requirements
Stating and understanding requirements is not an easy task. Let us look at a
few examples:
"The counter value is picked up from the last record"
In the above statement, the word 'last' is ambiguous. It could mean the last accessed
record, which could be anywhere in a random access file, or, it could be physically
the last record in the file
"Calculate the inverse of a square matrix 'M' of size 'n' such that LM=ML=In where
'L' is the inverse matrix and 'In' is the identity matrix of size 'n' "
This statement though appears to be complete, is missing on the type of the matrix
elements. Are they integers, real numbers, or complex numbers. Depending on the
answer to this question, the algorithm will be different.
"The software should be highly user friendly"
How does one determine, whether this requirement is satisfied or not.
"The output of the program shall usually be given within 10 seconds"
What are the exceptions to the 'usual 10 seconds' requirement?

7. The statement of requirements or SRS
should possess the following properties:
All requirements must be correct. There should be no accurate errors
All requirements should have one interpretation only. We have seen a few
examples of ambiguous statements above.
The SRS should be complete in all respects. It is difficult to achieve this objective.
Many times clients change the requirements as the development progresses or new
requirements are added. The Agile development methodologies are specifically
designed to take this factor in to account. They partition the requirements in to
subsets called scenarios and each scenario is implemented separately. However,
each scenario should be complete.

8. Contd….
All requirements must be verifiable, that is, it should be possible to verify if a
requirement is met or not. Words like 'highly', 'usually', should not be used.
All requirements must be consistent and non-conflicting.
As we have stated earlier, requirements do change. So the format of the SRS should
be such that the changes can be easily incorporated

9. Functional Requirements
Requirements can be classified in to two types, namely, functional requirements
and non-functional requirements.
Functional requirements specify what the system should do.
Examples are:
Calculate the compound interest at the rate of 14% per annum on a fixed deposit for
a period of three years
Calculate tax at the rate of 30% on an annual income equal to and above
Rs.2,00,000 but less than Rs.3,00,000
Invert a square matrix of real numbers (maximum size 100 X 100)

10. Non-Functional Requirements
Non-functional requirements specify the overall quality attributes the
system must satisfy.
The following is a sample list of quality attributes:
Portability
Reliability
Performance
Testability
Modifiability
Security
Presentation
Reusability
Understandability
Acceptance Criteria
Interoperability

11. Examples of non-functional requirements
Some examples of non-functional requirements are:
Number of significant digits to which accuracy should be maintained in all
numerical calculations is 10.
The response time of the system should always be less than 5 seconds
The software should be developed using C language on a UNIX based system
A book can be deleted from the Library Management System by the Database
Administrator only

12. Other Classifications
Requirements can also be classified in to the following categories:
Satisfiability
Criticality
Stability
User categories
Satisfiability:
There are three types of Satisfiability, namely, normal, expected, and
exciting.
Normal requirements are specific statements of user needs. The user
satisfaction level is directly proportional to the extent to which these
requirements are satisfied by the system.

13. Other Classifications Contd…..
Expected requirements may not be stated by the users, but the
developer is expected to meet them. If the requirements are met, the
user satisfaction level may not increase, but if they are not met, users
may be thoroughly dissatisfied. They are very important from the
developer's point of view.
Exciting requirements, not only, are not stated by the users, they do not
even expect them. But if the developer provides for them in the system,
user satisfaction level will be very high. The trend over the years has been
that the exciting requirements often become normal requirements and some
of the normal requirements become expected requirements.

14. Satisfiability Requirements

15. Criticality
Criticality: This is a form of prioritizing the requirements. They can be
classified as mandatory, desirable, and non-essential. This classification should
be done in consultation with the users and helps in determining the focus in an
iterative development model.
Stability: Requirements can also be categorized as stable and non-stable.
Stable requirements don't change often, or atleast the time period of change will
be very long.
Non - Stable requirements Some requirements may change often.

16. User categories
User categories:
 As was stated in the introduction, there will be many stake holders in a
system. Broadly they are of two kinds. Those who dictate the policies of the
system and those who utilize the services of the system. All of them use the
system. There can be further subdivisions among these classes depending on the
information needs and services required. It is important that all stakeholders
are identified and their requirements are captured.

17. Modelling Requirements
Overview
Every software system has the following essential characteristics:
It has a boundary. The boundary separates what is with in system scope
and what is outside
It takes inputs from external agents and generates outputs.
It has processes which collaborate with each other to generate the
outputs.
These processes operate on data by creating, modifying, destroying, and
querying it.
The system may also use data stores to store data which has a life beyond
the system

18. Structured Systems Analysis and Design
Methodology (SSADM)
Describing artifacts used by Structured Systems Analysis and Design
Methodology (SSADM).
It uses:
Data Flow Diagram (DFD) for modelling processes and their interactions.
Entity Relationship Diagram (ERD) for modelling data and their
relationships.
Data Dictionary to specify data
Decision Tables and Decision Trees to model complex decisions.
Structured English to paraphrase process algorithms.
State Transition Diagram to model state changes of the system.

19. Data Flow Diagram (DFD)
Data Flow Diagram (DFD)
Data flow diagram focuses on movement of data through the system and its
transformations.
 It is divided in to levels. Level 0, also known as the context diagram, defines the
system scope. It consists of external agents, system boundary, and the data flow
between the external agents and the system.
Level 1 is an explosion of Level 0, where all the major processes, data stores, and
the data flow between them is shown. Level 2, Level 3, etc. show details of
individual processes.

20. Symbols

21. The notation used in DFD
External agents: They are external to the system, but interact with the system.
They must be drawn at level 0, but need not be drawn at level 2 onwards.
Duplicates are to be identified. They must be given meaningful names.
Process: They indicate information processing activity. They must be shown at all
levels, At level 0, only a single process, depicting the system is shown. On
subsequent levels, the number of processes should be limited to 7 ± 2. No
duplicates are allowed.

22. The notation used in DFD Contd….

23. The notation used in DFD Contd….
Data Stores: They are used to store information. They are not shown at
level 0. All data stores should be shown at level 1. Duplicates must be
indicated.

24. The notation used in DFD Contd….
Data Flows: They indicate the flow of information. They must be shown at all
levels and meaningful names must be given.

25. Getting started:
Identify the inputs or events which trigger the system and outputs or
responses from the system
Identify the corresponding sources and destinations (external agents)
Produce a context diagram (Level 0). It should show the system
boundary, external agents, and the data flows connecting the system
and the external agents.
Produce Level 1 diagram. It must show all the external agents, all the
major processes, all the data stores, and all the data flows connecting
the various artifacts. The artifacts should be placed based on logical
precedence rather than temporal precedence. Avoid dataflow crossings.
Refine the Level 1 diagram.
Explode the individual processes as necessary.

26. Points to remember
1) Remember to name every external agent, every process, every data store,
and every dataflow.
2) Do not show how things begin and end.
3) Do not show loops, and decisions.
4) Do not show data flows between external agents. They are outside the
scope of the system.

27. Points to remember Contd…..
5) Do not show dataflow between an external agent and a data store. There
should be a process in between.

28. Points to remember Contd…..
6) Do not show dataflow between two data stores. There should be a process
in between.

29. Points to remember Contd…..
7) There should not be any unconnected external agent, process, or data store.
8) Beware of read-only or write-only data stores
9) Beware of processes which take inputs without generating any outputs. Also, beware
of processes which generate outputs spontaneously without taking any inputs.

30. Entity Relationship Diagram (ERD)
ERD complements DFD.
While DFD focuses on processes and data flow between them,
ERD focuses on data and the relationships between them.
It helps to organize data used by a system in a disciplined way.
It helps to ensure completeness, adaptability and stability of data.
It is an effective tool to communicate with senior management (what is the
data needed to run the business), data administrators (how to manage and
control data), database designers (how to organize data efficiently and
remove redundancies).

31. ERD Components
It consists of three components.
Entity
Attributes
Relationships
Entity: It represents a collection of objects or things in the real world whose
individual members or instances have the following characteristics:
Each can be identified uniquely in some fashion.
Each plays a necessary role in the system we are building.
Each can be described by one or more data elements (attributes).
Entities generally correspond to persons, objects, locations, events, etc.
Examples are employee, vendor, supplier, materials, warehouse, delivery, etc.

32. Types of Entities
There are five types of entities.
Fundamental entity: It does not depend on any other entity for its existence.
For e.g. materials
Subordinate entity: It depends on another entity for its existence.
For example, in an inventory management system, purchase order can be an entity and it
will depend on materials being procured. Similarly invoices will depend on purchase
orders.
Associative entity: It depends on two or more entities for its existence.
 For example, student grades will depend on the student and the course.
Generalization entity: It encapsulates common characteristics of many subordinate entities.
For example, a four wheeler is a type of vehicle. A truck is a type of four wheeler .
Aggregation entity: It consists of or an aggregation of other entities.
For example, a car consists of engine, chasis, gear box, etc. A vehicle can also be regarded
as an aggregation entity, because a vehicle can be regarded as an aggregation of many
parts.

33. Attributes
AttributesAttributes:: They express the properties of the entities.
Every entity will have many attributes, but only a subset, which are relevant for the
system under study, will be chosen.
For example, an employee entity will have professional attributes like name,
designation, salary, etc. and also physical attributes like height, weight, etc. But
only one set will be chosen depending on the context.

34. Relationships
Relationships: They describe the association between entities.
They are characterized by optionality and cardinality.
Optionality is of two types, namely, mandatory and optional.
Mandatory relationship means associated with every instance of the first
entity there will be at least one instance of the second entity.
Optional relationship means that there may be instances of the first entity,
which are not associated with any instance of the second entity.
For example, employee-spouse relationship has to be optional because
there could be unmarried employees. It is not correct to make the
relationship mandatory.

35. Relationships Contd…..
Cardinality is of three types: one-to-one, one-to-many, many-to-many.
One-to-one relationship means an instance of the first entity is associated with
only one instance of the second entity. Similarly, each instance of the second entity
is related to one instance of the first entity.
One-to-many relationship means that one instance of the first entity is related to
many instances of the second entity, while an instance of the second entity is
associated with only one instance of the first entity.
In many-to-many relationship an instance of the first entity is related to many
instances of the second entity and the same is true in the reverse direction also.
Other types of relationships are multiple relationships between entities,
relationships leading to associative entities, relationship of entity with itself,
EXCLUSIVE-OR and AND relationships

36. ERD Notation
ERD notation: There are two type of notation used:
Peter Chen notation
Bachman notation
Components Notations
Entity or Object type
Relationship
Cardinality
Optionality

Purchase Order

37. Example for Peter Chen notation
A tender is floated either for materials or services but not both.

A car consists of an engine and a chasis

38. ER diagrams using Bachman notation
In a company, each division is managed by only one manager and each
manager manages only one division.
Among the automobile manufacturing companies, a company
manufactures many cars, but a given car is manufactured in only one
company .
In a college, every student takes many courses and every course is taken by many
students

39. ER diagrams using Bachman notation
In a library, a member may borrow many books and there may be books
which are not borrowed by any member
A teacher teaches many students and a student is taught by many teachers.
A teacher conducts examination for many students and a student is
examined by many teachers.

40. Data Dictionary
Data Dictionary
It contains
an organized list of data elements, data structures, data flows,
and data stores
Mini specifications of the primitive processes in the system
It will provide useful information on the system
Data element is piece of data, which can not be decomposed further in
the current context of the system.
Examples are purchase_order_no., employee_name, interest_rate, etc.
Each data element is a member of a domain. The dictionary entry of a
data element should also specify the domain.

41. Data Dictionary Contd…
Data structure is composed of data elements or other data structures.
Examples are Customer_details, which may be composed of
Customer_name and Customer_address. Cutomer_address in turn is a
structure.
Data flow is composed of data structures and/or data elements. Definitions
of dependent data structures/data elements precede the definition of data
flow. While defining the data flow the connecting points should be
mentioned.
Also useful to include the flow volume/frequency and growth rates.

42. Data Dictionary Contd….
Data store, like data flow is made up of a combination of data structures and/or
data elements. The description is similar to data flows.
The notation elements used in the data dictionary are the following:
[last_name]
This indicates that last_name is optional
{dependent_name,
relationship} * (0 to 15)
This indicates that the data strucure can be repeated 0 to 15 times

43. Data Dictionary Contd….
{expense_description,
company_name,
charge} * (1 to N)
This indicates that the data structure may be repeated 1 to N where N is not fixed.
·voter_identity_number/customer_account_number
This indicates that either of the elements will be present.

44. Data Dictionary Symbol’s & Example
The symbols used are:
Equal sign, meaning “consists of”.
Plus sign, meaning "and”.
Braces {} meaning repetitive elements, a repeating element or group of
elements.
Brackets [] for an either/or situation.
The elements listed inside are mutually exclusive.
Parentheses () for an optional element.
Structural Record Example:
Customer Name =First Name +Middle Initial) +Last Name
Address = Street +(Apartment) +City +State + Zip + (Zip Expansion) + (Country)
Telephone = Area code + Local number

45. Decision Tree and Decision Tables
Decision Tree and Decision Tables
A decision tree represents complex decisions in the form of a tree.
An example is given below
Rules for electricity billing are as below:
If the meter reading is "OK", calculate on spending basis(i.e. meter reading)
If the meter reading appears "LOW", then check if the house is occupied.
If the house is occupied, calculate on seasonal spending basis otherwise
calculate on utilization basis
If the meter is damaged, calculate based on maximum possible electricity usage.

46. Decision Tables
There are two types of decision tables.
Binary-valued (yes or no)
Multi-valued.
An example follows:
ELECTRICITY BILL CALCULATION BASED ON CUSTOMER CLASS
If a customer uses electricity for domestic purposes and if the utilization is less
than 300 units per month then bill with minimum monthly charges.
Domestic customers with a utilization of 300 units or more per month are billed
at special rate.
Non-domestic users are charged double that of domestic users (minimum and
special rates are double).

47. BINARY-VALUED DECISION TABLE
Domestic Customer Y Y N N
Consumtion < 300 units per month Y N Y N
Minimum rate Y N N N
Special rate N Y N N
Double minimum rate N N Y N
Double special rate N N N Y

48. MULTI-VALUED DECISION TABLE
Customer D D N N
utilization ≥ 300 <300 ≥300 <300
Rate S M 2S 2M

49. Structure English
 Structured English
To specify the processes (minispecifications) structured English is used.
It consists of:
sequences of instructions (action statements)
decisions (if-else)
loops (repeat-until)
case
groups of instructions
Examples:
Loose, normal English:
In the case of 'Bill', a master file is updated with the bill (that is consumer account number and
bill date). A control file is also to be updated for the 'total bill amount'. A similar treatment is
to be given to 'Payment'

50. Structure English Contd…
Structured English:
If transaction is 'BILL' then
update bill in the Accounts master file
update total bill amount in the Control file
If transaction is 'PAYMENT' then
update receipt in the Accounts master file
update total receipt amount in the Control file
Another example:
If previous reading and new reading match then
perform 'status-check'
If status is 'dead' then
calculate bills based on average utilization
Else
compute bill based on actual utilization

51. State Transition Diagram
State Transition Diagram
Another useful diagram is the state transition diagram.
It can be used to model the state changes of the system.
 A system is in a state and will remain in that state till a condition and an
action force it to change state.

52. State Transition Diagram Contd….

53. Conclusion
The output of the requirements engineering phase is the software
requirements specifications (SRS) document.
At a minimum, it should contain the DFD, ERD, and the data dictionary
and the minispecifications.
The other diagrams may be used as required.
The standards body of Institute for Electrical Electronics Engineers (IEEE)
has defined a set of recommended practices called "IEEE Recommended
Practice for Software Requirements Specifications", IEEE standards
830-1998. It can be used as a guideline document for SRS.

54. Thank U