Process Support for requirements engineering


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Process Support for requirements engineering

  1. 1. Software Requirement Engineering Presented by 08-SE-10 08-SE-62
  2. 2. Process Support for Requirement Elaboration
  3. 3. What is Process Support for requirement Elaboration . <ul><li>It is a method for elaborating requirements models with the support of any process. It usually deals with the correction of requirement uncertainties,inconsistencies and errors. </li></ul>
  4. 4. Process Support for requirement Elaboration <ul><li>As we know that the requirement engineering is the first step in the life cycle of any approach so it is necessary to overcome such requirement ambiguities in order to prevent heavy failure in the future use. </li></ul>
  5. 5. Diagram of KAOS approach
  6. 6. Requirements Engineering . <ul><li>Requirement Engineering is concerned with determining the goals, functions and constraints of hardware and software systems. </li></ul><ul><li>Systematic requirements analysis is also known as requirements engineering. </li></ul>
  7. 7. Process modeling . <ul><li>The modeling of the software process refers to the definition of the processes as models and any optional automated support available for modeling and for executing the models during the software process. </li></ul>
  8. 8. Motivation
  9. 9. <ul><li>• Building a first requirements model is an important and very hard activity. Requirements errors are the most common among those occurring during the life cycle and are the most costly and time-consuming to correct in the later stages .Therefore, it is challenging to investigate weakest link in the chain- in order to improve software quality. </li></ul>Motivation
  10. 10. <ul><li>The research community has developed many formal notations to support software development (and particularly to support requirements engineering); however very little (heuristic) guidance is provided to support the use of such formal notations. </li></ul>Motivation
  11. 11. <ul><li>We are strongly convinced that formal approaches will be more widely used by the software community if effective assistance can be provided to developers for constructing such formal models. </li></ul>
  12. 12. <ul><li>One of the most challenging issues in Software Engineering is the reuse of software artifacts. We are among those who strongly believe that effective reuse of software can only be achieved through the reuse of the development having led to the software artifacts. </li></ul>Motivation
  13. 13. Example of Process Support for Requirement Elaboration.
  14. 14. <ul><li>KAOS stands for Knowledge Acquisition in Automated Specification . This approach is used for this purpose which allows requirements to be captured more rigorously. It’s two main features are: </li></ul><ul><li>• A conceptual model for acquiring and structuring requirements. </li></ul><ul><li>• A method for elaborating requirements models in this framework. </li></ul>KAOS APPROACH
  15. 15. Three levels of modeling: <ul><li>Meta, Domain and Instance Models </li></ul><ul><li>The KAOS approach to requirements acquisition involves three levels of modeling: </li></ul><ul><li>• the meta level refers to domain-independent abstractions in terms of which requirements models have to be acquired. The KAOS models the abstractions in terms of a constrained entity-relationship model, i.e. in terms of meta-entities, meta-relationships. </li></ul>
  16. 16. Domain and instance levels . <ul><li>• the domain level refers to concepts specific to the application domain. These concepts are instances of the abstractions defined at the meta level. </li></ul><ul><li>• the instance level refers to specific instances of domain-level concepts. </li></ul>
  17. 17. Features of KAOS approach
  18. 18. <ul><li>The most original and essential features in KAOS concerns goals . A goal is a property wished by system stakeholders. It looks for the requirement inconsistencies, solve their errors and ambiguities, and emphasizes on the accomplishment of goals, after the fulfillment of requirements . </li></ul>Features
  19. 19. Another feature <ul><li>In this approach, a library of “abstract goal refinement patterns” has been developed. The use of such patterns allows refinements to be corrected and completed. The more refined the requirements are the software will be able to fulfill the user’s needs in a better way. </li></ul>
  20. 20. Another Feature <ul><li>Tactics have also been introduced; they are based on semantic criteria and provide guidance about how to select a refinement and how goals can be achieved through operational constraints. The library of refinement patterns have been also used to define models. </li></ul>
  21. 21. Elaborative Diagram.
  22. 22. <ul><li>In this figure the first part deals with Requirements Engineering, a second one concerns Process Modeling and a third one describes our use of process modeling to support requirements engineering processes. </li></ul>Explanation
  23. 23. CONCLUSION <ul><li>So from above discussion it has been concluded that Process Support for Requirement elaboration really helps in building a stable and efficient system which causes minimum errors in future use. </li></ul>Thank You.