Introduction to Requirements Engineering

1. Introduction toRequirements Engineering 28.10.2001 Marjo Kauppinen Qure Project Software Business and Engineering Institute (SoberIT) Helsinki University of Technology (HUT)

2. Agenda • Basics of Requirements Engineering (RE) • Requirements • User Requirements Document • Requirements Definition Process • Summary

3. Basics of Requirements Engineering (1/2) specification & design & coding & testing acceptance testing requirements definition requirements management

4. Basics of Requirements Engineering (2/2) Requirements engineering (RE) means that requirements for a system are defined, managed and tested systematically. Requirements engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system. The term engineering implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant etc. [Som97]

5. What are Requirements?(1/4) user and customer requirements for SYSTEM technical requirements for SYSTEM User/customer requirements documents Technical specifications Project plan requirements for PROJECT

6. What are Requirements?(2/4) User/Customer Requirements Document Technical Specifications Requirements Definition Design Specification

7. What are Requirements?(3/4) user/customer requirements business requirements technical requirements requirements definition process specification process How? Why? What?

8. What are Requirements?(4/4) • User: The person who operates directly with the system [IEE93]. • Customer:The person who pays for the system and usually (but not necessarily) decides the requirements [IEE93] . • Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s) [Abb86]. • Constraints and properties are also called non-functional requirements or quality requirements.

9. What are User Requirements?(1/7) Why are user requirements important? • If a system doesn’t satisfy users’ requirements, it is useless. • In the worst case, the system is not taken into use at all. • The most successful systems exceed user’s expectations.

10. What are User Requirements?(2/7) user group A user group B • User requirements tell WHAT the system shall do from user’s point of view. • We are interested in only those functions and properties visible to the users. • The system is seen as a black box.

11. What are User Requirements?(3/7) • Functional requirement – A requirement that specifies a function or service that a system must be capable of performing from user’s point of view. • Non-functional requirement – A requirement that describes the property of the system including performance, reliability and usability.

12. What are User Requirements?(4/7)

13. What are User Requirements?(5/7)

14. What are User Requirements?(6/7) Characteristics of a good user requirement: • One requirement per one sentence. • Clear structure: • Functional requirement: The user shall do something. • Property: The minimum font size shall be 14.

15. What are User Requirements?(7/7) Characteristics of a good user requirement: • Correct: A requirement contributes to a real user need. • Understandable:A reader can easily understand the meaning of the requirement. • Unambiguous: A requirement has only one possible interpretation. • Verifiable: A requirement can be tested.

16. User Requirements Document (1/18) • is official statements of user requirements • says what the system should do without specifying how.

17. User Requirements Document (2/18) Contents • Introduction: Short description of the system and goals/benefits of the system • Glossary: Short descriptions of the special terms used in the document • Overview of the system • Users • Functional requirements • Non-functional requirements: Performance, reliability, usability etc. • Constraints: Standards, software and hardware constraints required by customer

18. User Requirements Document (3/18)Contents: Overview of the system • Main functions (services) of the system • Use case diagrams are a good way to describe the main functions and the users of the system. • Basic principle: The system is seen as a black box. We are interested in only those functions visible to the users.

19. User Requirements Document (4/18) Contents: Overview of the systemExample of Use Case Diagram*: Handling Emergency Alarm Call Konect System Making Emergency Alarm Call passenger service center operator Dispatching Job Helping Passenger out of Elevator Reporting serviceman * Kone Research Center has given a permission to present this use case diagram as an example.

20. User Requirements Document (5/18) Contents: Overview of the systemChecklist for Use Case Diagrams • Are the actor names consistent and unambiguous? • Is it clear which use cases are inside and which outside the system? • Are the use cases written from the user’s point of view not from the system’s point of view? • Does the use case diagram have too many use cases (not more than 8)? • Is the use case diagram clear and easy to read (not a spider’s net)?

21. What Is the Contents of User Requirements Document?(6/18) Users:

22. User Requirements Document (7/18)Contents: Functional Requirements • Use cases are a good way to document functional requirements. • Use cases originally developed by Jacobson and Rumbaugh [Rum94]. • [Rum94]: J. Rumbaugh, “Getting Started: Using Use Cases to Capture Requirements”, JOOP, September 1994.

23. User Requirements Document(8/18)Contents: Functional RequirementsTemplate for Use Case Description • Use Case: Name of the use case • Summary: Short description of the use case • Actors: List of users and other systems that interacts directly with a system • Preconditions: Description of “start situation” and goals of the users • Basic sequence: Descriptions of the main actions of the user • Exceptions: Descriptions of special situations • Postconditions: Description of “end situation”

24. User Requirements Document (9/18)Contents: Functional RequirementsExample for Use Case Description • Use Case: Making Emergency Alarm Call • Preconditions:An elevator has stopped between floors and there is a passenger in the elevator. The passenger wants to get out of the elevator safely and as fast as possible. • Actors:Passenger and service center operator • Summary:An entrapped passenger pushes the emergency alarm button in order to get help. A service center operator receives the emergency alarm call and informs the passenger that a serviceman will come and let the passenger out of the elevator. * Kone Research Center has given a permission to present this use case as an example.

25. User Requirements Document (10/18)Contents: Functional RequirementsExample for Use Case Description • Basic sequence: • Step 1: The passenger presses the emergency alarm button. • Step 2: The service center operator gets a visible notification about the emergency alarm call on the screen with an optional audio signal. • Step 3: The service center operator accepts the emergency alarm call to be handled. • Step 4: The system opens voice connection between the service center operator and the passenger. • Step 5: The system indicates the service center operator and the passenger that voice connection is open. • Step 6: The system guides the service center operator what information to ask from the passenger. • Step 7: The service center operator informs the system that the emergency alarm call is correct.

26. User Requirements Document (11/18)Contents: Functional RequirementsExample for Use Case Description Exceptions: • Step 1: If an entrapped passenger does not push the alarm button long enough (less than 3 seconds), the system alerts the passenger with voice announcement. • Step 7: If the passenger has pressed the emergency alarm button by accident, the service center operator informs the system that the emergency alarm call is false. The system resets the emergency alarm call. Postconditions:The entrapped passenger knows that service center operator will contact a serviceman who will be helping the passenger out of the elevator safely and as soon as possible.

27. User Requirements Document (12/18)Contents: Functional RequirementsChecklist for Use Case Descriptions • Is the use case description too long (not more than 15 actions)? • Is the use case description logical from user’s point of view? • Does the use case describe the functions from the users’ point of view? • Is the use case described using user’s language not computer slang? • Does the use case contain no design and implementation information?

28. User Requirements Document (13/18)Characteristics

29. User Requirements Document (14/18)Characteristics

30. User Requirements Document (15/18)Purpose • to describe what a system does from the user’s point of view • to get feedback from users and customers • to guide design • to guide testing • to guide project planning and follow-up • to provide material for user manuals • to provide material for marketing and selling

31. User Requirements Document (16/18)Stakeholders users designers User Requirements Document customers testers marketing and sales personnel user manual writers project manager

32. User Requirements Document (17/18)Objectives

33. User Requirements Document (18/18)Objectives Quality of Software Product Quality of Software Project Quality of Requirements Document Quality of Requirements Engineering Processes

34. Requirements Definition Process (1/14) specification & design & coding & testing acceptance testing requirements definition requirements management

35. Requirements Definition Process (2/14) user requirements document business requirements requirements definition process requirements elicitation requirements analysis requirements representation requirements validation

36. Requirements Definition Process (3/14) • Elicitation is the process of discovering the requirements for a system • through consultation with users, customers and other stakeholders • from system documents, domain knowledge and market studies • through “brain storming”.

37. Requirements Definition Process (4/14) • Realities of requirements elicitation • Stakeholders do not often know what they want. • Users and customers use a language of their own. • Different stakeholders have different viewpoints. • The business environment is dynamic.

38. Requirements Definition Process (5/14) Requirements elicitation practices: • Identify and consult all stakeholders. • Record requirements sources. • Record requirements rationale. • Prototype poorly understood requirements. • Define users’ processes.

39. Requirements Definition Process (6/14) • Analysis is the process of establishing an agreed set of requirements and discovering • missing requirements • requirements conflicts • ambiguous requirements • overlapping requirements • unrealistic requirements.

40. Requirements Definition Process (7/14) • Realities of requirements analysis • Conflicting requirements require negotiations. • Proper analysis requires hard thinking, time and effort.

41. Requirements Definition Process (8/14) • Requirements analysis practices • Use checklists for requirements analysis. • Plan conflict resolution. • Prioritise requirements. • Assess requirements risks.

42. Requirements Definition Process (9/14) • Representation is the process of describing individual requirements in a • concise, • understandable, and • unambiguous way.

43. Requirements Definition Process (10/14) • Realities of requirements representation • Requirements are read more often than they are written. • Readers of requirements come from diverse backgrounds. • Writing clearly and concisely is not easy.

44. Requirements Definition Process (11/14) • Requirements representation practices • Use standard templates for describing requirements. • Use simple and consistent language. • Use diagrams. • Specify requirements quantitatively.

45. Requirements Definition Process (12/14) • Validation is the process of checking the requirements for • omissions, • conflicts, and • ambiguities and • for ensuring that the requirements follow quality standards.

46. Requirements Definition Process (13/14) • Realities of requirements validation • The main problem of requirements validation is that there is no existing document which can be a basis for the validation. • If you do not allow sufficient time for validation, you will almost certainly end up with requirements problems.

47. Requirements Definition Process (14/14) • Requirements validation practices • Organise formal requirements inspections. • Use multi-disciplinary teams to review requirements. • Use validation checklists. • Write a draft user manual. • Propose requirements test cases.

48. Summary (1/2) Requirements Engineering Design, coding and system testing Acceptance testing User requirements definition User requirements management Useful and Successful Products

49. Summary (2/2) • There is huge potential for improvement in RE. • RE is a big challenge and an opportunity for organisations and individuals.

50. References • [Abb86] R. Abbott, An Integrated Approach to Software Development, John Wiley, New York, 1986. • [Hsi93] P. Hsia, A. Davis and D. Kung, “Status Report: Requirements engineering,” IEEE Software, pp. 75-79, November 1993 • [IEE94] IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1993, the Institute of Electrical and Electronics Engineers, New York, 1994 • [Kot98] G. Kotonya and I. Sommerville, Requirements Engineering - Processes and Techniques, John Wiley & Sons, New York, 1998. • [Saw99] P. Sawyer, I. Sommerville and S. Villier, “Capturing the Benefits of Requirements Engineering,” IEEE Software, pp. 78-85, March/April 1999. • [Som97] I. Sommerville and P. Sawyer, Requirements Engineering - A Good Practice Guide, John Wiley & Sons, New York, 1997.