CS 551 – Requirements and Prototyping Fall 2004 Thanks to Rand Edwards and Ian Summerville for this material

Software Requirements Process l Requirements Elicitation l Requirements Analysis l Use Cases l Requirements Specification l Prototype l Requirements Management

Requirements Specification Spec 1. Project Title, Revision Number and Author 2. Scope and Purpose of the system 3. Measurable Operational Value 4. Description 5. Feature List including ICED T and Simplified QFD analysis 6. Interfaces 7. Constraints 8. Change Log and Expected Changes 9. Responses to the unexpected 10. Measurements 11. Glossary 12. References

Requirements Engineering Process Requirements Document & Validation Report Requirements Elicitation Requirements Analysis Agreed Requirements Prospectus Decision Point: Accept Document or re-enter spiral Requirements Specification Requirements Validation Prototype Simple QFD Baseline Document

Key Question l What’s the problem?

Prospectus & Elicitation l What Information do we need? Description of the Problem Description of the Environment Scope of Solution A list of project goals Any constraints on the behavior or structure of the solution- system

oInterviews oScenarios oPrototypes oFacilitated Meetings oObservation Elicitation Techniques

Use Cases Drive Development Use Cases Test Case Design Architecture and Design

Elicitation Challenges l Experts don’t know what they know! Much knowledge is tacit thru extensive use Difficult to dig it out Know-how expressed as solutions l Analysts are domain novices Tend to simplify Often miss key functions

Mapping Requirements to a Framework l ICED T Intuition Consistent Efficient Durable Thoughtful l UML Framework Use Cases Structure Business Rules PMO Models Requirements Elicitation Reports Use Cases Static Structure Activity Model

ICED T Mappings Ratings 1 = ‘Worst I have ever seen’ 2 = ‘Worse than Average’ 3 = ‘Average, like most other systems’ 4 = ‘Better than Average’ 5 = ‘Best I have ever seen’

Simplified QFD (scale 0 to 10) Goals/FeaturesTrack Delivery Trucks.On-line Customer Inquiry Credit Check 1. Easy to Order % Less Inventory % Profit Increase Speed Product Introduction 090 Total32712

Package Diagram l Groups related use cases l Forms basis for a functional partitioning from the users point of view. l Shorthand for tracking within the project Order Entry View Status Create & Submit Orders

Activity Chart Enter Order Check Credit [submitted] [aborted] [denied] Allocate Inventory [approved] Prepare Delivery Receive Payment Create Order & Submit > Order EntryFinance Shipping Inventory Management

Required Measurements l Function Points l ICED T l Consistency = %features with average QFD > 7 l Stability = feature changes/month

Prototyping l Prototyping is the rapid development of a system l The principal use is to help customers and developers understand the requirements for the system Requirements elicitation – Users can experiment with a prototype to see how the system supports their work Requirements validation – The prototype can reveal errors and omissions in the requirements l Prototyping can be considered as a risk reduction activity –As of 23 Sept.

Five Great Patterns Solo Virtuoso Code Ownership Engage QA Divide and Conquer Prototype Reference: Technical Memorandum by J. O. Coplien Document No. BL TM

Product Size Reduction TRADITIONAL PROCESSPROTOTYPING 40% REDUCTION 20% 80% 40% 30% 45% 25% Systems Engineering Design, Develop, Test, Install Final Development, Deployment Systems Engineering & Prototype Final Development Deployment

Prototyping Benefits l Misunderstandings between software users and developers are exposed l Missing services may be detected and confusing services may be identified l A working system is available early in the process l The prototype may serve as a basis for deriving a system specification l The system can support user training and system testing

Approaches to Prototyping Prospectus Evolutionary prototyping Throw-away Prototyping Delivered system Executable Prototype + System Specification

Prototyping Objectives l The objective of evolutionary prototyping is to deliver a working system to end-users The development starts with those requirements which are best understood. l The objective of throw-away prototyping is to validate or derive the system requirements The prototyping process starts with those requirements which are poorly understood

Evolutionary Prototyping l Must be used for systems where the requirements specification cannot be developed in advance l Based on techniques which allow rapid system iterations l Verification is impossible as there is no specification l Validation means demonstrating the adequacy of the system

Evolutionary Prototyping

Evolutionary Prototyping Advantages l Accelerated delivery of the system Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability l User engagement with the system Not only is the system more likely to meet user requirements, they are more likely to commit to the use of the system

Evolutionary Prototyping l Specification, design and implementation are inter-twined l The system is developed as a series of increments that are delivered to the customer l Techniques for rapid system development are used such as CASE tools and 4GLs l User interfaces are usually developed using a GUI development toolkit

Evolutionary Prototyping Problems l Management problems Existing management processes assume a waterfall model of development Specialist skills are required which may not be available in all development teams l Maintenance problems Continual change tends to corrupt system structure so long-term maintenance is expensive l Contractual problems

Prototypes as Specifications l Some parts of the requirements may be impossible to prototype E.g., safety-critical functions l An implementation has no legal standing as a contract l Non-functional requirements cannot be adequately tested in a system prototype

Incremental Development l System is developed and delivered in increments after establishing an overall architecture l Requirements and specifications for each increment may be developed l Users may experiment with delivered increments while others are being developed These serve as a form of prototype system l Intended to combine some of the advantages of prototyping More manageable process Better system structure

Incremental Development Process

Throw-away Prototypes l Used to reduce requirements risk l The prototype is developed from an initial specification, delivered for experiment then discarded l The throw-away prototype must NOT be considered as a final system Some system characteristics may have been left out There is no specification for long-term maintenance The system will be poorly structured and difficult to maintain

Throw-away Prototyping

Rapid Prototyping Techniques l Various techniques may be used for rapid development Dynamic high-level language development Database programming Component and application assembly l These techniques are often used together l Visual programming is an inherent part of most prototype development systems

Dynamic High-level Languages l Languages which include powerful data management facilities l Need a large run-time support system. Not normally used for large system development l Some languages offer excellent UI development facilities l Some languages have an integrated support environment whose facilities may be used in the prototype

Choice of Prototyping Language l What is the application domain of the problem? l What user interaction is required? l What support environment comes with the language? l Different parts of the system may be programmed in different languages l Example languages Java, Smalltalk, Lisp, Prolog, Perl, Tcl/TK

Database Programming Languages l Domain specific languages for business systems based around a database management system l Normally include a database query language, a screen generator, a report generator and a spreadsheet l May be integrated with a CASE toolset l The language + environment is sometimes known as a “4GL” l Cost-effective for small to medium sized business systems

Prototyping with Reuse l Application level development Entire application systems are integrated with the prototype so that their functionality can be shared For example, if text preparation is required, a standard word processor can be used l Component level development Components are mutually independent Individual components are integrated within a standard framework to implement the system Framework can be a scripting language or an integration platform.

Key points l A prototype can be used to give end-users a concrete impression of the system’s capabilities l Prototyping is becoming increasingly used where rapid development is essential l Throw-away prototyping is used to understand the system requirements l In evolutionary prototyping, the system is developed by evolving an initial version to the final version

Key points l Rapid prototyping may require leaving out functionality or relaxing non-functional constraints l Prototyping techniques include the use of very high-level languages, database programming and prototype construction from reusable components l Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified l Users must be involved in prototype evaluation

Case History Harbor Radar CS 551 Senior Design

Project Overview l To primarily serve boaters in the Hudson River area with a 40 mile radius and inexpensive TV to display weather info, buoy data, and plotted locations l Interactive website Accessible to everyone Secure section where admin can control information displayed with ability to plot coordinates and alter broadcast information l Difficult time writing requirements and setting scope

Requirements l Website Design -Easy to use, clean, intuitive and clearly display maps l Reliability High reliability requested by customer Availability »Ultimate goal of 24/7, however probably not doable. 20/7 has been suggested

Requirements (cont.) l Performance Website will support 50 simultaneous users »Reach for goal of 100 Television broadcast(s) place little load on the system Response Time »Average of.5s l Constraints Television resolution will be an issue »Aim to be readable on a 9” screen Support both IE and Netscape, versions TBD

Map Module Screenshots

Larger View Grid Icons

Wrapper Module for TV Screens