1 / 14

Determining system requirements

Asper School of Business University of Manitoba. Systems Analysis & Design. Instructor: Bob Travica. Determining system requirements. Updated: September 2018. Outline. Requirements determination = system analysis activity done by a system analyst Concept of system requirement

cchancellor
Télécharger la présentation

Determining system requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related