1. Requirement Management
Lecture 3
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

2. Requirements engineering processes
The processes used for RE vary widely depending on:
The application domain,
The people involved and
The organisation developing the requirements.
However, there are a number of generic activities common to all processes
Requirements elicitation;
Requirements analysis;
Requirements validation;
Requirements management.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

3. Processes
A process is an organized set of activities which transforms inputs to outputs
Process descriptions encapsulate knowledge and allow it to be reused
Examples of process descriptions
Instruction manual for a dishwasher
Cookery book
Procedures manual for a bank
Quality manual for software development
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

4. Process activities Requirements discovery
Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organisation
Groups related requirements and organises them into coherent clusters.
Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts.
Requirements documentation
Requirements are documented
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

5. Requirements discovery
The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.
Sources of information include:
Documentation,
System stakeholders and
The specifications of similar systems.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

6. Viewpoints
Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders.
Stakeholders may be classified under different viewpoints.
This multi-perspective analysis is important as there is no single correct way to analyse system requirements.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

7. Types of viewpoint Interactor viewpoints Indirect viewpoints
People or other systems that interact directly with the system.
In an ATM,
the customer’s and the account database are interactor VPs.
Indirect viewpoints
Stakeholders who do not use the system themselves but who influence the requirements.
management and security staff are indirect viewpoints.
Domain viewpoints
Domain characteristics and constraints that influence the requirements.
an example would be standards for inter-bank communications.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

8. Viewpoint identification
Identify viewpoints using
Providers and receivers of system services;
Systems that interact directly with the system being specified;
Regulations and standards;
Sources of business and non-functional requirements.
Engineers who have to develop and maintain the system;
Marketing and other business viewpoints.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

9. LIBSYS viewpoint hierarchy
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

10. Process improvement
Process improvement is concerned with modifying processes in order to meet some improvement objectives
Improvement objectives
Quality improvement
Schedule reduction
Resource reduction
Planning for Process improvement
What are the problems with current processes?
What are the improvement goals?
How can process improvement be introduced to achieve these goals?
How should process improvements be controlled and managed?
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

11. Process maturity
Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them.
The SEI’s Capability Maturity Model is a framework for assessing software process maturity in development organizations
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

12. Maturity levels Initial level Repeatable level Defined level
Organizations have an undisciplined process and it is left to individuals how to manage the process and which development techniques to use.
Repeatable level
Organizations have basic cost and schedule management procedures in place.
They are likely to be able to make consistent budget and schedule predictions for projects in the same application area.
Defined level
The software process for both management and engineering activities is documented, standardized and integrated into a standard software process for the organization.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

13. RE process maturity model
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST

14. Maturity levels Managed level Optimizing level
Detailed measurements of both process and product quality are collected and used to control the process.
Optimizing level
The organization has a continuous process improvement strategy, based on objective measurements, in place.
Requirement Engineering, by Asst Prof Athar Mohsin, CS Department, MCS - NUST