Week 3 Flashcards

1
Q

System Development Life Cycle

A

Includes a detailed plan of all activities needed for building, developing modifying and maintaining an information system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

SDLC

A

Planning
Analysis
Design
Implementation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Primary focus of Analysis

A

Understanding business functions and developing system requirements

Understanding the problem

Breaking a whole part into parts with the intent of understanding the part’s nature, function and interrelationship

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Skills Needed for Analysis in Analysis

A

Fact finding for investigation

Learn details of business

Knowledgeable as business domain users to build credibility

Brings fresh perspective to the problem (analyst from different business domain)

Communication

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Requirement

A

A statement (with context) of what the system must do or what characteristics it needs to have

Detailed enough to prevent misunderstanding

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

User Requirement Gathering - Business

A

What the business needs :-

Functions performed

Operating environment

Current problems that have driven the need for a new system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

User Requirement Gathering - User Needs

A

What the users see and do to support business needs

In what circumstances things are done

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Types of System Requirements

A

Functional

Non-functional

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Functional Requirements

A

Activities that the system must perform

They are based on business rules and processes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Non-functional requirements

A

Characteristics that the system must provide or support

try to fulfill these requirements as much as you can

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

FURPS

A
Functional
Usability requirements
Reliability requirements
Performance requirements
Securityrequirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Functional requirements

A

business tasks that users must perform using the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Usability requirements

A

Represent operational characteristics

-Like user interface, menu structure, color choice, online help

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Reliability requirements

A
  • Shows dependability

- E.g. services not available

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Performance requirements

A
  • Response time (e.g. 1 second for logon)

- Throughput (e.g. can support 100 students’ usage of Moodle)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Security requirements

A

–Password protection

  • Encryption
  • Unauthorize access
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

FURPS +

A

Additional requirements beyond FURPS

Design constraints (hardware or software restrictions)

Implementation requirements (programming language and tools)

Interface requirements (interactions among system)

Physical Requirements (hardware characteristics)

Supportability requirements (about the system installation, configuration and upgrade)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Stakeholders

A

Any person who has an interest (stake) in the successful implementation of the system

Direct or indirect relationship with the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Internal Stakeholders

A

Persons within the organisation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

External stakeholders

A

Persons outside the organisation but have an interest

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Operational stakeholderst

A

Persons who regularly interact with the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Executive stakeholders

A

Persons who dont directly interact but use the information or have financial interest

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Latents

A

High interest low interest

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Promoters

A

High influence high interest

25
Q

Apathetics

A

Low influence low interest

26
Q

Defenders

A

Low influence high interest

27
Q

Techniques

A

Technique 1: Interview

Technique 2: Distributing and collecting questionnaires

Technique 3: Reviewing inputs, outputs, and documentation

Technique 4: Observing and documenting business procedures

Technique 5: Researching vendor solutions

Technique 6: Collecting active user comments, and suggestions

28
Q

Interview

A

Conducted at users workplace (see how work is done)

Conducted away (to avoid work related interruptions)

29
Q

Structured interview

A

List of predetermined questions

30
Q

Semi-structured

A

Using some predetermined questions but allowing further elaboration and discovery

31
Q

Unstructured

A

Mainly using open questions

32
Q

Question types

A

Closed ended questions -> yes/no limit discussion and data elicitation

Open ended questions -> enable exploring, probing and learning on complex topics

33
Q

Interview purpose

A

Understand the needs and expectations

raise awareness of the project

34
Q

Interview advantages

A

Effective way to understand
business functions and rules

Get a first hand impression of
business requirements

Create bonds

35
Q

Interview disadvantages

A

Time consuming and resource expensive

What people say is not always what they really do

36
Q

Questionnaires

A

paper or electronic

allows gathering of data from a large group

annonymous

standardized

37
Q

Advantages

A

Cover a wide spectrum of people

38
Q

Disadvantags

A

Low response rate

Questions may not be well understood

39
Q

Review Reports, Forms and Procedure Descriptions

A

Document analysis of existing internal business documents/ procedures

40
Q

What to look for in reviewing internal documents

A

identify business rules, discrepancies, redundancies

cautious of outdated material

preliminary understanding of processes

use as guideline for interviews

41
Q

What to look for in reviewing external documents

A

industry wide practices

trade publications

42
Q

Observations

A

to obtain discrepancy between documentation and what is actually performed

43
Q

Passive observation

A

watching and listening to users in their environments

44
Q

Active observation

A

asking users questions and having a conversation

45
Q

Hawthorne (observer) effect

A

If users are aware of being observed, their behavior may be affected

46
Q

Research Vendor Solutions

A

Many problems already solved (prepacked solutions)

Positive contributions (new ideas, new state of art tech, cheaper and less risky)

Danger
purchase a solution before understanding the problem
may not address all requirements
vendor support, upgrade issues

47
Q

Techniques in Vendor Research

A

Technical specifications from vendor (for integration with pre-existing system)

Demo or trial system

References of existing clients

On-site visits

Printout of screens and reports

RFP - request for proposal

48
Q

Collective ACTIVE USER COMMENTS and suggestions

A

Feedback on models and tests

Users know it and when they see it

49
Q

Extra Techniques: Workshops

A

Get all stakeholders in a room for a couple of days and facilitate discussion

Build models with everyone there

People bounce ideas of each other

Requires a conference room, whiteboard facilitator and a scribe

50
Q

Problems of Workshops

A

Can be very difficult to organise

Particularly when senior people are involved

Requires taking people off work for a week or so

51
Q

Requirements Specification Report

A

Document or report that communicates the design that you are proposing

describes understanding of business problem

52
Q

Scope

A

Critical concept that defines the conceptual boundary of the project

everything inside the scope needs to be designed

impacts size, cost, complexity and time

disagreement between clients and designers due to scope

53
Q

Assumptions

A

Results from gaps in understanding of the design problem

should be minimal or none at all

gap should be clarified with client

54
Q

Requirements Specification

A

The remainder of the report deals with various models making up the design

55
Q

Unified Modelling Language

A

UML is the standard set of model constructs and notations by the Object Management Group

Analyst and end users can depict and understand a variety of specific models used in SAD

56
Q

Why are models developed?

A

models are used to converse with clients to clarify requirements

designers learn more about expectations and requirements

let designers study certain properties

learning mechanism

products or systems are built based on lessons learned from modelling exercise

57
Q

Models in System Analysis

A

Models are constructed to represent requirements of the system

58
Q

Examples of models

A

Use cases

class diagrams

sequence diagrams

activity diagrams

59
Q

Activities of Analysis

A

Gather detailed information

Define (functional and non-functional) requirements

Prioritise requirements

Develop user interface dialogs

Evaluate requirements with users