attach file with question

CSCI 450/928 Project Guidelines

OUTLINE:

You are required to conduct an in-depth study of one of the following 6 topics (in some instances, an alternative topic will be permitted but must be discussed in advance with the instructor). Given a choice of topic, your project report must describe and survey existing topics in that area in considerable detail. Ideally, your project report should also propose a novel solution in that problem domain (project reports which only describe existing techniques are acceptable, but a novel technique, adequately described, will earn extra credit). If your project only surveys existing techniques, you must attempt to include the following:

• A taxonomy (classification) of the techniques that you have looked at.
• A critique of each technique. What are the benefits of using the technique in question? What are its weaknesses?

DELIVERABLES:

• A project report. The report should be ideally structured as a research paper (see class readings for exemplars) with the following sections:
  • Introduction
  • Background
  • Several sections describing the actual work conducted
  • Related work
  • Conclusions

Variations on this structure are possible. Please discuss this with your lecturers.

• Any additional material developed in the course of the project. This might include: working code, detailed requirements models/specifications, case studies etc.

PROCESS:

• Develop your project idea in close consultation with your lecturers. Once you have selected a topic, your lecturers can help guide the development of your ideas and point you to additional resources beyond those listed in this document.
• You must present a 1-page project proposal in week 8 and a 1-page progress report in week 11.
• A hardcopy of the final report must be submitted in the lecture of Week 13
• Projects should ideally be individual. Groups with a maximum of 2 students will be permitted.

TOPICS:

• Requirements engineering for socio-technical systems: Socio-technical systems, which emphasize the synergy between humans and machines, are becoming increasingly important for the RE community. What are some of the issues that distinguish traditional RE from this new set of questions? What innovations do we need?
  • References:
    • http://www.software-engin.com/teaching/socio-technical-systems-engineering
    • http://www.software-engin.com/teaching/socio-technical-systems-engineering/background-reading-sommerville
    • www.humancomputation.com

• Managing consistency in requirements specifications: How can inconsistencies in requirements specifications be detected? Once detected, how can they be resolved?
  • References:
    • W.N. Robinson, S. Pawlowski, Managing Requirements Inconsistency with Development Goal Monitors, IEEE, Transactions on Software Engineering, Nov/Dec 1999.(Available from IEEExplore via UoW Library).
    • S. M. Easterbrook and B. A. Nuseibeh (1996) Using ViewPoints for Inconsistency Management. Software Engineering Journal, Vol 11, No 1, Jan 1996.
    • S. M. Easterbrook and M. Chechik, “A Framework for Multi-Valued Reasoning over Inconsistent Viewpoints“, Proceedings, 23rd International Conference on Software Engineering (ICSE-01), Toronto, Canada, May 12-19, 2001. IEEE Computer Society Press.
    • A. van Lamsweerde, R. Darimont, E. Letier
      Managing Conflicts in Goal-Driven Requirements Engineering
      IEEE Transactions on Software Engineering, Special Issue on Managing Inconsistency in Software Development, November 1998. (Available from IEEExplore via UoW Library).
• Requirements change management: How can requirements change requests be handled? How can we evaluate the trade-offs involved in incorporating a change request, as opposed to rejecting it (trade-off analysis)? What steps should we take in the event of the requirements change rendering the specification inconsistent?
  • References:
    • S. M. Easterbrook and B. A. Nuseibeh (1995) Managing Inconsistencies in an Evolving Specification. Proceedings, Second IEEE International Symposium on Requirements Engineering (RE’95), York, UK, April 1995, pp48-55.
      PDF file
    • D. Zowghi, A. K. Ghose and P. Peppas, 1996.A framework for reasoning about requirements evolution. In Proceedings of the Fourth Pacific Rim International Conference on Artificial Intelligence, Cairns, Australia, August, 1996. Springer Verlag Lecture Notes in Computer Science Volume 1114. Available through Springerlink: http://www.springerlink.com/content/p707181265j9/
    • A. K. Ghose. Formal tools for managing inconsistency and change in RE. Proceedings of the 10th International Workshop on Software Specification and Design (IWSSD 2000), San Diego, IEEE Computer Society Press, November 2000, pp. 171-182. (Available from IEEExplore via UoW Library).
• Compliance management in requirements models:There is considerable contemporary interest in building systems that comply with legislative/regulatory frameworks (these can often be represented as sets of rules). One approach to managing compliance concerns is to bring them to bear in the early phases of the software lifecycle, thus reducing the need to effect compliance-driven changes to downstream artefacts. How can requirements models be checked for compliance? How can these be modified if found to be non-compliant?
  • References:
    • Guido Governatori, Zoran Milosevic, Shazia Sadiq and Maria Orlowska. On Compliance of business processes with business contracts Technical Report, School of Information Technology and Electrical Engineering, The University of Queensland. 2006.
    • Aditya Ghose and George Koliadis. Auditing business process compliance. In Proc. Of the 2007 International Conference on Service-Oriented Computing (ICSOC-2007). Springer Verlag Lecture Notes in Computer Science. (Draft version available online at: www.uow.edu.au/~aditya/publications.html)
• Semantic annotation of requirements models: Many requirements modeling notations are semi-formal, providing minimal semantic information. Advanced tool support for many requirements analysis tasks such as consistency and completeness checking becomes possible if requirements models can be annotated with additional semantic information. For instance, a UML activity diagram might be annotated describe the effects of each process step. Semantic annotation of a UML sequence diagram can reveal the impact of each message. How can requirements models be augmented with semantic annotation? What form would this annotation take? What are the downstream benefits of such annotation?
  • References:
    • Model Checking Early Requirements Specifications in Tropos. Ariel Fuxman, Marco Pistore, John Mylopoulos, and Paolo Traverso. In IEEE International Symposium on Requirements Engineering, 2001.[pdf]
    • G. Koliadis and A. Ghose. Semantic verification of inter-operational business process models. In Proceedings of the 2007 IEEE Services Congress. IEEE Computer Society Press. (Available from IEEExplore via UoW Library).
• Evaluating completeness in requirements models: The problem of deciding whether a given set of models is complete relative to the needs of the task at hand is difficult and has received relatively little attention in the literature. A theoretically grounded understanding of how to detect incompleteness in a set of models (relative to a given task), and how to minimally augment the set of models to obtain completeness can be of great value.
  • References
    • Rolland, C. Souveyet, C. Achour, C.B. 1998.Guiding goal modeling using scenarios. InIEEE Trans. On Software Engg.,vol. 24, no. 12. (Available from IEEExplore via UoW Library).
    • Heimdahl, M & Leveson, N. 1996. Leveson.Completeness and Consistency in Hierarchical State-Based Requirements. IEEE Transactions on Software Engineering, Vol. SE-22, No. 6, pp. 363—377. (Available from IEEExplore via UoW Library).
• Modeling non-functional requirements: While many notations support the modeling of functional requirements, very few provide support for non-functional requirements. Non-functional requirements tend to be vague, and in many cases, qualitative, making the evaluation of whether they have been “satisfied” difficult. How can novel ways of modeling non-functional requirements be devised, leading to new stand-alone modeling notations or augmentations to existing notations?
  • References:
    • J.Mylopoulos, L. Chung, and B. Nixon, “Representing and Using Non-Functional Requirements: A process-Oriented Approach”;, IEEE Transactions on Software Engineering, Special Issue on Knowledge Representation and Reasoning in Software Development, 18(6), June 1992, pp. 483-497.
    • L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishing, 2000. 472pp. ISBN 0-7923-8666-3. Some earlier drafts (at Lawrence Chung’s webpage). (Available at UoW Library)

Our website has a team of professional writers who can help you write any of your homework. They will write your papers from scratch. We also have a team of editors just to make sure all papers are of HIGH QUALITY & PLAGIARISM FREE. To make an Order you only need to click Ask A Question and we will direct you to our Order Page at WriteDemy. Then fill Our Order Form with all your assignment instructions. Select your deadline and pay for your paper. You will get it few hours before your set deadline.