imat1906 systems development lecture week 26: revision term 1

IMAT1906 Systems Development

Lecture week 26: revision term 1

Today’s Agenda

IMAT 1906 Lecture Week 26 (c) De Montfort University 2010-112

Weeks 1-5 : evaluation Weeks 6-9: logical system design Weeks 10-11: physical system design

Purpose


To remember and understand what we have seen in the module

To prepare for the exam

Weeks 1-5 : evaluating a system


Evaluating a system Decide the requirements

What you expect of the system Functional requirements Non-functional requirements

Test the system against the requirements Build test plan based on requirements Include functional and non-functional requirements Write test data and test cases based on expected real

data Run the tests and fill in test log

Documenting the evaluation


Report containing: Requirements specification

List of requirements Detailed description

Test strategy Overview of test plans Test cases used

Findings Overview of test results Test logs

Conclusions Is the system fit for purpose Brief explanation of any faults or improvements needed

Where are we on agenda



Initial activity


Business problem is stated, expressed in business language Explains why the system is needed

Fact finding techniques for high-level understanding Workshops Interviews

Documented in rich picture Actors Processes Things in use Interactions


8

Feasibility study


To decide whether the system is worth developing

Four types of feasibility Technical – can we do this Economic / financial – can we afford to do this Operational / organisational – will this meet the

business need Schedule – can we do this in time

Documented in feasibility report

Detailed requirements


Fact finding techniques for detailed understanding Workshops Interviews Questionnaires Surveys Observation Document analysis Task analysis

Requirements specification


Types of requirement Functional / user – what the system needs to

provide Non-functional – typically about interface and

system behaviour Data requirements – what data is needed

Documented in requirements catalogue or specification List of requirements Detailed specification of each requirement


12

Requirements Date: 4 October 2010

Req. Id: 9 Name: Sales Report for MonthPriority: M

Source: Joe Bloggs (cashier)

Functional Description: The system records books sold to buyers. The sales report for a month accepts the month as input and prints a report showing book title, author, sale date and price for each book sold within the requested month. Books listed are to be ordered by seller surname. Totals are to be included on the report, showing total number of books sold and total income. Subtotals are to be included as well, showing total number of books sold and total income for that seller.

Non-functional description:

Description Target Value Acceptable RangeAccess Cashier n/aStationery Bookshop logo n/a

Rationale This report is needed for the cashier to keep track of books sold and monies received. It allows cashier to give the correct amounts to each seller at the end of the month.

Test strategy


Test strategy What kinds of testing will be done Unit / system / end-to-end / user acceptance

Test data and test cases Based on realistic cases from work environment Anonymised, no real people Test plans

Can be written once the requirements are known Shows how developers and users will know the

system is acceptable

Use case model


Use case model shows the actors and processes Use case diagram

Shows all the use cases One process per use case Some dependencies: extends, includes

Use case description One description per use case Gives all relevant details Includes step-by-step description for successful

outcome Includes steps for alternative outcome(s) eg error

conditions


15


16

Use case name: list books for sale

Primary actor: Seller

Goal/description: Book added to list of seller’s books

Scope: Bookshop system; single book

Preconditions: Seller has accessed correct part of system;Seller has identified a book to sell

Successful completion: 1- seller accesses own book list2- seller requests to add new book to list3- system returns open screen with empty fields4- seller inputs book details5- system stores book details and returns Success message

Alternative: 1a- book has already been listed1b- system returns Duplicate Book message2a- some details are missing2b- system requests missing details2c- seller supplies missing details2d- system stores book details and returns Success message

Postconditions: Book has been added to seller’s list of books

Use Case Description

Data flow diagrams


Data flow diagrams show increasing detail of processing and data stores

Context diagram System is empty box Actors as external entities Data flows show information that is passed

between external entities and system – noun-based data flow names


18

Level 1 diagram


Fills in the empty box from the context diagram Shows external entities, processes, data stores

and data flows Data flows from context diagram also shown on

level 1 diagram Data flow names show information ie noun-based Process names show actions ie verb-based Data store names show stored information ie

noun-based Data flows connect processes to data stores

and/or external entities


20

Level 2 diagram


Expands any complex processes from level 1 diagram Components as for level 1 diagram

Processes, data flows, data stores Data flows into and out of the diagram are same

as data flows into and out of the process on the level 1 diagram


22

Data model


Shows the structure of data stores to be used for the system

Used to design database Includes all data items from data

requirements Things relevant to the system, called entities Details needed about the things, called attributes How things link together, called relationships

Consists of Entity-relationship diagram Table names with identifiers and attributes

Structured English


Some use case descriptions include details of part of the process

Expressed in structured English Describes logic of business process Simple language constructs Clear and unambiguous

Structured English - example


IF user is registered to system allow entry display list of public books ELSE disallow entry display unsuccessful sign-in message ENDIF

Decision tables


Used to describe how to make complex decisions

Clear and unambiguous Components

Conditions – usually as questions with yes/no answers

Rules – combinations of answers to questions Actions – what will happen in each case Decisions – which actions apply to which rules ie in

which circumstances

Decision tables - example


To calculate ticket fares Conditions:

Concession (child, senior), return ticket Actions:

No discount, 10% discount, 50% discount

Concession Y N Y N

Return N Y Y N

No discount X

10% discount X

50% discount X X

Checking logical model


Go back to the business people you talked to earlier Bring requirements specification and diagrams

and models Go through all the diagrams and models Check your understanding of their requirements Get any corrections or adjustments Revise the diagrams and models

Can take time but is worth the effort Finds mistakes or misunderstandings early

Revisit test strategy


Test strategy and test cases written based on requirements specification

Revised and refined based on logical system design

Test are not carried out until after system has been developed

Testing is team effort with developers and users

Where are we on agenda



Interface considerations


Interface is user’s way of interacting with system

And customer’s way of interacting with organisation

Techniques Storyboard Screen design Report design

Storyboard


Technique to clarify requirements for the interface

Low-tech mock-up of the interface and the user’s conversation with the system Paper and pencil or flip chart pens Analyst or analyst and user together

Common uses Clarify flow of work or information from beginning

to end including things outside the computer system

Clarify content and format of screens Clarify sequence of screens and navigation

Screen design


Interface combines input and output Basic design rules

Consider the user Choose appropriate data entry method Minimise effort required

HCI concepts – human-computer interface Appearance - uncluttered Layout – consistent Controls – text boxes, buttons etc Flow through fields on screen Conversation flow from screen to screen

User help


Several ways of providing help to user Self-explanatory instructions Tool tips or help menu

Help user to avoid or recover from input errors Data validation Input masks Helpful error messages

Usability


What does ‘user friendly’ mean? Easy to use Consistent Self-explanatory to a large extent Natural aid to the user’s task

Usability checklist

Report design


Detail report Header Body Trailer

Other types Exception report Summary report On demand report Internal report Archival report

System documentation


Logical model Process designs and models Data designs and models Interface designs and models

Physical model Self-documenting code ER model and tables with attributes Process descriptions User guide

Further information


Further information can be found in many textbooks on systems development or systems analysis, for example:

Skidmore & Eva (2004) Shelly & Rosenblatt (2010) Cadle, Paul & Turner (2010) Schneider & Winters (1998) McCracken & Wolfe (2004) Bocji P, A Greasley and S Hickie (2008)

imat1906 systems development lecture week 26: revision term 1

Documents

system imat

montfort university

detailed requirements

requirements date

physical system design

test log slide

test data

evaluation imat