Discussion questions Chapter 4

Requirements Engineering
  1. How does Requirements elicitation fit into the development models we have already discussed in this class, like the agile method?
  2. How do structured specifications relate to functional and non functional requirements?
  3. Are there times where you would not focus on non-functional requirements at all?
  4. What are examples of systems where you would expect the requirements to change frequently?
  5. Are there ever situations where the application/program being developed is so technical that some software engineer would not be able to understand the requirements requested by the specialists that will use the software? What needs to happen in such situations?
  6. In a software development project, are requirements specification and validation carried out separately (as in with different times, in different times or spaces) or are they more often carried out in the same setting?
  7. It seems like object-oriented programming is becoming a very common philosophy, even the requirement discovery tool has object-oriented method like the UML. What are the principles of object-oriented programming?
  8. What format for requirement management do you suggest for our team project?
  9. How would you figure out how many meetings the team needs with the client to get started on a minimum level of requirements?
  10. How many times is to be expected to revise a requirements document?
  11. How does one agree on proper metrics for non-functional requirements? How do you
  12. arrive at a specific figure?
  13. Why are non-functional requirements harder to implement than functional requirements?
  14. How to treat “enduring” and “volatile” requirements differently during the initial making of
  15. the requirement specification?
  16. Are there any other popular and effective use case graphical models other than UML?
  17. What if a team of four people is working on the requirements elicitation separately using interview and ethnography. How can they keep track of the all requirements so they don’t become inconsistent?
  18. How efficiently manage the process of requirements validation, via either requirements reviews, prototyping, or test-case generation, in short amount of time and limited budget?
  19. Why is it important to keep track of who proposed certain requirements on the requirements document?
  20. How would software engineers know what questions to ask in a closed interview?
  21. How can one reconcile different, sometimes conflicting, requirements from multiple stakeholders of a software product?
  22. How is a test-case generation different from prototype testing?
  23. Does establishing requirements necessarily need to go through every phase of the defined
  24. requirements elicitation process, or can it be a more natural and free-flowing interview process
  25. with eventual formalization and documentation?
  26. What are some ways to negotiate realistic requirements within our current projects? How
  27. ambitious should we be in meeting the clients’ needs?
  28. How experienced are clients, generally, in establishing requirements for software development?
  29. The book talks about the idea of soliciting requirements by presenting a prototype so people have something concrete to picture from the start. Is it also common to have people look at a similar existing system and comment on how they’d like their new system to be different?
  30. When using an agile approach, are the more technical system requirements usually written only in the code as it’s being written? Is it worth the time to add them to a requirements document when that part of the system is nearly finalized?
  31. The book often mentions how difficult it is for end users to picture a system without anything to go on. How useful is it to try to establish requirements before making a prototype or first iteration of a system?
  32. How do most contracts account for changes to system requirements? Do they just focus on static requirements and leave the rest open to change? Or do contracts make inevitable changes to requirements more difficult?
  33. What are real life examples of when functional and non-functional requirements clash with each other?
  34. Do programmers ever work on the non-functional requirements?
  35. Can those who work on the project reject the requirement change due to the process already invested in them? 
  36. What are main consequences for forgetting to change the requirement document when implementing a system change?
  37. What does  it means by requirements elicitation in working with small projects.
  38. What are the significances of requirement elicitation and requirements validation?
  39. What are the differences between functional and non-functional requirements?
  40. What are the various types of non-functional requirements?
  41. Give examples of requirements documentation written via natural language specification.
  42. Why is interviewing and ethnography important when learning about system requirements from stakeholders? (4.1 – 4.4)
  43. How can prototyping be effective when validating the user requirements of the system?
  44. How can an engineer responsible for drawing up a system requirements specification keep track of the relationships between functional and non-functional requirements?
  45. Which type of check should be used to check that requirements reflect the real needs of consumers, and why? Validity checks are used because user requirements are always changing from the first time they were elicited due to changing circumstances. 
  46. What is a real life example of natural language specification specific to our projects? How can we predict the ever changing aspects of the business and technical environment?
Scroll to Top