cc20o7n - software engineering 1 cc2007n software engineering 1 requirements analysis techniques...

CC20O7N - Software Engineering 1

CC2007NSoftware Engineering 1

Requirements Analysis TechniquesBasic Structured Modelling Techniques


Contents

• Introduction

• Functional Sub-model

• Data Sub-model

• Dynamic/Behavioural Sub-model

• Relationship between these (Sub)Models


Sub-models

• Functional Model describes the functionality of the systems from the user’s point of view. (DFD, use case diagram, etc.)

• Data Model consists of three interrelated pieces of information: the data object, the attributes that describe the data objects, and the relationships that connect data objects to one another. (ERD)

• Dynamic/Behavioural Model describes the components of the systems that have interesting behaviour. (DFD, statechart diagrams, sequence diagrams, activity diagrams, etc.)


Different Systems/Applications- Different Emphasis

• Information Systems – the emphasis on data and functional sub-models

• Process Control Systems – the emphasis on functional and dynamic sub-models


Functional Sub-model

• Functional Model describes the functionality of the systems from the user’s point of view. (DFD, use case diagram, etc.)

• The main basic modelling technique is Data Flow Modelling. It involves the development of Data Flow Diagrams (DFDs) and (in addition) Elementary Process Specifications and Data Flow and Data Store definitions (part of Data Dictionary)

• In SSADM this is followed by Function Definition and Conceptual Process Modelling (ECDs, EAPs, UPMs, EPMs - to specify elementary processes in more detail). ECD:Effect Correspondence Diagram, EAP: Enquiry Access Path, UPM: Unconstrained Process Model , EPMs: Entity Process Models


Data Flow Diagrams (DFDs) - Main Elements (notation)

Yourdon SSADM

name

Process

Data flow

Data store

Terminator (external entity)

name

name

name namename

name name

no

namename. .


DFDs Main Elements (meaning)

• PROCESS - processes show what systems do. Each process has one or more data inputs and produces one or more data outputs (there are some exceptions but very rare!)

• DATA FLOWS model the passage of data in the system• DATA STORE (FILE) is a repository of data. It contains data that is

retained in the system (persistent data). Processes can enter data into a data store or retrieve data from the data store.

• TERMINATORS are outside the system, but they supply input data into the system and/or use the system output e.g other systems, other organisations, system users, departments outside the system, etc


DFDs - Basic Rules 1

Data flows can be drawn between:• two processes (only when they are ‘tightly’ coupled i.e.

they are ‘executed’ in the same, relatively short time ‘frame’)

• a data store and a process• a process and a terminatorData flows must not be drawn between two data stores !!!Avoid (if possible) flows between terminators and data

stores, and between two terminators.


DFDs - Basic Rules 2‘Dodgy’ Situations (to be double checked) are:• processes with inputs only• processes with outputs only• data stores with inputs only• data stores with outputs only• does each process receive all the data it requires?• are all main data flows labelled?


Simple DFD - Example (Yourdon’s Notation)

Reg_details

Acc details Cust_details

AccountsCustomers

Withdrawal_dets Deposit_dets

Manager

1Registercustomer

2Withdraw

3Deposit

Clerk


DFD - SSADM Notation

Manager

Clerk

Record deposits3

*Record deposits2

*

D1 Customers

D2 Accounts

Register new customer

1

*

Registration details

Cust_details

Account_no.

AmountBalance

Amount Balance

Withdrawal_info Deposit_in

fo

Manager

Clerk

Record deposits3Record deposits3

*Record deposits2

*Record deposits2Record deposits2

*

D1 CustomersD1 Customers

D2 AccountsD2 Accounts

Register new customer

1

*

Registration details

Cust_details

Account_no.

AmountBalance

Amount Balance

Withdrawal_info Deposit_in

fo


DFDs - ‘Leveling’

• The idea of ‘levelling’ is to present the system at different levels of detail.

• The top-level diagram (level 0) is known as the context diagram (it models the whole system as a single process).

• The level 1 DFD gives an overview of the whole system, identifying the major processes, data flows and data stores.

• Processes from level 1 can be expanded to show more detail (if necessary) at level 2. Processes from level 2 can be further expanded, etc.


‘Leveling’ (cont.)

• In the classical approach DFDs are built in a top-down fashion. First of all the context diagram is produced, next it is refined/partitioned into lower-level DFDs.

• In a lower-level DFD, a process (from a higher level) is expanded to reveal more details. The numbering convention for ‘parent’ and ‘child’ processes is as follows: if the parent’s no is e.g. 5 then its ‘children have numbers 5.1, 5.2, 5.3, etc.

• Typically when we get to the point at which the operation of a process can be described in about half page using a pseudo code/structured English, We can stop partitioning.

• Processes which have not been partitioned (decomposed) are called ‘atomic’ or elementary processes. They belong to a ‘bottom’ level.


‘Levelling’ - Balancing Rules

• Balancing rules require that data flows entering or leaving a parent diagram (i.e. a process at a higher level) must be equivalent to those on the ‘child’ diagram. It means that new flows may not be arbitrarily introduced at lower, more detailed levels !


Simple Bank - Context DFD i.e. Level 0

Reg_details


SimpleBankManager

Clerk


Simple Bank -Level 1 DFD

Reg_details

Acc details Cust_details

AccountsCustomers


Manager

1Registercustomer

2Withdraw

3Deposit

Clerk


Simple Bank - Level 2 DFD

Accounts

Withdrawal_dets

Accepted_dets

Rejected

2.1Check

accountstatus 2.2

Updateaccount


Example of Process Specification using Structured English/pseudocode for Register customer i.e. Process 1

Get Reg_detailsGenerate Account NoCustomer Record = Cust Name, Cust Addr, Cust Tel No.Write Customer Record to CustomersBalance = 0Account Record = Account No., Balance, Curr DateWrite Account Record to Accounts


Structured English/pseudocode Notation

• It combines the precision of a formal programming language (e.g. C, Pascal, Java) with the casual informality and readability of the English language (or any natural language)

• It means that it provides the keywords to structure process specification logic (e.g. IF, ELSE, WHILE, etc) while leaving some freedom when describing the activities and data used in the process


Structured English/pseudocode Notation (cont.)

Possible notation• Boolean and arithmetic operators• = assignment operator• Control structures such as: WHILE, IF ELSE, DO WHILE, etc• Indentation is used to show groups/blocks of statements/

activities e.g. within WHILE structure• Get, Display (or Input, Output) to input/output data• Read, Write to read and write records of data (from and to

data stores)


The Data Dictionary

• The data dictionary is an organised listing of all the data that are pertinent to the system with precise, rigorous definitions.

• A typical data dictionary includes definitions/ descriptions of: data flows, data stores and entities (from the data sub-model)

• As data flows and data stores are ‘made up’ of data structures and data elements, these data structures and elements also should be described/defined!


Data Dictionary- notations

• There are many different ‘data dictionary notations’.• All are ‘structured’ notations i.e. they allow to specify

sequences, iterations and ‘selections’ of data elements and data structures

• Examples of some notations: Jackson diagrams, BNF (Backus Naur Form ) notation, etc


Data Dictionary – BNF Notation

The notation is summarised below:= is composed of (definition)+ and (sequence of data){ } iteration/repetition of data[ | ] selection (either or) of data* * comment() optional data


Data Dictionary

Examples of BNF definitions:Reg_Details = Cust Name + Cust Addr + Cust Tel No. + Account

No. * data flow*Cust_Details = Cust Name + Cust Addr + Cust Tel No.Accounts = {Account} *data store*Account = Account No. + Balance + Date Opened *entity*


Data Sub-model

• Data Model consists of three interrelated pieces of information: the data object, the attributes that describe the data objects, and the relationships that connect data objects to one another. (ERD)

• The main modelling technique is Entity Relationship modelling (Logical Data Modelling - LDM in SSADM). It involves the development of Entity Relationship Diagrams (E-R diagrams, ERDs, LDS in SSADM) and Entity Definitions/Descriptions (part of Data Dictionary)


Entity Relationship Modelling- Entity

• Entity (or an Entity type) – any object or concept about which a system needs to hold information.

• Examples of entities;Library system: Book, Reader, Loan, Reservation, etcDoctor’s surgery system: Doctor, Nurse, Patient, Appointment, etc

• Each entity (Entity type) must have a number of real-world occurrences (instances). For example in a typical Library system (see above) there are many instances of Book, Reader, Loan, etc.


Entity Relationship Modelling- Entity (Cont.)

An entity must have a number of properties to qualify as such:

1. There must be more than one occurrence/instance of the entity.

2. Each occurrence/instance should be uniquely identifiable.3. There must be data that we want to hold about the entity.4. It should be of direct interest to the system.


Entity Relationship Modelling- Entity (Cont.)

• Each data item that we hold about an entity is known as an ATTRIBUTE. For example some of the attributes of Book might be: Book Number, Title, Year, etc

• The symbol for an entity in an ERD is a round-cornered rectangle with the entity’s name

Book


Entity Relationship Modelling- Relationships

• Relationship – a logical association between two entities (or between an entity and itself)

• In physical data structures these relationships are represented by physical links such as pointers, etc

• In logical models relationships represent business associations or rules and NOT physical links!


Entity Relationship Modelling – Relationships (Cont.)

• Relationships have two important properties:– Degree – Optionality

• Degree – the number of occurrences of each entity type participating in a given relationship

• Optionality – if there can be occurrences of one entity that are not related to at least one occurrence of the other, then the relationship is said to be optional for that entity.


Entity Relationship Modelling- Relationships (Cont.)

There are three types of degree:1.Many-to-many (m:n)

Each occurrence of A is related to one or more occurrences of B, and each occurrence of B is related to one or more occurrences of A

A BA BA B


Entity Relationship Modelling- Relationships (Cont.)

2. One - to - many (1:m)

Each occurrence of A is related to one or more occurrences of B, but each occurrence of B is related to only one occurrence of A

A B


Entity Relationship Modelling – Relationships (Cont.)

3. One-to-one (1:1)

Each occurrence of A is related to only one occurrence of B, and each occurrence of B is related to only one occurrence of A

A B


Entity Relationship Modelling –Relationships (Cont.)

• Optionality – if there can be occurrences of one entity that are not related to at least one occurrence of the other, then the relationship is said to be optional for that entity.

• Each A may be related to one B; Each B must be related to one A

• Dashed line denotes optional relationship

A BA B


E-R Diagrams (Using SSADM Notation)

Customer

Customer/Account link

Transaction

Account


Entity Definitions/Descriptions• In some organisations only brief descriptions/definitions will

be required, while in others they may consist of several sections including details of attributes, relationships, volumes of data, user access, etc

• For CC2F07N brief descriptions/definitions will be used which list attributes and show primary keys. These descriptions can be included in Data Dictionary (together with definitions of data flows and data stores).


Examples of Simple Entity Definitions

Customer = Cust No + Cust Name + Cust Addr +Cust Tel No….Account = Account No. + Balance + Date Opened….

alternatively they can be specified as follows e.g:CUSTOMER

Cust No Cust name Cust Addr Cust Tel No


Dynamic Sub-model• Dynamic Model describes the components of the

systems that have interesting behaviour.• Modelling techniques for this sub-model include Entity

Life Histories (ELHs), State Transition Diagrams (STDs) etc. in O.O. statechart diagrams, sequence diagrams, activity diagrams, etc.


Entity Life Histories(Using Jackson Notation Adopted in SSADM)

ManagementProducts

Account

Account life Account closedAccount opened

*

Deposit Withdrawo o

ManagementProducts

Account

Account life Account closed Account opened

*

Deposit Withdrawo o


Relationships between Sub-modelsFunctional Model DFDsFunctional Model

ELHsELHs

Account opened

ManagementProducts

Account

Account life Account closed

*

Deposit Withdrawo o

Manager

Clerk

Record deposits3

*Record deposits2

*

D1 Customers

D2 Accounts

Register newcustomer

1

*Customer

Customer/accountlink

Transaction

Account

Data ModelERDs

Dynamic Model

Data DictionaryAccounts = {Account}Account = Account No. +

Balance + Date Opened

Account

Account life Account closed

*

Deposit Withdrawo o

Manager

Clerk

Record deposits3Record deposits3

*Record deposits2

*Record deposits2Record deposits2

*

D1 CustomersD1 Customers

D2 AccountsD2 Accounts

Register newcustomer

1

*Customer

Customer/accountlink

Transaction

Account

Dynamic Model

Data DictionaryAccounts = {Account}Account = Account No. +

Balance + Date Opened


How Is the SDLC Used In This Class?

Clearly, the SDLC requires significant time, human resources and technical resources to perform well.

For the class project, your team must implement the SDLC steps as follows:– Systems Planning (project requirements summary, project team

description, preliminary work schedule, service area demographic analysis)

– Systems Analysis (E-R diagram, Data Flow Diagrams, high-level functional description)

– Systems Design (RDBM, Data Dictionary, identification/description of database objects, Web site map)

– Systems Implementation (Access database, Web site content, elementary test plan)

In addition, a White Paper will address practical systems implementation and operations/support issues.


PERT Chart for

Abbreviated Systems Analysis and Design Life Cycle

Systems Analysis Phase

Start

Process(DFD)Model

ERModel

RDBModel

TestData

DataDictionary

Start

Module 1 Unit 1Testing

Module N Unit NTesting

BaseTables

UserInterface

Integration SystemTesting

Finish

Finish

Development Phase

. . . . . .


Business Analysis with Data Flow Diagrams

We initially claimed that entity-relationship diagrams could encode many business rules.

But many elements of business processes cannot be represented by E-R diagrams: – Actors (individuals, organizations) which generate input data and/or

receive output data;– Data transformations using specific business rules (which we said

required application-level code);– Data storage or display that may or may not correspond to entities (e.g.

views, reports, temporary tables, screens);– Data flows between actors, processes or data stores over time, and – Manual versus automated processing.

Data Flow Diagrams (DFDs) are the link between initial business analysis, E-R diagrams and relational database models


Practical Significance of DFDs

• Many older information systems (legacy systems):– Are mainframe-based (inaccessible to most non-IT users);– Use non-relational (hierarchical) databases, and– Require second-generation programming languages (e.g. COBOL)

to perform data input, queries, reporting.

Thus, many IT professionals focus on data flows and physical implementation, not data relationships or RDBM design principles.

• Many business processes are so complex that E-R design alone will not give analysts insight into their businesses

DFDs allow the analyst to determine: What does the organization do? How does the organization do it?


Creating DFDs

Define Entities • External entities represent

persons, processes or machines which produce data to be used by the system or receive data that is output by the system

• Examples: Student, Customer, Client

Define Processes• Processes are discrete actions

that transform input data to output data

• Examples: Create Student Record, Calculate Purchase Cost, Register Client

Student

2.1

Create Student Record


Creating DFDs (cont’d)Define Data Stores

• Data stores are temporary or permanent repositories of information that are inputs to or outputs of processes

• Examples: Student Master, Client List

Define Data Flows• Data flows represent the transfer of

data over time from one “place” (entity, process, data store) to another

• Examples: New Student Information (from Student, to Student Master)

New Student Information

(Templates are posted in l:\academic\90728\DFDSymbols.ppt)

Student Master

D3


Creating DFDs (cont’d)

Define the System• A system is the collection of all

business processes which perform tasks or produce outputs we care about. It is “what happens.”

• The system is a single process, connected to external entities

• Represented in a “Context Diagram”

Define Subsystems• A subsystem gives a more detailed

view individual processes contained in the context diagram

• Includes data stores, more elementary processes

(Figure 4.13, Shelly, Cashman and Rosenblatt)


DFDs Created by Top-Down Analysis• Create a narrative: description of

system

• Create a Context Diagram that contains a single process (“the system”) and all entities which share data with the system

• Explode the “parent” context diagram to produce a Diagram 0 (“child”) DFD

• Create Diagram 1, 2, …, n DFDs that represent “explosions” of Diagram 0, 1, …, n-1 DFDs until a diagram has only “primitive” processes

• Create process descriptions to be implemented by application programs: queries, macros, reports, programming languages

Context Diagram

Diagram 0 DFD

Diagram 1 DFDs

Diagram n DFDs

Narrative

E-R Diagram Process Descriptions


Where to Begin Creating DFDs

• Start with the data flow from an external entity and work forwards

• Start with the data flow to an external entity and work backwards

• Examine the data flows into or out of a data store

• Examine data flows, entity connections and data stores associated with a particular process

• Note fuzzy, ill-defined areas of the system for further clarification


What to Avoid in DFDs

Making the data flow diagram too cluttered (e.g. 9 processes)

4

Perform Repair

Processes with no outputs or no inputs

1 2 3Many processes with a single input and output (linear flow)

Processes whose inputs are obviously inadequate to yield

outputs

Having data flows terminate at data stores

Connecting data stores directly to each other Courses Students

Class List

Connecting entities to anything other than processes

Payroll Department

Employees

Process A

Process B

Process C


DFD Example: Bus Garage Repairs

Buses come to a garage for repairs. A mechanic and helper perform the repair, record the reason for the repair

and record the total cost of all parts used on a Shop Repair Order. Information on labor, parts and repair outcome is used for billing by the

Accounting Department, parts monitoring by the inventory management computer system and a performance review by the supervisor.

• Key process (“the system”): performing repairs and storing information related to repairs

• External Entities: Bus, Mechanic, Helper, Supervisor, Inventory Management System, Accounting Department, etc.

• Processes: – Record Bus ID and reason for repair– Determine parts needed– Perform repair– Calculate parts extended and total cost– Record labor hours, cost


DFD Example: Bus Garage Repairs (cont’d)

• Data stores: – Personnel file– Repairs file– Bus master list– Parts list

• Data flows:– Repair order– Bus record– Parts record– Employee timecard– Invoices


Bus

Mechanic

Helper0

Bus Repair Process

Supervisor

Accounting

Bus Garage Context Diagram

Mechanical problem to be repaired

Labor

Labor

Fixed mechanical problems

Inventory Management

System

Repair summary

List of parts used

Labor, parts cost details


• Practice Session of the modelling in the LAB of your own selected project

• One example will be discussed in the tutorial class

• Thank you

cc20o7n - software engineering 1 cc2007n software engineering 1 requirements analysis techniques...

Documents