This document discusses different methods for gathering requirements for a software project, including interviews, observation, and research. It emphasizes the importance of talking to multiple stakeholders to get balanced information and priorities. Requirements gathering takes practice and demands identifying goals and priorities to guide development and avoid overscoped "gold-plated" software. Social and organizational factors within the customer environment must also be considered.

1. Software Requirements Distinguishes between Customer " needs " -- AND Customer's " wants " --

2. How do we gather data to determine a Project’s Requirements? Observation - Watch Interview - Listen Research - Learn

3. Interview Determine who are the project’s stakeholders ! Talk to customers Talk to users Talk to other stakeholders

4. The Interview Process How many persons should attend an interview?

5. The Interview Process not everything spoken is the truth sometimes people lie or forget facts most often they speak from their own ignorance or point of view interview many people to gather balanced information evaluate what you are hearing watch body language

6. What happens after the interview? Immediately write down interview results. Research show that even in a life-and-death situations: 50% of what took place is forgotten within 30 minutes . Follow-up Memo

7. Observation: Watch, Who, Where, Why? Watch the way it is done: Go to the customer’s site, spend time in the users real-world environment! Who does the job? Where is it done? Why is it done in this particular way? Learn everything you can about the way the process is done. At this stage it doesn’t matter if it is done by hand or by computer.

8. Research and Observation How do we get what we need? Obtain copies of ALL operating documents Assess existing documents Assess current procedures Focus on identifying what’s visible Observe current procedures Cross “fertilization”

9. Research Study documentation provided by the customer. Collect materials generated by the existing system, even if such materials are paper-and-pencil versions Examine the input and output currently generated

10. Data Gathering for Software Requirements Analysis: Takes practice Demands Prioritization Means Identifying Goals

11. Prioritization users are likely to ask for the moon if there are no limits. beauty should not outweigh functionality. help customer be realistic about expectations. useful to identify enhancements for future work once basic product is developed.

12. Prioritization: Guides team in allocating effort May be needed to schedule incremental development Enables determination of what is really important Avoid "gold-plated" software

13. Analysis  Specification The goal: understanding the customer's requirements for a software system. involves technical staff working with customers involves all the stakeholders in the system

14. Who ARE the stakeholders?

15. What are the problems associated with the Requirements phase?

16. Requirements gathering problems? Stakeholders don't really know what they want Stakeholders express their requirements in their own terms

17. Requirements gathering problems? Different stakeholders may have conflicting requirements

18. Requirements gathering problems? The requirements may change during the process New stakeholders may emerge on the scene

19. Requirements gathering problems? Stakeholders don't really know what they want Stakeholders express their requirements in their own terms

20. Analysis Viewpoints: Partitioning : Identifies the structural relationships between components Abstraction : Identifies generalities among components Projection : Identifies different ways of looking at a problem

21. Social and Organizational factors effect all systems!

22. Software systems are used within a social and organizational context.

23. Social and organizational factors CAN dominate system requirements.

24. Software Viewpoints:

25. Software is not designed in a vacuum! There is no single “correct” viewpoint. Effective software involves combining all viewpoints.

26. Good analysts must be very sensitive to different views. There is no systematic way to factor them into the analysis process.