CIE 203 Software Engineering Lecture 4 : Requirements Engineering I

1. CIE 203 Software Engineering Lecture 4: Requirements Engineering I Mohammad El-Ramly, PhD 2016 http://www.acadox.com/join/4DMHHB http://www.acadox.com/class/37407

2. What we covered last lecture … • Software Chronic Crisis • Cost of Software Errors • Ariane 5 • Therac 25  LAS • How Projects Fail  Vasa • Characteristics of Software Systems

3. Lecture Outline • 4.1 Domain analysis • 4.2 • 4.3 Defining the problem and the scope • 4.4 What is a requirement? • 4.5 Types of requirements • 4.6 Use Cases • These are the numbers of sections in Chap 4.

4. Book

5. What we covered last lecture … • Software Chronic Crisis • Cost of Software Errors • Ariane 5 • Therac 25  LAS • How Projects Fail  Vasa • Characteristics of Software Systems

6. 4.1 Domain Analysis** • The process by which a software engineer learns about the domain to better understand the problem: • The domain is the general field of business or technology in which the clients will use the software • A domain expert is a person who has a deep knowledge of the domain • Benefits of performing domain analysis: • Faster development • Better system • Anticipation of extensions ** Topics are numbered according to Chap 4 sections (Reading 4)

7. Domain Analysis document** A. Introduction B. Glossary C. General knowledge about the domain D. Customers and users E. The environment F. Tasks and procedures currently performed G. Competing software H. Similarities to other domains ** See a sample Domain Analysis document in Chap 4, OOSE by Tim Lethbridge

8. 4.3 Defining the Problem and the Scope • A problem can be expressed as: • A difficulty the users or customers are facing, • Or as an opportunity that will result in some benefit such as improved productivity or sales. • The solution to the problem normally will entail developing software • A good problem statement is short and concise.

9. Defining the Scope • Narrow the scope by defining a more precise problem • List all the things you might imagine the system doing • Exclude some of these things if too broad • Determine high-level goals if too narrow • Example: A university registration system

10. Example …………

11. Example ………… • In every organization, there are many events that must be publicized to its members. Currently paper notices or email are often used for this purpose. The goal of the proposed software is to centralize all the information concerning events. To each event will be associated a title, a description, a date and a location. • Using this application, a user will be able to obtain the list of coming events in a period of interest. It will also be possible to visualize a calendar on which the events will occur. • Authorized users will be able to add new events. Each event will therefore be associated with a user that will have the right to modify and delete this event. Some super users will have the right to create new authorized users and to delete any event. Finally, outdated events should be automatically removed from the database.

12. Example ………… A. Introduction B. Glossary C. General knowledge about the domain D. Customers and users E. The environment F. Tasks and procedures currently performed

13. Introduction • This document describes background information that has been gathered about events in organizations and how they are handled. This information is to be used to guide the development of software to automate the process of informing people of events.

14. Glossary • -Open event: An event that starts at a precise instant but with no predetermined duration. Meetings and celebrations often fall into this category. • - Fixed event: An event that starts at a precise instant and with a predetermined duration. Course lectures and seminars are examples of this kind of event. • - Day events: An event associated with a particular day without precise start and end times. Auditing visit, etc. • - Recurrent event: An event that occurs repeatedly on some regular schedule (for example daily, weekly or monthly). • - Composite event: An event composed of several sub-events. For example, a training activity can be composed of a registration period (fixed event), a series of seminars (recurrent events), and a final evening celebration (open event).

15. Glossary • - Open event: An event that starts at a precise instant but with no predetermined duration. Meetings and celebrations often fall into this category. • - Fixed event: An event that starts at a precise instant and with a predetermined duration. Course lectures and seminars are examples of this kind of event. • - Day events: An event associated with a particular day without precise start and end times. Auditing visit, etc. • - Recurrent event: An event that occurs repeatedly on some regular schedule (for example daily, weekly or monthly). • - Composite event: An event composed of several sub-events. For example, a training activity can be composed of a registration period (fixed event), a series of seminars (recurrent events), and a final evening celebration (open event).

16. General knowledge about the domain • • Events are of different types (see glossary). Events have a date and maybe start and end times and maybe a location (things like an audit visit may not have a specific location) • • Events have an owner or organizer and a contact person. They also have title, description and details. • • It is possible to add categories to events so that groups of interest can be created. This way, events can target more precisely people that might be interested. • • Outdated events are removed. • • Events may be seen by anyone within the organization, but there is control over posting events.`

17. Customers and users • Potential clients • Medium or large organizations whose staff access computers or mobile devices frequently. • Potential users • Staff interested in knowing about events with basic computer /mobile skills • Event organizers, authorized to publicize them • System admin who manages the system • IT Staff who install and configure the system

18. Tasks and procedures currently performed • Posting Events • The organizer of the event compiles information concerning an event and after approval, posts it so members of the organization can see it. •  Events are posted on a physical bulletin board at a place that most users pass each day. Events are also sent by email. • Important emails are sent by paper leaflets to all employees. • There is no central listing of available events. • Information about an event is not presented in a standard fashion.

19. Tasks and procedures currently performed • Learning about Events • At irregular intervals, employees check the list of upcoming events and seek more information about ones of interests. •  Or they read the incoming email or leaflets. • Outdating Events • The person of the bulletin board checks it regularly to remove past events.

21. مثال: تحليل نطاق / تحليل الأعمال • نقوم بعمل تحليل نطاق أو تحليل أعمال لنظام المرتبات لأعضاء هيئة التدريس بجامعة القاهرة.

22. أ. مقدمة Introduction • هذه الوثيقة تصف نظام حساب أجور هيئة التدريس الحالى و المصطلحات الفنية المتداولة فى هذا المجال و القواعد المتبعة فى الحساب و بيئة العمل المحيطة به و مستخدميه. 0.1

23. ب. المصطلحات Glossary • المجرد: هو الراتب الأساسى المنصوص عليه فى القانون. • علاوة: إضافة سنوية للراتب. • التأمينات: ما يدفع لهيئة التأمينات مقابل التأمين و المعاش و سنقسم لحصة العامل و حصة الدولةو نسبتها ...................... • ضريبة كسب العمل: ضريبة متدرجة على الدخل و شرائحها ................... 0.3

24. ب. المصطلحات Glossary • بدل جودة : ........................ • بدل جامعة: ........................ • بدل بحوث: ........................ • الدمغة النسبية: ........................ 0.3

25. ج. معلومات عامة General Knowledge • يعرف كل عضو هيئة تدريس باسمه و رقمه القومى و درجته الوظيفية. • عند التعيين يحسب راتبه كما فى الجزء ”و“ و يزيد سنويا بحسب العلاوات المضافة. • يحسب الراتب بحساب الفارق بين إجمالى الاستحقاقات و إجمالى الاستقطاعات. • و عند الترقية ينتقل من درجة إلى درجة أعلى فيحسب راتبه علىالدرجة الجديدة.

26. د. العملاء و المستخدمون Clients & Users • العميل لهذا النظام هو كلية الحاسبات و المعلومات بجامعة القاهرة و المستخدمون له هم المحاسبون فى إدارة الحسابات قسم الاستحقاقات. 0.1

27. هـ. بيئة العمل Environment • يعمل هذا النظام على شبكة داخلية داخل قسم الاستحقاقات و لكل محاسب بالقسم جهاز خاص به و النظام غير متصل بأى أجهزة أو نظم خارجية. 0.1

28. و. الإجراءات و المهام الحالية Current Tasks and Procedures • المعيد: • المجرد 48 جنيه • تضاف علاوات 87 إلى 2010 و قيمتها 285% • إلخ ........... 0.3

30. 4.4 What is a Requirement? • It is a statement describing • 1) an aspect of what the proposed system must do, • or 2) a constraint on the system’s development. • In either case it must contribute in some way towards adequately solving the customer’s problem; • the set of requirements as a whole represents a negotiated agreement among the stakeholders. • A collection of requirements is a requirements document.

31. Requirements Engineering Process • Elicitation- Collectfeatures of the system • Negotiation- Negotiatefeatures to include, time and price • Documentation - Write down SRS formally and sign • Validation - Review and ensurecorrectness • Management - Maintain and update

32. 4.5 Types of Requirements • Functional requirements • Describe what the system should do • Non-Functional Requirements • Software Quality requirements • Constraints on the design to meet specified levels of quality • Platform requirements • Constraints on the environment and technology of the system • Process requirements • Constraints on the project plan and development methods

33. Functional Requirements • What inputs the system should accept • What outputs the system should produce • What data the system should store that other systems might use • What computations the system should perform • The timingandsynchronization of the above

34. Functional Requirements • An individual requirement often covers more than one of the above categories. • For example, the requirements for a word processor might say, ‘when the user selects “word count”, the system displays a dialog box listing the number of characters, words, sentences, lines, paragraphs, pages, and words per sentence in the current document.’ • This requirement clearly describes input, output and computation.

35. Software Quality Requirementts • All must be verifiable • Examples: Constraints on • Availability • Telecommunications systems have very rigorous availability criteria: • for example, you might specify that such a system must not be down more than 10 minutes in its 20-year life-span. • This is also called ‘6-nines’ availability, since it is equivalent to saying that the system must be up 99.9999% of the time. • Recovery from failure (think a failing banking transaction) • Allowances for maintainability and enhancement • Allowances for reusability

36. Software Quality Requirementts • All must be verifiable • Examples: Constraints on • Response time • Throughput • Resource usage • Reliability • The average amount of time between failures or • The probability of a failure in a given period.

37. 4.5 Types of Requirements • Functional requirements • Describe what the system should do • Non-Functional Requirements • Software Quality requirements • Constraints on the design to meet specified levels of quality • Platform requirements • Constraints on the environment and technology of the system • Process requirements • Constraints on the project plan and development methods

38. IEEE 830-1998 Standard – Section 1 of SRS • Title • Table of Contents • 1. Introduction • 1.1 Purpose • 1.2 Scope • 1.3 Definitions. Acronyms, and Abbreviations • 1.4 References • 1.5 Overview • 2. Overall Description • 3. Specific Requirements • Appendices • Index • Describe purpose of this SRS • Describe intended audience • Identify the software product • Enumerate what the system will and will not do • Describe user classes and benefits for each • Define the vocabulary of the SRS (may reference appendix) • List all referenced documents including sources(e.g., Domain Analysisand Problem Statement; Experts in the field) • Describe the content of the rest of the SRS • Describe how the SRS is organized

39. States assumptions about availability of certainresources that, if not satisfied, will alter systemrequirements and/or effect the design. IEEE 830-1998 Standard – Section 2 of SRS • Present the business case and operational concept of the system • Describe how the proposed system fits into the business context • Describe external interfaces: system, user, hardware, software • Title • Table of Contents • 1. Introduction • 2. Overall Description • 2.1 Product Perspective • 2.2 Product Functions • 2.3 User Characteristics • 2.4 Constraints • 2.5 Assumptions and Dependencies • 3. Specific Requirements • 4. Appendices • 5. Index • Summarize the major functional capabilities • Include the Use Case Diagram (identify actors and use cases) • Include Data Flow Diagram if appropriate • Describe and justify technical skills and capabilities of each user class • Describe other constraints that will limit developer’s options; e.g., regulatory policies; target platform, database, network software and protocols, development standards requirements

40. States assumptions about availability of certainresources that, if not satisfied, will alter systemrequirements and/or effect the design. IEEE 830-1998 Standard – Section 2 of SRS • Describe in details all interfaces that the system have to interact with • 3. Specific Requirements • External interfaces • 3.1.1 User interfaces • 3.1.2 Hardware interfaces • 3.1.3 Software interfaces • 3.1.4 Communication interfaces • 3.2 Functional requirements • 3.3 Performance requirements • 3.4 Design constraints • 3.5 Quality requirements • 3.6 Other requirements • Describe in great details all the functions that the system should do. Detail enough for designers, developers and testers to do their job. • Other types of requirements

41. Characteristics of Good Requirements • Unambiguous • Complete • Detailed enough to enable designers to design a system to satisfy those requirements and testers to verify the requirements • Verifiable • Consistent • Modifiable • Traceable

44. 4.6 Use-Cases: describing how the user will use the system • A use caseis a typical sequence of actions that a user performs in order to complete a given task • The objective of use case analysisis to model the system from the point of view of... • how users interact with this system • when trying to achieve their objectives It is one of the key activities in requirements analysis • Ause case modelconsists of • a set of use cases • an optional description or diagram indicating how they are related

45. Use cases • A use case should • Cover the full sequence of stepsfrom the beginning of a task until the end. • Describe the user’s interactionwith the system ... • Not the computations the system performs. • Be written so as to be as independent as possible from any particular user interface design. • Only include actions in which the actor interacts with the computer. • Not actions a user does manually nor internal actions of the system

46. Use case diagrams for registration system Register in Course Add Course Offering Registrar Actor Add Course Enter Grade for Course Student Actor Find information about course Professor Actor

47. Use Cases at a Glance

48. How to describe a single use case • A. Name: Give a short, descriptive name to the use case. • B. Actors: List the actors who can perform this use case. • C. Goals: Explain what the actor or actors are trying to achieve. • D. Preconditions: State of the system before the use case. • E. Summary: Give a short informal description. • F. Related use cases. • G. Steps: Describe each step using a 2-column format (Actor actions and System responses). • H. Postconditions: State of the system following completion. • A and G are the most important

49. Questions for Payroll Domain Analysis • ما أنواع العمالة ؟ (موظف ، مؤقت ، هيئة تدريس، ....) • كيف يحسب راتب كل منهم ؟ • ما هى القوانين و اللوائح المنظمة لذلك ؟ • ما هى التأمينات و أين تذهب و كيف تحسب ؟ • ما هى الضرائب و كيف تحسب ؟ • ما هى الاستقطاعات الأخرى ؟ (صندوق الزمالة .... ) • ما هى الإضافات الأخرى للمرتب ؟ ما أنواعها و كيف تحسب ؟ • ما هى المكافآت أو المزايا المالية الأخرى التى يحصل عليها العاملون و كيف تحسب ؟ • كيف يتم صرف الرواتب للعاملين ؟ •                    

50. What did we cover today … • Domain Analysis • Scope • Types of Requirements • Functional Requirements • Non-functional Requirements • Introduction to Use Cases