INFO2010 - L3 System requirements Flashcards

1
Q

TELOS

A
Technical
Economic
Legal
Operational
Schedule
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Technical feasibility

A

Can a solution be supported with existing technology?
Hardware and software capability, reliability and availability
Concerned with determining the possibility and practicability of using existing and modern IT to develop the proposed system

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

Economic feasibility

A

Assesses budgetary & financial constraints on proposed IT system
Cost savings, increased revenue, decreased investment, increased profits
Is existing tech cost effective - will costs be offset by the benefits?

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

Operational feasibility

A

Determining whether existing or proposed procedures & practices are adequate for the purposes of the proposed system
Will the solution work within the org if implemented?
Give consideration to education, training & development required to operate proposed info system
End user acceptance
Management control
Customer, supplier and government requirements

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

Schedule feasibility

A

Assists in determining practicality and acceptability of the time-frame for development of the proposed information system

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

REQUIREMENTS DEFINITION

A

COARSE GRAIN FR
- system functions defined in an abstract way
SYSTEM PROPERTIES
- non funct. reqs for the sys in general are defined
UNDESIRABLE characteristics
- unacceptable system behaviour is specified

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

Information system components

from Lester

A
PROCESSING (comms)
 - create, 
update/edit, 
enquiries (ad-hoc),
reports (regular),
delete
INTERFACE
 - user
DATA (network)
 - files,
records, 
fields,
database relationships
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Information system requirements FR

from Lester

A

Processing - what must be done FR
Create, update, enquire, report, delete
Data - what sort of data must b processed FR
files, records, fields
Interface- what protocols must be used FR
user, network, telecomms

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

Information system requirements NFR

from Lester

A
Availability?
Security?
Access?
Monitoring?
Constraints?
Response time?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Requirements

A

/ (Need) –> Solution
Problem->Cause - Req tackles cause-> Sol
\ (Wish) –> Solution

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

Requirements Catalogue

A

ID
Who has this req
Priority (Optional, Desirable, Mandatory)
Requirement (updates, enquiries, interfaces, reports, data)
Target value (security, availability, audit & control, service level, monitoring, constraints, access)
Acceptable range
Comments (benefits, suggested solutions)
Related docs
Resolution (Where in the analysis, specification or design is this requirement addressed?)

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

Requirements validation

A

Demonstrate the requirements define the system which the customer really wants
Very important as req error costs are high
Prototyping - important technique

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

Requirements validation - aspects to be checked:

A

Validity - reqs must be a compromise across user community
Consistency - one req should not conflict with another
Completeness - incl all functs & constrts intended by sys user
Realism - must be realisable

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

Requirements validation - in practice

A

Must not be after req doc is complete

Regular req reviews with both users and sw engineers essential during req definition

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

Prototyping

A

Is a working model of one or more aspects of a system
Involves users early in development
Quick and inexpensive
Important req validation technique
Gives users hands on experience, they can see how it supports their work
Allows rapid dev and testing of ideas
USeful when user reqs undefined

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

Prototyping types

A

Throw away
Evolutionary
Incremental

17
Q

Prototyping - Throw away

A

Used to test an idea
Discarded when dev starts
Not developed using final sw or hw

18
Q

Prototyping - Evolutionary

A

Developed and modified till finally in state where it can become the operational system
Standards used have to be carefully considered

19
Q

Prototyping - Incremental

A

Strictly speaking - not prototyping
Operational system developed and implemented in small stages
Feedback from earlier stages can influence dev in later stages

20
Q

Advantages of prototyping

A

Learning by doing
Improved communication
Improved user involvement
Clarification of partially-known requirements
Demonstration of the consistency and completeness of a spec
Reduced need for docs
Reduced maintenance costs (i.e. changes after sys goes live)
Production of expected results

21
Q

Disadvantages of prototyping

A
Users might misunderstand the role of prototype
Lack of project standards is possible
Lack of control
Additional expense
Machine efficiency
Close proximity of developers
22
Q

System Life Cycle

A
Feasibility
Analysis - > Requirements
Design
Implement->Pilot and Test->Deploy
Maintain/Evolution
Decommission
23
Q

Analysis

A

Process - the set of activities lead to production of:

  • requirements definition
  • requirements specification
24
Q

Feasibility studies

A

Is is realistic to address a problem or opportunity under consideration?
Used to investigate the information needs of prospective users:
- estimate if current sw & hw might satisfy users
- is it cost effective from biz POV - can it be dev within current budget
- should be quick and cheap and inform decision go/no go