Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "CS 551 – Requirements and Prototyping Fall 2004 Thanks to Rand Edwards and Ian Summerville for this material."— Presentation transcript:

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

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

3 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

4 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

5 Key Question l What’s the problem?

6 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

7 oInterviews oScenarios oPrototypes oFacilitated Meetings oObservation Elicitation Techniques

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

9 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

10 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

11 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’

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

13 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

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

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

16 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.

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

18 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

19 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

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

21 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

22 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

23 Evolutionary Prototyping

24 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

25 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

26 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

27 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

28 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

29 Incremental Development Process

30 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

31 Throw-away Prototyping

32 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

33 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

34 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

35 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

36 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.

37 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

38 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

39 Case History Harbor Radar CS 551 Senior Design

40 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

41 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

42 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

43 Map Module Screenshots

44 Larger View Grid Icons

45 Wrapper Module for TV Screens


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

Similar presentations


Ads by Google