Advanced Requirement Engineering Instructor: Dr. Nadeem Ahmad Chauhdry Dual PhD (Politecnico di Torino, Italy & University of Potsdam, Germany) HOD, CS & IT Department The University of Lahore Defence Road Campus, Lahore. Email: nadeem.ahmad@cs.uol.edu.pk https://sites.google.com/site/pctresearchgroup/

Biography: Dr. Nadeem Ahmad Ch. Dual PhD (Politecnico di Torino, Italy & University of Potsdam, Germany) HOD, CS & IT Department 15 Years Teaching and Research Experience 14 International Conference and Journal Publications Head of People Centered Technology Research Group Former Head of CS & IT department, The University of Lahore

What is Requirement Engineering? Discussion What is Requirement Engineering? Why you are here?

2018 Jobs Projection in Different Areas .

Bad Design Bad Design costs lives, money, & time.

Problem Solving .

What is a requirement? A statement of a system service or constraint Requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements.

Requirements abstraction “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The use of the term ‘engineering implies’ that systematic and repeatable techniques should be used.

How much does requirements engineering cost? About 15% of system development costs The requirement engineering cost depends on the type and size of the system being developed In some cases, the system requirements are not developed in detail; in others a formal specification may be produced.

What happens when the requirements are wrong? The system may be delivered late and costs more than originally expected The customer and end-user are not satisfied with the system. They may not use its facilities and may even decide to scrap it altogether The system may be unreliable in use, with regular system errors and crashes disrupting normal operation If the system continue in use, the cost of maintaining and developing the system are usually very high.

What is a requirements document? The formal statement of the system requirements for customer, end user and software developers. Depending on the organization, the requirement document may have different names such as The requirements definition The software requirements specification (SRS)

What are system stakeholders? Anyone affected in some way by the system and who have a direct or indirect influence on the system requirements The stakeholders include end-user of the system, customer of the system, managers and others involved in the organizational processes influenced by the system, engineers responsible for the system development and maintenance

What is the relationship between requirements and design? Requirements are mostly concerned with the problem to be solved; design is concerned with the solution to the problem That is requirements engineering is about what has to be done; design is about how it should be done In reality, requirements engineering and design are intermingle activities.

Course Literature Software Requirements by Karl E Weigers Requirements Engineering: Processes and Techniques by Gorald Kotonya and Ian Sommerville Requirements Engineering and Management for Software Development Projects by Murali Chemuturi Mastering the Requirements Process by James Robertson

Requirements Engineering Processes

What is Process? A process is an organised set of activities which transforms inputs to outputs Process descriptions encapsulate knowledge and allow it to be reused Examples of process descriptions Procedures manual for a bank Quality manual for software development

What is a requirements engineering process? The structured set of activities involved in developing system requirements Process activities include requirements elicitation, requirements analysis and negotiation, requirements specification, and requirements validation A complete process description should include what activities are carried out, the structuring or scheduling of these activities, who is responsible for each activity, the inputs and outputs to/ from the activity and

Is there an ideal requirements engineering process? Each organization modified the process according to the type of systems it develops, its organizational culture and the level of experience and ability of the people involved in requirements engineering. To define a good requirements engineering process, organizations need to involve the people who are actually part of requirement engineering.

Inputs and outputs for RE Process

RE process variability RE processes vary from one organisation to another Factors contributing to this variability include Technical maturity The technology and methods used for requirements engineering vary from one organization to another Disciplinary involvement The types of engineering and managerial disciplines involved in requirements engineering vary from one organization to another Organisational culture The culture has an important effect on all processes , as the culture varies, so does the requirements engineering process Application domain Different types of application domains have different types of requirements engineering process There is therefore no ‘ideal’ requirements engineering process

Process models A process model is a simplified description of a process presented from a particular perspective Types of process model include: Coarse-grain activity models Fine-grain activity models Role-action models

Types of process models Coarse grain activity model It shows the principal requirements engineering process activities and their (approximate) sequencing. It is constructed as a starting point for a process description with separate sections Fine grain activity model These are the more detailed models of a specific process. They may be used for understanding and improving existing processes. Role action models These models show the roles of different people involved in the process and the action which they take. These models may be helpful for process understanding and automation.

Corse grain model of the Requirements Engineering process

RE process activities Requirements elicitation Requirements discovered through consultation with stakeholders Requirements analysis and negotiation Requirements are analysed and conflicts resolved through negotiation Requirements documentation A requirements document is produced Requirements validation The requirements document is checked for consistency and completeness Requirement management Concerned with managing changes to the requirements

Actors in the RE process Actors in a process are the people involved in the execution of that process Actors are normally identified by their roles rather than individually Requirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc) as well actors interested in the solution (system designers, etc.) Role-action diagrams document which actors are involved in different activities

RAD for software prototyping

Role descriptions

Factors influencing requirements The personal goals of individuals within an organisation Each group of stakeholders have different goals. They will try to influence the requirements so that their goals are met, without necessarily taking the goals of the other stakeholders into account Personality and status of stakeholders If the end user has managerial support then their requirements will probably be accepted If the end user has an aggressive personality , the engineer s may agree to accept their requirements simply to get rid of them The degree of political influence of stakeholders within an organisation People try to influence system requirements, so that they can maintain or increase their own political influence in the organization. If a budget information system is planning in a university, both administration and academic departments are likely to propose requirements which give them more power

Process support CASE tools provide automated support for software engineering processes The most mature CASE tools support well-understood activities such as programming and testing Support for requirements engineering is still limited because of the informality and the variability of the process

CASE tools for RE Modelling tools support the development of system models which can be used to specify the system and the checking of these models for completeness and consistency. Management tools help manage a database of requirements and support the management of changes to these requirements.

Requirements management tools facilities Requirements browser So that the reader of requirements can browse the database Requirements query system so that tool user can retrieve specific requirements Traceability support system That can be used to generate traceability information Report generator Reports about the requirements such as requirements from specific stakeholders Change control system That can maintain information about requested requirements changes and links to the requirements affected by the changes

Process improvement Process improvement is concerned with modifying processes in order to meet some improvement objectives Improvement objectives Quality improvement The output produced by the process are of high quality. It means that requirements contain fewer errors, more complete or better reflect the real needs of system stakeholders Schedule reduction The output from the process are produced more quickly. This means that less time is needed to produce the final version of the requirements document Resource reduction Fewer resources such as staff time are needed to perform the process. Therefore a small team of requirements engineers can produce the final requirements document.

Planning process improvement What are the problems with current processes? Late delivery of products, budget over-runs, poor quality What are the improvement goals? To Improve quality management procedures to satisfy CMMI standard (Quality management problem) to reduce the amount of rework which is required in a process (budget over-run problem) How can process improvement be introduced to achieve these goals? This involve assessing the existing requirements engineering processes to find out the activities causing more problems and identifying changes for improvements How should process improvements be controlled and managed? Procedures to collect feedback on improvements, which may be either quantitative measurements of the process or informal comments on the improvement

RE process problems Lack of stakeholder involvement The process does not identify the real needs of all of the different stakeholders Lack of requirements management Changes to requirements may be introduced in an ad hoc manner and great effort and time is required to understand and incorporate these requirement changes Lack of defined responsibilities Some tasks may not be carried out because everyone assumes that someone else is responsible for it. Stakeholder communication problems The different stakeholders of the system fail to communicate effectively so that the resulting requirements document is not understandable by all stakeholders

Types of requirement User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

User and system requirements

Readers of different types of requirements specification

Classification of Requirements Functional Requirements Non Functional Requirements

Functional and non-functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. The word processor must include a spell checking and correction command Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services.