Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Determining systems requirements Updated: September 2014

3510 Systems Analysis & Design * Bob Travica 2 of 14 Outline System analyst’s job Concept of system requirement Modeling requirements via diagrams Requirements gathering methods (Interviewing, Focus Groups, Observation, Think–Aloud Protocol, Joint Application Design, Survey)

3510 Systems Analysis & Design * Bob Travica 3 of 14 Requirements activity in SDLC Requirements collected in each iteration; most of it is in Elaboration phase. Requirements activity precedes design, implementation, testing… In the end of each iteration (a column) is working software, whose development can be continued later. needs.

3510 Systems Analysis & Design * Bob Travica 4 of 14 Systems analyst’s job Define & document system requirements (functional & non- functional): Investigate user needs (interview, etc.) Understand business (application domain) Study existing system (hands-on, documentation, inputs/outputs) Study benchmark systems Create diagrams & descriptions to capture requirements that will translate into system’s data model and functionality Model user interface

3510 Systems Analysis & Design * Bob Travica 5 of 14 System Requirements Functional: Specification of tasks system should perform (e.g., calculate pay) Non-functional: User interface (e.g., ease of use) Technical performance (e.g., execution speed, reliability) Security…

3510 Systems Analysis & Design * Bob Travica 6 of 14 Object-oriented diagrams Activity Diagram

3510 Systems Analysis & Design * Bob Travica 7 of 14 Requirements gathering methods Interviewing Focus Groups Observation Think–Aloud Protocol Joint Application Design Survey

3510 Systems Analysis & Design * Bob Travica 8 of 14 Interviewing Data collection through talking with users Natural, pervasive, basic method Considerations: Communication issues Level of structuring (open-ended vs. close-ended) Time expenditures Advantages: Can provide specific & rich account of needs Challenges: Striking a right balance between considerations Good example: Consultants developing custom software, multiple visits, working with client Bad example: Too short interviewing, biased user samples, inappropriate outsourcing of interviewing task

3510 Systems Analysis & Design * Bob Travica 9 of 14 Interviewing example ThemeQuestions to ask users What tasks and processes are involved? What do you do usually at work? How are the tasks and processes performed? How should they be? How do you do your work? Can you describe any steps you may need do take? Anything you’d like to change to make your work easier or better? What are the informing needs of this user? What documents do you use at work? Any communications you use daily? Is there anything you feel missing?

3510 Systems Analysis & Design * Bob Travica 10 of 14 Focus Groups Group interviewing with many interviewers Origin: Marketing research Considerations: Discussion focus Time distribution (talkative vs. silent interviewees) Advantages: Deep initial insight in user situation. Challenges: Managing group dynamics Example Designing campus wise IS at Syracuse Univ. Example Untrained interviewers, weak analysis of focus group data. Usually not obvious immediately.

3510 Systems Analysis & Design * Bob Travica 11 of 14 Observation Collecting data by watching, listening and asking spontaneous questions with various degrees of the observer’s visibility. Considerations: Involvement in user situation Subjectivity Obtrusiveness Advantages: Learning in natural context, rich in detail. Challenges: Hawthorne effect (negative effect from obtrusiveness), validity of conclusions Example Designing a database for a music store in NY Example Observers incapable of reading body language, speaking technical lingo, acting as authority

3510 Systems Analysis & Design * Bob Travica 12 of 14 Think-Aloud Protocol Recording users’ thoughts they speak aloud while performing a task with a system; “short memory “dump” Considerations: Relaxing the user to talking along with doing (not a natural behavior) Advantages: Insight in user’s short-term memory that otherwise may be lost Challenges: User’s account may be narrow and not reflexive (thought-through) Can be combined with observation (in usability study) Example Simulation systems for risky situations (pilots) Example Lack of prompting users to speak

3510 Systems Analysis & Design * Bob Travica 13 of 14 Survey Collecting mostly quantitative data by administering a questionnaire (mail, or electronic). Considerations : Limitations of written communication Advantages: Specific coverage and time savings, electronic trail (direct entry of answers to database) Challenges: Validity of users’ responses and lower response rates Example Quick probing a general feeling about an existing system & a need for new sys. User satisfaction. Example Asking too specific & too many questions, anonymity issue

3510 Systems Analysis & Design * Bob Travica 14 of 14 Joint Application Design A JAD Facility Discussion in a small group (designated team, committee) until job is done. Example: IBM