2. Requirement Gathering Fall 2006/1385 Semester 1

3. Sharif Univ. of Tech.2 Sources Gather information on what system should do from many sources –Users –Reports –Forms –Procedures

4. Sharif Univ. of Tech.3 Before you start gathering requirements... Identify Stakeholders. Develop a problem statement Develop a “vision” - The project vision aligns all project participants in a common and clearly expressed direction. The vision describes what the project is about and what the product could ultimately become in a perfect world. *

5. Sharif Univ. of Tech.4 What are some common software requirements? Business rules - “Inventory shipments come on the 25th” Budget - “We only have $1,000 for this project” Interface - “We need a web enabled sales entry system” Reports or outputs - “Stock check; monthly or weekly summaries on...” Performance - “There might be 5000 concurrent users …” Project Completion Date - “Oh, I need that next week …” Security - “Everyone must have their own login and can see..” Hardware - “We don’t want to buy additional hardware…14’’ screens will have to do.” Software - “Everything must coded in Java and XML…”

6. Sharif Univ. of Tech.5 Requirements Continued... Error - Embedded system for the fire sprinklers; financial. User level - “Mary has been dying to learn Windows...” System maintenance - “Jack, our stock guy, he can…” System location - “The server is located in Dallas and we connect using this here modem. Just wiggle the cord...” No subcontracting - “Due to confidentiality, we ask…”

7. Sharif Univ. of Tech.6 Requirements Gathering Techniques Review Existing Documents. Review current system input and outputs. Interviews. Role playing. Research Existing Solutions. Storyboarding. Prototypes. Questionnaires. Brainstorming and idea reduction. Workshop.

8. Sharif Univ. of Tech.7 Interviews

9. Sharif Univ. of Tech.8 Interviews At first you should try to find right people. This depends on what kind of information you are looking for. Grouping interview: –More effective use of time. –Enables people to hear opinions of others and to agree or disagree. –Difficulty in scheduling

10. Sharif Univ. of Tech.9 Interviews -- Five Basic Steps Selecting interviewees –Based on information needed –Often good to get different perspectives Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

11. Sharif Univ. of Tech.10 Interview Questions Ask Open-Ended Questions. –What do you think about the current system? –What are some of the problems you face on a daily basis? Avoid asking questions like: –Why? –For what? Do not phrase questions in ways that imply a wrong or right answer Avoid asking people to describe things they don’t usually describe.

12. Sharif Univ. of Tech.11 Interview Preparation Steps Prepare general interview plan –List of question –Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee –Schedule –Inform of reason for interview –Inform of areas of discussion Sometimes it is better not to use tape recorder. You should know the domain and also the characteristics of the interviewee.

13. Sharif Univ. of Tech.12 Conducting the Interview Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

14. Sharif Univ. of Tech.13 Conducting the Interview Practical Tips Don’t worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language Listen and Listen and Listen.

15. Sharif Univ. of Tech.14 Post-Interview Follow-Up Prepare interview notes Prepare interview report with in 48 hours. Look for gaps and new questions Send interviewee a report to confirm the information.

16. Sharif Univ. of Tech.15 Questionnaires

17. Sharif Univ. of Tech.16Questionnaires Good for large groups An average response level is usually around 10%, if there is no threat from the boss. When you used correctly, questionnaires can be an excellent supplement to interviewing data. A user can’t tip you off to explore different problem areas with a questionnaire easily. They will want to get through with it as soon as possible, not to mention subjective answers will usually be too brief.

18. Sharif Univ. of Tech.17 Good Questionnaire Design Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaire Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents

19. Sharif Univ. of Tech.18 Storyboarding/Prototyping

20. Sharif Univ. of Tech.19Storyboarding/Prototyping Passive storyboards - sketches, pictures, screenshots, Powerpoint presentations, or sample outputs. Use stick figures. Active storyboards - automated slide presentation or movie describing the way the system behaves. Interactive storyboardsInteractive storyboards - require participation by the user. Throw away code. Sample interface or reporting outputs; very close to a throwaway prototype. Storyboard elements: –Who are the players –What happens to them –How it happens

21. Sharif Univ. of Tech.20 Storyboarding/Prototyping Continued... Don’t invest too much in the prototype. A throwaway prototype shouldn’t take more than a week to build. Customers will be intimidated to make changes if it looks to close to the real thing. If the prototype looks too good, customers will want it now or assume that you are almost done. “So you are pretty much done, right?” Have backup plans. Bring a paper version of a interactive prototype. –What prevents a client from taking your code and giving to another developer? “Here is what we want and you can do this for a better price, right?” –Hardware presentation problems - no outlet, machine lockup, screen can’t be seen by everyone, software not cooperating, etc. –Make sure the prototype is portable. Sized to fit screen. Basic colors. Can it run without special software? “Let me just load this calendar control…”