Requirements Engineering: The RE Process

1. Requirements Engineering: The RE Process UFCE4S-10-3 Lecture Two Stewart Green

2. Lecture Structure • The RE process: inputs and outputs • Elaborating the RE process • Customer-supplier relationships determine the RE process • Requirements elicitation • Requirements analysis and negotiation Requirements Engineering UFCE4S-10-3 Lecture Two

3. References • Requirements Engineering, Sommerville, I., and Kotonya, G., John Wiley,1997 • Requirements Engineering, Macaulay, L.,Springer, 1996 Requirements Engineering UFCE4S-10-3 Lecture Two

4. The RE Process: Inputs and Outputs Requirements Engineering UFCE4S-10-3 Lecture Two

5. Describing the Inputs and Outputs Requirements Engineering UFCE4S-10-3 Lecture Two

6. Example Inputs • Existing system information • “The Library Information system shall poll the existing barcode reader every 2 seconds” • Stakeholder needs • “The system should provide a help facility which will explain the facilities of the system to new users” • Organisational standards • The system shall run on a Sun server running the Solaris 2.0 OS” • Regulations • The system shall be able to print all the personal information held on it for a library user” (Data Protection Act) • Domain information • Books are uniquely identified by an ISBN which is a 10 digit identifier” Requirements Engineering UFCE4S-10-3 Lecture Two

7. Stakeholders (1) • Who are they? • Anyone with a stake in creating or using a new computer-based system • Hands-on users • Their managers • The system administrator • The client (system owner) • The requirements engineer • Designers • Programmers Requirements Engineering UFCE4S-10-3 Lecture Two

8. Stakeholders (2) • Stakeholders’ backgrounds vary: they may: • come from different departments • be trained in different disciplines • have different (possibly conflicting) goals • be unwilling to consider other stakeholders’ goals • have more or less political influence over requirements decisions Requirements Engineering UFCE4S-10-3 Lecture Two

9. Elaborating the RE Process Requirements Engineering UFCE4S-10-3 Lecture Two

10. Customer-Supplier Relationship Determines the Requirements Engineering Process • I have just introduced a generic process • There is, however, a wide range of actual RE processes being enacted currently in a wide range of organisations • Macaulay claims that the particular customer-supplier relationship being used on a project determines the particular RE process that is best to use • She identifies 7 customer-supplier relationship types: Requirements Engineering UFCE4S-10-3 Lecture Two

11. Different Kinds of Customer-Supplier Relationship • A customer issues an invitation to tender to a number of potential suppliers • A specific supplier is asked to respond to a specific customer request • A supplier wishes to make a generic product which will meet the needs of a (large) number of customers • A supplier has a generic product which needs to be customised to meet a specific customer need • The business (customer) and the IT function (supplier) are completely separate, and operate as individual businesses • The business (customer) is functionally separate from the IT function, but each IT sub-function has clearly defined responsibilities for aspects of the business • The IT function is integrated within the business function, with each business unit having it sown IT staff Requirements Engineering UFCE4S-10-3 Lecture Two

12. Scenario Two: responding to a Specific Customer Request • A typical example of this scenario: • A supplier (software house) is asked by an international vendor of paper packaging to develop a system which will help to reduce stock levels to a minimum. Requirements Engineering UFCE4S-10-3 Lecture Two

13. Requirements Elicitation • The “investigate problem” activity in the previous process model may be viewed as another way of describing requirements elicitation, the first stage in the generic RE process • Requirements elicitation is about discovering what requirements a computer-based system should be based upon • This doesn’t involve just asking stakeholders what they WANT. It requires a careful analysis of: • The organisation • The application domain • Organisation processes where the system will be used • To determine what the stakeholders NEED. Requirements Engineering UFCE4S-10-3 Lecture Two

14. Knowledge Uncovered by Requirements Elicitation • Application knowledge • E.g. knowledge about airport systems • Problem context knowledge • E.g knowledge about Heathrow Airport • Problem knowledge • E.g. knowledge about Heathrow’s baggage-handling system • Stakeholders needs and work processes to be supported Requirements Engineering UFCE4S-10-3 Lecture Two

15. Elicitation process • Establish objectives • Business goals • Problem to be solved • System constraints • Understand background • Organisational structure • Application domain • Existing systems • Organise knowledge • Stakeholder identification • Goal prioritisation • Domain knowledge filtering • Collect requirements • Stakeholder requirements • Domain requirements • Organisational requirements Requirements Engineering UFCE4S-10-3 Lecture Two

16. Requirements Analysis and Negotiation • Purpose: • To establish an agreed set of requirements which are complete, consistent, and unambiguous. Such a set can be used as the basis for systems development. • Negotiation: • Stakeholders often disagree over requirements. Therefore they need to negotiate to try to reach agreement. Requirements Engineering UFCE4S-10-3 Lecture Two

17. Requirements Analysis and Negotiation Process Requirements Engineering UFCE4S-10-3 Lecture Two