https://itse171556810.wordpress/

1. تحليل متطلبات البرمجياتSoftware Requirements AnalysisITSE 311Chapter 5د.حنانالداقيزh.dagez@uot.edu.ly

2. https://itse171556810.wordpress.com/

3. Form-based specifications • Definition of the function or entity. • Description of inputs and where they come from. • Description of outputs and where they go to. • Indication of other entities required. • Pre and post conditions (if appropriate). • The side effects (if any).

4. PDL-based requirements definition • Requirements may be defined operationally using a language like a programming language but with more flexibility of expression • Most appropriate in two situations • Where an operation is specified as a sequence of actions and the order is important • When hardware and software interfaces have to be specified

5. PDL disadvantages • PDL may not be sufficiently expressive to express the system functionality in an understandable way • Representation is only understandable to people with programming language knowledge • The requirement may be taken as a design specification rather than a model to help understand the system

6. The Characteristics of a good user requirements Good requirements are the key to both successful system development and good quality testing. A good set of user requirements are needed for any project to be successful. good requirement cannot be misunderstood

7. Think of these characteristics as a series of filters. A good requirement will pass through all these filters. • What Are the Characteristics of Good User Requirements? • A user requirement is good if it is: 1. Complete 2. Clear and brief 3. Unambiguous 4. Consistent 5. Verifiable(testable) 6. Feasible (realistic ) 7. Necessary

8. Is this UR Complete? • Bad example: • UR3: On loss of power, the battery backup must support normal operations. • For how long? • Good example: • UR3: On loss of power, the battery backup must support normal operations for 20 minutes.

9. What Makes a UR Clear? • A clear and brief requirement … • must consist of a single requirement, • should be no more than 30-50 words in length, • must be easily read and understood by nontechnical people, • use simple sentence.

10. Should not contain unnecessary information. They should be stated clearly and simply. • REQ1 Sometimes the user will enter Airport Code, which the system will understand, but sometimes the closest city may replace it, so the user does not need to know what the airport code is, and it will still be understood by the system. • This sentence may be replaced by a simpler one: • REQ1 The system shall identify the airport based on either an Airport Code or a City Name. • Must avoid subjective or open-ended terms.

11. Is this UR Clear & Concise? • Good example: • UR2: When the user accesses any screen, it must appear on the monitor within 2 seconds. • Bad example: • UR2: All screens must appear on the monitor quickly. • How long is quickly? Requirements must have enough detail that developers can design a system that does what the users want.

12. Must be understood with only one meaning. This means they must be unambiguous and specific. What Makes a UR unambiguous? • should be only one way to interpret the requirement. Sometimes ambiguity is introduced by undefined abbreviations: • REQ1The system shall be implemented using ASP. • Does ASP mean Active Server Pages or Application Service Provider? • To fix this, we can mention a full name and provide an abbreviations in parentheses: REQ1 The system shall be implemented using Active Server Pages (ASP).

13. Here’s another example: • REQ1 The system shall not accept passwords longer than 15 characters. • It is not clear what the system is supposed to do: • The system shall not let the user enter more than 15 characters. • The system shall truncate the entered string to 15 characters. • The system shall display an error message if the user enters more than 15 characters. • The corrected requirement reflects the clarification: • REQ1 The system shall not accept passwords longer than 15 characters. If the user enters more than 15 characters while choosing the password, an error message shall ask the user to correct it.

14. What Makes a UR Consistent? • A consistent requirement … • The key point about consistency is that no requirement contradicts what another says. • Paths though the system must not process the same input differently. • uses the same terminology throughout the requirement specification.

15. REQ1 For outbound and inbound flights, the user shall be able to compare flight prices from other, nearby airports. REQ2 The outbound and return flights shall be sorted by the smallest number of stops. To describe the same concept, in the first requirement the term “inbound flights” is used, and in the second requirement the term “return flights” is used. The usage should be consistent. In this case the conflict cannot be resolved by adding conditions, so one of the requirements should be changed or removed.

16. Should not be any conflicts between the requirements in the requirement specification. • conflicts occur when, in the same situation, different behavior is expected: • REQ1 Dates shall be displayed in the mm/dd/yyyy format. • REQ2 Dates shall be displayed in the dd/mm/yyyy format.

17. What Makes a UR Verifiable (testable)? • A verifiable(testable) requirement … • is stated in such a way that it can be tested by:- inspection, - analysis, or - test. • As you review a requirement, think about how you will prove that the product meets it. Determine the specific criteria for product acceptance, which will ensure verifiable requirements. • To be testable, requirements should be clear, and unambiguous. • Some words can make a requirement untestable : - Some adjectives:, safe, accurate, effective,, expandable, flexible, user-friendly, - Some adverbs: quickly, safely.

18. URVerifiable? • Bad example: • UR1: The system must be user friendly. • How should we measure user friendliness? • Good example: • UR1: The user interface shall be menu driven. It shall provide dialog boxes, help screens, radio buttons, dropdown list boxes, and spin buttons for user inputs.

19. What Makes a UR Feasible? • A feasible or Realistic requirement … • Should be achievable within existing constraints such as time, money, and available resources. • can be met using existing technology, • can be achieved within the budget, • can be met within the schedule, • will be used by the end users. • must be helpful to build the system.

20. What Makes a UR Necessary? • A necessary requirement … • is one that must be present to meet system objectives, and • is absolutely critical for the operation of the system, • leads to a deficiency in the system if it is removed. • A requirement is unnecessary if: - None of the stakeholders needs the requirement. - Removing the requirement will not affect the system.

21. What Makes a UR Free of Implementation Details? • A requirement that is free of implementation details … • defines what functions are provided by the system,does NOT specify how a function can or should be implemented. • allows the system developer to decide what technology is best suited to achieve the function. REQ1 Content information shall be stored in a text file. How the information is stored , this should be the designer’s decision.

22. Is this UR Free of Implementation Details? • Bad example: • After 3 unsuccessful attempts to log on, a Java Script routine must run and lock the user out of the system. • Specifying a JavaScript routine concerns how the requirement will be implemented. • Good example: • After 3 unsuccessful attempts to log on, the user must be locked out of the system.

23. Analyzing the Problem The 5 Steps in Problem Analysis

24. Problem Analysis • Definition:the process of understanding the real-world problems and users’needs and proposing solutions to those needs. • Goal:to gain a better understanding of the problem being solved before development begins.

25. Five steps of problem analysis • Step 1:Gain Problem Definition Agreement • Step 2: Understand the root causes • Step 3: Identify Stakeholders and Users • Step 4: Define Solution System Boundary • Step 5: Identify Problem Constraints

26. Gain Problem Definition Agreement • Write a simple and clear definition of the problem description. • Establish an order of importance for all features of the system. • Come to an agreement with all stakeholders • Resolve conflicts by negotiation.

27. Problem Statement Format

29. Step 2 : Understand the root causes of the problem • A problem can have several causes: المشكلة لها اكثر من سبب • Some might be eliminated by non-software solutions الحل ليس من الضروري ان يكون باستخدام البرمجيات • Some might need contradictory solutions يمكن اقتراح حل عكسي لها • More than one solution might be needed يمكن ان يكون اكثر من حل • Sometimes, a problem hides other more important problemsبعض المشاكل تخبئ ورأها مشاكل اكبر • Addressing the wrong problem leads to failure التركيز على المشكلة الخطأ ينتج عنه الفشل • This part of the analysis requires input from extremely knowledgeable, insightful and experienced persons. هذا الجزء من التحليل يحتاج لمعلومات من ذوي الخبرة والدراية

30. Fishbone diagram of root cause

31. Fishbone diagram of root cause

33. Step 3 : Identify stakeholders and users • Stakeholder: anyone who could be affected by the new system or has input to provide in the implementation of the new system. • Complex problems always involve the input of different stakeholders that have different viewpoints on the problem. • Users: will use the system • Managers: will pay for the system, or will manage the users • IT people: will install, manage and maintain the system • External regulators: will impose constraints on the system operation. • System developers: will implement a solution to the problem and maintain it. • Forgetting one of these might lead to major rework later on, or even to project failure

34. Step 4 : Define the system boundary • Any software system has to interact with its environment • System boundary describes an envelope in which the solution is contained. • System is divided as: • The system itself and its functionalities • The things (outside the system) that interacts with the system • Actors: • Supply, use, or modify information in the system • Someone or something, outside the system, that interacts with the system • Later on, this early information will direct how the system interfaces will be defined.

35. Step 5 : Identify the constraints to be imposed on the solution • Constraint : a restriction on the degree of freedom we have in providing a solution • They are as important as requirements : they direct what the system should not do, or what the system should not be

36. Potential System Constraintsقيود النظام المحتملة • Economical اقتصادية • Is there any licensing issues? هل يوجد رخصة • Are there costs of goods sold? هل هناك تكاليف للبضائع المباعة • Political سياسية • Interdepartmental problems or issues مشاكل او قضايا مشتركة بين الادارات • Technical تقنية • Choice of technologies اختيار التقنية • Any non-permitted technologies . أي التقنيات غير مسموح بها • Can we use purchased packages هل يمكن استخدام الحزم التي تم شراؤه • System النظام • What operating system and environments must we support? • Should we build on the current system? هل يمكن البناء على النظام الحالى

37. Potential System Constraintsقيود النظام المحتملة • Environmental بيئة العمل • Legalقانوني • Security requirements متطلبات امنية • Is there any other restricting standards?هل هناك معاير اخري لموانع • Schedule and Resourcesالجدول والموارد • Are we restricted on exiting resources ( hardware, dev. Teams, etc.) • Can we expand resources? • Is the schedule defined?

38. Any Question ? Thanks 