Introduction to Requirements Specification

1. Introduction to Requirements Specification

2. Outline • Requirement Engineering • Software Lifecycle and Software Processes

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

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

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. Features of the System

8. Software Requirements

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. Importance of Requirements

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. We are focusing on these stages of RE Elicitation Representation, Specification Negotiation Requirements Management Analysis Validation, Verification Introduction 12

13. Requirements Engineering: General View

14. Requirements Development Process

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. What is Requirements Management?

17. Requirements Types

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

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. Non-Functional Requirements

21. Design Constraints

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. 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. How Do You Expect to Use the Dice Game ? • “Happy end” scenario • Dice Game: • Roll two dice. • System: • CONGRATULATIONS! You won the game.

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. Play with one user and two dice Modeling: Dice Game • Modeling Features: • Dice Game: • A player rolls two dice. • If the total is seven, the player wins; otherwise he loses.

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

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

29. Role of Visual Modeling

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. 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. Errors in Requirements might be also dangerous …

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 References References 33

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 References References 34