260 likes | 416 Views
Requirements Engineering. Week 3 Requirements Engineering Processes. Dr. Eman Al- Maghary. Requirements Engineering Processes. Processes organized set of activities which transforms inputs to outputs vehicle to communicate details of human activities
E N D
Requirements Engineering Week 3 Requirements Engineering Processes Dr. Eman Al-Maghary
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
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
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
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*****
Requirements Engineering Process Output • Agrred Requirements • System specification • System models 6
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
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
Requirements Engineering Process - Coarse-grain Activity Model • Activities • Requirements elicitation • Requirements analysis and negotiation • Requirements documentation • Requirements validation
Requirements Engineering Process - Spiral Model • Different activities in requirements engineering are repeated until a decision is made to accept SRS
Requirements Engineering Process Actors • People involved in carrying out the process • Role-action diagrams show actors associated with different process activities
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
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
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)
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
Process Improvement • Objectives • Quality improvement • Schedule reduction • Resource reduction
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?
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
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
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
Requirements Engineering Process Maturity Model • Three Levels (on next slides • Level 1 - Initial • Level 2 - Repeatable • Level 3 - Defined
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
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
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”