Determining system requirements

1. Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Determining system requirements Updated: September 2018

2. Outline • Requirements determination = system analysis activity done by a system analyst • 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. Requirements activity in SDLC • System is analyzed - requirements are collected - in each iteration; most of it is in the 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. 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. 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. Object-oriented diagrams Activity Diagram 3510 Systems Analysis & Design * Bob Travica

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

8. Interviewing • Data collection through talking with users • Natural, pervasive, basic method • Good example: Consultants developing custom software, multiple visits, working with client • Bad example: Too short interviewing, biased user samples, inappropriate outsourcing of interviewing task • 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 3510 Systems Analysis & Design * Bob Travica

9. Interviewing example 3510 Systems Analysis & Design * Bob Travica

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

11. Observation • Collecting data by watching, listening and asking spontaneous questions with various degrees of the observer’s visibility. • Example Designing a database for a music store in NY • Example Observers incapable of reading body language, speaking technical lingo, acting as authority • 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 3510 Systems Analysis & Design * Bob Travica

12. Think-Aloud Protocol • Recording users’ thoughts they speak aloud while performing a task with a system; “short memory “dump” • Example Simulation systems for risky situations (pilots) • Example Lack of prompting users to speak • 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) 3510 Systems Analysis & Design * Bob Travica

13. Survey • Collecting mostly quantitative data by administering a questionnaire (mail, or electronic). • 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 • 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 3510 Systems Analysis & Design * Bob Travica

14. A JAD Facility Joint Application Design • Discussion in a small group (designated team, committee) to define system requirements. Made for waterfall methodology but may be iterative. • Example: IBM 3510 Systems Analysis & Design * Bob Travica