1. 1 Week 3 Requirements Engineering Processes Dr. Eman Al-Maghary Requirements Engineering

2. 2 Requirements Engineering Processes Processes organized set of activities which transforms inputs to outputs vehicle to communicate details of human activities activities in a process may be enacted differently depending on the background of the people involved and the circumstances

3. 3 Design Processes (Cont.) Processes which involve Creativity Interactions between a wide range of different people Engineering judgment Background knowledge and experience Inputs to the processes are not usually precisely defined Many possible outputs may be defined to satisfy the inputs

4. 4 Design Processes (Cont.) Examples Process of writing a book Process of organizing a conference Process of designing a processor chip Requirements engineering process is a design process

5. 5 Requirements Engineering Process Inputs 1. Existing system information: Information about the functionality of the systems to be replaced or other systems which interact with the system being specified (* see example) 2. Stakeholder needs: Description of what stakeholders need from the system to support their work.** 3. Organizational standards: Standards used in an organization regarding system development, practice, quality management, etc..*** 4. Regulations: external regulations such as health and safety regulations that apply to the system, or copy rights, data protection…**** 5. Domain information : General information about the application domain of the system*****

6. 6 Requirements Engineering Process Output 1. Agrred Requirements 2. System specification 3. System models 6

7. 7 Requirements Engineering Process Variability RE processes range from very unstructured processes to systematic processes Factors influencing variability Technical maturity: The technologies and methods vary from one organization to another. Disciplinary involvement: Types of engineers and managerial involved in RE from one organization to another. Organizational culture: as the culture varies so is the RE process Application domain: Different types of applications require different types of RE processes

8. 8 Process Models A process model is a simplified description of a process Types of models Coarse-grain activity models Sequencing mode Software life cycle model Fine-grain activity models: more detailed process models Role-action models: Show the role of different people involved in the process and the actions they take Entity-relation models: Show process inputs, outputs and intermediate results

9. 9 ERM for the RE process 9

10. 10 Requirements Engineering Process - Coarse- grain Activity Model Activities Requirements elicitation Requirements analysis and negotiation Requirements documentation Requirements validation

11. 11 Requirements Engineering Process - Spiral Model Different activities in requirements engineering are repeated until a decision is made to accept SRS

12. 12 Requirements Engineering Process Actors People involved in carrying out the process Role-action diagrams show actors associated with different process activities

13. 13 Human, Social and Organizational Factors - Stakeholders May or may not have technical backgrounds Have other jobs and may not give priority to requirements engineering Usually have different goals - may not take into account goals of other stakeholders May try to influence requirements to maintain or increase political influence

14. 14 Human, Social and Organizational Factors – Stakeholders (Cont.) Stakeholders software engineers: Responsible for system development system end-users: Responsible for using the system after delivery managers of system end-users Project manager : responsible of planning and estimating the prototype project external regulators who check to make sure system meets legal requirements domain experts: Responsible for providing information about the application domain and problems specific to that domain which is to be resolved

15. 15 Requirements Engineering Process Support Computer-Aided Software Engineering (CASE) tools support software design configuration management testing CASE tools developed around the more understood portions of the lifecycle (not requirements engineering)

16. 16 Requirements Engineering Process Support (Cont.) Modeling and validation tools used to specify the system SADT, IDEF, PSL/PSA, etc. Management tools manage a database of requirements RTM, CMVS

17. 17 Process Improvement Objectives Quality improvement Schedule reduction Resource reduction

18. 18 Process Improvement (Cont.) Planning questions What are the problems with current process? What are the improvement goals? How can we introduce process improvements to achieve these goals? How should improvements be controlled and managed?

19. 19 Process Improvement (Cont.) Common requirements engineering process problems Lack of stakeholder involvement Business needs are not considered Lack of requirements management Lack of defined responsibilities Stakeholder communication problems

20. 20 Process Maturity The extent to which an organization has defined its processes actively controls these processes provides systematic human and computer-based support for them An organization with defined processes is more mature than one with informal processes

21. 21 Process Maturity (Cont.) Software Engineering Institute (SEI) Capability Maturity Model (CMM) five levels of maturity Initial - undisciplined (star personality) Repeatable - project oriented control Defined - organization oriented control Managed - measurements of both process and product quality Optimizing - continuous process improvement strategy

22. 22 Requirements Engineering Process Maturity Model Three Levels (on next slides Level 1 - Initial Level 2 - Repeatable Level 3 - Defined

23. 23 Requirements Engineering Process Maturity Model (Cont.) Level 1 - Initial no defined process requirements engineering process, it is left to individuals requirements problems exist excessive requirements volatility unsatisfied stakeholders large rework costs poor quality requirements documents over budget, missed schedule

24. 24 Level 2 - Repeatable Organizations have basic cost and schedule management procedure predictions in the same application area defined standards for requirements documents defined policies/procedures for requirements management some advanced requirements engineering tools more likely to have quality documents on time Requirements Engineering Process Maturity Model (Cont.)

25. 25 Level 3 - Defined Defined requirements engineering process model based on good practices and techniques Active process improvement program in place Make objective assessments of the value of new methods and techniques “ Have software process for both management and engineering activities documented, standardized and integrated into software process for the organization” Requirements Engineering Process Maturity Model (Cont.)