Embed Size (px)
Citation preview
Structuring System Requirements & System Design
System Design & Data and File Design
Presented by : Harminder Kaur Bhatia
Objectives
• Data Analysis using
• Data Modeling
• Relational Modeling
• Design Principles
• Design Strategies
• Design Components
• Physical Data Design
• Input Design
• Output Design
• Finalizing Design Specifications
Data Analysis
Objective
To gain a sound understanding of the data in use in the area of study and to provide a basis for the design of physical data structure which are:
– Flexible– Easily maintainable– Unambiguous– Able to provide for differing access requirements– Subject to a minimum of data redundancy
Methods of Data Analysis
Entity Analysis (Conceptual Data Modeling)
Relational Analysis & Modeling
Conceptual Data Modeling
Representation of organizational data
Purpose is to show rules about the meaning and interrelationships among data
Entity-Relationship (E-R) diagrams are commonly used to show how data are organized
Main goal of conceptual data modeling is to create accurate E-R diagrams
Methods such as interviewing, questionnaires and JAD are used to collect information
Consistency must be maintained between process flow, decision logic and data modeling descriptions
Process of Conceptual Data Modeling
First step is to develop a data model for the system being replaced
Next, a new conceptual data model is built that includes all the requirements of the new system
In the design stage, the conceptual data model is translated into a physical design
Project repository links all design and data modeling steps performed during SDLC
Deliverables and Outcome
Primary deliverable is the entity-relationship diagram
There may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling
Covers just data needed in the project’s application
E-R diagram for system being replaced
An E-R diagram for the whole database from which the new application’s data are extracted
An E-R diagram for the whole database from which data for the application system being replaced is drawn
Sample conceptual data model diagram
Deliverables and Outcome
Second deliverable is a set of entries about data objects to be stored in repository or project dictionary
Repository links data, process and logic models of an information system
Data elements that are included in the DFD must appear in the data model and visa versa
Each data store in a process model must relate to business objects represented in the data model
Introduction to Entity-Relationship (E-R) Modeling
Notation uses three main constructs
Data entities
Relationships
Attributes
Entity-Relationship (E-R) Diagram
A detailed, logical representation of the entities, associations and data elements for an organization or business
Entity-Relationship (E-R) Modeling
Entity
A person, place, object, event or concept in the user environment about which the organization wishes to maintain data
Represented by a rectangle in E-R diagrams
Entity Type
A collection of entities that share common properties or characteristics
Attribute
A named property or characteristic of an entity that is of interest to an organization
Candidate keys and identifiers
Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type
Candidate key– Attribute (or combination of attributes) that uniquely identifies each instance of
an entity type
Entity-Relationship (E-R) Modeling
Relationship
An association between the instances of one or more entity types that is of interest to the organization
Association indicates that an event has occurred or that there is a natural link between entity types
Relationships are always labeled with verb phrases
Example relationships of different degrees
Cardinality
The number of instances of entity B that can be associated with each instance of entity A
Minimum Cardinality
The minimum number of instances of entity B that may be associated with each instance of entity A
Maximum Cardinality
The maximum number of instances of entity B that may be associated with each instance of entity A
The Role of CASE in Conceptual Data
CASE tools provide two important functions:
Maintain E-R diagrams as a visual depiction of structured data requirements
Link objects on E-R diagrams to corresponding descriptions in a repository
Database design - objectives
• Discuss the role of designing databases in the analysis and design of an information system
• Learn how to transform an Entity-Relationship (ER) Diagram into an equivalent set of well-structured relations
• Learn how to merge normalized relations from separate user views into a consolidated set of well-structured relations
• Explain choices of storage formats for database fields
• Learn how to transform well-structured relations into efficient database tables
• Discuss use of different types of file organizations to store database files
• Discuss indexes and their purpose
Purpose of Database Design
Structure the data in stable structures, called normalized tables
Not likely to change over time
Minimal redundancy
Develop a logical database design that reflects actual data requirements
Develop a logical database design from which a physical database design can be developed
Translate a relational database model into a technical file and database design that balances several performance factors
Choose data storage technologies that will efficiently, accurately and securely process database activities
Process of Database Design
Logical Design
Based upon the conceptual data model
Four key steps
1. Develop a logical data model for each known user interface for the application using normalization principles
2. Combine normalized data requirements from all user interfaces into one consolidated logical database model
3. Translate the conceptual E-R data model for the application into normalized data requirements
4. Compare the consolidated logical database design with the translated E-R model and produce one final logical database model for the application
Process of Database Design
Physical Design
Based upon results of logical database design
Key decisions1. Choosing storage format for each attribute from the logical
database model2. Grouping attributes from the logical database model into
physical records3. Arranging related records in secondary memory (hard disks
and magnetic tapes) so that records can be stored, retrieved and updated rapidly
4. Selecting media and structures for storing data to make access more efficient
Deliverables and Outcomes
Logical database design must account for every data element on a system input or output
Normalized relations are the primary deliverable
Physical database design results in converting relations into files
Relational Database Model
Data represented as a set of related tables or relations
Relation
A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows
– Relation – File or table– Tuple - Record or row of the table– Domain - data field or column of the table
Properties– Entries in cells are simple– Entries in columns are from the same set of values– Each row is unique– The sequence of columns can be interchanged without changing the
meaning or use of the relation– The rows may be interchanged or stored in any sequence
Well-Structured Relation
A relation that contains a minimum amount of redundancy and allows users to insert, modify and delete the rows without errors or inconsistencies
Normalization
The process of converting complex data structures into simple, stable data structures
First Normal Form (1NF)
Each row is uniquely identified with a key
Second Normal Form (2NF)
Each nonprimary key attribute is identified by the whole key (called full functional dependency)
Third Normal Form (3NF)
Non-primary key attributes do not depend on each other (called transitive dependencies)
The result of normalization is that every non-primary key attribute depends upon the whole primary key
Normalization steps
Take data items from each source in un-normalized form
Convert to First Normal Form (FNF)
Covert to Second Normal Form (SNF)
Covert to Third Normal Form (TNF)
Test and Verify
First Normal Form (FNF)
Identify unique key
Remove repeating groups
Example : Un-normalized data
Order-no.
Order Date
Supplier Code
Supplier Name
Item Code
Item Name
Qty Ordered
Unit Price
Order Amount
FNF data
Orders– Order No.– Order Date– Supplier code– Supplier Name– Order Amount
Order Details– Order No.– Item code– Item name– Qty Ordered– Unit Price
Second Normal form (2NF)
Second Normal Form (2NF)
A relation is in second normal form (2NF) if any of the following conditions apply:
– The primary key consists of only one attribute– No nonprimary key attributes exist in the relation– Every nonprimary key attribute is functionally dependent on the full set of
primary key attributes
In 2NF, we remove part-key dependencies
2NF data
Orders– Order No.– Order Date– Supplier code– Supplier Name– Order Amount
Order Details– Order No.– Item code– Qty Ordered– Unit Price
Items Master– Item code– Item Name
Third Normal Form (3NF)
Third Normal Form (3NF)
A relation is in third normal form (3NF) if it is in second normal form (2NF) and there are no functional (transitive) dependencies between two (or more) nonprimary key attributes
Check dependencies between the fields within each relation
Remove calculated field
Create separate table and retain the key as foreign key 3NF data
Orders– Order No.– Order Date– Supplier code
Suppliers– Supplier code– Supplier Name
Order Details– Order No.– Item code– Qty Ordered– Unit Price
Items Master– Item code– Item Name
Third Normal Form Test
Given the value for the key(s) is there only one possible value for each of the associated data items?
IS each data item directly dependent on the whole key?
Optimization
Merge relations which have the same keys
Look for synonyms e.g.. Clients, customers being different names for the same relation
Transforming E-R Diagrams into Relations
It is useful to transform the conceptual data model into a set of normalized relations
Steps
Identify entities from ER Model and create a relation for each entity
Include only the atomic components of the composite attributes– E.g. Name may comprise of First name, Middle name and Last name. In the
tables include the elements First name, Middle name and Last name instead of the composite attribute Name
From among the candidate keys choose a primary key that uniquely identifies the entity type
Transforming E-R Diagrams into Relations
Represent Entities
Each regular entity is transformed into a relation
The identifier of the entity type becomes the primary key of the corresponding relation
The primary key must satisfy the following two conditionsa. The value of the key must uniquely identify every row in the relationb. The key should be non-redundant
Physical File and Database Design
The following information is required
Normalized relations, including volume estimates
Definitions of each attribute
Descriptions of where and when data are used, entered, retrieved, deleted and updated (including frequencies)
Expectations or requirements for response time and data integrity
Descriptions of the technologies used for implementing the files and database
Designing Fields
Field The smallest unit of named application data recognized by system software
Each attribute from each relation will be represented as one or more fields
Choosing data types Data Type
– A coding scheme recognized by system software for representing organizational data
Four objectives– Minimize storage space– Represent all possible values of the field– Improve data integrity of the field– Support all data manipulations desired on the field
Calculated fields– A field that can be derived from other database fields
Methods of Controlling Data Integrity
Default Value
A value a field will assume unless an explicit value is entered for that field
Range Control
Limits range of values which can be entered into field
Referential Integrity
An integrity constraint specifying that the value (or existence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation
Null Value
A special field value, distinct from 0, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown
Designing Physical Tables
Relational database is a set of related tables
Physical Table
A named set of rows and columns that specifies the fields in each row of the table
Design Goals
Efficient use of secondary storage (disk space)– Disks are divided into units that can be read in one machine operation– Space is used most efficiently when the physical length of a table row
divides close to evenly with storage unit
Efficient data processing– Data are most efficiently processed when stored next to each other in
secondary memory
De-normalization
The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields
Designing Physical Tables
Arranging Table Rows
Physical File– A named set of table rows stored in a contiguous section of
secondary memory
Each table may be a physical file or whole database may be one file, depending on database management software utilized
File Organization
A technique for physically arranging the records of a file
Objectives for choosing file organization1. Fast data retrieval2. High throughput for processing transactions3. Efficient use of storage space4. Protection from failures or data loss5. Minimizing need for reorganization6. Accommodating growth7. Security from unauthorized use
Designing Physical Tables
Types of File Organization
Sequential– The rows in the file are stored in sequence according to a primary
key value– Updating and adding records may require rewriting the file– Deleting records results in wasted space
Indexed – The rows are stored either sequentially or non-sequentially and an
index is created that allows software to locate individual rows– Index
- A table used to determine the location of rows in a file that satisfy some condition
– Secondary Index- Index based upon a combination of fields for which more than one
row may have same combination of values
System Design - Objectives
• System Design Definition
• Aims of system Design
• Categories of Design Methodologies
• Features of a good design
• Design Constraints
• Activities in the System Design
System Design - Definition
The iterative process of taking a logical model of a system together with a strongly stated set of objectives for that system and producing specification of a physical system that will meet those objectives.
The requirements analysis and specifications describes ‘what’ the system is required to do and the Design describe ‘how’ it will do that.
Aims of System Design
Design input and output
Design user-computer interface
Design data structures
Design processes
Make decisions about hardware and software
Categories of Design Methodology
Top down functional design
Designed from functional view-point
Define high level view and refine it iteratively
Object oriented design
View system as a collection of objects with messages passed between them
Each object has a set of associated operations
Data Driven design
Design is derived from an analysis of the data flows and data entities
Desirable features of ‘good’ quality design
Functional
Satisfies user requirements
Efficient
Efficient performance in terms of response time and throughput
Flexible
Able to accommodate growth, diversity and change in organization
Portable
Hardware and software independent as far as possible
Usable
Easy to learn and operate
Design constraints
Budget
Time (Delivery Schedule)
Integration with other systems
Skills
Standards
Activities in System Design
Input-Output Design
Methods of data capture and reporting
Screens and reports similar to the existing documents / forms / reports
Specify format and layout
Dialog design
User Interface design
Consider user interaction, possible errors, help, prompts, screen content and layout
Data Design
Design of files and databases
Access requirements, file organization
Process Design
Structure chart– Program flowchart / pseudocodes
System Controls
Data integrity, recovery, data backup etc.
Activities in System Design
Technical considerations
Hardware and software to be used
Design documentation
Design Verification and validation
Review
Technical
Economic
Operational feasibility
Deliverables
Input-output Design
Dialog Design
Data Design
Process Design
Input Document and Report Layouts
Menu Trees, Screen layouts
File/ database table structures
Structure charts and action diagrams, flowcharts
Selecting the Best Alternative Design Strategy
Two basic steps
1. Generate a comprehensive set of alternative design strategies
2. Select the one design strategy that is most likely to result in the desired information system
Process
Divide requirements into different sets of capabilities
Enumerate different potential implementation environments that could be used to deliver the different sets of capabilities
Propose different ways to source or acquire the various sets of capabilities for the different implementation environments
Selecting the Best Alternative Design Strategy
Deliverables
1. At least three substantially different system design strategies for building the replacement information system
2. A design strategy judged most likely to lead to the most desirable information system
3. A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system
Issues to Consider in Generating Alternatives
Sources of Software
Hardware manufacturers
Packaged software producers
Custom software producers
Enterprise solution software
Application Service Providers
In-house development
Hardware and Software Issues
Existing Platform
1. Lower costs
2. Information system staff is familiar with operation and maintenance
3. Increased odds of successfully integrating system with existing applications
4. No added costs of converting old systems to new platform or transferring data
New Hardware and System Software
1. Some software components will only run on new platform
2. Developing system for new platform gives organization opportunity to upgrade technology holdings
3. New requirements may allow organization to radically change its computing operations
Designing Forms & reports (I/O Design)
• Explain the process of designing forms and reports and the deliverables for their creation
• Discuss general guidelines for formatting forms and reports
• Use color and know when color improves the usability of information
• Learn how to effectively format text, tables and lists
• Explain how to assess usability
Designing Forms and Reports
System inputs and outputs are produced at the end of the analysis phase
Precise appearance was not defined during this phase
Forms and reports are integrally related to DFD and E-R diagrams
Definitions
Form– A business document that contains some predefined data and may
include some areas where additional data are to be filled in– An instance of a form is typically based on one database record
Report– A business document that contains only predefined data– A passive document for reading or viewing data– Typically contains data from many database records or transactions
The Process of Designing Forms and Reports
User-focused activity
Follows a prototyping approach
Requirements determination
Who will use the form or report?
What is the purpose of the form or report?
When is the report needed or used?
Where does the form or report need to be delivered and used?
How many people need to use or view the form or report?
The Process of Designing Forms and Reports
Prototyping
Initial prototype is designed from requirements
Users review prototype design and either accept the design or request changes
If changes are requested, the construction-evaluation-refinement cycle is repeated until the design is accepted
Deliverables and Outcome
Design specifications are major deliverable and contain three sections
1. Narrative overview
2. Sample design
3. Testing and usability assessment
General Formatting Guidelines for Forms and Reports
Highlighting
Use sparingly to draw user to or away from certain information
Blinking and audible tones should only be used to highlight critical information requiring user’s immediate attention
Methods should be consistently selected and used based upon level of importance of emphasized information
Benefits from Using Color
Soothes or strikes the eye
Accents an uninteresting display
Facilitates subtle discriminations in complex displays
Emphasizes the logical organization of information
Draws attention to warnings
Evokes more emotional reactions
Problems from Using Color
Color pairings may wash out or cause problems for some users
Resolution may degrade with different displays
Color fidelity may degrade on different displays
Printing or conversion to other media may not easily translate
General Formatting Guidelines for Forms and Reports
Displaying Text
Display text in mixed upper and lower case and use conventional punctuation
Use double spacing if space permits. If not, place a blank line between paragraphs
Left-justify text and leave a ragged right margin
Do not hyphenate words between lines
Use abbreviations and acronyms only when they are widely understood by users and are significantly shorter than the full text
Designing tables and lists
Labels– All columns and rows should have meaningful labels– Labels should be separated from other information by using highlighting– Re-display labels when the data extend beyond a single screen or page
General Formatting Guidelines for Forms and Reports
Designing tables and lists (continued)
Formatting columns, rows and text– Sort in a meaningful order– Place a blank line between every five rows in long columns– Similar information displayed in multiple columns should be sorted
vertically– Columns should have at least two spaces between them– Allow white space on printed reports for user to write notes– Use a single typeface, except for emphasis– Use same family of typefaces within and across displays and reports– Avoid overly fancy fonts
General Formatting Guidelines for Forms and Reports
Designing tables and lists (continued)
Formatting numeric, textual and alphanumeric data– Right-justify numeric data and align columns by decimal points or other
delimiter– Left-justify textual data. Use short line length, usually 30 to 40 characters per
line– Break long sequences of alphanumeric data into small groups of three to four
characters each
Paper versus Electronic Reports
Printer used for producing paper report needs to be considered in design
Use a prototyping process similar to designing a form
Assessing Usability
Overall evaluation of how a system performs in supporting a particular user for a particular task
Three characteristics
1. Speed
2. Accuracy
3. Satisfaction
Assessing Usability
Success Factors
Consistency– Design elements all appear in the same place on all forms and reports
Context– Users– Tasks– Environment
Assessing Usability
Measures of Usability
Considerations– Time to learn– Speed of performance– Rate of errors– Retention over time– Subjective satisfaction
Collection methods– Observation– Interviews– Keystroke capturing– Questionnaires
Thank You
