Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

System Design > Week 3 > Flashcards

Week 3 Flashcards

(59 cards)

Start Studying
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

Study These Flashcards
A

High influence high interest

25
Apathetics
Low influence low interest
26
Defenders
Low influence high interest
27
Techniques
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
Interview
Conducted at users workplace (see how work is done) Conducted away (to avoid work related interruptions)
29
Structured interview
List of predetermined questions
30
Semi-structured
Using some predetermined questions but allowing further elaboration and discovery
31
Unstructured
Mainly using open questions
32
Question types
Closed ended questions -> yes/no limit discussion and data elicitation Open ended questions -> enable exploring, probing and learning on complex topics
33
Interview purpose
Understand the needs and expectations raise awareness of the project
34
Interview advantages
Effective way to understand business functions and rules Get a first hand impression of business requirements Create bonds
35
Interview disadvantages
Time consuming and resource expensive What people say is not always what they really do
36
Questionnaires
paper or electronic allows gathering of data from a large group annonymous standardized
37
Advantages
Cover a wide spectrum of people
38
Disadvantags
Low response rate Questions may not be well understood
39
Review Reports, Forms and Procedure Descriptions
Document analysis of existing internal business documents/ procedures
40
What to look for in reviewing internal documents
identify business rules, discrepancies, redundancies cautious of outdated material preliminary understanding of processes use as guideline for interviews
41
What to look for in reviewing external documents
industry wide practices trade publications
42
Observations
to obtain discrepancy between documentation and what is actually performed
43
Passive observation
watching and listening to users in their environments
44
Active observation
asking users questions and having a conversation
45
Hawthorne (observer) effect
If users are aware of being observed, their behavior may be affected
46
Research Vendor Solutions
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
Techniques in Vendor Research
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
Collective ACTIVE USER COMMENTS and suggestions
Feedback on models and tests Users know it and when they see it
49
Extra Techniques: Workshops
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
Problems of Workshops
Can be very difficult to organise Particularly when senior people are involved Requires taking people off work for a week or so
51
Requirements Specification Report
Document or report that communicates the design that you are proposing describes understanding of business problem
52
Scope
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
Assumptions
Results from gaps in understanding of the design problem should be minimal or none at all gap should be clarified with client
54
Requirements Specification
The remainder of the report deals with various models making up the design
55
Unified Modelling Language
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
Why are models developed?
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
Models in System Analysis
Models are constructed to represent requirements of the system
58
Examples of models
Use cases class diagrams sequence diagrams activity diagrams
59
Activities of Analysis
Gather detailed information Define (functional and non-functional) requirements Prioritise requirements Develop user interface dialogs Evaluate requirements with users

System Design (3 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions