5(re dfd-erd-data dictionay)

1. Requirements Engineering Lecture @LPU

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

Theobjectives of this module are

To establish theimportance / relevance of requirementspecifications in software development

To bring out theproblems involved in specifying requirements

To illustrate the use of modelling techniques tominimize problemsin specifying requirements

Requirementscan be defined as follows:

Aconditionorcapability needed by a usertosolve a problemorachieve an objective.

A condition or capability that must be met or possessed by a system tosatisfy a contract, standard, specification, or other formally imposed document

High level, requirementscan be classified asuser/client requirements and software requirements .

Client requirementsare usually statedin terms of business needs .

Software requirementsspecifywhat the software must do to meet the business needs .

For example,a stores managermight state his requirements in terms ofefficiency in stores management.

A bank managermight state his requirements interms of time to service his customers .

It is theanalyst's job to understand these requirements and provide an appropriate solution .

To be able to do this, theanalyst 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 analystshould not blindly assume that only a software solutionwill solve aclient's problem .

He should have abroader vision . Sometimes,re-engineering of the business processes may be required toimprove efficiency and that may be all that is required .

After all this,if it is found that a software solution will add value , then adetailed statementof what thesoftware must do to meet the client's needs should be prepared . This document is calledSoftware Requirements Specification (SRS) document.

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' isambiguous.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 behighly 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?

All requirements must becorrect . There should be no accurate errors

All requirements should haveone interpretation only . We have seen a few examples of ambiguous statements above.

The SRS should becomplete 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.

All requirements must beverifiable , that is, it should bepossible to verify if a requirement is met or not. Words like 'highly', 'usually', should not be used.

All requirements must beconsistent 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

Requirements can be classified in totwotypes, namely ,functional requirements and non-functional requirements. Functional requirementsspecifywhat 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)

Non-functional requirementsspecify theoverall quality attributes the system must satisfy.

The following is asample list of quality attributes :

Portability

Reliability

Performance

Testability

Modifiability

Security

Presentation

Reusability

Understandability

Acceptance Criteria

Interoperability

Some examples of non-functional requirements are :

Number of significant digits to whichaccuracy should be maintained in all numerical calculations is 10.

Theresponse timeof the system should always be less than 5 seconds

The software should be developed usingC language on a UNIX based system

A book can be deleted from the Library Management System bythe Database Administrator only

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 . Normalrequirementsarespecific statements of user needs . The user satisfaction level is directly proportional to the extent to which these requirements are satisfied by the system .

Expectedrequirementsmay notbe stated by the users , but thedeveloper 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 thedeveloper's point of view .

Excitingrequirements ,not only, are not stated by the users ,they do not evenexpect 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.

Criticality :This is a form ofprioritizing the requirements . They can be classified asmandatory, desirable, and non-essential . This classification should be done inconsultation with the users and helps in determining the focus in an iterative development model.

Stability:Requirements can also be categorized asstable and non-stable .

Stable requirementsdon't change often, or atleast thetime period of change will be very long.

Non - Stable requirementsSome requirements may change often.

User categories:

As was stated in the introduction, there will be manystake holdersin a system. Broadly they are oftwo kinds . Those whodictate the policies of the systemandthose 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 thatall stakeholders are identified and their requirements are captured.

Overview

Everysoftware system hasthe followingessential characteristics :

It has a boundary. The boundary separates what is within system scope and what is outside

It takesinputs from external agents and generates outputs.

It hasprocesses which collaborate with each other to generate the outputs .

These processes operate ondata by creating, modifying, destroying, and querying it.

The system may also usedata stores to store data which has a life beyond the system

Describing artifacts used byStructured Systems Analysis and Design Methodology (SSADM).It uses:

Data Flow Diagram(DFD) for modellingprocesses and their interactions .

Entity Relationship Diagram(ERD) for modellingdata 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 .

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 ofindividual processes.

External agents :They areexternal to the system , but interact with the system. They must bedrawn at level 0,butneed not be drawn at level 2 onwards . Duplicates are to be identified. They must be given meaningful names.

Process :They indicateinformation processing activity . They must be shown at alllevels, 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.

Data Stores :They areused to store information . They are not shown at level 0. All data stores should be shown at level 1. Duplicates must be indicated.

Data Flows :They indicatethe flow of information . They must be shown at all levels and meaningful names must be given.

Identify theinputs or eventswhich trigger the system and outputs or responses from the system

Identify the correspondingsources and destinations(external agents)

Produce acontext diagram(Level 0). It should show thesystem boundary, external agents, and the data flows connecting the system and the external agents .

ProduceLevel 1 diagram . It must show all the external agents, allthe 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.

1)Rememberto name every external agent, every process, every data store, and every dataflow.

2) Do not showhow things begin and end .

3) Do not showloops, and decisions.

4) Do not showdata flows between external agents . They are outside the scope of the system.

5) Do not showdataflow between an external agent and a data store. There should be a process in between .

6) Do not showdataflow between two data stores . There should be a process in between.

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.

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

It consists ofthreecomponents.

Entity

Attributes

Relationships

Entity : It represents acollection of objects or thingsin the real world whose individual members or instances have the following characteristics:

Each can be identifieduniquelyin some fashion.

Each plays anecessary rolein the system we are building.

Each can bedescribed by one or more data elements(attributes).

Entitiesgenerally correspond topersons, objects, locations, events,etc.Examplesareemployee, vendor, supplier, materials, warehouse, delivery , etc.

There are five typesof 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.

Attributes :They express theproperties 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, anemployee entitywill have professional attributes likename, designation, salary, etc . and alsophysical attributes like height, weight , etc. But only one set will be chosen depending on the context.

Relationships :They describe theassociation between entities .They are characterized byoptionalityandcardinality . Optionalityis of two types, namely,mandatoryandoptional .

Mandatory relationship means associated with every instance of the first entity there will be at least one instance of the second entity.

Optional relationshipmeans 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.

Cardinalityis of three types:one-to-one, one-to-many, many-to-many .

One-to-one relationshipmeans 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 relationshipmeans 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.

Inmany-to-many relationshipan 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

ERD notation :There are two type of notation used:

PeterChen notation

Bachman notation

Components Notations

Entity or Object type

Relationship

Cardinality

Optionality

A tender is floated either for materials or services but not both.

A car consists of an engine and a chasis

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

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.

Data Dictionary

It contains

an organizedlist of data elements, data structures, data flows, and data stores

Mini specificationsof the primitive processesin thesystem

It will provide useful information on the system

Data elementis piece of data, whichcan not be decomposedfurther in the currentcontext of the system.

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

Data structureiscomposed of data elements or other data structures .

Examplesare Customer_details, which may be composed of Customer_name and Customer_address. Cutomer_address in turn is a structure.

Data flowiscomposed 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 .

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 isoptional

{dependent_name, relationship} * (0 to 15) This indicates that the data strucure can berepeated 0 to 15 times

{expense_description, company_name, charge} * (1 to N) This indicates that the data structure may be repeated1 to Nwhere N is not fixed.

voter_identity_number/customer_account_numberThis indicates thateither of the elementswill be present.

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

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 basisIf the meter is damaged, calculate based on maximum possible electricity usage.

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 electricityfor domestic purposesand if the utilization isless than 300 units per monththen bill withminimum monthly charges. Domestic customerswith a utilization of300 units or more per monthare billed atspecial rate. Non-domestic usersare charged double that of domestic users ( minimum and special rates are double).

Technology

5(re dfd-erd-data dictionay)