Requirements for rapid application development

“It is easier to tell what you don’t like about an existing system than to describe what you would like in an imaginary one”
A.M. Jenkins, 1983

Identify
Initial
Requirements
Develop
System
Use and
Evaluate
Iterate
Document and Install

 Approver Approves payment and accepts final product
 User Responsible for business solutions
 Intermediary Run system for user
 Builder Write code for application
 Technical Supports the development
Support tools
 Toolsmith Build basic tool modules (often work for software houses)

Requirements for Successful
Prototyping: User
 Initiate the process
 Seeks IS assistance
 Competent in business area
 Willing to spend time with system

Requirements for Successful
Prototyping: Builder
 Assigned to Prototyping
 Competent with tools
 Knows organizational data resources

Requirements for Successful
Prototyping: Technology
 Roles identified
 4GL Tools established
 Data is managed
 Technology response adequate

 Life cycle too slow
 Scope of project manageable
30 screens
Small team: 1-2 users/designers
50 attributes
 User not sure of specifications
 User satisfaction very important
 Reporting or DSS
 Irregular or infrequent use

 Don’t understand tools
 Data not well managed
 Software not well managed
 Professional staff not available
 Technology response not adequate
 User not willing to invest time

 All requirements cannot be specified
 Quick build tools are available
 Communications gap between builders and users
 Active models are required
 Rigorous approaches are appropriate once requirements are known
 Iteration is valuable

Life Cycle
 Prespecification possible
 Changes expensive
 Good project communication
 Static model OK
 Rigorous approach useful
 Iteration unacceptable
Prototype
 Prespecification difficult
 Quick tools work
 Communications gap
 Animated model needed
 Rigor after requirements
 Iteration accepted

 Determine suitability for prototyping
 Identify basic needs
 Develop working model
 Demonstrate and solicit refinements
 Revise and redemonstrate
 Clean up and document

 Structure: interactive, on-line (OLAP)
 Logic: structured but not algorithmic
DSS applications are often data-report types
 User: competent and active participant
 Time Constraint: not a crash project
 Management: willing to work with method
 Size: not overly large or complex

 Problem: imprecise specifications, poorly defined communications, interactive model needed
Why not use prototyping

 Date and time stamps
 Control totals
 Audit trails
 Common interface feel
 Additional functions
 Testing

1.
Most applications arise from a small set of basic systems
1. Batch edit/update 7. On-line application
2. Batch reporting interface
3. Batch data update 8. On-line report
4. Batch interface
5. On-line update/query
6. On-line ad hoc query

2. Most systems use a common set of data processing functions
 Add
 Modify
 Display
 Delete
 Locate
 Browse
 Activate
 Copy
 Connect
 Stop

3. Most editing derives from a small set of models.
 Tunnel edits
 Cross field edits
 Cross record edits

4. Most reports are based on a four step process.
 Select data from the database
 Sort by specification
 Format and edit for printing
 Print

5. There are a standard set of value added design structures that should be added


Audit trails
Control totals
 Menu and command modes
 Help facility
 Standard screen formats
 Date/time stamping
 Ergonomics

 Normalize data to 3NF
 Use component engineering
Use existing components
Assemble from existing parts
Reuse pieces
Create pieces so that they can be reused
 Cut and paste
 Keep a set of examples

 Use active data dictionaries
 Automate documentation
 Keep teams small
 Integrated software workbench tools
 Specify objectives not procedures
 Provide end-user report writing tools
 Use professional prototypers
 Have systems developers work with prototypers

 Initial Model: 2-6 weeks
Must be fast enough to maintain interest
 Revisions: immediate - 2 weeks
 Chargeback: use charges to avoid frivolous changes
 Approval: determine the group who approves iterations
 Sign off: formal acceptance

Additional
Implementation Requirements
 Operational documentation and procedures
 Data size and operational impact analysis
 Test plan
 Training procedures

 Evolution
 Throwaway
 Life Cycle component

 Bernard H. Boar, Application Prototyping, Wiley, 1984.
 Ralph Sprague & Eric Carlson, Building Effective Decision Support Systems,
Prentice Hall, 1984.