Collecting user requirements Introduction to data flow modeling

1. Collecting user requirementsIntroduction to data flow modeling BCIS 4610 BCIS 4610, Fall 2008

2. Agenda • Project proposal discussion • Project scheduling with network diagrams • Collecting user requirements • Introduction to requirements analysis

3. Project Proposals • Follow the • Collect background information • Create a convincing proposal • Be creative • Make it look professional • For grading purposes, the quality of the document matters most! BCIS 4610, Fall 2008

4. Resource Rate Table BCIS 4610, Fall 2008

5. Creating a budget in Excel BCIS 4610, Fall 2008

6. Creating a budget in MS Project • Enter tasks • Enter resources (names, rates and availability) • Assign resources to tasks • View Resource Usage and Resource Graph to make adjustments BCIS 4610, Fall 2008

7. Collecting user requirements BCIS 4610, Fall 2008 • What are the requirements • What are the methods for collecting requirements • Interviews • Questionnaires • Document analysis • Observations • Other

8. System Requirements Determination BCIS 4610, Fall 2008

9. What are system requirements • Requirement is a statement of what the system must do and what characteristics it must have • “What” of the system • During analysis – businessperson’s perspective • During design – translated into developer’s perspective • Evolve over the course of the project • Go from the overall goal of the systems to detailed specifications BCIS 4610, Fall 2008

10. What are system requirements • Functional requirements – relate directly to a process the system has to perform or information it needs to contain • Non-functional requirements – refer to the behavioral properties of the systems, such as usability and performance • User interface • Hardware and software • Integration capabilities • Security BCIS 4610, Fall 2008

11. Understanding user requirements • Sponsors of the system - understanding the goal of the system • Process owners and functional experts – understanding the functional requirements • End-users – understanding user interface needs • IT people – understanding how the system fits into the overall IT architecture BCIS 4610, Fall 2008

12. Other sources of information • Enterprise data model – if it exists • Process maps – if they exist • Old system and system documentation • Reports currently used • Paper and electronic forms • Other organizational documentation BCIS 4610, Fall 2008

13. Collecting user requirements includes • Requirements planning and management • Understand team roles for the project • Define business analyst work division strategy • Define requirements risk approach • Determine planning considerations • Select requirements activities • Estimate requirements activities • Manage requirements scope • Measure and report on requirements activity • Manage requirements change • Requirements elicitation BCIS 4610, Fall 2008

14. REQUIREMENTS PLANNING AND MANAGEMENT The goals of requirements planning and management is to ensure that: • All necessary stakeholders are identified and properly represented during the requirements gathering process. • The most appropriate activities related to the requirements process are performed, given the project circumstances. • The requirements work effort is coordinated with other work done on the project. • The requirements team has a common understanding of the activities they will perform. • The BA or BA team can effectively monitor and react to requirements challenges and slippage. • The tools, resources, and requirements contributors are available when • requirements activities are scheduled. • Changes are captured correctly and consistently. BCIS 4610, Fall 2008

15. REQUIREMENTS Planning and management The key outcomes include: • List of project team members assigned to the project and team member roles • List of stakeholders and their relationship to the project • List of requirements gathering tasks and division of work • Tool(s) used to gather and communicate requirements. BCIS 4610, Fall 2008

16. TYPICAL PROJECT ROLES • Executive Sponsor • Business Analyst • Project Manager • Developer • Quality Assurance Analyst • Trainer • Application Architect • Data Modeler • Database Analyst (DBA) • Infrastructure Analyst • Information Architect • Solution Owner • End User • Subject Matter Expert (SME) • Stakeholders BCIS 4610, Fall 2008

17. Defning requirements risk approach Some examples of common requirements risks are: • Insufficient level of user involvement in identifying, detailed, and analyzing requirements • Ambiguous requirements. Not enough detail in the specification of the requirements. • Missing, incorrect, and conflicting requirements • Lack of requirements management and planning, such as requirements change control BCIS 4610, Fall 2008

18. Requirements ELICITATION BCIS 4610, Fall 2008

19. REQUIREMENTs Elicitation Techniques • Brainstorming • Document Analysis (Review existing documentation) • Focus Group • Interface Analysis (External Interface Analysis) • Interview • Observation (Job Shadowing) • Prototyping (Storyboarding, Navigation Flow) • Requirements Workshop (Elicitation Workshop) • Facilitated Workshop • Joint Application Design (JAD) • Reverse Engineering • Survey Questionnaire BCIS 4610, Fall 2008

20. Interview Guidelines • Plan • Checklist • Appointment • Gather facts, opinions and speculations • Be neutral • Listen • Observe body language and emotions • Seek a diverse view • TAKE NOTES! BCIS 4610, Fall 2008

21. Interview questions • Types of questions • Open-Ended • Close-Ended • Probing • Level of details • Very general – “How can order processing be improved?” • Moderately specific – “ How can we reduce the number of times that customers return items • Very specific – “How can we reduce the number of errors in order processing?” BCIS 4610, Fall 2008

22. Determining Requirements: Questionnaires • Design • Mostly closed-ended questions • Can be administered over the mail, Web, phone or in person • Vs. Interviews • Interviews cost more but yield more information • Questionnaires are more cost-effective • Choosing respondents • Should be representative of all users BCIS 4610, Fall 2008

23. Determining Requirements: Observations • Serves as a good method to supplement interviews • Time consuming • Often difficult to obtain unbiased data • People often work differently when being observed BCIS 4610, Fall 2008

24. Analyzing Procedures and Other Documents • Types of information to be discovered: • Rules for processing data • Special information processing circumstances • Values of organization • Organizational direction • Names of key individuals • Problems with existing system • Opportunity to meet new need BCIS 4610, Fall 2008

25. Determining Requirements: JAD and Prototyping • Focus group • Brainstorming BCIS 4610, Fall 2008

26. Agile usage-centered design method • Gather a variety of users and developers • Let them vent about problems (record) • Determine key user roles and goals • Determine tasks for each role • Group tasks • Write task descriptions • Sketch user interface for each task group • Go through each user role on paper BCIS 4610, Fall 2008

27. Deliverables and Outcomes • Transcripts of Interviews • Notes from observations and analysis of documents • Analyzed responses from surveys • Prototypes • Results of JAD and Agile Usage-centered design sessions • Use-case descriptions – more recently BCIS 4610, Fall 2008

28. Next step – analyzing user requirements • Functional • Recording system requirements through use-cases and use-case diagrams • Process and functional modeling with DFDs and Activity diagrams • Data and structural modeling with ERDs and Class diagrams • Non-functional • Interface design and prototypes • Physical design constraints BCIS 4610, Fall 2008

29. In-Class Exercise • Get together with your group members • Create a plan for system requirements collection: • - What methods would you use? • - Create a timeline • Come up with 2-3 closed-end and 2-3 open-ended questions that you would like to potential users of your proposed system. Tell us about the system and present the questions BCIS 4610, Fall 2008

30. Analyzing process requirements BCIS 4610, Fall 2008

31. REQUIREMENTS ANALYSIS • Requirements analysis and documentation describes how stakeholder needs are analyzed, structured and specified for use in the design and implementation of a solution. • The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it. • The primary focus of this activity is to develop the analysis models and determine the gaps in the information provided by the stakeholders. BCIS 4610, Fall 2008

32. REQUIEREMENTS ANALYSIS INCLUDES • Structure requirements packages • Create business domain model • Analyze user requirements • Analyze functional requirements • Analyze quality of service requirements • Determine assumptions and constraints • Determine requirements attributes • Document requirements • Validate requirements • Verify requirements BCIS 4610, Fall 2008

33. Requirements Modeling Techniques • DATA AND BEHAVIOR MODELING TECHNIQUES • Business rules • Class model • Crud matrix • Data dictionary • Data transformation and mapping • Entity relationship diagrams • Metadata definition BCIS 4610, Fall 2008

34. Requirements Modeling Techniques • PROCESS/FLOW MODELING TECHNIQUE • Activity diagram • Data flow diagram • Event identification • Flowchart • Sequence diagram • State machine diagram • Workflow models (Process maps) BCIS 4610, Fall 2008

35. Requirements Modeling Techniques • USAGE MODELS • Storyboards/screen flows • Use case description • Use case diagram • User interface designs • User profiles • User stories BCIS 4610, Fall 2008

36. Next time • Process Modeling • Modeling user requirement with DFDs • Using Oracle CASE tools BCIS 4610, Fall 2008