CSE1IS Information Systems
Week 6

Alternatives and the System Requirements Document

S.C.&R. Ch. 5

so far:

have a Systems Proposal
performed preliminary analysis to determine feasibility
- Preliminary Investigation Report
analysed and documented current system
- DFDs and System Dictionary
DFDs and System Dictionary for proposed system are also produced
Final Analysis tasks:
1. Investigate Development Alternatives
2. Prepare a Cost-Benefit analysis for each alternative
3. Prepare the Systems Requirements Document

Who develops the system?
- Develop in-house
  - Program
  - Off-the-shelf package
  - customisation of off-the-shelf package
- Outsource
Platform for development:
- traditional (forms-based) program
- web-based program
- use a Rapid Application Development (RAD) environment, or code from first-principles?
  - Prototyping?

Complex software systems take man-years to develop
- very expensive on a one-off basis.
- final system should satisfy user needs.
Advantages:
- Satisfy unique requirements.
- Minimise change.
- Fits in with existing system's hardware/software
S.C.&R. Fig 5-9 outlines the alternatives:

eg. Accounting, Library, Inventory
Comprises:
- programs
- documentation
- tailor made installation options.
- training
Advantages of a package:
- The package has been pre-tested and proven.
- Less time to implement.
- Fewer technical staff required.
- On-going support from the vendor.
- In-house testing before buying.
  → less risk of bad system.
- Usually cheapest alternative.
- Upgraded by vendors

Many questions to be answered:

Does package perform the standard operations required?
Does package handle exceptional circumstances in the manner required?
Is the package fast enough?
Are other users of the package happy with it?
Has package been evaluated by computer publications?
- How did it rank?
Will package handle the volume of transactions required?
Are field sizes large enough?
- Is it capable of handling your future expansion?
Is the package compatible with:
- existing hardware and communications?
- other systems within organisation?
Does the package have adequate security and control methods?
Are your users comfortable with the package?
When are new versions of modified software available?
- At what (extra) cost?
Maintenance fees?
- monthly, yearly?
- At what cost?
- What services are included, excluded?
Hours of software support service
- Emergency support outside these times?
- At what cost?
Is initial training provided?
Compatibility of file types with
- current system?
- other systems within organisation?

Buying a package does not eliminate all the phases involved in building your own systems.

Evaluate as for alternative 2. Determine amount of modifications required.
General guideline:
- if unmodified package meets only 50% of specifications, it is no good
- if 85% of specifications are satisfied consider changing some business practises which may be cheaper than modifying the package.
Vendors often charge excessive amounts to modify source code.
Customising Inhouse:
- Does package vendor allow/provide sufficient access for required customising?
Do you have necessary expertise?
- How easy will it be to customise new versions of the software?
Customising provided by Vendor:
- Will this occur before system is installed?
- How will disputes about software maintenance fees be resolved?
- New Versions:
  - will they incorporate the additions?
  - at what extra cost?
Compatibility of file types:
- with unaltered version
- other software packages

Contract a third party for development, maintenance etc.
Growth area because:
- major software developers develop allpications based on their product, eg. Oracle
- developers have expertise and experience in development environment
  - changing environments makes it difficult for inhouse staff to keep abreast of latest technology
- only pay for time required
fees may be time based
- or, more usually, a contract for the entire system
  - maybe divided up on subsystems
- be careful that the boundaries are clear
Offshore Outsourcing:
- developed by programmers that work for cheaper rates in other countries
- communication is not a hurdle as with manufacturing (where goods must be physically transferred)

provides for future growth - estimate that. S.C.&R. Fig 5-15 is a good example showing a growth comparison between two alternatives:

	Current level	Future growth based on existing order processing procedures	Future Growth assuming new web site is operational
Customers	36500	40150	63875
Daily Orders	1435	1579	2811
Daily Order Lines	7715	7893	12556
Sales Reps	29	32	12
Order Processing Support Staff	2	4	3
Products	600	650	900

Prepare a Cost-Benefits for each alternative considered.

or, Software Requirements Specification, contains:

a description of the new system
- incorporate Data Flow Diagrams, Data Dictionary and Decision Tables.
the alternatives for implementing the new system
- cost-benefits of each alternative
recommendation for management . Usually one of:
- one of the alternatives
- "Further Analysis Required" to make a decision
- "Stop all further work"
  - eg. if benefits of the new system are far outweighed by the cost
Note the System Requirements Document is similar to a Blue-Print that can be used by vendors for final quotations etc.
- accuracy and completeness is important
Example of Management Summary of a System Requirements Proposal for Fleet Foot Enterprizes.

Shelly, Cashman & Rosenblatt, Systems Analysis and Design, 6th Edition, Course Technology, 2006.