Week 3 Requirements Engineering Processes

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

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. 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. 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. Requirements Engineering Process Inputs • 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) • Stakeholder needs: Description of what 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 that apply to the system, or copy rights, data protection…**** • Domain information : General information about the application domain of the system*****

6. Requirements Engineering Process Output • Agrred Requirements • System specification • System models 6

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. 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. ERM for the RE process 9

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

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

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

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. 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. 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. 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. Process Improvement • Objectives • Quality improvement • Schedule reduction • Resource reduction

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. 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. 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. 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. Requirements Engineering Process Maturity Model • Three Levels (on next slides • Level 1 - Initial • Level 2 - Repeatable • Level 3 - Defined

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. Requirements Engineering Process Maturity Model (Cont.) • 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

25. Requirements Engineering Process Maturity Model (Cont.) • 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”