IT607 – Software Engineering Requirements Engineering

1. IT607 – Software EngineeringRequirements Engineering Kavi Arya M. Mohan

2. Objectives • Introduce the concepts User and System Requirements • Describe functional and non-functional requirements • Explain how to document software requirements

3. Railway reservation system • Who are the users of this system ? Financial Gateway (bank) Reservation System Traveler IVR system Travel Agent System administrator Reservation Clerk

4. Quiz 0 Assume, you are analyzing an existing railway reservation system for devising enhancements. Answer the following questions with reference to any railway reservation system you are familiar with. Please write your assumptions clearly. i) Who are the various kinds of users of the system? What are their expectations of the system? ii) Will a system administrator who manages the system be a user? Justify your answer ? iii) List as many functional requirements of the system as possible ? iv) Write down five non-functional requirements of the system ?

5. Quiz 0 (contd.) v) Write down any additional requirements you would like to add to the system? (mention clearly whether they are functional or non-functional requirements) vi) Suppose, the system under study has no facility for making reservations using SMS. The customer wants this feature to be implemented. Is this requirement functional? If no, can you think of a way of implementing this non-functional requirement in terms of any existing functional requirements ? vii) What process model would you adopt in building the system? Explain why and give two other models you would not use, explaining why.

6. Users expectations : Traveler • What are the Travelers expectations of the System ? • Expects reservation, cancellation, adjustment, and enquiry facilities. • Above facilities offered online and telephonic are highly appreciated

7. Users expectations : Travel Agent • Travel Agents expectations of the System • Bulk reservation, cancellation, adjustment facilities. • Enquiry facilities. • Above facilities offered online and telephonic are highly appreciated • Wants to be notified of important events like introduction of new / seasonal trains.

8. Users expectations : Reservation Clerk • Reservation Clerks expectations of the System • Reservation, cancellation, adjustment, and enquiry facilities. • Season ticket issuing facility • Concession handling facility like handling concessions given to senior citizens, Army personnel, students etc. • Report generation facility. Ex: for generating daily sales reports etc.

9. Users expectations : System administrator • System administrator’s expectations of the System • A data backup facility • An error recovery facility • Adding, removing new trains to the system • Modifying train schedules and fares

10. Users expectations : Financial Gateway • Financial gateway’s expectations of the System • Communication with the system should be safe to safeguard the integrity of the payment data. • System should be using EDI or any other standard data interchange formats that the financial gateway understands. • Note : Most of the external systems expectations are interoperability requirements.

11. Product requirements • The reservation system product requirements • High availability ( less MTBF ) • High throughput: handle more number of transactions per second • Reliability • Scalability • Security etc.

12. External requirements • External requirements include: • Interoperability requirements. Ex: Syntax and semantics of the messages to be used to communicate with the external systems. • Legislative requirements. Ex: Personal information of a client should not be revealed to a third party without his consent.

13. Overall system requirements • User Requirements • Product Requirements • External Requirements

14. Requirements Engineering • The process of establishing services that the customer requires from a system and the constraints under which it operates and is developed. • The requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. • Running example : Indian Railway Reservation System.

15. Users • The stakeholders of the system, who interact with the system to accomplish their tasks. • A user may be any entity that is interested in the services offered by the system. • Eg : Traveler, Travel Agent, Reservation Clerk, Financial Gateway, System Administrator etc.

16. User Requirements • Different users have different expectations of the system behavior, and all these combined together constitute the overall system requirements • Ex :- • Traveler expects an easy to use online system for booking tickets. • A reservation clerk expects a good user interface and response time for serving the customers efficiently. • A payment gateway expects the communication with the system be very secure, to ensure the integrity of the payment data.

17. Types of Requirements • Functional Requirements ( Application requirements ) • Eg: Cancellation, Reservation, enquiry etc. • Non-Functional Requirements ( Quality Requirements ) • Eg: • Reservation at counter should be closed by 8 p.m. every day. • Online reservations should be allowed till 11 p.m. etc.,

18. Functional VS Non-functional requirements • Functional Requirements • Describes an interaction between the system and its environment • Functional requirements change less frequently • Non-functional Requirements • Describes a restriction or constraint that limit our choices for constructing a solution • Most of the changing requirements fall in to this category • Ex:- Some time later, Indian railway may decide to provide online reservation facility round the clock.

19. Classification of Non-functional requirements • Product Requirements: defines product characteristics • Ex: Execution speed, Reliability, Security, Scalability etc. • Organizational Requirements: requirements which are a consequence of organizational policies and procedures. • Ex: Operational time in railway reservation time • External Requirements: requirements which arise from factors external to the system. • Ex: interoperability requirements, legislative requirements etc.

20. Characteristics of Requirements • Are they correct ? • Are they Consistent ? • Are they Complete ? • Are they Realistic ? • Are they verifiable ? • Are they traceable ?

21. Characteristics of Requirements. . • Realistic Requirements : Are the requirements technically, financially, and operationally feasible ? • Verifiable requirements : Should be able to verify whether a requirement is implemented correctly or not • Traceable requirements : traceability is the ability to describe and follow the life of a requirement throughout the software development life cycle. This is a very useful feature used in change management.

22. Requirement Elicitation techniques • Traditional Techniques • Group elicitation techniques • Prototyping

23. Requirement Elicitation techniques • Traditional Techniques • Use of questionnaires and surveys • Interviewing stakeholders • Analyzing existing systems and processes

24. Requirement Elicitation techniques • Group elicitation techniques • A small group is formed, including some of the stakeholders also, to elicit requirements. This group brainstorms to define the requirements for the new system. • This requirement gathering technique is very effective as the end users take active part in requirement definition. • Group size should be reasonably small. • Group composition: at least one representative from every group of end-users should be present in the group. This eliminates any bias in defining requirements.

25. Requirement Elicitation techniques • Prototyping • Used when there is a great deal of uncertainty about the requirements, or where early feedback from stakeholders is needed. • A prototype is: • Built rapidly from initial requirements • Analyzed to refine the requirements • New prototype is developed from these new requirements. • Process continues until requirements defined satisfactorily.

26. Why document requirements ? • It will help clarify what you think • It is necessary to communicate with the users • It is necessary to communicate with the development team • It could form a basis for a contractual relationship

27. How to write it down ? • Natural Language • Structured Natural Language • Graphical Notations • ex. Use cases • Mathematical Specifications • ex. finite state machines

28. Problems with natural language • Lack of Clarity : precision is difficult without making the document difficult to read. • Requirements Confusion: functional and non-functional requirements tend to be mixed-up. • Requirements Amalgamation: several different requirements may be expressed together. • Ambiguity: the readers and writers of the requirement must interpret the same words in the same way. Natural language is ambiguous so this is very difficult. • Lack of Modularization: natural language structures are inadequate to structure system requirements.

29. Structured Natural Language • A predefined template is used for documenting the requirements. All the requirements are written in a standard way. • Each template defines a unique function (reqmt) or entity. • Describes inputs and where they come from. • Describes outputs and where they go to. • Indicates other entities involved. • Pre and Post conditions (if appropriate). • The side effects (if any) of the function.

30. Structured Natural Language

31. Structured Natural Language contd…

32. Structured Natural Language

33. Analysis Models • Use cases, Sequence Diagrams, Class Diagrams, Object Diagrams, Collaboration Diagrams etc. • to be discussed in the next class