1 / 24

IS550: Software requirements engineering

IS550: Software requirements engineering. 4. Functional details. Dr. Azeddine Chikh. Text. Soren Lauesen, "Software Requirements: Styles & Techniques" Addison-Wesley Professional 2002,  608 pp, ISBN-10: 0201745704 - ISBN-13: 9780201745702. 0. Introduction.

medmond
Download Presentation

IS550: Software requirements engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IS550: Software requirements engineering • 4. Functional details Dr. Azeddine Chikh

  2. Text Soren Lauesen, "Software Requirements: Styles & Techniques"Addison-Wesley Professional 2002,  608 pp, ISBN-10: 0201745704 - ISBN-13: 9780201745702

  3. 0. Introduction • The first styles are best suited for discussions with expert users, while the later styles mainly are for IT professionals. • UML Unified Modeling Language is a standard notation introduced by object-oriented schools.

  4. 1. Complex and simple functions • Highlights • Ignore trivial functions • Describe semi-complex domain functions in requirements • Describe semi-complex product functions as part of design • Specify complex functions by performance or standards

  5. 1. Complex and simple functions Domain obvious FindFreeRoom PrintInvoice Checkin if booked if non-booked if add room Fastest truck route Voice recognition? Domain non-obvious Discount calculation Business rules Tax calculation Payroll Optimize roster Voice recognition? Simple program Interaction complexity Hard to program Possible requirement styles: A. (Leave to intuition) B. Natural language or tables C. Process description (algorithm) D. Performance specification E. Refer to laws and agreements Suitable choices?

  6. 2. Tables and decision tables • What is it ? • Tables listing all the possibilities • Easy to validate • Easy to verify for user as well as developer • Suited for business rules

  7. 2. Tables and decision tables R1. The product shall suggest the following discount rates if a customer asks for discount: 1. Double room used as single 25% 2. Family with more than one room, discount for additional rooms 10% 3. Discount at immediate checkin: 3a. Before 6pm and hotel less than 50% booked, fair weather 25% 3b. Before 6 pm and hotel less than 50% booked, bad weather 0% Case 1 and 2 cannot apply in the same stay. R2. Managers shall be able to change the rates Business rules, informal table

  8. 2. Tables and decision tables R1. The product shall suggest the following discount rates if the customer asks for discount: 1. Dble room used as single Y N Y 2. Family, additional rooms N Y Y 3. Immediate checkin Y Y 4. Before 6 pm Y Y 5. Less 50% booked Y Y 6. Fair weather N Y a. Room discount 25% v ? b. Room discount 10% v c. Early discount 25% v d. Early discount 0% v e. Error v R2. Managers shall be able to change the rates and the rules Business rules, decision table

  9. 3. Textual process descriptions • What is it ? • Outline of the program (the algorithm) in text form • Sometimes called mini-specs or pseudo-code • The only way to provide fine detail. • Useful for design-level requirements, e.g. buttons in prototypes. • Sometimes useful for business rules

  10. 3. Textual process descriptions The product shall provide the following functions: 1.1 FindFreeRoom (type, period) List rooms of the requested type that are free in the period requested. Allow the user to select some of them as CurrentRooms in the requested period. 1.2 CreateNewStay (partial guest data, guest record) Create a temporary CurrentStay. If guest record exists then fill CurrentStay with recorded guest data else fill CurrentStay with partial guest data. Note: The product should look for similar records too. 1.3 Checkin (CurrentStay, CurrentRooms) If CurrentStay is booked, record rooms in stay as occupied. If CurrentStay is not recorded, check CurrentRooms free. If guest not recorded, check guest data complete, record guest. record CurrentRooms as occupied, record stay. If . . . Process description, pseudo-code

  11. 4. State diagrams • What is it ? • Diagrams showing how something changes from one state to another • Good for finding missing or obscure functions • Can model things in the domain as well as in the product • Use it only for complex life cycles

  12. 4. State diagrams cancel create repair done ? Rooms have a RoomState for each day in the planning period. The status shows whether the room is free, occupied, etc. that day. R12: RoomState shall change as shown in Fig. 12. Fig. 12. RoomState free booked book checkout changeRoom checkin changeRoom checkin repair occupied event

  13. 5. State-transition Matrices • What is it ? • Tables showing how something reacts in all possible cases • Better than state diagrams for finding missing or obscure functions • Use it only for complex life cycles

  14. 5. State-transition Matrices

  15. 6. Activity diagrams • What is it ? • A diagram showing the flow of control and the flow of data (objects) • Handles concurrency and synchronization • Good for analysis • Useful as requirements for workflow applications

  16. 6. Activity diagrams Activity diagram, workflow

  17. 6. Activity diagrams Fork and join

  18. 7. Class diagrams • What is it ? • A data model where entities have data and can perform something • For users, even harder to understand than data models • Widely used – even when unsuccessful • Useful as requirements for some technical systems • Not suitable as requirements for business applications

  19. 7. Class diagrams Class name Guest name address passport book . . . Association = relationship Operations 1 Service date count set . . . get . . . 0..* ServiceType name price set . . . 0..* 0..* 1 Stay stay# paymethod checkout recordService printConfirm 1 Program: curRoomState.setState(occupied) Room State date #persons state setState getState set . . . 0..1 1..* 0..* 1 Room . . . UML Class Diagram

  20. Guest name ... set ... Stay stay# ... set ... Room date ... set ... Service (empty) checkout book ... Observe (empty) update Stay window Display attr. Update 7. Class diagrams SQL-driven database Data objects (trivial functions) Service and Observer functions (little data) User interface objects (GUI) Rooms window Display attr. Update OO Business Application

  21. 8. Collaboration diagram • What is it ? • A box diagram of how objects call each other • Good for describing the internal working of the product • Sometimes useful for intermediate work products • Rarely useful as requirements

  22. 8. Collaboration diagram 1: checkOut 1.1: * get- Service 1.1.1: get- ServicePrice Service Type Stay Service 1.2: * getRoom Room State 1.2.1: getRoomPrice Room

  23. 9. Sequence diagrams, events, and messages • What is it ? • Time diagram of how objects communicate • Good for describing simple communication protocols • Useful as intermediate work products • Useful as design-level requirements for technical interfaces

  24. 9. Sequence diagrams, events, and messages User Product FindRooms free rooms Event + message + reply SelectRoom Event + asynchronous message Product Account system Transfer OK Event + message + reply Data 1 Message + reply OK Data 2 Message + reply OK Done Sequence diagram Asynchronous message

More Related