CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae

Size: px

Start display at page:

Download "CS350 Lecture 2 Requirements Engineering. Doo-Hwan Bae"

Dominic Spencer
5 years ago
Views:

1 CS350 Lecture 2 Requirements Engineering Doo-Hwan Bae bae@se.kaist.ac.kr

2 Contents Overview of Requirements Engineering OO Analysis: Domain modeling, Use-case, sequence, class Structured Analysis: Dataflow diagraming Finite State Machines: State transition diagraming Petri-Nets: control/operational CS350 Software Engineering, SoC, KAIST 2

3 Importance of Requirements (1/2) Problem: Sorting a given list of numbers in ascending order. In order to solve it, answer the following questions Is the given problem statement sufficient to develop a program? If not, what additional information do we need to know? CS350 Software Engineering, SoC, KAIST 3

4 Importance of Requirements (2/2) in SW Development Projects Some advices from industry practitioners Do not make assumptions as to the user/customer s needs, ask them. Involve the end users as soon as possible, get in touch with the actual people that will be using the software on a daily basis, they are the ones that truly understand what Is needed. Scope creep is major issue in most project, especially custom development. A clear and defined scope is going to save a lot of headaches for all involved in the long run. A great way to show a customer what you envision is with a prototype. A well written, clear and easy to follow documentation of the requirements is essential and before they sign off, go over it with the customer It is important to understand the environment in which the software will run CS350 Software Engineering, SoC, KAIST 4

5 Requirements Engineering Overview (1/7) Must state what to do, not how to do. Identify the qualities required for the application. Functional and nonfunctional Used by both customer and designers CS350 Software Engineering, SoC, KAIST 5

6 Requirements Engineering Overview(2/7) Three steps in RE Requirements Elicitation (gathering and analysis) -- understand/analyze the problem Requirements Specification -- Once the problem is understood, it has to be specified -- Or, describe the product to be delivered -- Informal and formal methods, used. Requirements validation and verification -- Once described, the different parties involved have to agree upon its nature. -- Validation: the correct R s are stated. -- Verification: The R s are stated correctly CS350 Software Engineering, SoC, KAIST 6

7 Requirements Engineering Overview(3/7) Group User R s into several categories (MoSCoW) - Must haves: Essential features - Should haves: Nice features - Could haves: if time allows - Won t haves: not today CS350 Software Engineering, SoC, KAIST 7

8 Requirements Engineering Overview(4/7) Separate functional requirements into three views: A model of data/static structure: Entity relationship diagrams, domain model (class diagram) A model of function: Data flow diagrams, use case diagram A model of control: Control flow diagrams, State Machines, Petri nets, sequence diagram CS350 Software Engineering, SoC, KAIST 8

9 Requirements Engineering Overview(5/7) Other Requirements - Which machine, which OS, which DBMS, terminal? - Which classes of users can be distinguished? - What is the size of the DB, how is it expected to grow? - What response time should the system offer? - How much will a system of this kind cost? CS350 Software Engineering, SoC, KAIST 9

10 Requirements Engineering Overview(6/7) Seven Deadly Sins Noise Irrelevant information Confusing presentation Silence Omissions Over-specification Premature implementation decisions Contradiction Inconsistency Ambiguity Forward reference Wishful thinking CS350 Software Engineering, SoC, KAIST 10

11 Requirements Engineering Overview(7/7) Specification Qualities Clear, unambiguous, understandable Consistent Complete Functional Verifiable Traceable Easily changed CS350 Software Engineering, SoC, KAIST 11

12 Specification Methods Representative methods: OO Analysis: object-oriented Domain/Class,, Use-case, Sequence diagram Structured Analysis: Dataflow diagram, Data dictionary Finite State Machines: State transition diagram Petri-Nets: CS350 Software Engineering, SoC, KAIST 12

13 Domain Modeling Why? The goal of domain modeling is to understand how system-tobe will work Requirements analysis determined how users will interact with system-to-be (external behavior) Domain modeling determines how elements of system-to-be interact (internal behavior) to produce the external behavior Where? We do domain modeling based on the following sources: Knowledge of how system-to-be is supposed to behave (from requirements analysis, e.g., use cases) Studying the work domain (or, problem domain) Knowledge base of software designs Developer s past experience with software design CS350 Software Engineering, SoC, KAIST 13

14 Domain Modeling What? Illustrates meaningful conceptual classes in a problem domain Is a representation of real-world concepts, not software artifacts Is the most important objects/classes in OO development Decompose the system into a set of objects, rather than functions! How? Identify nouns and noun phrases in textual descriptions of the domain Use use cases in use-case diagrams Add associations for relationships that must be retained Add attributes necessary for information to be preserved CS350 Software Engineering, SoC, KAIST 14

15 Conceptual Class vs. Software Artifacts CS350 Software Engineering, SoC, KAIST 15

16 Use Case Analysis vs. Domain Analysis In use case analysis, we consider the system as a black box In domain analysis, we consider the system as a transparent box (a) (b) System Domain Model Use Case 1 Use Case 2 Actor Use Case N Actors Actor Actors CS350 Software Engineering, SoC, KAIST 16

17 Example: ATM Machine System (b) Domain Model Concept 1 Concept Actor (Bank customer) (ATM machine) Actor (Remote datacenter) Actor Concept 2 Concept n (a) Actor CS350 Software Engineering, SoC, KAIST 17

18 Building Domain Model from Use Cases Step 1: Identifying the boundary concepts Boundary concepts Concept 3 Concept 1 Actor C Actor A Step 2: Identifying the internal concepts Actor B Concept 2 Concept 4 Actor D Concept 3 Actor A Concept 1 Concept 5 Concept 6 Actor C Actor B Concept 2 Internal concepts Concept 4 Actor D CS350 Software Engineering, SoC, KAIST 18

19 Initial ATM Requirements ( Problem ) A customer uses a bank ATM for checking balances of bank accounts, depositing funds, withdrawing cashes, and transferring funds. A bank ATM consists of a keypad, screen, cash dispenser, ATM card reader, cash deposit slot. A user can have a checking account and saving account. A customer enters his/her card and password for authentication and then choose a transaction to be executed. After the transaction is over, the ATM returns the card and receipt, and stores the transaction for bookkeeping. Once the request from the ATM is passed, the bank checks the account and process a requested transaction and update the account CS350 Software Engineering, SoC, KAIST 19

20 Identify Use Cases Identify actors first Actor: a person/thing that initiate actions to a system or receives results of actions from the system Use cases are Why the customer goes to the ATM? Find action terms from the initial requirements Check balances Deposit funds Withdraw cashes Transfer funds Enters card/password Authenticate Choose a transaction Return a card.. Check, process, update CS350 Software Engineering, SoC, KAIST 20

21 Use Case Diagram for ATM Let us try Identify actors, use cases, system boundary CS350 Software Engineering, SoC, KAIST 21

22 Top-level Use Cases CS350 Software Engineering, SoC, KAIST 22

23 Identify the classes Identify all the nouns or noun phrases. Customer, bank, ATM, (bank) account, funds, cash, keypad, screen, cash dispenser, cash deposit slot, user, checking account, saving account, card, password, transaction, receipt, bookkeeping, request. Eliminate redundant, irrelevant, implementation constructs, attributes, etc CS350 Software Engineering, SoC, KAIST 23

24 Initial Class Diagram (Domain Model) Objects: ATM, Keypad, Deposit slot, Cash dispenser, Screen, Transaction, Bank, Account, Customer Draw a class diagram with only classes and relationships CS350 Software Engineering, SoC, KAIST 24

25 Domain Model for an ATM & Bank CS350 Software Engineering, SoC, KAIST 25

26 Domain Model for an ATM & Bank ATM in Bank Consortium CS350 Software Engineering, SoC, KAIST 26

27 Refined Class D CS350 Software Engineering, SoC, KAIST 27

28 High Level Sequence Diagram You can have more SDs CS350 Software Engineering, SoC, KAIST 28

29 Refining Diagrams Now we have Use case diagram Initial class diagram (domain diagram) Sequence diagram Once, the initial requirements analysis/specification is over, refining those diagrams until.. Then, verify the results Also, identify Non-functional requirements CS350 Software Engineering, SoC, KAIST 29

30 Structured Analysis Consists of -- Data Flow Diagram -- Data Dictionary -- Process Specification CS350 Software Engineering, SoC, KAIST 30

31 Data Flow Diagram For business data processing, where control aspects may not play significant role. Components Function, or action: Data store: External entity: Data flow: Conceptual Example: (a + b) * ( c + a * d) b + a * d c * CS350 Software Engineering, SoC, KAIST 31

32 Data Flow Diagram(Cont.) Example: Automatic Teller Machine(ATM) CS350 Software Engineering, SoC, KAIST 32

33 Data Flow Diagram (Cont.) Drawback: Cannot give a precise and detailed definition. Cannot simulate the system with DFDs. Extensions Integrate with different description, i.e., STD Augment DFD with control flow, Ward&Mellor Revise DFD, to make it fully formal CS350 Software Engineering, SoC, KAIST 33

34 Data Dictionary(1/2) Contains formal definitions of all the data items shown in DFD Provides precise detail concerning the data entities Format -- Alphabetically ordered list of entries -- Consists of formal definitions and verbal descriptions Notations: data-element-name = expression + : concatenation : alternatives : literals [ ] : options { } : repetitions CS350 Software Engineering, SoC, KAIST 34

35 Data Dictionary(2/2) Example 1 Payment = US-dollars Korean-Wons US-dollars = $ + dollar-amt +. + cent-amt * Payment is the income received from subscribers. It is entered as dollars and cents. Korean-Wons = w +.. dollar-amt = {digit} cent-amt = digit + digit digit = CS350 Software Engineering, SoC, KAIST 35

36 Finite State Machine (FSM) (1/3) Emphasize control aspects of the application. Components A finite set of states A finite set of input A transition function CS350 Software Engineering, SoC, KAIST 36

37 FSM (2/3) Example: Producer/Consumer problem. write producer P1 produce P2 consumer C1 consume read C2 buffer 0 read 1 read 2 write write CS350 Software Engineering, SoC, KAIST 37

38 FSM (3/3) Drawback; Computation power is limited. (Not easy to specify data info.) The cardinality of the state space growth Difficult to specify asynchronous activities CS350 Software Engineering, SoC, KAIST 38

39 Petri Net (1/4) Specify asynchronous systems Components A finite set of places: A finite set of transitions: A finite set of arrows: from places to transitions, from transitions to places. Tokens CS350 Software Engineering, SoC, KAIST 39

40 Petri Net (2/4) Example: Producer/Consumer problem. write P1 C1 produce consume read P2 C2 read read CS350 Software Engineering, SoC, KAIST 40 write write

41 Petri Net (3/4) Modeling examples Finite state machines. Parallel activities. Data flow computations. Communication protocols. Synchronous control. Producer-consumer problem with priority. Formal languages CS350 Software Engineering, SoC, KAIST 41

42 Petri Net (4/4) Drawback: Too simple to specify complex systems. Not possible to specify a selection policy. Timing issues for real-time systems. Extensions: Assigning values to tokens. Specifying scheduling policies. Incorporate timing constraints CS350 Software Engineering, SoC, KAIST 42

43 Nonfunctional Requirements User interface & human factors Documentation Hardware consideration Performance characterization System interfacing Quality issues System modification Physical environments Security issues Resources and management issues CS350 Software Engineering, SoC, KAIST 43

44 Summary Remember that in the real world, no one will give you the exact, complete, consistent, and unambiguous requirements for software development. Also requirements document will be used as a contract Requirements changes are inevitable. Be prepared! In addition to functional requirements, nonfunctional requirements are also important for value-added software development CS350 Software Engineering, SoC, KAIST 44

45 Exercise Try the following case study and examples CS350 Software Engineering, SoC, KAIST 45

46 Requirements Engineering: Case Study(1/4) University s library want to automate its operations by SW. Start with the library containing a number of cabinets, each holds a huge number of cards, one per book. Each card contains the names of the authors, the book title, ISBN, publication year, etc.. The cards are ordered alphabetically by the name of the first author of each book. Starting with the above statements, you are expected to specify its requirements CS350 Software Engineering, SoC Fall

47 Requirements Engineering: Case Study(2/4) What are the ambiguities, here? It only works well if we know the first author s name. Solution to it: -- Duplicating each card a number of times -- Use database During Requirements Analysis, a number of user R s can be raised: - Adding, deleting, and changing records - Give a list of all books written by X - Give a list of all books whose title contains Y - Give a list of all books on topic Z - Give a list of all books that arrived after date D CS350 Software Engineering, SoC Fall

48 Requirements Engineering: Case Study(3/4) Predict a number of future requirements Storing information about the books that have been ordered but have not been received. Storing information about the library members, such as their names and addresses, and the dates on which books are lent to them Library management may wish to use the system to get information on member profiles in order to improve the title acquisition process CS350 Software Engineering, SoC Fall

49 Requirements Engineering: Case Study(4/4) Other Requirements Which machine, which OS, which DBMS, terminal? Which classes of users can be distinguished? What is the size of the DB, how is it expected to grow? What response time should the system offer? How much will a system of this kind cost? CS350 Software Engineering, SoC Fall

50 Examples: Wrong Specifications(1/2) Example: "select" command in word processing. ``Selecting is the process for designating areas of your document that you want to work on. Most editing and formatting actions require two steps:first you select what you want to work on, such as text or graphics, then you initiate the appropriate." Q: What are ambiguous? Example: Space shuttle monitoring system ``The message must be triplicated. The three copies must be forwarded through three different physical channels. The receiver accepts the message on the basis of a two-out-ofthree voting policy." Q: What is not clear? CS350 Software Engineering, SoC, KAIST 50

51 Examples: Wrong Specification(2/2) Example: A text editor ``The whole text should be kept in lines of equal length, with the length specified by the user. Unless the user is given an explicit hyper-nation command, a carriage return should occur only at the end of a word." Q: What is inconsistent? CS350 Software Engineering, SoC, KAIST 51

Introduction to Software Specifications and Data Flow Diagrams. Neelam Gupta The University of Arizona

Introduction to Software Specifications and Data Flow Diagrams Neelam Gupta The University of Arizona Specification A broad term that means definition Used at different stages of software development for