Analysis

• Objectives:
  • analyse and evaluate different methods of researching a situation (including: questionnaires, interviews, observation, document analysis)
  • describe the content of the requirements specification, system specification and design specification

Analysis

• Finding how current system works
• Gathering requirements for the new system

Methods of research

• Questionnaires
• Interviews
• Observation
• Document Analysis

Questionnaire

• Large amount of user can response
• No elaboration from respondent
• Questions should be asked in a way to help data to be analyzed
• Close-ended questions is more common

Interview

• Direct conversation between analyst and client / potential users
• Can be one-to-one or groups of users
• More in-depth questions and answers can undertake
• Time consuming compare to questionnaire
• Sometimes interview may not receive honest answer, but anonymous questionnaire can

Observation

• Analyst watch the process (of existing system)
• Include sitting with user, ask questions about the flow etc. 
• Analyst can get first hand experience of how the system works
• But the user may perform/act differently when being observed (imagine how you behave differently when someone observe your class!)

Document analysis

• Analyst check examples of documents
  • Information outputted from existing system or;
  • Data collected / processed by system
  • In other words, input form and report
• ​Helps to identify the input and output of the current system

Specifications

• During the analysis stage, several types of specification is released (act as a guide to the project)
• That include:
  • Requirements Specifications
  • Design Specifications
  • System Specifications

Requirement Specification

• Contract between developer and client
• Specify what client needs
• Includes:
  • Purpose and objectives of system
  • Data output (e.g. database report)
  • Data input (e.g. input form)
  • Validation and verification needed
  • Data stored (e.g. Database fields and tables)
  • Functional requirements
  • Timeline and deadlines etc. 
  • Budget
• Work between system analyst and client, and client should approve the requirements

System Specification

• List software and hardware needed for new system
• Usually software is identified first, and later follow by hardware
• Software may include:
  • Database platform, other system software
  • Operating system requirements
• Hardware may include:
  • Estimated storage requirements
  • Minimum and recommended processing and memory
  • Extra input / output devices

Design Specification

• How the system will look like (by designer)
  • House styles (e.g. https://material.io/design)
  • User interface
  • Storyboard (interaction between screens)
• How the system should work (by developer)
  • Data Flow diagram
  • System Flowchart
  • Data collection forms
  • Screen layouts
  • Validation routine
  • Data dictionary

Storyboard of a smartphone app

Think Pair Share

1. Why do we need to create all these specifications? [3]

Design

• Objectives:
  • identify a flow of data through a system and create a data flow diagram (DFD) and a system flowchart
  • design and evaluate data collection forums and screen layouts
  • design and evaluate validation routines
  • create a data dictionary for a given situation
  • evaluate suitable hardware and software for a new system

Data Flow Diagram

• Shows how data flows throughout a system
• Level 0 Diagram - Context level:
  • Show whole system and data flow between whole system and any external entities
• Level 1 Diagram:
  • Within the system (partially or whole) 
  • If the diagram is part of the system then parts of system is view as external entity

Process

External entity

Data store

Data Flow

Symbols used in DFD

Example Level 0 Diagram

A hotel accepts online bookings for its hotel rooms. Guests make a booking online and the booking is received by the hotel. When customer arrives, they are given an electronic key which includes encrypted data that will unlock the door and allow purchases at the bar. At the end of the stay, the guest is presented with a bill which must be paid before leaving. 

Steps in creating Context DFD

1. Identify the external entities
2. Put data flow between entities

Example Level 1 Diagram

When the guest sends their online booking, the room availability is checked and the booking details are stored. When the guest arrives, their key card is activated by retrieving the room access details. When the guest is ready to leave, a bill is produced by retrieving the booking details and any bar expenditure from the bar system. When payment is made, the booking detail are updated to confirm that payment has been made. 

Steps in creating Level 1 DFD

1. Identify the entities
2. Put data flow between entities

System Flowchart

• Shows the processes take place within the system and the decision made
• Can represent whole system or part of it

More symbols on Flowchart, about data storage

Example of a system flowchart, can you guess what is the system it is describing?

Example:

Draw the flowchart for the following scenario:

A pizza delivery company accepts orders of pizzas by phone. The customer is asked for their address. If the address is not within the delivery area, then the order is stopped. If the address is within the delivery area, then the customer is asked for their order. The customer is offered the option to have garlic bread as a starter. If the customer does not accept, then the order continues to payment. If the customer choose to pay by cash, then the order is complete. If the customer chooses to pay by credit card or debit card, then the customer is asked for their card details. If the card details are accepted, then the order is complete. If the card details are not accepted, then the customer is asked to repeat the card details. 

Data Dictionary

Data dictionary is a table that contains how data is stored in an application

It contains the following fields:

• Field Name
• Data type
• Data Format
• Field size
• Description
• Example

It may also include validation rules

e.g. mj18/31/q10

Validation Routines

• Type of validations:
  • Presence 
  • Range (can apply to number or date)
  • Type (Data type must match)
  • Length (Text)
  • Format (Text, give in proper validation format)
  • Lookup (One of the options in a dataset, usually from another database table)

Assumes we are working on a Student Table (Entity), write the validation routines for some of the fields

Development and Testing

• Developers will follow the designed and agreed specification, to develop the application
• Testing of the developed part will occur alongside with the development on
  • individual modules (unit test) or
  • Multiple modules (integration test or system test) or
  • Full System test
• Test Plan is required such that testers will follow exactly how and what to test the system.

Types of testing

• Alpha Test: Internal test, usually within developer's company
• Beta Test: Selected group of tester, public or target users
• White-box test: Testing the internal workflow of the software, with the knowledge of the construction of the software, more suitable for internal or unit test
• Black-box test: Testing the functionality of the software, more suitable for beta test or testing with external software

Test plan

• Components in a test plan
  • Serial Number
  • Description
  • Type of test
    • Valid / Extreme / Invalid
  • Input Data
  • Expected Result
  • Pass/Fail

Example

• Create a test plan to test the input of a date within 2020
• You should:
  • Start with considering the format of the data
  • Also types of validation
  • Both of these are defined in data dictionary
• Then decide what might go wrong, what might be close to the extreme (boundary, usually for number or range check). Also include some valid (common) data

Exercise

• Design a test plan to test input of data for a character code between letters D and P (inclusive)