SYS366

1. SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering: Part 2 – The Stakeholders’ Needs

2. Today • Stakeholders • Identifying System Requirements • Functional Requirements • Technical Requirements • Data Requirements • Fact Finding Methods • Interview Questions • WP1

3. Categories of Stakeholders • Five primary categories • Users • Sponsors • Developers • Authorities • Customers

4. Questions to Ask to Determine Stakeholders: • Who will be affected by the success or failure of the new solution? • Who are the users of the system? • Who is the economic buyer for the system? • Who is the sponsor of the development? * * Use Case Modeling, by Bittner & Spence, page 63.

5. Questions to Ask to Determine Stakeholders: • Who else will be affected by the outputs that the system produces? • Who will evaluate and sign off on the system when it is delivered and deployed? • Are there any other internal or external users of the system whose needs must be addressed? * * Use Case Modeling, by Bittner & Spence, page 63.

6. Questions to Ask to Determine Stakeholders: • Are there any regulatory bodies or standards organizations to which the system must comply? • Who will develop the system? • Who will install and maintain the new system? • Who will support and supply training for the new system? • Who will test and certify the new system? * * Use Case Modeling, by Bittner & Spence, pages 63 - 64.

7. Questions to Ask to Determine Stakeholders: • Who will sell and market the new system? • Is there anyone else? • Okay, Is there anyone else? * * Use Case Modeling, by Bittner & Spence, page 64.

8. Back to In-class exercise 5 • Using In-class exercise 4 and the list of business processes for your area, update In-class exercise 5 to include more stakeholders

9. Today • Stakeholders • Identifying System Requirements • Functional Requirements • Technical Requirements • Data Requirements • Fact Finding Methods • Interview Questions • WP1

10. Identifying System Requirements • Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system

12. Identifying System Requirements • “A requirement is a desired feature, property or behavior of a system.” * * Unified Modeling Language

13. Identifying System Requirements • A requirement “is either derived directly from stakeholder or user needs Or stated in a contract, standard, specification, or other formally imposed document.” * * Use Case Modeling, by Bittner & Spence, page 5.

14. Identifying System Requirements • Stakeholder Need: • A reflection of the business, personal or operational problem…that must be addressed to justify consideration, purchase or use of the new system. * * Use Case Modeling, by Bittner & Spence, page 72.

15. Identifying System Requirements • Capturing stakeholder needs allows us to understand how and to what extent the different aspects of the problem affect different [categories] of stakeholders. * * Use Case Modeling, by Bittner & Spence, page 72.

16. Identifying System Requirements • Stakeholder needs are an expression of the true ‘business requirements’ of the system * * Use Case Modeling, by Bittner & Spence, page 72.

17. Stakeholders’ Needs • Back to In-class Exercise 5 to identify Stakeholders’ needs!

18. Identifying System Requirements • Features: • “Informal statements of capabilities of the system used often for marketing and product-positioning purposes as a shorthand for a set of behaviors of the system.” Use Case Modeling, by Bittner & Spence, pages 5 - 6.

19. Identifying System Requirements • Features: • “The high-level capabilities (services or qualities) of the system that are necessary to deliver benefits to the users and that help to fulfill the stakeholders and user needs.” * * Use Case Modeling, by Bittner & Spence, page 74.

20. Identifying System Requirements “Features can be functional or non-functional.” * * Use Case Modeling, by Bittner & Spence, page 75.

21. Identifying System Requirements “Features represent some area of functionality of the system that, at this time, is important to the users of the system” * * Use Case Modeling, by Bittner & Spence, page 75.

22. Identifying System Requirements “The immediate and informal nature of features makes them a very powerful tool when working with the stakeholders and customers in defining what they want from a system’s release.” * * Use Case Modeling, by Bittner & Spence, page 76.

23. Identifying System Requirements “Features provide the fundamental basis for product definition and scope management” * * Use Case Modeling, by Bittner & Spence, page 76.

24. Identifying System Requirements • Software Requirements • “Individual statements of conditions and capabilities to which the system must conform.” Use Case Modeling, by Bittner & Spence, page 5. • Page 6

25. Identifying System Requirements • Each Software Requirement Is the specification of an externally observable behavior of the system • Inputs to the system • Outputs from the system • The processing of the system • Attributes of the system • Attributes of the system environment Use Case Modeling, by Bittner & Spence, page 5. Page 6

26. Identifying System Requirements • Software Requirements specify the things that the software does on behalf of the user or another system. Use Case Modeling, by Bittner & Spence, page 5. • Page 6

27. Successful Project Requirements • Detailed plans • Organized, methodical sequence of tasks and activities

28. Requirements Gathering • Analyst needs to find out what the user requires in the new system or what the user requires to be changed in an existing system • Gather the requirements by doing fact finding • Document the requirements

29. Requirements Gathering • For an existing system, analyst needs to find out: • Functionality • Some of the functionality of the existing system will be included in the new system (can be acquired from existing documentation and code) • Data needs • Some of the data of the existing system will need to be migrated into the new system

30. Requirements Gathering • For a new system, analyst needs to find out: • Functionality • What are the activities the system needs to perform? • How is the user to interact with the system? • Are other systems to interact with the system? • Data needs • What information is needed?

31. Requirements Gathering Scope of the System Functional Technical Data Requirements Requirements Requirements

32. Functional Requirements • Describe what a system does or is expected to do • Include: • Descriptions of the processing which the system will be required to carry out

33. Functional Requirements • Include: • Details of the inputs into the system from paper forms and documents or the interactions between people and the system or transfers from other systems • Details of the outputs that are expected from the system in the form of printed documents and reports, screen displays and transfers to other systems

34. Technical Requirements • Describe the aspects of the system that are concerned with how well it provides the functional requirements. • Include: • Performance criteria • Anticipated volumes of data • Security requirements (let’s talk about the Bank of Montreal!)

35. Data Requirements • Describe what information the system is going to need or produce – really a part of Functional and Technical Requirements • Include • Details of the data that must be held in the system

36. Themes To Guide Investigation • What are business processes and operations? • How should the business processes be performed? • What are the information requirements? Understand the Users’ Needs!

37. Today • Stakeholders • Identifying System Requirements • Functional Requirements • Technical Requirements • Data Requirements • Fact Finding Methods • Interview Questions • WP1

38. Fact Finding Methods • Conduct interviews and discussion with users • Distribute and collect stakeholder questionnaires • Review existing reports, forms, and procedure descriptions • Observe business processes and workflows • Build prototypes • Conduct JAD sessions

39. Fact Finding Methods • Interviews • Questionnaires • Review Documentation • Observation • Prototypes • JAD sessions • RAD

40. Interviews • Primary technique for fact finding and information gathering • Most effective way to understand business functions and business rules • Usually requires multiple sessions • Usually conducted with customers/clients/users • Clients are not always able to express their requirements clearly  it is up to the analyst to ask the right questions to help the client express their requirements

41. Interviews • We are going to concentrate on interview techniques; the rest of the slides explain the other methods for fact finding

42. Conducting effective interviews • Determine who you are going to interview • Know what information that stakeholder can provide for you • Prepare for the interview • Conduct the interview • Follow up on the interview

43. Determine who you are going to interview • Can be business or technical stakeholders • Business stakeholders provide the functional and data requirements • Technical stakeholders provide the technical and data requirements

44. Determine who you are going to interview • Stakeholders • Executives • Will provide information related to strategic issues about the business • Need statistical and summary information • Management • Will provide a broad perspective about the business as well as information about the system being developed • Need statistical and summary information

45. Determine who you are going to interview • Stakeholders • Operational staff will provide information about how the work is actually done

46. Prepare for the interview • Structured Interview • Formal style • Requires significant preparation • Unstructured Interview • Informal • No pre-determined questions or objectives

47. Structured Interview • Preparing for the interview • Establish the objectives for the interview • Have a clear agenda • Prepared in advance with a list of open and closed ended questions • Set the time and location for the interview • Inform all participants of the objective, time and location

48. Structured Interview • Questions • Questions should allow you to keep on track and avoid getting off topic during the interview • Questions can be prepared from any of the following: • Observations made when existing form and reports may have been reviewed • Observations made when reviewing the strategic, tactical or operational plans • Observations made when observing employees doing current job tasks • Keep length of questions reasonable (15-20 words or less)

49. Structured Interview • Questions • Phrase questions to avoid misunderstandings - use simple terms and wording • Do not ask questions that give clues to expected answers • Avoid asking two questions in one • Do not ask questions that can raise concerns about job security or other negative issues

50. Structured Interview • Questioning Strategies Top Down How can order processing be improved? How can we reduce the number of times that customers return items they’ve ordered? How can we eliminate shipping the wrong products? High-level: very general Medium-level: moderately specific Bottom UP Low-level: very specific