1 / 14

Determining systems requirements

Asper School of Business University of Manitoba. Systems Analysis & Design. Instructor: Bob Travica. Determining systems requirements. Updated: September 2013. Outline. System analyst’s job Concept of system requirement Modeling requirements via diagrams Requirements gathering methods

balin
Télécharger la présentation

Determining systems 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 systems requirements Updated: September 2013

  2. 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. 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 developemnt 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 operatrions 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 • Considerations: • Communication issues • Level of structuring (open-ended vs. close-ended) • Time expenditures • Advantages: Can provide specific & rich account of user needs • Challenges: Striking a right balance between considerations 3510 Systems Analysis & Design * Bob Travica

  9. Interviewing example What tasks and processes are involved? How you do it? Which steps do you follow? Anything you’d like to change? How are the tasks and processes performed? How should they be? What are the information needs of this user? What documents do you use? Any communications you use? 3510 Systems Analysis & Design * Bob Travica

  10. 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 3510 Systems Analysis & Design * Bob Travica

  11. Observation • Collecting data by watching, listening and asking ad hoc questions with various degrees of the observer’s visibility. Subjectivity in interpreting results. • Considerations: • Involvement in user situation • Subjectivity • Obtrusiveness • Advantages: Learning in natural context, rich in detail. • Challenges: Hawthorne effect (negative effect from obtrusiveness), validity of perceptions 3510 Systems Analysis & Design * Bob Travica

  12. Think-Aloud Protocol • Recording users’ thoughts they speak aloud while performing a task with a system • 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. A JAD Facility Joint Application Design • Discussion in a small group (designated team, committee) until job is done. 3510 Systems Analysis & Design * Bob Travica

  14. Survey • Collecting mostly quantitative data by administering a questionnaire (mailed, or on site). • Considerations: Limitations of written communication • Advantages: Specific coverage and time savings • Challenges: Validity of users’ responses and lower response rates 3510 Systems Analysis & Design * Bob Travica

More Related