INFO2010 - L3 System requirements Flashcards
TELOS
Technical Economic Legal Operational Schedule
Technical feasibility
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
Economic feasibility
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?
Operational feasibility
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
Schedule feasibility
Assists in determining practicality and acceptability of the time-frame for development of the proposed information system
REQUIREMENTS DEFINITION
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
Information system components
from Lester
PROCESSING (comms) - create, update/edit, enquiries (ad-hoc), reports (regular), delete INTERFACE - user DATA (network) - files, records, fields, database relationships
Information system requirements FR
from Lester
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
Information system requirements NFR
from Lester
Availability? Security? Access? Monitoring? Constraints? Response time?
Requirements
/ (Need) –> Solution
Problem->Cause - Req tackles cause-> Sol
\ (Wish) –> Solution
Requirements Catalogue
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?)
Requirements validation
Demonstrate the requirements define the system which the customer really wants
Very important as req error costs are high
Prototyping - important technique
Requirements validation - aspects to be checked:
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
Requirements validation - in practice
Must not be after req doc is complete
Regular req reviews with both users and sw engineers essential during req definition
Prototyping
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