1. 1 Introduction to Requirements Specification

2. 2 Outline Requirement Engineering Software Lifecycle and Software Processes

3. 3

4. 4 Three Level Requirements Stakeholder Needs Features of the System Software Requirements

5. 5 Stakeholder Needs (extracted from the slides of Peter Hauker, Rational)

6. 6 Stakeholders in SE Customers Those who pay for the software Users Those who use the software Software developers Development Managers Problem: The customer often doesn’t have good grasp of what he wants.

7. 7 Features of the System

8. 8 Software Requirements

9. 9 Importance of Requirements The set of requirements constitute a contract between the client and the software developer It should be written such that all stakeholders can understand what the system will do. It allows developer to map problem domain concepts to solution domain concepts

10. 10 Importance of Requirements

11. 11 How Do We … ? … know what the system is supposed to do? By proper requirements development … keep track of the current status of requirements? … determine the impact of a requirements change? By proper requirements management

12. 12 Introduction 12 We are focusing on these stages of RE Elicitation Analysis Negotiation Requirements Management Validation, Verification Representation, Specification

13. 13 Requirements Engineering: General View

14. 14 Requirements Development Process

15. 15 Requirements Development Process Elicitation: work with the customer on gathering requirements Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements Specification: Structure the customer input and derived requirements as written documents and diagrams Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors.

16. 16 What is Requirements Management?

17. 17 Requirements Types

18. 18 Functional Requirements Describe the functionality or services that the system is expected to provide Address the input-output behavior of a system

19. 19 Examples of Functional Requirements 3.1.1{FR1} Software shall automatically detect the presence of the network. 3.1.2{FR2} Software shall automatically detect the presence of other computers running the application that are connected to the network.

20. 20 Non-Functional Requirements

21. 21 Design Constraints

22. 22 Requirements Gathering: Dice Game Requirements gathering is the Starting Point (WHAT, i.e., problem oriented) Dice Game: A player rolls two dice.  If the total is seven, the player wins; otherwise he loses.

23. 23 Modeling: Bridge between Requirements and Solution Modeling a system involves: identifying the things that are important to your particular view Their properties consider how specific instances of these things must fit together. Modeling a system is affected by how you expect to use the system

24. 24 How Do You Expect to Use the Dice Game ? “Happy end” scenario Dice Game: Roll two dice. System: CONGRATULATIONS! You won the game.

25. 25 How Do You Expect to Use the Dice Game ? Not so “happy end” scenario Dice Game: Roll two dice. System: Looser, try again …

26. 26 Modeling: Dice Game Modeling Features: Dice Game: A player rolls two dice.  If the total is seven, the player wins; otherwise he loses. Play with one user and two dice

27. 27 Modeling: Dice Game Modeling Structure Player name Die FaceValue DiceGame total Rolls 12 1 1 Plays 1 2 Includes

28. 28 Modeling: Dice Game Modeling Behavior : DiceGame Die1: Die Die2:Die Play() GetFaceValue() roll() GetFaceValue() Total() Result()

29. 29 Role of Visual Modeling

30. 30 Modeling Requirements: Requirements Specifications Definition: “Specifications represent a model of how inputs are related to system reactions and outputs” Specification is an ABSTRACTION of the Requirements Needed for: complex, large, or critical problems. Specifications will increase the technical level of details given in the requirements

31. 31 Modeling of The Problem: Problems? Abstraction might capture only part of the real world truth (i.e., incomplete) A book may have more than one writers Somebody else is paid to write the book … Domain Knowledge is required Complexity of the Problem is an issue

32. 32 Errors in Requirements might be also dangerous …

33. 33 References 33 Collaboration (2006). Requirements Analysis. http://en.wikipedia.org/wiki/Requirements_engineering Karl E. Wiegers (2000). When Telepathy Won’t Do: Requirements Engineering Key Practices. http://www.processimpact.com/articles/telepathy.html HCi Consulting (2001-2). Software requirements analysis, and why it doesn't work. http://www.jiludwig.com/HCI_Journal_article.html Michael G. Christel, Kyo C. Kang (1992). Issues in Requirements Elicitation. http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf Mildred Shaw (1997). Soft System Methodology. http://sern.ucalgary.ca/courses/seng/613/F97/grp2/ssm.htm

34. 34 References 34 Pictures: http://japanesecentral.com/Siryoo/pictureclips/clothes/suit.jpg http://www.bchu.org/whyweight/Success_Strategy/Content.htm http://www.customnames.com/NewVinylList.html http://pacovilla.com/v- web/gallery/slideshow.php?set_albumName=PacosToyBox http://www.tacojohns.com/HTML/Graphics/Food/Burritos/Medium/Combo- Burrito.gif http://www.cia.gov/cia/information/artifacts/model.htm All references on recipe cards