SOFT 423: Software Requirements

Size: px

Start display at page:

Download "SOFT 423: Software Requirements"

Nigel Ward
5 years ago
Views:

1 SOFT 423: Software Requirements Week 11 Class 3 Exam Review Weeks 1-3 SOFT 423 Winter

2 Last Class Final Content Class More System Examples SOFT 423 Winter

3 This Class Exam Review Weeks 1-3 Hand Back Test 3 SOFT 423 Winter

4 Introduction SOFT 423 Winter

5 Definition of Requirements Define what a system is required to do and the constraints under which it is required to operate SOFT 423 Winter

6 Definition of Requirements IEEE Standard Definition A condition or capability that must be met or possessed by a system or system component in order to satisfy a contract, standard, specification or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component. SOFT 423 Winter

7 Other Topics From the Intro Why are requirements important? Impact of wrong requirements? Sources of Requirements Errors: Correctness (not understanding situation) Completeness (situation not mentioned) SOFT 423 Winter

8 What Might Requirements Describe User level features General system properties Specific constraints Computation constraints Development constraints SOFT 423 Winter

9 Systems What is a system? [Easterbrook 2002] An actual or possible part of reality that can be observed or interact with it s environment A closed system doesn t interact with its environment Systems might have no physical existence SOFT 423 Winter

10 Types of Systems Natural Systems Abstract Systems Designed Systems Human Activity Systems Any system may be hard or soft soft -> cannot represent precisely hard -> system is precise and well-defined SOFT 423 Winter

11 System Boundary Where does the system end and the environment begin? Difficult to pinpoint! SOFT 423 Winter

12 Systems have Structure Encapsulation, subsystems, etc. State Memory of interactions, observable states SOFT 423 Winter

13 Custom Systems Classes Information Embedded Command and Control Others as well, but above are the main ones SOFT 423 Winter

14 Requirements vs. Design Ideal world: Requirements happen before design Requirements specify what not how Requirements specifies problem Design is solution Requirements never change Not the real world!! SOFT 423 Winter

15 Elicitation What is it? Sources? Driven by system goals! SOFT 423 Winter

16 Stakeholders What are they? Indirect vs. Direct Remember that not all stakeholder are obvious! SOFT 423 Winter

17 Specification This is the actual documentation of requirements Must be PRECISE! Official handover of authority to development processes SOFT 423 Winter

18 Validation Mitsakes will be made validation is designed to fix them. Determine if descriptions and requirements are accurate, complete, and correct. SOFT 423 Winter

19 Requirements Process SOFT 423 Winter

20 Design Process External Design (requirements) vs. Internal Design (design in software engineering) SOFT 423 Winter

21 Requirements Engineering Process [Bray] Existing System Information Stakeholder Needs Organizational Standards Regulations Domain Information Requirements Engineering Process Requirements Document System Specification HCI Specification SOFT 423 Winter

22 Requirements Engineering Process Don t forget the center oval contains much more detail! SOFT 423 Winter

23 Process Variability The processes will change from company to company, project to project, etc. This just part of the process. SOFT 423 Winter

24 Data Systems manipulate data This is part of an interaction with the environment usually. Problem Data vs. Solution Data SOFT 423 Winter

25 Modeling Data As part of the requirements process, there will be a need to model the data But we will come back to modeling later There will also be other models of the environment, be careful not to confuse the two. SOFT 423 Winter

26 Elicitation SOFT 423 Winter

27 Elicitation The first step! Gathering of information from many sources. Not simply knowledge transfer, more work is necessary. SOFT 423 Winter

28 Dimensions of Requirements Elicitation Application domain understanding Problem understanding Business understanding Understanding needs of stakeholders SOFT 423 Winter

29 Requirements Engineers Must Identify the problem / opportunity Which problem needs to be solved? (identify problem/boundaries) Where is the problem? (understand Context/Problem Domain) Whose problem is it? (Stakeholders) Why does it need solving? (Stakeholder Goals) How might a software system help? (collect some Scenarios) When does it need solving? (Constraints) What might prevent us solving it? (Feasibility/Risk) SOFT 423 Winter

30 Elicitation Difficulties Domain spread over many sources Tacit knowledge Limited observability Ignorance Bias SOFT 423 Winter

31 Elicitation Sources Clients Client specifications Documentation for pre-existing systems Users of pre-existing systems Potential Users of new system Predecessor Products Competitors Products Domain experts Documents for interfacing systems Standards and Legislation SOFT 423 Winter

32 Organization Techniques for Elicitation Partitioning Abstraction Projection SOFT 423 Winter

33 Elicitation Techniques Background Reading/Research Interview Questionnaires Use Cases/Scenarios Document Inspection Requirements Stripping Workshops/Brainstorming SOFT 423 Winter

34 Background Reading/Research Often forgotten, but equally important Preparation to make sure you understand problem domain before meeting with stakeholders SOFT 423 Winter

35 Interview Prominent technique Discussing with stakeholders directly Structured/Closed vs. Open SOFT 423 Winter

36 Questionnaires Used for large groups of stakeholders to quickly collect a lot of data Users! Set of questions feedback not always useful. SOFT 423 Winter

37 Document Inspection Look at existing system documents Help understand domain Help understand existing solutions SOFT 423 Winter

38 Requirements Stripping Looking at existing documents and stripping away what you don t need and using the useful nuggets SOFT 423 Winter

39 Use Cases/Scenarios Describe typical uses of the solution system Sequences of actions, who is involved, and other relevant information is created. Make sure you know the long form of use cases! SOFT 423 Winter

40 Use Case Diagrams Show the interaction/relationship between use cases Also includes actors SOFT 423 Winter

41 Requirements Reuse Reuse requirements whenever possible Why reinvent the wheel? Very informal process, but very useful! SOFT 423 Winter

42 Workshops/Brainstorming Groups of Stakeholders (min 7) discussing problem and solution. Workshops usually include brainstorming sessions. Workshops are short, but intense sessions. SOFT 423 Winter

43 Requirements Analysis Now we have all the info.now what? SOFT 423 Winter

44 Analysis Input: Elicitation Data Output: Back to elicitation for more data Requirements document A further understanding SOFT 423 Winter

45 Analysis More to come later! SOFT 423 Winter

46 Requirements Document More later, but we do have an introduction to the IEEE/ANSI Document Structure SOFT 423 Winter

47 Modeling Data & Analysis Approaches How do we deal with data requirements? SOFT 423 Winter

48 Modeling 3 Types of Models Iconic (sculpture) Analogical (model airplane) Analytical (mathematical equations) In general, a way of representing something in another form, particularly useful for data in the real world. SOFT 423 Winter

49 Modeling 3 Types of Models (according to Easterbrook): Natural Language Semi-Formal Formal SOFT 423 Winter

50 Analysis Approaches Structured Analysis Old, but still used Object Oriented Analysis Newer, and object based Problem Domain Oriented Analysis Based on the environment, or problem domain SOFT 423 Winter

51 Data Flow (Structured Analysis Technique) Concept that a system can be modeled as a set of interacting processes Diagrammatic notation Multiple levels SOFT 423 Winter

52 Other Structured Analysis Techniques Data Dictionaries Primitive Process Specification SOFT 423 Winter

53 Next Classes Monday Exam Review (Weeks 5-7) Wednesday Exam Review (Weeks 8-10) SOFT 423 Winter

Lecture 13: Requirements Analysis

Lecture 13: Requirements Analysis 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 Mars Polar Lander Launched 3 Jan