1 / 28

INFO2005 Requirements Analysis Requirements Capture

INFO2005 Requirements Analysis Requirements Capture. Department of Information Systems. Lecture 2 - Learning Objectives. Identify the problems associated with Requirements Capture Consider various fact-finding approaches. . Requirements Change. Why do requirements change?.

nijole
Download Presentation

INFO2005 Requirements Analysis Requirements Capture

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. INFO2005Requirements AnalysisRequirements Capture Department of Information Systems

  2. Lecture 2 - Learning Objectives • Identify the problems associated with Requirements Capture • Consider various fact-finding approaches

  3. Requirements Change • Why do requirements change?

  4. The impact of change 60X - 100X 1.5X - 6X 1X

  5. Why things go wrong Type of Failure Reason for Failure Comment Wrong problem addressed Quality Problems Wider influences are neglected Analysis carried out incorrectly Project undertaken for wrong reason Users change their mind Productivity Problems External events change the environment Implementation is not feasible Poor project control From Bennett et. al. (1999)

  6. Requirements Capture • We will be considering requirements capture in the context of the Unified Process • All thetechniques may be used in conjunction with development method • The traditional techniques are known collectively as Fact-Finding Techniques

  7. Rational Unified Process “The Rational Unified Process is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users, within a predictable schedule and budget. The Rational Unified Process captures many of the best practices in modern software development in a form that can be tailorable for a wide range of projects and organizations.” Rational Software Corportation - RUP v5.1.1

  8. Requirements in RUP

  9. Fact-Finding Techniques • Remembering the techniques: • S . . . • Q . . . • I . . . • R . . . • O . . . • Not in order of importance, or sequence in the project

  10. Interviewing • The most widely used traditional technique

  11. Interviewing • Preparing for an interview • Time-consuming • ½ day preparation for one hour interview

  12. Interviewing “An effective, direct person-to-person interviewing technique requires that you have prepared a list of questions designed to gain an understanding of the real problems and potential solutions. To get as unbiased answers as possible, you need to make sure the questions you ask are context free. The context-free question is a high-level, abstract question that can be posed early in a project to obtain information about global properties of the user’s problem and potential solutions.” Rational Unified Process V5.1

  13. Interviewing • A context-free question is: • Always appropriate.

  14. Interviewing • Examples of context-free questions used to find actors: • Who is the customer?

  15. Interviewing • Context-free questions that help understand business processes and requirements: • How do you take a customer order at the moment?

  16. Interviewing • Examples of non-context-free questions are: • Leading questions: "You need a faster printer, don't you?" • Self answering questions: "Are fifty items about right?"

  17. Interviewing • Conducting an interview • Introduce … • Permission … • Stay within agreed time • State objectives- keep them in mind • Show respect • Don’t dominate • But control direction

  18. Interviewing • Conducting an interview • Be flexible • Seek evidence… • Open questions • “Reflect back” • Summarise • Can you return later?

  19. Interviewing • Ending the interview • Can I ask more questions later? • Would you be willing to participate in a requirements review? • Is there anything else I should be asking you? • Post-interview • Write up asap (1/2 day per interview) • Verify facts

  20. Sampling • Almost always used to support interviews • Adds • Can resolve • Identifies • Confirms • Identifies

  21. Sampling • Range from- • highly informal to… • rigorous statistical investigation • sample size chosen for significance • Informal: • collecting used documents

  22. Sampling • Formal Sampling • need to understand statistical theory to set up study and analyse data • In all cases, minimise disruption to users.

  23. Research / Reading • Particularly useful at start of project

  24. Observation • Less widely used • Observation can:

  25. Questionnaires • Questionnaires useful where: • Many people involved with system • Geographically dispersed

  26. Questionnaires • Also bear in mind:

  27. Documenting Requirements • Requirements must be carefully documented • Analyst’s notes must be: • summarised • organised • filed • One way to do this is to use a CASE tool • We will be using the Rational CASE tools.

  28. Summary In this session we have learned about various fact finding techniques - use the acronym SQIRO to help remember them. References: • Rational Unified Process • Bennett, S. et. al. “Object-Oriented Systems Analysis & Design using UML” McGraw-Hill 1999 Ch5 pp96–121

More Related