CMPT 275 Software Engineering

1. CMPT 275Software Engineering Requirements Gathering Activity

2. Overview of Requirements Analysis Requirements Specification Requirements Elicitation Functional requirements Functional model (scenarios) Analysis Non-Functional requirements Analysis Model System Design Dynamic model Static Model Analysis object model

3. Requirements Gathering/Specification Project Description Software Developer Client/User Informal Scenarios And / or use cases Questions Requirements Specification Document Iterative process of successive evaluation and refinement. Remember the user/client will only be available for a ‘small’ number of iterations

4. Initial Requirements • The initial specification of the requirements may be created by the end users or by the technical staff or be based on interviews • Independent of the source of the initial specification of the requirements it must be refined and verified to be correct and complete • What resources are available? • Are all users requests possible to implement with available resources? (scope is important) • Which requirements are most important? Less important? Even less important?

5. Understanding Client Needs • The first step is to understand what the system you will be building will do • A useful tool to help you understand this is the use of informal scenarios. • Based on information gathered from the client, tell stories of how the system will work from the clients point of view • From your point of view your are investigating WHAT the system will do

6. Example System • To help us explain some basic concepts let us consider a simple system • Student Registration System • Students may register in classes • Instructors may enter grades for classes • Instructors may view class lists • … What else?

7. Informal Scenarios • Read Project Description or Requirements provided by the client, or your notes about interviews with the client • Tell the story of one particular activity done by one particular user of the system • Purpose: • Help conceptualization • Help understanding • Brings to light any ambiguity, misunderstood or problematic aspects of software system as described by the client/users

8. Roles • Participants are people associated with the project (software system) • Client, developer, manager, end user • A set of related tasks that are assigned to a participant is a role • A student (role) is assigned a group of related tasks: registers in classes, receives grades • A teacher (role) is assigned a group of related tasks: gives classes, marks student work, gives grades

9. Actor • Entity outside the software system • interacts with the system • Operates on objects in the system but cannot be operated upon by objects in the system. • Human, hardware device, another software system • Represents coherent role played by users • e.g.: In an automated registration system teacher, student, registrations data base

10. Actor • A user of software system may take on more than 1 role, usually at different times • e.g.: Eva interacts with the system not only as a student actor but also as a teacher actor • Eva teaches math, but is a student of French • An actor may represent more than one user • e.g.: Both Eva and John may take the role of a student

11. Primary and Secondary Actors • Primary Actors • Actors who initiate a scenario (use case) causing the system to achieve a goal • automated registration system example the student or teacher is a primary actor • Secondary Actors • Actors supporting the system so primary users goals can be completed (do not initiate the use case or scenario) • automated registration system example the registration data base is a secondary actor

12. Primary and Secondary Actors • It is possible for an Actor to be a primary (initiating) actor in one scenario and a (non-initiating) or secondary actor in another scenario in the same system • For example in the automated registration system example • When Eva registers in a French class she is the primary actor (student) and the registration data base is the secondary actor. • Periodically the registration data base (primary actor) uses the registration data to print notifications of registration to be sent to students.

13. Informal Scenarios: Concrete Values • Tell the story of one particular activity. • Use concrete values to make the activity particular rather than generic • A concrete value gives a value for a specific person or thing in the system • A student registered in a course (generic) • John Smith registered in MATH 232 (concrete)

14. Examples of possible scenarios • Alan Smith, who is a student, will register in CMPT 333 • Jane Doe, an instructor, will obtain a copy of the class list for ENG 99 • Kev Wu, an instructor, will enter the final grades for all students in MATH 222 • Can you give some more examples?

15. Informal Scenario, first example Describe Scenario: Instructor Jane Doe wishes to obtain a copy of the class list for ENG 99 Current System State: • Initial state waiting for input. • System moves into initial state after an instructor logs into the system • Jane Doe is an instructor for ENG 99

16. Informal Scenario, first example Outline of informal Scenario: • Jane selects “generate class list” from the list of possible tasks displayed on the screen in the initial state • Jane enters the name of the class she wishes to generate a class list for and requests the list • The system displays the class list • Jane prints the class list • Jane indicates she is done Next Scenario: System returns to the initial state. Any scenario that begins in the initial state may be the next scenario

17. Another Example System: • Library management system (LMS) • This system is mean to keep track of present location of resources available in a library, (books and other items) and of all library users (patrons) and what they have presently borrowed from the library. It also records information about all library staff and all librarians

18. Example: Informal Scenarios • What are a few potential informal scenario’s for the LMS • Library student patron John returns a book “Training Your Dog” • Library faculty patron Sue reports a book “What I am missing” has been lost • Librarian Bob receives a shipment of 5 new books (“Birds v1” … “Birds v5”) and wishes to add them to the Library management system • Staff member Ellen requests a library card

19. Formulating Informal Scenarios • Should be short • Should address one activity • Should specify concrete values • May address some form of user error • Implementation/GUI details should be omitted • System state prior to initiation should be described • The next scenario (ending state) should be indicated

20. Informal Scenario, check out Describe Scenario: Student patron John wishes to check out a book “Calculus Fun” Current System State: • Initial state waiting for input. • System moves into initial state after Librarian logs into the system, or finishes an action • John is a valid student patron of the library

21. Informal Scenario, how to start Outline of informal Scenario: • Librarian enters John’s ID into the system • The system tells the librarian about John • The system says John can check out more books the Librarian enters information for “Calculus Fun” into the system • The system adds “Calculus Fun” to the list of items John has borrowed Next Scenario: System returns to the initial state

22. Importance: Current System State • The steps in the scenario outline, or the outcome of the informal scenario may change depending on the initial state of the system • Example: Assume a student library patron may borrow up to 16 books, then the example scenario will change according to how many books the patron has already borrowed (see next slide)

23. Importance: Current System State • Current System State: John has 10 books checked out • Informal Scenario as given on previous slide • Current System State: John has 16 books checked out • John has reached his borrowing limit, John cannot check out more books • A new scenario is needed to describe what happens

24. Alternate Informal Scenario Describe Scenario: Student patron John wishes to check out a book “Calculus Fun” Current System State: • Initial state waiting for input. • System moves into initial state after Librarian logs into the system • John, a student patron of the library, has already checked out 16 other books

25. Alternate Informal Scenario Outline of informal Scenario: • Librarian enters John’s ID into the system • The system tells the librarian about John • The system says John has reached his borrowing limit and cannot check out more books • The librarian tells John he cannot borrow more books Next Scenario: System returns to the initial state

26. Formulating Informal Scenarios • Should be short • Should address one activity • Should specify concrete values • May address some form of user error • Implementation/GUI details should be omitted • System state prior to initiation should be described • The next scenario (ending state) should be indicated

27. Specify Concrete Values • Why is it important to specify concrete values? • To understand how the system will respond to different types of situations, • To better understand the application domain, what values are important and how do they interact

28. Specify Concrete Values • Concrete values for our new example (book titles omitted for brevity) • John is a student library patron • Each patron has an ID, John’s ID is ? • John is trying to check out 9 books • John already has 4 books on loan from the library • One bookJohn has on loan is overdue • All books John wished to borrow are available for loan. • John has paid all previous library fines

29. Questions arising • Applying the concrete values to the outline of the informal scenario raises questions. • First need to know if John MAY check out all the books he has selected • How many books may a student check out at one time? • What is the form of the ID used by the library? • May a student patron check out more books if he has overdue material on loan? • May a student check out more books if he has outstanding library fines? • These are the types of questions that may need to be clarified in your discussions with the client. You can find these questions by using informal scenarios as a tool

30. Refining Scenarios • The answers to the questions arising from the specific concrete values describing our student patron John will give us more information • A student patron may borrow up to 16 books • Books cannot be borrowed if the patron has outstanding overdue charges • Books can be borrowed if the patron presently has overdue books • Books on reserve cannot be borrowed • We can then refine (add more detail, correct problems) our scenario

31. Informal Scenario Identify Scenario: Student Patron John wishes to check out nine specific books (titles omitted for brevity). All these books are available to be checked out (none are on reserve) Current System State: • Library management system initialized and waiting for input (initial state). • Student patron John has 4 books on loan, one of them is overdue. John owes no overdue charges

32. Informal Scenario Outline of Informal Scenario: • Librarian enters John’s ID into the system (12 digit number) • The system tells the librarian that John has four books on loan, that one of those books is overdue, and that no library fines are outstanding. • The system tells the librarian how many more books John can check out. (maximum 16- 4, maximum 0 if old fines unpaid) John can check out up to 12 books.

33. Informal Scenario • Outline of Informal Scenario (continued): • The Librarian enters information for each book that John can to borrow into the system • Those books are added to the list of items John has borrowed • Next Scenario: • System returns to the initial state

34. Formulating Informal Scenarios • Should be short • Should address one activity • Should specify concrete values • May address some form of user error • Implementation/GUI details should be omitted • System state prior to initiation should be described • The next scenario (ending state) should be indicated

35. Importance of Next Scenario • When all steps in the outline of the informal scenario have been completed • What can happen next? • What is the state of the system? • In what state does the completed scenario leave the system? • The Final state of the system, after the present scenario has been completed, becomes the current state of the system at the start of the next scenario • To know what the system can do next we need to know the state the system is in when the present scenario is completed