Takako Nakatani
Toshihiko Tsumaki
ABSTRACT
The success of a project is often affected by imperfect requirements. In order to cope with this risk, a requirements analyst needs to communicate with a client. However, communication between the requirements analyst and the client is not enough to prevent requirements imperfection, since requirements come from various sources, e.g. environment, laws, documents, actual usage, etc. The process of requirements elicitation is affected by the requirements stability, the ability of a requirements analyst, and accessibility of the source of requirements. This paper focuses on the distance between the source of requirements and a requirements analyst, and clarifies how the distance influences the requirements maturation. Requirements maturation represents the degree to which the requirements are elicited completely. We define a measure for observing requirements maturation and analyzing the accessibility of the source of the requirements. Then, we define a hypothesis. A case is analyzed in order to verify the hypothesis. As a result, there is a correlation between the requirements maturation efficiency and the accessibility of the source of the requirements.
- I. Alexander and S. Robertson. Understanding project sociology by modelling stakeholders. IEEE Software, 21(1):23--27, 2004. Google Scholar
Digital Library
- S. Anderson and M. Felici. Controlling requirements evolution: An avionics case study. In SAFECOMP 2000 (LNCS 1943), pages 361--370. Springer-Verlag, 2000. Google ScholarDigital Library
- M. Cataldo and S. Nambiar. On the relationship between process maturity and geographic distribution: an empirical analysis of their impact on software quality. In The 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on the foundations of software engineering, ESEC/FSE '09, pages 101--110. ACM, 2009. Google ScholarDigital Library
- N. E. Fenton and S. L. Pfleeger. Software Metrics: A Regorous and Practical Approach, second edition. Course Technology, 1998. Google ScholarDigital Library
- N. Hanakawa and M. Obana. Mobile game terminal based interactive education environment for large-scale lectures. In The Eighth IASTED International Conference on Web-based Education (WBE2010), March 2010.Google ScholarCross Ref
- IEEE Std 982.1. IEEE standard dictionary of measures to produce reliable software, 1988.Google Scholar
- T. Nakatani, S. Hori, M. Tsuda, M. Inoki, K. Katamine, and M. Hashimoto. Towards a strategic requirements elicitation: A proposal of the PRINCE model. In The 4th International Conference on Software and Data Technologies (ICSOFT 2009). INSTICC, 2009.Google Scholar
- T. Nakatani, S. Hori, N. Ubayashi, K. Katamine, and M. Hashimoto. A case study: Requirements elicitation processes throughout a project. In The 16th International Requirements Engineering Conference (RE'08), pages 241--246. IEEE, 2008. Google ScholarDigital Library
- N. Nurmuliani, D. Zowghi, and S. Fowell. Analysis of requirements volatility during software development life cycle. In The 2004 Australian Software Engineering Conference (ASWEC'04), pages 28--37, 2004. Google ScholarDigital Library
- S. Robertson and J. Robertson. Requirements-Led Project Management. Addison-Wesley, 2005.Google Scholar
- K. Stapel, E. Knauss, and K. Schneider. Using flow to improve communication of requirements in globally distributed software projects. Collaboration and Intercultural Issues on Requirements: Communication, Understanding and Softskills, pages 5--14, 2009. Google ScholarDigital Library
- M. R. Strens and R. C. Sugden. Change analysis: A step towards meeting the challenge of changing requirements. In the IEEE Symposium and Workshop on Engineering of Computer Based Systems (ECBS'96), pages 278--183, 1996. Google ScholarDigital Library
Index Terms
- Requirements maturation analysis based on the distance between the source and developers
Recommendations
Requirements Maturation Analysis by Accessibility and Stability
APSEC '11: Proceedings of the 2011 18th Asia-Pacific Software Engineering ConferenceThe success of any projects can be affected by requirements changes. We define requirements elicitation as the activity of adding, deleting, and modifying requirements. We here refer to the completion of requirements elicitation of a software component ...
Quality Requirements Analysis Using Requirements Frames
QSIC '11: Proceedings of the 2011 11th International Conference on Quality SoftwareDefining quality requirements completely and correctly is more difficult than defining functional requirements because stakeholders do not state most of quality requirements explicitly. We thus propose a method to measure a requirements specification ...
Semantic analysis of functional and non-functional requirements in software requirements specifications
Canadian AI'12: Proceedings of the 25th Canadian conference on Advances in Artificial IntelligenceSoftware Requirements Specifications (SRS) documents are important artifacts in the software industry. A SRS contains all the requirements specifications for a software system, either as functional requirements (FR) or non-functional requirements (NFR). ...
Comments