Section 2

Section Goals

• To describe requirements analysis.
• To explain the approaches and techniques used in requirements specification.
• To discuss the main aspects of requirements validation.
• To describe the practical aspects of requirements engineering.

Learning Objectives

Learning Objective 1

• Describe requirements analysis.
• Explain how to detect and resolve conflicts between requirements.
• Explain how to find the limits of software, and how the software must interact with its environment.
• Compare system requirements and software requirements.

Objective Leading Questions

• How would you define requirements analysis?
• How would you describe the current state of requirements analysis?
• Why is requirements analysis important, and what are the main benefits of requirements analysis?
• How would you describe conflict detection and conflict resolution?
• What are the main techniques used in requirements analysis?
• What are the main research challenges in requirements analysis, and why?
• What are the most promising areas from which requirements analysis can benefit?
• Explain how the current methods of conflict detection and conflict resolution ensure that the goals of the various stakeholders are mutually understood (e.g., see Niu and Easterbrook [2007]).

Objective Readings

Required Readings

Chapter 1: "Section 4: Requirements Analysis" of SWEBOK [Bourque and Fairley 2014].

Niu, N. and S. Easterbrook (2007), "So, You Think You Know Others' Goals? A Repertory Grid Study," IEEE Software 24, 2, 53-61. https://doi.org/10.1109/MS.2007.52

Supplemental Readings

Cysneiros, L.M. and J.C.S. do Prado Leite (2004), "Nonfunctional Requirements: From Elicitation to Conceptual Models," IEEE Transactions on Software Engineering 30, 5, 328-350. https://doi.org/10.1109/TSE.2004.10

Alexander, I. (2003a), "Misuse Cases: Use Cases with Hostile Intent," IEEE Software 20, 1, 58-66. https://doi.org/10.1109/MS.2003.1159030

Grünbacher, P. and N. Seyff (2005), "Requirements Negotiation," In https://doi.org/10.1007/3-540-28244-0_7

van Lamsweerde, A. (2001), "Goal-Oriented Requirements Engineering: A Guided Tour," Proceedings of the 5th IEEE International Symposium on Requirements Engineering, Institute of Electrical and Electronic Engineers, Los Alamitos, CA, pp. 249-262. https://doi.org/10.1109/ISRE.2001.948567

Sobel, A.E.K. and M.R. Clarkson (2002), "Formal Methods Application: An Empirical Tale of Software Development," IEEE Transactions on Software Engineering 28, 3, 308-320. https://doi.org/10.1109/32.991322

Learning Objective 2

• Define requirements specification.
• Describe the types of technique used in requirements specification, and the aspects that are typically specified.

Objective Leading Questions

• Explain requirements specification.
• What kinds of document are produced as a result of the requirement specification?
• What do the following three documents define: system definition, system requirements specification, and software requirements specification?
• Describe the shortcomings of the current practice of requirements specification, and the main challenges of this phase?
• In your opinion, which technologies and approaches will significantly contribute to requirements specification?

Objective Readings

Required Readings

Chapter 1: "Section 4: Requirements Specification" of SWEBOK [Bourque and Fairley 2014].

Supplemental Readings

"IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998)," (1998), Institute of Electrical and Electronic Engineers, New York. Retrieved October 30, 2007, from https://ieeexplore.ieee.org/servlet/opac?punumber=5841

Learning Objective 3

• Define requirements validation.
• Describe the major difficulties involved in requirements validation.
• Outline the techniques used in requirements validation.

Objective Leading Questions

• Why is it so important to validate requirements?
• What is the impact of requirements validation on the overall requirements phase?
• How do formal methods, such as Petri nets, improve requirements validation?
• What are the main research challenges of software validation?
• In your opinion, which technologies and approaches will significantly contribute to requirements validation?

Objective Readings

Required Readings

Chapter 1: "Section 6: Requirements Validation" of SWEBOK [Bourque and Fairley 2014].

Jorgensen, J.B. and C. Bossen (2004), "Executable Use Cases: Requirements for a Pervasive Health Care System," IEEE Software 21, 2, 34-41. https://doi.org/10.1109/MS.2004.1270759

Supplemental Readings

Egyed, A. and P. Grünbacher (2004), "Identifying Requirements Conflicts and Cooperation: How Quality Attributes and Automated Traceability Can Help," IEEE Software 21, 6, 50-58. https://doi.org/10.1109/MS.2004.40

Denger, C. and T. Olsson (2005), "Quality Assurance in Requirements Engineering," In Engineering and Managing Software Requirements, A. Aurum and C. Wohlin, Eds., Springer, Berlin, Germany, pp. 163-185. https://doi.org/10.1007/3-540-28244-0_8

Learning Objective 4

• Describe the topics that need to be understood to practice requirements engineering.
• Introduce the iterative nature of the requirements process.
• Define change management, maintenance of requirements, and requirements measurement.
• Distinguish between different types of software requirements tools

Objective Leading Questions

• What are the practical considerations of requirements engineering?
• Define the following concepts: requirements change management, requirements maintenance, and requirements measurement?
• What different types of software requirements tools exists, and what are some examples in each category?

Objective Readings

Required Readings

Chapter 1: "Section 7: Practical Considerations" of SWEBOK [Bourque and Fairley 2014].

Chapter 1: "Section 8: Software Requirements Tools" of SWEBOK [Bourque and Fairley 2014].

Supplemental Readings

Atlee, J. and R. Wieringa (2006a), "RE 05: Engineering Successful Products," IEEE Software 23, 3, 16-18. https://doi.org/10.1109/MS.2006.79

Damian, D., J. Chisan, L. Vaidyanathasamy and Y. Pal (2005), "Requirements Engineering and Downstream Software Development: Findings from a Case Study," Empirical Software Engineering 10, 3, 255 - 283. https://doi.org/10.1007/s10664-005-1288-4