1. 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.

2. 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

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

4. 2018 Jobs Projection in Different Areas.

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

6. Problem Solving .

7. 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.

8. 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.”

9. 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.

10. 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.

11. 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.

12. 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)

13. 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

14. 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.

15. 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

16. Requirements Engineering Processes

17. 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

18. 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

19. 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.

20. Inputs and outputs for RE Process

21. 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

22. 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

23. 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.

24. Corse grain model of the Requirements Engineering process

25. 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

26. 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

27. RAD for software prototyping

28. Role descriptions

29. 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

30. 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

31. 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.

32. 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

33. 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.

34. 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

35. 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

36. 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.

37. User and system requirements

38. Readers of different types of requirements specification

39. Classification of Requirements
Functional Requirements
Non Functional Requirements

40. 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.