1. CS 564AR Systems Engineering for Software Intensive Systems with Requirements Engineering

2. CS 564AR © 2005 Prof. Bernstein Software Requirements Process Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype/Modeling Requirements Management

3. CS 564AR © 2005 Prof. Bernstein Software Requirements Lecture 1 Administrative Objective Software Development Model Overview Requirements Process Systems Engineering Software as a Business

4. CS 564AR © 2005 Prof. Bernstein Contact Information Professor Larry Bernstein –Director QSE Program Education BSEE Rensselaer Polytechnic Institute MSEE NYU CDT Professional Experience Stevens/consultant to industry – 9 years Bell Labs – 35 years Email: lbernste@stevens.edu Phone: 973-258-9213 Office Hrs: by appointment & 4:00 PM Wed.

5. CS 564AR © 2005 Prof. Bernstein Course Elements Requirments Specifications (40%) Patriot Anti-Missile CRM Bed and Breakfast JiffyLoop Exams (30%) Final Exam (30%) A ≥ 80; 65  B < 80; 50  C < 65; F< 50

6. CS 564AR © 2005 Prof. Bernstein Highlights of Quantitative Approach Lambda Protocol Overlaps with Systems Engineering Industrial Strength Requirements for Software Intensive Systems-of-Systems

7. CS 564AR © 2005 Prof. Bernstein What is a Requirement? A property that must be exhibited by a system to solve some problem. Requirements may be Functional providing product capabilities Non-Functional constraining the implementation

8. CS 564AR © 2005 Prof. Bernstein System Performance Resulting from Robust Requirements vs. Discrete Specifications Volume Dynamic Range Ideal Discrete Specifications Robust Requirements

9. CS 564AR © 2005 Prof. Bernstein Waterfall Development Model System Feasibility System Feasibility Validation Software Plans & Requirements Software Plans & Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Implementation System Test Operations & Maintenance Operations & Maintenance Revalidation From Boehm (1988), p. 62

10. CS 564AR © 2005 Prof. Bernstein Simplified Spiral Model Determine objectives, alternatives, constraints 1 Evaluate alternatives; identify and resolve risks 2 Develop and verify next-level product 3 Plan next phase 4 Cumulative Cost Progress through steps Commitment Partition Review

11. CS 564AR © 2005 Prof. Bernstein Spiral Model Determine objectives, alternatives, constraints 1 Evaluate alternatives; identify and resolve risks 2 Develop and verify next-level product 3 Plan next phase 4 Cumulative Cost Progress through steps Commitment Partition Review Requirements Plan Life-cycle plan Concept of Operation Risk Analysis Prototype 1 Prototype 2 Prototype 3 Operational Prototype Simulations, models, benchmarks Software Requirements Risk Analysis Requirements Validation Development Plan Integration and Test Plan Software Product Design Design Validation and Verification Detailed Design Code Unit Test Integration and Test Acceptance Test Implementation From Boehm (1988), p. 64

12. CS 564AR © 2005 Prof. Bernstein Relative Project Costs Relative Cost Range x 1.25x 1.5x 2x 4x 0.8x 0.5x 0.8x 0.67x Phases and Milestones Feasibility Concept of Operation Plans and Requirements Requirements Specifications Product Design Product Design Specifications Detailed Design Detailed Design Specifications Development and Test Accepted Software

13. CS 564AR © 2005 Prof. Bernstein SEI Capability Model Level 1 Initial Process 81% Ad Hoc, chaotic Level 2 Repeatable Process 12% Intuitive, dependent on talented individuals Level 3 Defined Process 7% Process defined & institutionalized, reliable cost & schedule Level 4 Managed Process 0% Reasonable control over quality, measured process Level 5 Optimizing Process 0% Adaptive feedback process Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996 Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996 Key Process Areas Configuration Management Quality Assurance Subcontract Management Project planning, tracking, & oversight Requirements management Peer reviews & training program Inter-group coordination Product engineering Process definition & focus Integrated software management Software quality management Quantitative process management Process change management Technology change management Defect prevention

14. CS 564AR © 2005 Prof. Bernstein Top Ten Software Risk Items CategoryRisk Item People1. Personnel Shortfalls 2. Unrealistic Schedules and Budgets Requirements3. Developing the Wrong Software Functions 4. Developing the Wrong User Interface 5. Gold Plating 6. Continuing Stream of Requirements Changes Externalities7. Shortfalls in Externally-Furnished Component 8. Shortfalls in Externally-Performed Tasks Technology9. Real-Time Performance Shortfalls 10. Straining Computer Science Capabilities From Boehm (1988), p. 6

15. CS 564AR © 2005 Prof. Bernstein Creeping Featurism Endemic to the Software Industry Occurs on more than 70% of all applications over 1000 function points From a 60 project sample Average creep was 35% Maximum observed was 200% Creeping requirements change about 1% per month For a 3 year project, 1/3 of the delivered requirements would have been added after requirements were initially defined Rate of Requirements change is higher than for other forms of engineering (electrical, mechanical, civil) Source: Assessment and Control of Software Risks, Capers Jones, 1994 Source: Assessment and Control of Software Risks, Capers Jones, 1994

16. CS 564AR © 2005 Prof. Bernstein Creeping Requirements – Root Cause Uncertainty in resolving true user needs For multi-year projects, changes in normal business environment Failure to adopt methodologies that limit the risk associated with creeping requirements Primitive fundamental technologies for exploring and modeling requirements Failure to use technology to measure the impact of creeping requirements Source: Assessment and Control of Software Risks, Capers Jones, 1994 Source: Assessment and Control of Software Risks, Capers Jones, 1994

17. CS 564AR © 2005 Prof. Bernstein Requirements Management Establish and maintain a business case to support funding Strategic linkages to business and technology organizations –AVOID SHELFWARE Continuous customer agreement on requirements Requirements agreement used as a basis for estimating, planning, implementing and tracking FORMAL COMMITMENT PROCESS Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996

18. CS 564AR © 2005 Prof. Bernstein Requirements Management Establish and maintain a business case to support funding Strategic linkages to business and technology organizations Agreement with customer on requirements for the project Covering technical and non-technical requirements Requirements agreement used as a basis for estimating, planning, performing and tracking the project Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996 Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and Cases McGraw-Hill, 1996

19. CS 564AR © 2005 Prof. Bernstein IEEE Stoneman Model Guide to the Software Engineering Body of Knowledge (Version 0.9) Software Requirements Software Requirements Software Design Software Design Software Construction Software Construction Software Testing Software Testing Software Maintenance Software Maintenance Software Configuration Management Software Configuration Management Software Engineering Management Software Engineering Management Software Engineering Process Software Engineering Process Software Engineering Tools & Methods Software Engineering Tools & Methods Software Quality Software Quality Requirements Engineering Process Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management

20. CS 564AR © 2005 Prof. Bernstein 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 Process Models Process Actors and Stakeholders Process Support and Management Process Quality and Improvements Relationship to the Business Decision

21. CS 564AR © 2005 Prof. Bernstein QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing, Quality Estimates ICED-T Trade-off Analysis

22. CS 564AR © 2005 Prof. Bernstein

23. Bed and Breakfast

24. CS 564AR © 2005 Prof. Bernstein Trustworthy Software is: Safe: Does no harm Reliable: No crash or hang. Secure: No Hacking Possible

25. CS 564AR © 2005 Prof. Bernstein QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing, Quality Estimates ICED-T Trade-off Analysis

26. CS 564AR © 2005 Prof. Bernstein 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

27. CS 564AR © 2005 Prof. Bernstein Conditions That Cause Unreliability Poor Algorithms Missing Deadlines Roundoff Error Build Up Memory Leaks Broken Pointers Register Misuse

28. CS 564AR © 2005 Prof. Bernstein QSE Characteristics Solving the right problem the right way Certified against requirements. Certified against problem Bounded execution domain

29. CS 564AR © 2005 Prof. Bernstein 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

30. CS 564AR © 2005 Prof. Bernstein SchedulerPro Prototype Screen

31. CS 564AR © 2005 Prof. Bernstein SchedulerPro Prototype Screen

32. CS 564AR © 2005 Prof. Bernstein SchedulerPro Notification Emails

33. CS 564AR © 2005 Prof. Bernstein Measurable Operational Value SchedulerPro MOV Course scheduling and registration time reduced by an average of 20 minutes per student per semester.

34. CS 564AR © 2005 Prof. Bernstein SchedulerPro Functional Goals Schedule Classes and Personal Time  Searching  Course Placement  Course Detail Viewing  Course Removal  Scheduling Personal Blocks  Notification (optional)  Course Suggestions (optional)

35. CS 564AR © 2005 Prof. Bernstein 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

36. CS 564AR © 2005 Prof. Bernstein 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

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

38. CS 564AR © 2005 Prof. Bernstein SchedulerPro sQFD Features / Functions Class Filters Allocate non- class time Long term information availability Authenticate Makes scheduling classes easier 8362 19 Makes scheduling a semester easier 7982 26 Find schedules in one place 1157 14 Total16131911 59

39. CS 564AR © 2005 Prof. Bernstein SchedulerPro Product Reliability Two hours of unavailability allows for daily backups, service, and reboots of the system Connections to server are minimized, reducing overall activity on the server

40. CS 564AR © 2005 Prof. Bernstein 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.

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

42. CS 564AR © 2005 Prof. Bernstein 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%

43. CS 564AR © 2005 Prof. Bernstein Complexity Chart - Client Project Type: online transaction Problem Domain: 2 Architecture Complexity: 3 Logic Design – Data: 2 Logic Design – Code: 3 Total Score: 10 Complexity = (10/18) * 5 = 2.78

44. CS 564AR © 2005 Prof. Bernstein Complexity Chart - Server Project Type: online transaction Problem Domain: 1 Architecture Complexity: 2 Logic Design – Data: 2 Logic Design – Code: 2 Total Score: 7 Complexity = (7/18) * 5 = 1.94

45. CS 564AR © 2005 Prof. Bernstein Complexity Chart - Overall Project Type: client/server Problem Domain: 2 Architecture Complexity: 3 Logic Design – Data: 2 Logic Design – Code: 3 Total Score: 10 Complexity = (10/18) * 5 = 2.78

46. CS 564AR © 2005 Prof. Bernstein 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

47. CS 564AR © 2005 Prof. Bernstein April Function Points Est. FunctionLowAverageHighTotal Outputs1019 Inquiries3009 Inputs23018 Internal Files31031 External Interfaces 11012 Total UFP79 AFP82

48. CS 564AR © 2005 Prof. Bernstein 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

49. CS 564AR © 2005 Prof. Bernstein Web Points FunctionTotal Web Objects Outputs11 Inquiries9 Inputs18 Internal Files31 External Interfaces12 # Multimedia files6 # Web building blocks7 # Scripts3 # Links0 Total Web Objects97 Effort = A * cd i (Size) P1 Because it is a small web project, assume: A=2.1, B=2.0, P1=1.00, and P2=.5 Language Expansion Factor = 25 From this, we estimate 2.43 KLOC Effort = A* KLOC = 2.1 * 2.43 = 5.103 staff-months Duration =B * Effort P2 = 2.0 * 5.103.5 4.518 calendar months = 4.518 calendar months

50. CS 564AR © 2005 Prof. Bernstein ICED-T Scheduling by: IntuitiveConsistentEfficientDurableThoughtful Paper32223 Excel32333 School Scheduler 34434 SchedulerPro44545

51. CS 564AR © 2005 Prof. Bernstein ScheulerPro Creeping Features Are the System Admins important stakeholders? You bet…

52. CS 564AR © 2005 Prof. Bernstein 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

53. CS 564AR © 2005 Prof. Bernstein 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

54. CS 564AR © 2005 Prof. Bernstein SchedulerPro Installation Plan 3. Configuring Your Installation Open the directory where you installed the site files (step 2A above). Open the file “web.config”, and find the properties labeled “DBLocation”, “DBUser”, “DBPassword”, and “SecretAuthenticateKey”. These are set to default values that you should modify. Make sure that the location, username, and password match those you set up in SQL Server in step 2B above. Set SecretAuthenticateKey to the random string you are using in your authentication web page. Technical Information Scheduler Pro uses HTTP and XMLTHTTP protocols: - HTTP: As a typical client/server application, an HTTP request is sent to server. Server processes the request and returns HTTP response. - XMLHTTP: client opens XMLHTTP connection to the server. Server executes query on the database and returns needed data. Refer to Development view and process view from the “4+1” architecture views for further technical details.

55. CS 564AR © 2005 Prof. Bernstein People Software Trustworthiness depends on people: I propose that customers insist that software products identify a Software Architect and Software Project Manager in their contracts

56. CS 564AR © 2005 Prof. Bernstein Software Architect: Affirms that the software product solves the customer’s problem Affirms that the software product is suitably reliable, easy-to-use, extendible, not harmful and robust. That it is trustworthy. Affirms that the requirements are valid.

57. CS 564AR © 2005 Prof. Bernstein Software Project Manager: Affirms that the software was successfully tested against the requirements. Affirms and identifies the good software engineering processes were used in the software development and integration. Affirms that the project is within budget, on- time and performs satisfactorily.

58. CS 564AR © 2005 Prof. Bernstein