Lecture2_REQUIREMENT_Process__Modelss.pptx
- 2. Process A process is an organized set of activities, which transforms inputs to outputs Processes are essential for dealing with complexity in real world Processes document the steps in solving a certain problem They allow knowledge to be reused Examples: An instruction manual for assembling a computer or its parts A procedure manual for operating a motor vehicle radio and CD player
- 3. Software Process Software processes help in performing different software engineering activities in an organized manner Examples: Software engineering development process (SDLC) Requirements engineering process Design process Quality assurance process Change management process
- 4. Process Models A process model is a simplified description of a process presented from a particular perspective There may be several different models of the same process No single model gives a complete understanding of the process being modelled
- 5. Variations in Process Models A process model is produced on the anticipated need for that model. We may need A model to help explain how process information has been organized A model to help understand and improve a process A model to satisfy some quality management standard
- 6. Types of Process Model Coarse-grain activity models Fine-grain activity models Role-action models Entity-relation models
- 7. Coarse-grain Activity Model This type of model provides an overall picture of the process Describes the context of different activities in the process It doesn't document how to enact a process
- 8. Context of Requirements Engineering Software requirements follow the system requirements and system design The primary goal is understanding Software requirements are followed by software design in a software development life cycle
- 9. Context of RE Process in Waterfall Model
- 10. Another Perspective on Context of RE Process
- 11. Coarse-grain Activity Model of the Requirements Engineering Process
- 12. Coarse-grain Activity Model This type of model provides an overall picture of the process and provide foundation for other models Describes the context of different activities in the process Problems in this model are: No user feedback No Freezing of requirements No risk management
- 13. Spiral Model for RE Informal statement of requirements Draft requirements document Requirements document and validation report Agreed requirements START Requirement elicitation Requirement analysis and negotiation Requirement validation Requirement documentation
- 14. Spiral Model for RE The key motivation for spiral model is the risk analysis and risk management Requirements are discovered in different iterations and can be re-evaluated after each spiral
- 15. Fine-grain Activity Models These are more detailed models of a specific process, which are used for understanding and improving existing processes It is estimated that development time of a project is reduced up to 20% just by increasing CMM level. Well discuss some fine-grain processes within the general requirements engineering processes in later lectures
- 16. Role-action Models These are models, which show the roles of different people involved in the process and the actions which they take They are useful for process understanding and automation Example: Stakeholders model for organization
- 17. Role-Action Diagram for Software Prototyping Understand problem Establish outline requirements Select prototyping system Develop prototype Evaluate prototype Req. Engineer Domain expert End-user Req. Engineer End-user SW Engineer Project Mgr Req. Engineer SW Engineer End-user Domain expert Req. Engineer SW Engineer ACTIONS ROLES
- 18. Role Descriptions Domain Expert: Responsible for proving information about the application domain and the specific problem in that domain, which is to be solved System End-user: Responsible for using the system after delivery Requirements Engineer: Responsible for eliciting and specifying the system requirements Software Engineer: Responsible for developing the prototype software system Project Manager: Responsible for planning and estimating the prototyping project
- 19. Entity-relation Models The models show the process inputs, outputs, and intermediate results and the relationships between them They are useful in quality management systems
- 20. Requirements Engineering Process The process(es) involved in developing system requirements is collectively known as Requirements Engineering Process
- 21. RE Process - Inputs and Outputs
- 22. RE Process Inputs It includes existing system information Information: It include the information about the functionality of systems to be replaced and the Information about other systems, which interact with the system being specified Stakeholder needs: Description of what system stakeholders need from the system to support their work Organizational standards: Standards used in an organization regarding system development practice, quality management, etc. Regulations: External regulations such as health and safety regulations, which apply to the system Domain information: General information about the application domain of the system
- 23. RE Process Inputs Agreed requirements: A description of the system requirements, which is understandable by stakeholders and which has been agreed by them System specification: This is a more detailed specification of the system, which may be produced in some cases System models: A set of models such as a data-flow model, an object model, a process model, etc., which describes the system from different perspectives
- 24. RE Process Variability RE processes vary radically from one organization to another, and even within an organization in different projects Unstructured processes rely heavily on the experience of the people, while systematic processes are based on application of some analysis methodology, but they still require human judgment
- 25. Variability Factors There are four factors which count towards the variability of the Requirements Engineering Process Technical maturity Disciplinary involvement Organizational culture Application domain
- 26. Variability Factors Technical maturity The technologies and methods used for requirements engineering vary from one organization to other Disciplinary involvement The types of engineering and managerial disciplines involved in requirements vary from one organization to another Organizational culture The culture of an organization has important effect on all business and technical processes Application domain Different types of application systems need different types of requirements engineering process
- 27. RE Process Requirement Engineering Process has a formal starting and ending point in the overall software development life cycle. Begins There is recognition that a problem exists and requires a solution A new software idea arises Ends With a complete description of the external behaviour of the software to be built
- 28. Two Main Tasks of RE There are two main tasks which need to be performed in the requirements engineering process. 1. Problem analysis: Analysis of a software problem 2. Product description: Complete specification of the desired external behaviour of the software system to be built. Also known as functional description, functional requirements, or specifications
- 30. Human and Social Factors Requirements engineering processes are dominated by human, social and organizational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organizational goals System stakeholders may come from a range of technical and non-technical background and from different disciplines
- 31. Factors Influencing Requirements Personality and status of stakeholders The personal goals of individuals within an organization The degree of political influence of stakeholders within an organization
- 32. RE Process Support One way to minimize errors in the requirements engineering is to use process models and to use CASE tools The most mature CASE tools support well-understood activities such as programming and testing and the use of structured methods Support for requirements engineering is still limited because of the informality and the variability of the process
- 33. CASE Tools for RE Requirement browsers Traceability support system Requirement query systems Report generators Change control systems
- 34. Process Improvement Process improvement is concerned with modifying processes in order to meet some improvement objectives Improvement objectives includes: Quality improvement Schedule reduction Resource reduction
- 35. RE Process Problems Lack of stakeholders involvement Business needs not considered Lack of requirements management Lack of defined responsibilities Stakeholders communication problems Gold-plating Over-long schedules and poor quality requirements documents
- 36. Process Maturity Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them The SEIs Capability Maturity Model is a framework for assessing software process maturity in development organizations
- 38. RE Process Maturity Model
- 39. Initial RE Process Maturity Level There is no defined RE process. It suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. It is dependent on individual skills and experience Defined standards for requirements documents, policies and procedures for requirements management Defined RE process based on good practices and techniques. Active process improvement process is in place