1. A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia university based on the material of "Requirements Engineering" textbook

2. If you can’t describe what you are doing as a process, you don’t know what you're doing.

3. DEVELOPING SYSTEMS Before any system can be developed it is essential to establish the need for the system. If the purpose of a system is not known, it is unclear what sort of system will be developed, and it is impossible to determine whether the system will satisfy the needs of its users If you don’t know where you are going, you are unlikely to end up there. 3

4. DEVELOPING SYSTEMS The need may be expressed in fairly vague terms initially, for example, “I would like a system that improves the efficiency of my department”. Clearly, such a “specification” is not appropriate to be used as the basis for going out to buy a system. However, it could be the basis for a study to determine exactly what the person really wants 4

5. DEVELOPING SYSTEMS 5

6. The “develop stakeholder requirements” process takes the statement of needs and produces the stakeholder requirements. Once a set of stakeholder requirements exist, it is possible to begin to think about potential solutions. Rather than jumping straight to a design, it is good practice first to determine what characteristics the system must have regardless of the final detailed design. This process is known as establishing the system requirements. 6

7. DEVELOPING SYSTEMS From the system requirements it is possible to consider alternative design architectures. A design architecture is expressed as a set of interacting components that collectively exhibit the desired properties. These properties are known as the emergent properties of the system and should exactly match the desired characteristics of the system as expressed in the system requirements. The design architecture defines the requirements for each system component in terms of their functionality and interaction obligations. 7

8. GENERIC PROCESS CONTEXT 8

9. 9

10. INPUT REQUIREMENTS AND DERIVED REQUIREMENTS Requirements derived by one process become the input requirements of another process. This leads to the idea that the generic engineer requirements process takes in input requirements and generates derived requirements. 10

11. ACCEPTANCE CRITERIA AND QUALIFICATION STRATEGY For each requirement, we should determine the criteria that will be used to establish whether or not the system that claims to implement the requirement is acceptable to the customer. It is also necessary to determine the circumstances under which the criteria will be examined. Testing is just one type of qualification strategy (others include trials and inspections). The type of qualification strategy to be used will depend on the nature of the system. For example, systems that have safety critical aspects will have to be checked much more carefully than, say, a management information system. 11

12. ACCEPTANCE CRITERIA AND QUALIFICATION STRATEGY Example of Acceptance Criteria Description: As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe. Acceptance Criteria: All mandatory fields must be completed before a customer can submit a form. Information from the form is stored in the customer orders database. Payment can be made via Master Card, or Visa credit card. The system shall accurately calculate and apply sales tax. The system shall accurately calculate and apply shipping charges. An acknowledgment email is sent to the customer submitting the form. Protection against spam is working. 12

13. ACCEPTANCE CRITERIA AND QUALIFICATION STRATEGY The qualification strategy often introduces new requirements for test equipment, the use of existing facilities and special diagnostic functions or monitor points. 13

14. GENERIC PROCESS INTRODUCTION 1. Ideal Development 14

15. GENERIC PROCESS INTRODUCTION 2. Development in the Context of Change 15

16. GENERIC PROCESS INFORMATION MODEL Information Classes input requirement derived requirement qualification strategy for input requirements qualification strategy for derived requirements change request 16

17. GENERIC PROCESS INFORMATION MODEL Information Classes 17

18. GENERIC PROCESS INFORMATION MODEL Agreement State 18

19. GENERIC PROCESS INFORMATION MODEL Qualification State 19

20. GENERIC PROCESS INFORMATION MODEL Satisfaction State 20

21. GENERIC PROCESS DETAILS Agreement Process The agreement process is always a concurrent activity between a supplier at one level and the customer at the level above. Before any derivation work can start, it is necessary to assess the input requirements to determine whether they form an adequate basis for the development to proceed. The assessment must answer the questions: - Is the requirement complete? - Is the requirement clear? - Is the requirement implementable? - Is the qualification plan clear and acceptable? 21

22. GENERIC PROCESS DETAILS Agreement Process Potential answers to these questions lead naturally to the following reasons why a requirement may be rejected: Missing information – e.g. placeholders such as “TBA” (to be agreed), “TBC” (to be completed) or “TBD” (to be decided) may be used. Lack of clarity – ambiguity, contradiction, confusion, etc. Impossible to implement – not known Unacceptable qualification plan. 22

23. GENERIC PROCESS DETAILS Analyze and Model This analysis part of this process is concerned with understanding the nature and scope of the input requirements to assess the likely risks involved in satisfying them. Analysis work can range from feasibility studies to explore potential implementation options to the building of prototypes of some vital or high-risk components. The other uses of models in this process are to understand the nature of and provide a structure for the derived requirements. 23

24. GENERIC PROCESS DETAILS Analyze and Model The most common models for understanding and structuring stakeholder requirements are use cases or user scenarios. These help to understand how people will use the intended system. The most common models for structuring solutions in the solution domain are design architectures. These identify elements of the solution and indicate how they interact. 24

25. GENERIC PROCESS DETAILS Analyze and Model 25

26. GENERIC PROCESS DETAILS Analyze and Model Can the analyze and model process be undertaken in parallel with the agree process?? 26

27. Derive Requirements and Qualification Strategy Deriving Requirements In addition to establishing the component requirements, it is also necessary to establish the satisfaction relationship between the input requirements and the derived requirements. This relationship indicates which input requirements are satisfied by which derived requirements and can be used to establish that: - all input requirements are satisfied. - all derived requirements are necessary (i.e. they directly or indirectly satisfy one or more input requirements). 27

28. Derive Requirements and Qualification Strategy Deriving the Qualification Strategy The qualification strategy consists of a set of qualification actions, each one a particular kind of trial, test or inspection. There may be several qualification actions defined against each requirement. Each qualification action should take into account the following aspects: - the kind of action that would be appropriate for the requirement; - the stage at which each action could take place – the earlier the better; - any special equipment that would be needed for the action; - what would constitute a successful outcome. 28