1. CS 551 – Requirements and Prototyping Thanks to Rand Edwards and Ian Summerville for some of 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. QSE Characteristics l Solving the right problem the right way l Certified against requirements. l Certified against problem l Bounded execution domain

5. Trustworthy Software is: l Safe: Does no harm l Reliable: No crash or hang. l Secure: No Hacking Possible As of 9/20/07

6. Progress Reports Progress reports are due 1:00 PM on Wednesdays Do not send WORD or PDF or text documents, use embedded text only]

7. Progress Report Contents Email Subject Line: CS 551, (Project Name) (date) Address to: lbernste@stevens.edu; sprasad@stevens.edu; (customer)lbernste@stevens.edu@stevens.edu Email body: Author: Team members:

8. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments 3. Risks and Contingencies 4. Problems Faced 5. Simplifications 6. Current Estimates

9. Progress Report Sections 1. Customer Interactions and Relations Did you meet with your customer? Do you understand the problem better? Is your customer happy with your progress? Do you have a good relationship with your customer? 2. Accomplishments 3. Risks and Contingencies 4. Problems Faced 5. Simplifications 6. Current Estimates

10. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments What was done since the last progress report, include schedule implications? What made the progress possible? 3. Risks and Contingencies 4. Problems Faced 5. Simplifications 6. Current Estimates

11. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments 3. Risks and Contingencies What are the project risks? How is each risk managed? 4. Problems Faced 5. Simplifications 6. Current Estimates

12. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments 3. Risks and Contingencies 4. Problems Faced Any delays encountered since your last report? Any new problems? ( “A project with no problems is in deep trouble,” Prof. Bernstein) 5. Simplifications 6. Current Estimates

13. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments 3. Risks and Contingencies 4. Problems Faced 5. Simplifications How did you simplify your design? How did you simplify your development process? (Quantitatively support each simplification) 6. Current Estimates

14. Progress Report Sections 1. Customer Interactions and Relations 2. Accomplishments 3. Risks and Contingencies 4. Problems Faced 5. Simplifications 6. Current Estimates Estimate completion dates.

15. From Project Gantt Chart create this table TaskWhoWhenCurrent Estimate  Who: The person in charge of the task  When: Task committed completion date owned by the project manager  Current Estimate: Task estimated completion date owned by the “Who person”

16. QSE Lambda Protocol l Prospectus l Measurable Operational Value l Prototyping or Modeling l sQFD l Schedule, Staffing, Quality Estimates l ICED-T l Trade-off Analysis

17. Universal Software Engineering Equation Reliability (t) = ℮ -k t when the error rate is constant and where k is a normalizing constant for a software shop and = Complexity/ effectiveness x staffing

18. Case Study: SchedulerPro Prospectus User friendly, efficient interface for students to create and modify class schedules. Features: Visual schedule creation and editing Schedule suggestion Schedule comparison view Monitor closed-out sections

19. SchedulerPro Prototype Screen

21. SchedulerPro Notification Emails

22. Measurable Operational Value SchedulerPro MOV Course scheduling and registration time reduced by an average of 20 minutes per student per semester.

23. SchedulerPro Functional Goals Schedule Classes and Personal Time  Searching  Course Placement  Course Detail Viewing  Course Removal  Scheduling Personal Blocks  Notification (optional)  Course Suggestions (optional)

24. SchedulerPro Functional Requirements Search available classes by: Same professor Similar time Same or equivalent class but different sections Register and track registrations Color classes and arbitrary time-blocks by user choice

25. SchedulerPro Nonfunctional Requirements Integrate with “Web for Students’ and existing authentication systems and avoid incompatibilities Allow schedules to be saved/accessed from a server or local file Provide a scaled time-accurate visual representation of the schedule

26. More Non-functional requirements l Make schedules available even if the application is down, provided an internet connection is available l Perform some functions without a live connection to the ‘Web for Students’ registrar web site l Make compatible with all popular browsers Display section states and print schedules without loss of detail

27. SchedulerPro sQFD Features / Functions Class Filters Allocate non-class time Long term information availability Authenticate Makes scheduling classes easier8362 19 Makes scheduling a semester easier 7982 26 Find schedules in one place1157 14 Total16131911 59

28. SchedulerPro Product Reliability l Two hours of unavailability allows for daily backups, service, and reboots of the system l Connections to server are minimized, reducing overall activity on the server

29. Jan. Function Point Est. FunctionLow (L)Average (A)High (H)Total Outputs130 19 Inquiries841 49 Inputs571 41 Internal Files320 24 External Interfaces210 10 Total UFP143 Adjustment Factor0.99 Total AFP141

30. April Function Points Est. FunctionLowAverageHighTotal Outputs1019 Inquiries3009 Inputs23018 Internal Files31031 External Interfaces11012 Total UFP79 AFP82

31. History of Function Points DateAFPProject Length* Projected Finish* January 2714119.7 staff months August 2006 February 2410414.4 staff months March 2006 April 17828.5 staff months May 2006 *Using COCOMO Model

32. ICED-T Scheduling by: IntuitiveConsistentEfficientDurableThoughtful Paper32223 Excel32333 School Scheduler34434 SchedulerPro44545

33. SchedulerPro Creeping Features Are the System Administrators important stakeholders? You bet…

34. Parnas reliability checklist Failures in communication, secondary storage, memory, or any hardware that may interrupt a transaction: »The SQL Server DBMS will not commit incomplete transactions. User will be notified of the error, and will have to redo the transaction. Operator error: »Important operations are confirmed before they are completed to avoid large accidental errors.

35. SchedulerPro Estimate of Reliability R(t) = 1 - F(t) F(t) = P(T ≤ t) l During load testing, we discovered the test server can support 1500 user queries a minute. l P(failures/query) = 55/1500 = 0.036 l Thus, F(t) = 3.6%, which means the software is 96.4% reliable

36. SchedulerPro Reliability Estimate 1/ λ = MTTF = εE/kC k = scaling constant = 1 C is complexity = 2.78 E is the development effort = 36.4 ε is the expansion factor = 1.5 λ = 0.05 t is the continuous execution time for the software R(t) = 95.12%

37. Complexity Chart - Client l Project Type: online transaction l Problem Domain: 2 l Architecture Complexity: 3 l Logic Design – Data: 2 l Logic Design – Code: 3 »Total Score: 10 »Complexity = (10/18) * 5 = 2.78

38. Complexity Chart - Server l Project Type: online transaction l Problem Domain: 1 l Architecture Complexity: 2 l Logic Design – Data: 2 l Logic Design – Code: 2 »Total Score: 7 »Complexity = (7/18) * 5 = 1.94

39. Complexity Chart - Overall l Project Type: client/server l Problem Domain: 2 l Architecture Complexity: 3 l Logic Design – Data: 2 l Logic Design – Code: 3 »Total Score: 10 »Complexity = (10/18) * 5 = 2.78

40. SchedulerPro Installation Plan Installation 1. Third Party Software Required Scheduler Pro requires the following products to be already installed on the target machine. Please consult the documentation of each product for installation instructions specific to each. - Windows 2000, XP, or 2003 Server - Microsoft IIS, version 5.0 or higher - Microsoft.NET, version 1.1 - Microsoft SQL Server 2000 - Message Queuing Service (Windows component) - ASP.NET State Service

41. 2. Installing the Scheduler Pro application To install Scheduler Pro, please follow these steps: I. Setting up the web site 1. Create a virtual directory for the site in IIS 2. Copy the contents of the “site” folder to the directory on your hard drive represented by the IIS virtual directory II. Setting up the database 1. Using the SQL Server Enterprise Manager tool, attach the database located under the “sqldb” directory. 2. Create a new user account for accessing this database, and give it read/write access for the database. III. Installing the Suggest, Notified, and Data Loader Windows Services Open the directory titled “services”. Run each of these files: - InstallSuggestService.exe - InstallNotifierService.exe - InstallDataLoaderService.exe Each installer will properly install the service. The Data Loader installer will also ask you for the location and name of the course data file it will load. SchedulerPro Installation Plan

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

43. Key Question l What’s the problem?

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

45. oInterviews oScenarios oPrototypes oFacilitated Meetings oObservation Elicitation Techniques

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

47. Software Requirements Objective l Requirements Elicitation Overview l Requirements Analysis l Unified Modeling Language Use Cases Behavioral Modeling

48. Requirements Engineering Process Requirements Elicitation Requirements Analysis & Negotiation Agreed Requirements Draft Requirements Document Requirements Document & Validation Report Informal Statement of Requirements Decision Point: Accept Document or re-enter spiral Requirements Specification Requirements Validation l Process Models l Process Actors and Stakeholders l Process Support and Management l Process Quality and Improvements l Relationship to the Business Decision

49. Requirements Process - Context l Varied Sources »Different Processes »Risk Factors l Different “Consumers” »Development »Marketing »Training »Documentation »Information Base Requirements Engineering Process Business Strategy Business Strategy Technology Strategy Technology Strategy Project, Process & Documentation Standards Project, Process & Documentation Standards Opportunity Analysis Market Analysis Customer Request Software Design Software Development Software Testing Requirement s Document Marketing, Etc.

50. UML Framework Source: Martin, James, Odell, James J., Object-Oriented Methods: A Foundation UML Edition Prentice-Hall PTR, 1998 Source: Martin, James, Odell, James J., Object-Oriented Methods: A Foundation UML Edition Prentice-Hall PTR, 1998 Basic Foundation Level Types (Concepts) Objects Mappings Relationships Associations Subtypes/Supertypes States Events Operations Methods Triggers Control Conditions State Changes Aggregation Constraints Rules Classification Meta-Models Power Types Extended Foundation Level Structural Specification Behavioral Specification OO Program Languages …… Class Diagram … Activity Diagram … C++ Smalltalk … Application Level

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

52. Mapping Requirements to a Framework l Requirements Purpose Prioritized Categorized Dependencies resolved Quantified Bounded PMO Models Requirements Elicitation Reports Use Cass l ICED-T Intuitive Consistent Efficient Durable Thoughtful

53. 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’

54. Mapping Requirements to a Framework PMO Models Requirements Elicitation Reports Use Cases Static Structure Activity Model UML Framework Use Case Diagram Class Diagram Component Diagram Activity Diagram State Chart Sequence Chart Timing Chart Only as needed!

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

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

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

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

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

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

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

62. Evolutionary Prototyping

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

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

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

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

67. Incremental Development Process

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

69. Throw-away Prototyping

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

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

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

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

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

75. Key points l A prototype can give end-users a concrete understanding of the system’s capabilities l Prototyping is used when rapid development is essential l Throw-away prototyping is used to understand the system requirements l In evolutionary prototyping, the system is developed by gradually adding features.

76. Guidelines 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

77. Case History Harbor Radar CS 551 Senior Design

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

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

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

81. Map Module Screenshots

82. Larger View Grid Icons

83. Wrapper Module for TV Screens