1. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering Lecture 6 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Today’s Lecture Reminders Requirements engineering Requirements specification (documentation) Requirements engineering with Use Cases

3. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Reminder: Fundamental Principles Rigor and formality Separation of concerns – Modularity – Abstraction Anticipation of change Generality Incrementality These principles apply to all aspects of software engineering

4. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 4 Reminder: High Cost

5. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Cost of Change Progressively Higher

6. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 6 Why Requirements? “[We] have grown to care about requirements because we have seen more projects stumble or fail as a result of poor requirements than for any other reason” – (Kulak and Guiney, in “Use Cases: Requirements in Context”) Studies show that many of the key contributors to project failures originate or relate to requirements – (The Standish Group CHAOS reports)

7. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 7 Some stats… From those CHAOS reports 31% of projects cancelled before they are even completed – Many others not delivered or not used (“shelfware”) even if completed – Many billions wasted per year on cancelled, unused or unusable projects – 52.7% of projects were more than 189% over budget when delivered Requirements defects are expensive – They represent more than 70% of rework costs – Rework consumes about 30-50% of total project budget – Lack of user input/user involvement listed as most frequent problem

8. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 8 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

9. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 9 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

10. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 10 The RUP Model Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction Workflows group activities logically In an iteration, you walk through all workflows

11. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 11 Requirements Phase Terminology – Requirements analysis/engineering Activity of discovering/observing/gathering customer’s needs – Requirements specification Activity of describing/documenting customer’s needs Note: requirements address what a customer needs, not what a customer wants – A customer often does not know what they want, let alone what they actually need… – Time-lag between initial desire and future need – Long and arduous, often educational, process And things change “under our feet” during the requirements process...

12. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Requirements Analysis System engineering versus software engineering – What role does software play within the full solution? – Trend: software is everywhere Contract model versus participatory design – Contract: carefully specify requirements, then contract out the development – Participatory: customers, users, and software development staff work together throughout the life cycle

13. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Techniques for Requirements Analysis Interview customer Create use cases/scenarios Prototype solutions Observe customer Identify important objects/roles/functions Perform research Construct glossaries Question yourself Discuss: Is this familiar?

14. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Requirements Specification Serves as the fundamental reference point between customer and software producer Defines capabilities to be provided without saying how they should be provided – Defines the “what” – Does not define the “how” Defines environmental requirements on the software to guide the implementers – Platforms, implementation language(s), … Defines constraints on the software – Performance, usability, … Defines software qualities

15. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Why Spend a Lot of Time? A requirements specification is the source for all future steps in the software life cycle – Lays the basis for a mutual understanding Consumer (what they get) Software producer (what they build) – Identifies fundamental assumptions – Potential basis for future contracts Better get it right – Upon delivery, some software is actually rejected by customers Changes are cheap – Better make them now rather than later

16. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 16 Users of a Requirements Document

17. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 17 Non-Functional Requirement Types

18. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Document Structure Introduction Executive summary Application context Functional requirements Environmental requirements Software qualities Other requirements Time schedule Potential risks Future changes Glossary Reference documents

19. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 19 Introduction What is this document about? Who was it created for? Who created it? Outline

20. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 20 Executive Summary Short, succinct, concise, to-the-point, description – Usually no more than one page Identifies main goals Identifies key features Identifies key risks/obstacles

21. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 21 Application Context Describes the situation in which the software will be used – How will the situation change as a result of introducing the software? – “World Model” Identifies all things that the system affects – Objects, processes, other software, hardware, and people – Provides an abstraction for each of those, characterizing the properties and behaviors that are relevant to the software system Identifies fundamental assumptions

22. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 22 Functional Requirements Identifies all concepts, functions, features, and information that the system provides to its users Provides an abstraction for each of those, characterizing the properties and functions that are relevant to the user – What is the system supposed to do? – What information does the system need? – What is supposed to happen when something goes wrong? An approximate user interface is part of functional requirements

23. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 23 Environmental Requirements Platforms – Hardware Operating systems, types of machines, memory size, hard disk space – Software Is it a Web app? Web 2.0?? Is it open source? Linux? Apache? PHP/MySQL? Is it enterprise software?.Net? Enterprise Java, J2EE? Programming language(s) Standards

24. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 24 Desired Software “ilities” (Qualities) Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability

25. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Other Requirements What about cost? What about documentation? What about manuals? What about tutorials? What about on-the-job training? What about requirements that do not fit in any of the previous categories?

26. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 26 Time Schedule By when should all of this be done? – Initial delivery date – Acceptance period – Final delivery date What are some important milestones to be reached? – Architectural design completed – Module design completed – Implementation completed – Testing completed

27. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 27 Potential Risks Any project faces risks – Boehm’s top ten risks (see lecture 3) – It is important to identify those risks up-front so the customer and you (!) are aware of them One of the requirements could be to explicitly address the risks

28. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 28 Future Changes Any project faces changes over time – It is important to identify those changes up-front so the customer and you (!) are aware of them – These changes could simply pertain to potential future enhancements to the product One of the requirements could be to build the product such that it can accommodate future changes Note: structure the requirements document in such a way that it easily absorbs changes – Define concepts once – Partition separate concerns – …

29. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 29 Glossary Precise definitions of terms used throughout the requirements document

30. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 30 Reference Documents Pointers to existing processes and tools used within an organization Pointers to other, existing software that provides similar functionality Pointers to literature

31. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 31 Observations Document is structured to address the fundamental principles – Rigor – Separation of concerns Modularity Abstraction – Anticipation of change – Generality – Incrementality Not every project requires every section of the document

32. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 32 Specification Methods Natural language Data flow diagrams – Office automation Finite state machines – Telephone systems – Coin-operated machines Petri nets – Production plants Formulas – Matrix inversion package Objects (in object-oriented methods) Use cases (in UML)

33. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Verification Is the requirements specification complete? Is each of the requirements understandable? Is each of the requirements unambiguous? Are any of the requirements in conflict? Can each of the requirements be verified? Are are all terms and concepts defined? Is the requirements specification unbiased?

34. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 34 Acceptance Test Plan Accompanies a requirements specification Specifies, in an operational way, consistency between the requirements specification and the system that will be delivered Binds a customer to accept the delivered system if it passes all the tests Covers all aspects of the requirements specification

35. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 35 V-Model of Development and Testing Develop Acceptance Tests Acceptance Test ReviewRequirements Review Develop RequirementsExecute System TestsDevelop Integration Tests Integration Tests ReviewDesign Review DesignExecute Integration TestsDevelop Unit Tests Unit Tests ReviewCode Review CodeExecute Unit Tests

36. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 36 Example French fries and mayonnaise place