Introduction to Software Engineering Lecture 5

1. Introduction to Software EngineeringLecture 5 André van der Hoek

2. Today’s Lecture • Requirements engineering • Requirements specification

3. Recurring, 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. Requirements phase Verify Design phase Implementation phase Testing phase Verify Test Verify ICS 52 Life Cycle

5. Requirements Phase • Terminology • Requirements analysis/engineering • Activity of unearthing a customer’s needs • Requirements specification • Document describing a 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 need • Time-lag between initial desire and future need • Long and arduous, often educational, process

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

7. 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 Use the principles

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

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

10. Users of a Requirements Document

11. Non-Functional Requirement Types

12. Structure • Introduction • Executive summary • Application context • Functional requirements • Environmental requirements • Software qualities • Other requirements • Time schedule • Potential risks • Future changes • Glossary • Reference documents

13. Introduction • What is this document about? • Who was it created for? • Who created it? • Outline

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

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

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

17. Environmental Requirements • Platforms • Hardware • Operating systems, types of machines, memory size, hard disk space • Software • CORBA, Jini, DCOM, 4GL, … • Programming language(s) • Standards

18. Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability Software Qualities

19. 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?

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

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

22. 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 • …

23. Glossary • Precise definitions of terms used throughout the requirements document

24. Reference Documents • Pointers to existing processes and tools used within an organization • Pointers to other, existing software that provides similar functionality • Pointers to literature

25. Structure • Introduction • Executive summary • Application context • Functional requirements • Environmental requirements • Software qualities • Other requirements • Time schedule • Potential risks • Future changes • Glossary • Reference documents

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

27. 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)

28. 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?

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

30. Develop Requirements Execute System Tests Requirements Review Develop Acceptance Tests Acceptance Test Review Design Execute Integration Tests Design Review Develop Integration Tests Integration Tests Review Code Execute Unit Tests Code Review Develop Unit Tests Unit Tests Review V-Model of Development and Testing

31. Example • French fries and mayonnaise place

32. Your Tasks • Read and study slides of this lecture • Read Chapter 9 of van Vliet • Note: discussion starts Friday